(decomp-academy.dev)
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.
By the way, I was able to "cheat" on the second lesson with
void identity(void) { return; }
As for cheating, the community calls this a fake match. I don't check that the code you submit conforms to what I expect, I only check if the assembly matches. You can do interesting things where you do a series of bit shifts and bit masks, and you can replicate an equality operator `a == b` or a low clamp `x < 0 ? 0 : x`. I'm not sure if I'll lock this down or not, for people who have accounts, I can see their submissions so I think I'll play it by ear and see what happens. If it looks like people are constantly fake matching, I can look at tweaking the lessons or locking it down more
Basically; can you reverse engineer in bite sized pieces, and recompile/customize their behavior, without needing to do it all at once?
0 - for example: https://github.com/Xeeynamo/sotn-decomp/blob/master/src/boss...
- 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.
- 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
Ironically, for myself at least, the least it looks AI, the more I've spent time prompting for it to not look AI.
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.
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!
USPTO and court precedent is leaning heavily toward LLM output not being transformative on its own, making it mechanical, and no longer fair use and in violation of copyright. This puts a legal gray cloud on a project where most contributors couldn’t defend themselves if a rights holder goes after it, and there’s a high likelihood that they would succeed. On the other hand there’s enough case law protecting human decompilation that even the most litigious game companies don’t go after decomp projects that have historically been done by humans.
(I’m not a lawyer, I’m not your lawyer, this is not legal advice, etc., etc.)
Nicalis and Take-Two have both gone after decompilation projects, also. In particular, Nicalis has gone after a decompilation of Cave Story, but not a black box reimplementation of the same, while Take-Two ended up suing a decompilation developer (albeit settled out of court). However, in some jurisdictions, even clean reimplementations have failed - see Tetris v. Xio.
(I am not a lawyer either, etc etc, but that's my understanding)
CSE2 was distributing binaries as well.
So was SM64 decomp and Nintendo told them to stop, they did and continued to share their source code.
Tetris v. Xio is unrelated to reverse engineering or decompilation.
Distributing binaries should not matter. If the binary is just compiled from the source code, the binary is just an (non-)infringing as the source code.
> They also allegedly violated a EULA
Meaningless. EULAs are not the law.
In some cases the EULA is what gives you access to the original binary to begin with (often the case with digital marketplaces, but also true of some physical media after 2010 or so). These have little to do with copyright, but whether someone could access the binary on the first place. To the best of my knowledge this contract law has largely been considered valid, but I try to avoid working on things with EULAs, so haven’t looked into it in depth.
Also, how to folks obtain binaries? Presumably unless there is a source code breach or vulnerability, source never gets exposed, is thst correct?
Otherwise they reference rips of the original game.
Don't think this was the case, what helped was it being compiled without optimizations.
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.
Drivers can also be partially implemented / buggy depending on the device. (And I'm not talking about closed source stuff, even things like usb or touch screen drivers).
I would say that the major blocker is that nobody really cares about these devices and the task itself to mainline them is gigantic.
Most SOC have 3 or maybe 4 contributors maximum and the phonedev kernel mailing list gets a new patch only every 2 days. The whole phone mainlining community is probably less than 60 people.
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?)
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.
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.