How to identify a control that a 3rd party app used?

Question

I have been tasked with pulling out information (which appears to be just a RTF document) for a client displayed in a 3rd party's software so it can be imported to our software (The client is switching software vendors to us and we are trying to convert their records over to us).

The main issue is the file they are storing the record's data in is some form of malformed zip file. However once I got the zip file opened the .enc file was no format I (nor TrID) recognized. I do not know if the unzipping worked and this is a unknown format, or the attempt at repairing the file caused it to decompress incorrectly but it did not throw any errors after doing it.

What would be the process of attempting to see if the control they are using is one from a common library I could buy so I could just provide the same data-source then parse out the information I need from the control?

I do know the main bulk of the program was written using PowerBuilder 12. And from Sybase's site they claim that PowerBuilder is .NET based but trying to open the exe with ILSpy says there is no managed assembly available inside the exe. However I have never used PowerBuilder and the exe is signed by sybase, not the 3rd party vendor, so I may need to try and find a library the sybase exe is loading and handing off to.

So now that the easy solution (ILSpy) is off the table what would be the next step in identifying what they are using to render that document (or at least I need to figure out how to find out where to look with ILSpy)?

Answer 1

At the risk of being Captain Obvious, doesn't the .ENC extension imply that the file has been "ENCrypted"? (At least, that's one of the potential interpretations that I've seen used.) That would explain the lack of discernible file format. To be more certain, since you can see the plain text through the application, I'd search for a key word through the decompressed data; if it's not there, since it's already been compressed with a ZIP algorithm (no point trying to compress twice.. at least no point from a compression point of view), then it's likely encrypted as well.

If that's the case, then you'll have to:

• Identify the method(s) used (the data could have been encrypted with multiple passes with one or more algorithms),
• Identify the keys used,
• Decrypt,
• Then start working on interpreting the raw data format.

If you had just the encrypted data and it had been properly done, this task should be impossible (without taking centuries). However, there's no guarantee that it's been done correctly, and you have the benefit of being able to observe the executable and test with it. With the right combination of experts, it could be done. (You did say "infinite budget", didn't you? grin)

One final note, for which I'm infinitely less qualified to make. If this is encryption, and it could be construed as copy-protection of the data, then this task could be a legally risky one, depending on the laws in your jurisdiction. Make sure you get qualified counsel on this; don't trust your PHBs to do it for you. (An earned cynicism.)

Good luck,

Terry.

Answer 2

My first move would be to capture the app actions via Sysinternals Process Monitor, and see what files/locations/keys are used.

http://technet.microsoft.com/en-us/sysinternals/bb896645