I'm trying to reverse engineer an application that uses SQL server but somehow hides the database files inside its own proprietary file format. What I'm aiming to do is to write my own app that can extract the data from the application files so I can work on it using my own preferred tools.

I can use WinDbg to intercept the SQL but I can't see how the application connects its datafile with the SQL server. Can anyone suggest where I might look?


  • Does this help maybe? technet.microsoft.com/en-us/library/ms139941.aspx
    – Devolus
    Nov 27, 2013 at 8:12
  • I'm not familiar with tracing T-SQL statements with WinDbg, are you just setting breakpoints at the function calls in which the Sql native provider are about to send a query over the TDS to the server? Dec 7, 2013 at 19:38

3 Answers 3


In the unlikely event that the file in question is just an mdf with a weird name, you can look at it with OrcaMDF by Mark S. Rasmussen.


Run Sysinternals Process Monitor and look for operation on that file, by any process. Something other than sqlserver.exe might be reading it. Once you see whats reading the file, look at the stacktrace leading to the file io calls in process monitor. Attach to that process that is reading the files with WinDbg and set the appropriate breakpoints to continue reverse engineering.


MS SQL DBA here... "Hides the database files in it's own proprietary format" sounds a little off.

SQL Server can use anything Windows can use as a datasource. So you can have SQL Server making queries against a plain text file joined against an excel spreadsheet, joined against data is mysql, or sqlite. This is one of the strengths of SQL Server, it can wire in almost anything.

SQL Server also has MANY options for encryption of the underlying files.

My suspicion is that SQL Server is either A) connecting to a well known file type that it supports as a linked server / linked data source which is something you didn't realize it can connect to, or B) using a regular SQL Server file but using the encryption options to ensure that the data is secure at rest.

I would tend toward the latter B). If you don't want people to be able to snag the database file and dump the data, SQL Server encryption will handle that easily. No need to create a special file format. A SQL Server developer would know that and go that route first.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.