This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=16051

athompson6735, posted Thu Nov 04, 2021 1:56 am (67360)

---

I'm looking for curious people interested in helping me reverse a file format for my 3d printer at work (EOS M100 LPBF metal printer). I highly suspect the files are encrypted with a baked-in key in the software, so the task starts off with however one would go about finding that (key and algo). I have basically 0 practical experience with hooking up a debugger to a program or sifting through DLL's. Older software from the same company used .ini - like files for the same purpose, so I'm hoping once the data is decrypted / deobfuscated it will be a simple format. I can provide files, as well as the program itself, but actually running the program is dependent on a usb token I obviously can't send.

I just started in earnest this afternoon, and forgot to copy any files to take home with me, but here's what I found so far:
- there's a small header and footer without much info (file size, and possibly version?)(33 byte header 16 byte footer)
- crafted input: files created to be exactly the same (exact same edits within software then saved) are exactly the same, so suspected encryption key is static (no nonce, no timestamp included)
- crafted input: files with a change to a single parameter in the editor result in entirely different data (though exactly the same size)(hence why I'm convinced the data section is encrypted in some way).
- data size seems to be multiple 16 bytes (probably more. I didn't think to check greatest common denominator between many files before I left work.)
- The software included a 3rd party dll for zip files that I briefly looked up to also have encryption tools, so best case scenario we find a simple call into that library with a static password (fingers crossed ).

I'm a bit new to zenhax, but you can also @ me on discord: Aaron#8011
I'd be super grateful for any help!

aluigi, posted Wed Dec 01, 2021 1:52 pm (67782)

---

Maybe the key is derived from the 16 byte footer which may act as MD5 hash too.
The 16 bytes padding may be related to AES.
I hardly doubt you would be so lucky to successfully decrypt the file using the last 16 bytes as key and AES 128 ECB as algorithm
Anyway just my quick toughts (I can't help further).

athompson6735, posted Thu Dec 02, 2021 7:43 pm (67805)

---

I've started going through the header and footer, and changing one byte at a time to see if the file is still open-able by the software, and if not, how it fails / errors. Some bytes can be changed with no impact, but will be changed back when re-saving the file. Some bytes show that behavior for some values but not all. Others just result in various error messages resulting in an un-openable file, or causing the process to exit. I've tried various combinations of the header and footer as the key / IV with CBC and ECB (not all permutations I guess....) with no success yet. I have to assume there's something like options / protocol version information somewhere in there. The only concrete data I really have right now is that the data size is contained within the footer (bytes 4-7).

I'm willing to dip my toes in trying to learn how attach a debugger to the software as it's running, but IDK where to start with that. Anyone got some good tutorials / etc for disassembling / debugging software you didn't write yourself? I would imagine doing that I could drop a breakpoint on any call to write to a file, then try to back up from there and see if any calls are made to an encryption library, and see if I can find where it gets the key.