hckrnws

I don't know anything about reverse engineering, but I have wanted to reverse engineer/decompile the Disney Animation Studio [1] for DOS for years.

I found the software at a thrift store in 2009, when I was eighteen, and I was immediately impressed. This was actually very intuitive, easy-to-use animation software that was very powerful, years before FutureSplash/Flash was released.

There's not a ton of info available on the internet now, but I have been trying to remedy that a bit [2] by uploading the manual. I reached out to Disney to ask if I could potentially buy and release the source code off of them, and they politely told me "no". I reached out to the creators in the credits on LinkedIn to see if there there was any way I could look at the code or if they could at least answer some questions, and they never got back to me.

I think the only way we're going to get the source code to The Animation Studio will be if I learn how to use Ghidra (or something similar) and decompile it myself.

[1] https://en.wikipedia.org/wiki/The_Animation_Studio

[2] https://archive.org/details/disney_beginner_guide_2/disney_b...

It isn't that hard. I'm currently reverse engineering a old flight simulator game called A-10 Cuba. I had to teach myself X86 Assembly, and understand basic calling convention. Then C++ vtables, struct alignment and struct layout. How-ever you do need this basic level understanding of the core fundamental to help you along when the tools you use IDA, Ghidra that turn the assembly code back into C pseudo code.

So there is a big hurdle to get over in the initial stages but you soon find out that a lot higher code structure/scaffold isn't wiped out by the compiler. For example, the generated assembly code very closely mirrors the C/C++ function boundaries. This enables you to infer the over-all original code structure/layout basically from the call chain, and then you can manually step through and figure out what the original programmer was trying to achieve - abet the order of execution does get messed up by the compiler but it isn't that bad.

In my project with A-10 Cuba, I was successful in reverse engineering its file format, the over-all module layout, engine and rendering engine during my three weeks break. I still have some time to work out the AI logic, and mission design but one builds on another. What do I mean one builds on another? Well when you first start you have no types, not structs. So the first days you think you're making absolutly no progress because you're trying to calculate pointer offsets and structs layouts in IDA. I highly recommend Google Gemini or Claude code to do this heavy lifting because you can get away with a lot by asking it (for this IDA Pseudocode, infer what the struct layout is and tell me what it is doing?).

The first stage of getting those first struct layout is painstaking, then you soon can branch off one strut, or struct pointer to another. This feeds back like a feed-back loop - because programmers are lazy. And you soon have a large part of the struct/code-flow layout figured out.

You then take the structs/code-flow, and pesudo code and then do a re-write in a modern C/C++ compiler until you have a working version.

It would likely be enormously useful in this to have a development wiki behind the games that devs and people that played the games may know the engines, file formats, save file formats, compilers, Langs, etc.

Old devs of the games could enlighten the game preservation community anonymously.

Game dev was a frontier and hardware pushing activity even in the directx era. The magic shift code for ...quake??? Was just the tip of the iceberg.

When I started with the gaming industry (Operation Flashpoint), I was coming in near the end of fixed point arithmetic where floating point units where becoming more common as part of the PII or PI era. It was around mid-1990, I'm actually in my early 40's now. I knew a little bit of floating point units but never really dived into the area - also at the time I wasn't really mathematically minded and we really didn't have access to the internet - Australia.

A-10 Cuba! came out around 1996, and only now am I getting to know its internal engine. For example, it utilizes a signed Q15.16 fixed-point representation for its X and Z axes. For instance, a raw value of 98,304 (0x00018000) decodes to 1.5 units - where a unit is defined as 6607.92 feet - which translates to 9,911.88 feet in the game world. Then to top it off, it uses a different coordinate scaling convention for its up axis. For example the up-axis resolution is 1/10th of a foot so a raw value of 10,000 is actually 1,000 feet. Then there are other discrete exponent scaling factors which the game applies to maintain numerical precision and accuracy.

I had a great time learning all this well reverse engineering the game, and also come to learn even today how common it is for chips not to come with FPU unit, and how common it is that those chips actually perform fixed point arithmetic.

I played A-10 Cuba a ton on an old Pentium 3. Are you doing this in a repo somewhere?

The plan is to put everything into a repo on github, this includes documentation on the file format, and also the rewrite of the original code in modern C++ and DirectX or Vulkan. I don't see much point in reverse engineering the old rendering engine - I can do it but I've got everything I need right now that I can just rewrite the game inside the browser.

Awesome. Good luck and I hope to see it.

Crimsonland (2003) is a top-down shooter that shipped as a stripped DirectX 8 binary with zero symbols. I decompiled it with Ghidra, validated behavior with WinDbg and Frida, and rewrote it from scratch in Python/Raylib — 46,800 lines matching the original behavior faithfully. The write-up covers static and runtime analysis, reverse engineering custom asset formats, and the full rewrite process. Code is on GitHub and it's playable now via uvx crimsonland@latest

Very fun use of an agentic loop :). Do you have any info/data about how many tokens this ended up consuming in that time?

Wow! What a blast from the past. I remember 13yo spending day after day on this game despite being an avid crpg player those days.

Going to give this a spin after work. Thanks for the work and the writeup!

.....python? Why a slow scripting lang?

I've been thinking about this topic and am glad to see it come up: AI is going to be a huge boon for digital preservation & restoration projects like this. I realized this while building this project (a map explorer for Tribes 2): https://exogen.github.io/t2-mapper/

Old games like this have a small (and shrinking) audience of people who care about them. With Tribes 2, for example, there are only ~50 people who actively play on a regular basis. A subset of those people are programmers, and a subset of those have the time & energy to put into a project like t2-mapper, assuming they're even interested. I got a basic version working, but then Claude Code helped decode and convert obsolete Dynamix/Torque3D file formats (improving existing Blender addons that were incomplete), got TorqueScript running in the browser, wrote shaders, and generally helped figure out what the original C++ code was doing.

In the past, you'd need the stars to perfectly align for stuff like this to happen: a passionate super-fan with the time, resources, knowledge, and persistence to see it through. Now, you mostly just need the persistence (and maybe a couple hundred bucks for tokens). I foresee people with niche interests (but not necessarily a programmer's skillset) being able to extend the lifetime (and maybe audience) of their obscure or obsolete software.

Wow, this whole thread has been a blast from the past. But this tribes mapper is beaming me back to my childhood. Seeing the actual siege base layouts, wow. I can still see myself as a little kid, not fully understanding or being good at the shooting part of tribes. I just stayed in base, repairing the generators. Sometimes enemies would run in, i would hide, and shoot from a distance and call for help. Them some heavyweight, powerarmoered up, armed to the teeth teammate would come down from the skies with his jetpack, carrying crazy armaments like heavy spinfusors, plasma cannons, artillery. The queiet generator complex would soon erupt in a burst of violence, this iron hulk would clear out the intruders, thank me for the heads up and leave. Then i would get back to the repairs! Now my friends, that kind of emergent gameplay, is hard to come by!

Nowadays you’d get whined at, “repairing the base isn’t meta, you are throwing, this is going to screw up my matchmaking rank.”

This is great. I'd love to do something similar for Ground Control (2000, https://en.wikipedia.org/wiki/Ground_Control_(video_game)).

Do you have a writeup of how you did it? Both (regular) tooling (radare2? rizin? IDA? ...) and how the LLM did (or did not) use it?

In the little spare time I have, I've been able to reverse engineer the "compressed" file format (ended up being basically a XOR'ed zlib-compressed TAR-like archive), but not much else. I have not used LLMs to help me.

Bumped into your project a while back - pretty impressive. I was a little disappointed it seemed to just convert the resources rather than use the original runtime formats (since there are a features that don't directly translate to gltf), but for a viewer it's perfectly reasonable. Are you planning on supporting tribes 1 maps at all? Theres still quite a surprising interest in reverse engineering and extending the life of torque games. I'm hoping on publicly releasing a refresh of the original torque codebase this year which improves support for modern platforms including wasm. It's amazingly easy these days to reverse engineer stuff and revive old codebases!

It would be possible to have it decode the .dts and .dif formats on demand - that was my original plan - just much less efficient for users, as the .glb files are about 1/5 of the file size on average. (I also assume glTF loading/rendering has had a lot more optimization work put into it than what I'd be able to accomplish.) For these reasons it seemed more productive to have it work on the Blender addons as a starting point rather than JavaScript/TypeScript parsers for the original formats. I still ship the original assets alongside the .glb files (meaning they have URLs just aren't loaded) in case I want to switch it someday.

Some of the custom features you may be referring to I implemented as custom properties in the glTF output - like surface flags. "Outside Visible" is one example, it's a flag baked into each .dif surface that determines whether rays can reach it from the outside, so the engine knows whether to apply the map's directional sunlight, or just ambient and light map lighting. So, even though it technically could try to render with modern PBR, dynamic lighting/shadows and all that, it instead renders as close to the original as possible using the same (or similar) techniques. Comparing screenshots with actual Tribes 2 renders is often indistinguishable unless you really know what to look for!

10tons tends to make smaller scale games and you feel it sometimes but I've had a great time with quite a few of their other shooters too. You used to be able to get this bundle for cheap from fanatical sometimes, not sure if that is still the case. They are best known in the modern era for Tesla vs Lovecraft which doesn't show up in this bundle. https://store.steampowered.com/bundle/428/10tons_Shooters/

There have been a few attempts to make open source versions of Crimsonland and I had a good time with Violetland https://github.com/ooxi/violetland

I can second this! The game was influential enough to cause multiple people being involved in recreations

I'm a big fan of the old Macintosh game Bolo [0]

There used to be a Linux version but apparently it hasn't been updated to be added to or even compiled on modern Linux kernels and distros.

Someone I know tried to resurrect it a few years back but now I'm wondering if couldn't use OpenCode etc to get it up and running again.

(I did find a recent-ish clone [1] so may start with that)

0 - https://en.wikipedia.org/wiki/Bolo_(1987_video_game)

1 - https://github.com/stephank/orona

If you ever do, I’d like to try it out! I don’t game much, but I played Bolo a bit once and enjoyed it.

I'd be curious to see if there were any discoveries of any cut features left on the cutting room floor still present in the code [0] (aside from the demo teaser code mentioned still being present). I always find software archaelogy fascinating, as we get scraps of unused content or code, and can only guess as to the decisions made that led to it being scrapped, or why certain custom file formats were used, or code was structured a certain way.

[0] I am aware that such a wiki exists exactly for this purpose.

As an active reverse engineer, I'm really curious how you used agetic AI for this! Did you just have them going through the code and labeling stuff? Or were they also responsible for writing the reimplementation? This overview is super interesting, I would love to see details about the pipeline itself.

There are many ghidra plugin, like GhidrAssist, you can use to connect to a LLM. They will automatically put a name on each function and variable. It is far from perfect but it is way faster than doing it by hand in my experience.

get someone to demo the 1980s software MacNosy. You might be surprised.

Bravo, that’s a seriously impressive undertaking, and a great demonstration of the augmentation potential in agentic coding. There’s so much focus on replacing entry-level work it gets missed what these power tools can do in the hands of people who know what they’re doing.

I still find myself wasting a few hours per year on this game since it’s on PS4/5

https://store.playstation.com/en-us/product/UP4403-PPSA02752...

I really need to start familiarizing with these new tools, I'm only using LLMs in interactive, “question and answer”, mode and it feels like using a typewriter when everyone is switching to computer word processors.

Thanks for sharing, it's a really interesting writeup and project!

Using LLM's in an "agentic loop" is indeed a game changer. Give it a try in a sandbox.

Is the idea that once you isolate a function it decompiles it and then iterates changes until either the recompiled asm matches?

That's one way. I'm not certain that's the way you'd project did it, hard to say without looking at the pipeline. But there are N64 "matching decompilation" projects that do it exactly the way you propose.

Thanks, I will have a look at it! Even just updating my jargon vocabulary fells like an improvement.

How much did this cost with the AI usage ? What plans did you have ?

Reversing this by hand seems like it would have taken orders of magnitude longer…

But it is more fun and more of a learning experience, I think.

Curious what parts you think can only be learned by hand? Having read the article I think the auto approach covers all the same ground, just at a much faster pace with no down time.

All modern AI tools tend to put `from __future__ import annotations` line into Python code which isn't required by recent Python versions.

I guess this is because they all are trained on an intermediate code bases when this was required some times (even at that time the real usage was quite rare).

And now this line is parroting everywhere like a junk DNA :)

I am not an AI and I missed the memo on this. I put that line in whenever I need to use a forward-declared type annotation. Last I recall reading about it, there were some deep issues that meant it had to stay in __future__ indefinitely. Is there a PEP / release note about it?

Oh, I was very wrong, my apologies!

I was sure this one was for Python from 3.7 up to 3.10. But it is still here.. But as for 2026 it will not stay forever as it was supposed to - there are 2 PEPs which are suppose to fix it in Python 3.14 - https://peps.python.org/pep-0649/ and https://peps.python.org/pep-0749/

This is brilliant, inspiring work. Well done and congratulations!

I'm also impressed by the game's jaz image format. Very cool.

I only know about this game because it was in some Humble Bundle. Have the Linux version from that. Not sure how old it is. Looks like the screenshot of one of the remastered versions. Remember installing it and playing for a few hours but then forgot about it.

Last Humble Bundle update from 2019, but I can't get it to run on my current Ubuntu. Runs in my Ubuntu 16 QEMU vm, but no audio for some reason.

Pretty much expected level of success for old binary-only Linux games. Can probably be fixed, but usually just playing the Windows version in WINE is easier and plays better.

Very impressive, makes one wonder what do some companies have in private compared to public tools that we stitch together. E.g. you can combine LLMs with statical analysis/proving to get much better results.

[dead]

This is a lot of fun! It's the first time i've ever used the uv package manager directly, and it was shocking how fast the game was running for the first time on my machine. Very nice.

Looks like the game still only runs in a small window, but Valve's gamescope*, had it running full screen right away too.

* gamescope -W 2560 -H 1440 -r 60 -S stretch uvx crimsonland@latest

I used to play a lot of Crimsonland, so this is very nice. I thought the updated version that they later released on Steam never captured the original feeling. The newer game is still fun but the older version is better, gameplay wise.

Any recommended learning materials/resources for basic binary reverse engineering? I'm imaging a resource that teaches the common tools/concepts and provides binaries in increasing complexity.

I'd suggest going through one of the relevant reverse engineering courses (all free) in either pwn[.]college or/and OpenSecurityTraining2 .