Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Dumb question — can LLM be used to reverse-engineer firmware blobs or binary only drivers for Linux, to create open-source drivers, for example, for unsupported smartphones?
  • As I'm working in this area, I can say that the biggest problem isn't binary only drivers but spotty mainline support of core features (provided that we're talking about Android phones, not iPhones or old Windows mobile stuff)
  • Most likely, this (reverse engineering) is one of the numerous things these LLM companies target. You can also assume all of the internet has been slurped up in to any frontier model. That doesn't mean what you want will be a one shot prompt though...
  • That is already happening for old games, and while they usually run on simpler CPUs than modern ones, I don't see why this couldn't be possible for binary Linux drivers.

    The toolchain would also be easier to match, unless they were using some proprietary compiler you can't get your hands on.

    Just lookup how they match the toolchain, and find an agent harness to do decompilation.

    I wonder if doing this kind of stuff with more recent software will cause more legal problems though. I am not really sure of the legal status of the resulting code.

  • > If even 1 instruction or bit is off, that's a fail.

    Does this assume having access to the exact version of the compiler use, or can it be done with a different compiler in practice?

    And do you care about things like binary layout, or just instruction match? (Does that ever matter in practice?)

  • Yes, exact version of the original compiler is required.

    Generally bit-for-bit equivalence to the original executable is expected. However I think for some cases where the original executable included debug info (eg. PS2 ELFs) then the unused-at-runtime sections need not match.

  • That's awesome! I have been playing with the idea of doing a Tales of Symphonia decomp. More than 10 years ago I started the high-res texture pack, which the community has now carried further than I ever did. But it would be totally awesome to be able to mod the game further and run it on other consoles without the godawful framerate downgrade.
  • This is cool as hell.

    On the first lesson, it tells me there's a target on "the right". There isn't anything to the right, I've in clue where to look.

  • Are you on mobile? You'll need to switch to the code/review tab to see. I think mobile support is a bit funky, I'll look at fixing that as soon as I can!
  • The backend is closed source, but it runs all on AWS Lambda/DynamoDB/APIGateway and is written in Rust. Getting the compiler running in a Lambda was an adventure of it's own
  • I’d be interested in hearing more detail on that. I’m actually surprised you were able to get the compiler, I assumed it would be expensive and proprietary.
  • I recently heard that Super Mario 64 (N64) modding community reverse engineered the game enough to recreate more-or-less accurate C code that can be compiled in binaries to execute on many popular target architectures. Have you managed to get beloved games into modifiable C code? Or is it more common to invest a lot of work to document assembly language functions? I know some old assembly but no idea what is involved at a high level. Maybe you explain in your lessons?

    Also, how to folks obtain binaries? Presumably unless there is a source code breach or vulnerability, source never gets exposed, is thst correct?

  • Most games will have been written in a higher level language first (like C or C++) and then compiled into assembly. With matching decomp, we write C, compile it to assembly, and see how much it matches the retail assembly. Using this we can write C that we theorise is almost identical to how it would have been written originally. There are things lost during the compilation process (like comments, function names, etc) these we have to name manually and it's a long process to do! But yes, the goal is to have C at the end and once you have C you can recompile using a different compiler and target any architecture you like
  • Mario 64 was byte for byte decompiled to C. It was helped by using the Debug symbols accidentally(?) compiled into the final version of the game.

    Otherwise they reference rips of the original game.

  • Love the idea! Assembly has been on my forever-list to eventually learn. I have worked through the warmup exercises, but I doubt I'll have the time to continue much past that. A few points of note:

    - Not a fan of the purple theme, it screams "AI-generated". It's not a deal breaker, you can keep it if you have more important concerns, but just something to point out

    - It would be nice to have a "Chapter 0" for a primer on assembly syntax. Does not have to be interactive, a few toy examples I can work out on paper would be good enough

    - Maybe I just haven't seen it, but it would be nice to have a reference of all the various instructions. Your lessens explain them well enough, but I would like to have a list of all of them at a glance so I can look up instructions from earlier chapters later.

  • Is "the layout scream AI generated" the new Bootstrap ? I.e what people use to quickly convey their ideas (bad or good)

    Ironically, for myself at least, the least it looks AI, the more I've spent time prompting for it to not look AI.

  • - The purple theme was a conscious choice, not an AI's decision. I wanted to match the colour theme of the GameCube. You can see the current colour pallete here: https://decomp-academy.dev/brand/brand-sheet this will likely go through changes in the near future but I'd like to stick to the purple theme as a nod to the GameCube

    - I've just added some new lessons before the first lesson to explain assembly syntax!

    - I believe there are around 200-odd instructions, and a lot of them I'm not sure you'll ever see, but I can certainly look at adding something like this

  • The purple theme seems fine and appropriate to me, given the GameCube’s color scheme - and some of the site feels almost Slippi-esque so there’s a bit of that angle too.
  • The browser-first approach is a bigger deal than it sounds. Every time I've looked at reverse engineering, I got stuck somewhere between "install this ancient compiler" and "patch this SDK". Being able to just open a tab and start experimenting removes a huge amount of friction.
  • Damn this is next level. Congratulations on your achievements!

    When Fable was around I thought i'd test it by taking an old piece of Windows software from the late 90s/2000s(ModPlug Player) and seeing how well it could convert it to being a native Mac application.

    I was blown away at how it got 85% of the way there in one prompt. Things such as writing a PE extractor, recovering the complete skin, menu tree, full accelerator table, all dialogs, and then it delved into the registry value names as well. Some more prompts got it to 99%(I was happy with that and stopped)

    I then took an old 1999 DOS demoscene and yet again it did wonderful magic and got me a native mac build.

    I dropped everything I was doing and just started going through all these old apps that I couldn't easily enjoy since im on a Mac. It got to the point where I was losing sleep over it(was just so excited).

    The fun ended when I was stopped mid-project with the Fable ban. Opus just does not compare and essentially killed all the enthusiasm after the nth failure of it to complete the task.

    It made me realize that among the efforts of the RE community, and the emerging capabilities of these frontier models, in the future we could have the possibility living in a renaissance of open computing if we want any software we see on the market to be forever remixed and tailored to our uses and completely open.

    I don't know how the business and legal side will deal with this. There needs to be new frameworks and ways of thinking about this stuff.

    I'm just happy that hopefully no code will ever be lost to the sands of time ever again.

  • Makes one wonder, why should anyone embark on learning this intricate and time-consuming art of reverse engineering when LLMs are on their way to automate it in seconds...
  • AI is being used in many retro game decomp projects!

    One of the reasons I went down the path of learning decomp myself was because AI had hit a wall. Matching decomp is quite a bit harder than just normal decomp as even simple things like using an if/else instead of a terney actually change the assembly. AI did an amazing job of getting to 95% matches on nearly all functions, but once it got to that tail end, it started to struggle quite a lot and would often just claim "it's impossible". So that's when I pivoted and started learning actual decomp myself so that I could prompt AI better and finish off the star fox adventures decomp!

  • Dumb question about reverse engineering binaries: is there a way to only do it piecemeal? I'm eventually waiting for LLMs and harnesses to get good enough to reverse engineer BFME (old Lord of the Rings game that still has an active modding community), but it's a multi GB sized game that would have to be done in bite-sized pieces.

    Basically; can you reverse engineer in bite sized pieces, and recompile/customize their behavior, without needing to do it all at once?

  • Most of those GB are probably data rather than executable code, it might not be quite as bad as you're imagining.
  • Have you tried? I've haven't tried anything huge but I've had LLMs decompile SNES ROMs for me.
  • I've just recently finished replaying BFME1's campaigns. The installation process was "fun" in its own way. There were some quirks in game that could definitely be fixed. I haven't used any unofficial patches though. But I would like to see and maybe even help with reverse engineering both of them. The second game gave me even more trouble yesterday. Would be nice to have community versions of the exes.
  • Yes, quite easily. It requires some setup, but the basic idea is that you create a DLL and a simple loader program which injects it into your target process. You can then use a hooking library like MinHook to replace individual functions with your own implementations. If the target application is in C++, you can additionally do vtable hooking and replace functions even easier (though it will always be a combination of the two techniques).
  • Most decomp projects (that I know of) are Ship of Theseus style projects where the minimum unit is a function, give or take alignment requirements and quirks of the compiler. On the MIPS side, tools like Splat and SPIM can help identify function and even source file boundaries, generate inline ASM C files[0], and write linker scripts to build a matching binary. You can then go through and replace the ASM functions one at a time until you just have C left.

    0 - for example: https://github.com/Xeeynamo/sotn-decomp/blob/master/src/boss...

  • This was interesting, but actually trying to contribute to decomp.me was still really hard! I found a lot of code that seemed perfect except for instructions slightly out of order, or dead pop statements after the logical end of the function. I wasn't able to actually fix anything :(

    Also, I wish there were a guide about how to start from nothing on a new GC game. That's more interesting to me than putting the finishing polish on a decomp project that already "works" functionally.

  • There will deffo be a lesson on how to setup a decomp project from scratch! This is far from finished, there's opportunity to add so much more. I'd argue that I'd rather teach the user the basics of matching first before diving into setting a project, as setting up the splits.txt or symbols.txt might be quite a leap for a beginner. Feel free to keep checking in once a week and the lesson will appear :)