I’ve inherited a project that’s using a legacy file format to store its data, I have access to the data going into that file format, and the resulting file, but I don’t have access to the template, and I need to recreate it.
Whats the best way to go about reverse engineering the binary file? How do I figure out what language/encryption is used, or do I even need to? Once I do, whats the best program (free, preferred) to get the information out? This is on a Windows system, but I run an OpenSUSE linux box that I’m not opposed to using for help with the issue.
The comment from about a year ago is the core of what I’d do, which is to reverse engineer the format behaviorally. Treat the legacy program as a black box. I’m assuming you can still run the legacy system somehow. The very first thing is to turn the whole legacy program into a subroutine that can be called somehow. That may mean scripting, running it inside a VM, simulated and/or mocked devices, etc.; whatever works. Ask a separate question for your particular situation if you don’t know how to do this already. The goal, though, is to automate the use of the legacy software so that you can run probe and test suites against it.
You mention encryption may be used. Deal with this first. Strongs ciphers have what’s called the avalanche property: changing a single bit of the input changes 50% of the bits of the output, in what’s tantamount to a pseudorandom bit-flip. You want to use the avalanche property to (1) test for the existence of encryption, and (2) find out the encryption structure. For example, if a database encrypted a row-at-a-time, then changing one bit of the stored row anywhere would change average-half of the bits of the encrypted row. Clearly, if changing one bit alters the whole file, you have a different kind of problem than if only a few bits change (e.g. checksums, etc.). If you have encryption in any form, you might need to run the legacy under a debugger and figure out the algorithm that way; this might not be worth it.
As you can see, all this means lots of invocations of the legacy to probe its behavior. You don’t want to do this by hand; see first paragraph. To address another concern, it’s unlikely you’re going to find off-the-shelf code to extract the data; it’s a custom code job. So now that your automation is working, you want to set up unit testing, calling the legacy code to see what should be expected.
This isn’t a quick process, nor easy. Always compare the anticipated cost of succeeding at this with the cost of acquiring the data in some other way, including paying for manual data entry.