Just judging by the title of the article, the process was a long one.

If you start at the entry point of the game and trace every memory access, and you run the game in a profiling and debugging emulator, you can figure out what every variable does. It’s a long and painstaking process. Definitely one you probably don’t embark on unless you really care about the result (or you’re well paid).

I can't help but think that might be something a ChatGPT-type tool could be extremely helpful at.

Trained on enough code, couldn't it figure out reasonable enough names from the structure of the code?

On the other hand, it might not work at all if short functions tend to be incredibly generic, and all the real meaning is tied up in the nonlocal organization of it all.

And then of course you need context to know what the nouns and verbs are at all. I can imagine similar structures involving Luigis and Koopas, or invoices and payments.

I want to try this but the context problem seems a bit hard to solve, you probably need to have a mental model of the whole program at once

Gee I'm sure nobody thought of using AI for that before /s

In the case of Super Mario 64, some of the source code was leaked in 2020.

Super Mario 64 was fully decompiled in 2019. It has went through several cleanup refreshes since then but they intentionally avoid the leaked source in doing so.

> It has went through several cleanup refreshes since then but they intentionally avoid the leaked source in doing so.

As if that would make a difference in how big of a copyright violation all of this is.

Assets are not included in the process which helps a lot, it still requires the original ROM to compile a ROM. Nintendo has heavily went against PC ports, even as far as videos about them on YouTube, but never even attempted to touch the root decomp projects for various titles. Later games you can get into more trouble because EULAs or on screen warnings started restricting reverse engineering, as well as DRM mechanisms which are impossible to reverse engineer without being implicated as also advertising a way to work around them.

Is this clean-room development process the cover story or honest-to-god truth? How does anyone verify that outside of the individuals who worked on it directly?

The decompilation process and toolset made available would take more work to fake than to just do, not to diminish how much work that last bit is. Particularly since parts of the toolset work successfully across many titles (e.g. Paper Mario, Super Mario 64, and Ocarina of Time).

You could download the leak and compare them

I’m sure people have done this, I have the leaked code somewhere so I could do it if you want

Which you can absolutely not base yourself if you want to ensure it's considered a clean-room reverse engineering and not have Nintendo's armies of lawyers sweeping down on you.

They are going through and mechanically translating functions 1:1 from the original binary, so there aren't exactly any concerns with "clean-room reverse engineering" here.

You can still achieve that without having access to the original source code, so the implementation would be considered clean from copyright claims as long as it doesn't contain any copyrighted assets (which are necessary to achieve a perfect clone), but those can be injected during compilation from the original ROM that the end-user must acquire themselves.

In which country is this interpretation of copyright law valid ?

Soon: Freedows 12. "Your Honor, I just looked at the compiled code, so it must be considered clean from copyright claims!".

Copyright laws mostly covers the assets (images, texts, etc) and the actual implementation. If you happen to make your own implementation that leads to the same output when compiled, that would be considered fair use in most situations. As long as you didn't copy from the original source code as long as you're not distributing the assets or the compiled version, the copyright holder can't stop you from distributing your own work.

ReactOS and Wine exists and are reimplementations of copyrighted code.

> If you happen to make your own implementation that leads to the same output when compiled, that would be considered fair use in most situations as long as you didn't copy from the original source code as long as you're not distributing the assets or the compiled version.

Good luck trying to prove to any judge in the world that you came up with an implementation that happens to be exactly the same as the original game code, down to the same checksum, by pure chance.

What is this, "the ChatGPT defense"? Do you really think that code has intrinsically less right to copyright than art, or what?

>ReactOS and Wine exists and are reimplementations of copyrighted code.

Clean room reimplementations that don't even dare to look at the copyrighted code.

Copyright, specifically code will only let you protect the IMPLEMENTATION, the code the copyright owner specifically made, not the IDEA of the code.

> Good luck trying to prove to any judge in the world that you came up with an implementation that happens to be exactly the same as the original game code, down to the same checksum, by pure chance.

Not impossible if you reverse engineer the software and look how the binary code is behaving, emulators does this all the time.

A reimplementation of code that leads to the same binary output isn't covered by the copyright, as long as you don't share copyrighted assets or the actual binaries. What people do with the alternative source code is their business, you can't hold responsible that person for others' action.

> Not impossible if you reverse engineer the software and look how the binary code is behaving, emulators does this all the time.

We are not talking about a program that "produces the same binary output" when executed. We are talking about a program that _is exactly the same_ as the original one, bit-by-bit.

It is ridiculously impossible to "independently" discover a program that is _exactly the same machine code_ as the original program by just looking at the inputs and outputs of the original program. (Barring trivial programs, of course.)

This is not reverse engineering. This is just dissasembling and decompiling.

But they're not distributing the compiled output, only their own implementation of the source code which leads to that. If they happen to make their own source code which leads to the same assembly opcodes in the compiler, is that really copyright infringement?

"But Your Honor, I'm not distributing copies of the copyrighted program, just another program which happens to generate the copyrighted program bit-by-bit! All my original creation, even though I was literally looking at the copyrighted program while developing it..."

Do you think that I can just gzip gplprogram.c and then redistribute gplprogram.c.gz under the "Do What The Fuck You Want To Public License"?

Technically you would be distributing your own implementation, not the original source code. Copyright does allow you to do that. They just applied the concept of reproducible build on top.

Allow me to introduce you to ReactOS.

https://reactos.org/

And Nintendo is well-known to be hyper litigious fucks that will try to destroy their fans in court, even when they are within the legal bounds of copyright.

That's right. You can look for signs of what the piece of code does, or what the memory is used for. Functions will betray they purpose by doing calls to external libraries. Those libraries have functions with certain names and their arguments have names too. Then you have counters which you can recognize by looping and incrementing by a certain amount.

Some variables are easily guessed because they refer to a string that's stored in plain text. "%d:%s" is likely to be a printf format string, so you can follow that lead and find out which arguments correspond to %d and %s. Sometimes you get lucky and the debug message tells you directly something like "Invalid value of the coin counter: %d". This is a dead giveaway for what the argument corresponding to %d is.

Other kinds of variables can be guessed by using a debugger and looking at their values, or patching code to modify them and watching what happens.

Debug symbols were left in the released binary for SM64

I think they didn’t turn optimisations all the way up but I didn’t hear anything about debug symbols. Are you sure you’re not getting it mixed up with that? I see how you could because a build with less optimisations is often a debug build