Reversing LZ91 from Commander Keen
lodsb.com
lodsb.com
From his homepage:
> "I wrote LZEXE in 1989 and 1990 when I was 17."
Incredible.
Modernizations are especially tricky. Modern compilers can do all sort of weird magic, sometimes combining two or more lines of code into one instruction. Old school compilers don't optimize much which is part of why performance-critical parts of game engines were written in Assembler for a long time.
Not to mention that some stuff you can do in Assembler has no equivalent in higher-level code (e.g. dealing with raw stack frames), and even Assembler to byte code is nowhere near 1:1 reversible.
IDA Pro and Ghidra can identify functions and generate the equivalent C code. I know that this is not the original code, but it does help a bit when you are trying to get an idea of what a large function doing.
I've used Ghidra to reverse-engineer a game's serialization format[0] and, even though the C-ish result was marginally better than manually tracking registers across the disassembly, it was far from understandable.
A great deal of the work was cleaning up the resulting C into something that a human would've written instead of the garbage ASM-with-C-syntax that Ghidra produced.
That is nowhere near what OP was suggesting (although useful nonetheless).
Only thing where Ghidra lacks any form of knowledge of is how to deal with the FS register that is used for SEH on win32... it just marks it as in_FS_offset with no way to tell it that it can replace FS:[0xXX] with appropriate TIB access macros.
the reason i posted this isn't because there's a lack of LZEXE unpackers around, but because learning to reverse is hard and i wanted to share an example of the step by step process of what reversing looks like. it's very tedious and slow. functions like these are places where a lot of reversers are going to give up and look elsewhere, so i wanted to show an example of how to break it apart piece by piece instead of getting lost or giving up