ghidra-scripts VS sm64

I've got no experience with reverse-engineering executables, but I got a bunch of code-like stuff showing up when I fed ULTIMA.EXE to Ghidra and told it to analyze it with all the flags set.

The whole game is written in C++ (game logic intertwined with graphics). Ghidra can help you deconstruct the game binaries, but you need to put in a GREAT great effort to even get a starting point. Cheat Engine has been successful for some purposes, including an AI enabling utility for multiplayer (use with great care!).

Ghidra: https://ghidra-sre.org/, https://github.com/NationalSecurityAgency/ghidra

What I think you’re talking about is reverse engineering. It’s basically taking a program and analysing the compiled code to attempt to find out how it works. It’s a fairly expansive topic, and fairly tricky to do but look at anything to do with Ghidra to get started.

Oh also just as an aside Ghidra is a really cool free tool developed by the NSA which can reverse engineer software by looking at its executable and recreating the C code from the instructions and static data within. It's another way to get familiarized with the relationship between C code and the instructions it compiles to.

There exist decompilers and other tools for helping make sense of assembly and that can automate some of the conversion back to higher level languages. In my brief involvement with Slippi I used Ghidra - a tool developed by the NSA, to do some of that kind of work, which I found a little amusing.

It's likely a binary file that's improperly being interpreted as Unicode by the text editor. If it's an executable file, you can use Ghidra to disassemble and analyze it. There may also be some interesting ASCII strings that would reveal its purpose. My guess is that it's a Windows version of Unix "tee" program which will write stdin to a file and stdout simultaneously.

On the other hand, this slick "Ghidra" webpage looks suspicious. It's probably written in Typescript on Electron!

The SM64 is still going strong https://github.com/n64decomp/sm64

Nintendo won't allow any binaries floating around though.

Romhacks are typically modifying the compiled binary ROM image. Kaze' work is based on the painstakingly disassembled code from the n64decomp project[1]. He's working in C, modifying the game and compiling it again for the original hardware. Not sure I'd call that a "romhack".

Great videos though!

[1] https://github.com/n64decomp/sm64

A team or something reverse engineered super mario. I think that's the repo and it's mostly in C

From course_table.h and course_defines.h we can find that: COURSE_MIN == 0 and COURSE_MAX == 25 - so it looks like every secret stage is a full-fledged "course" for the purposes of counting stars, bringing us to 25 courses + castle stars (COURSE_NONE). So, the maximum possible value for starCount should be 7 * 26 = 182.

Multi-year decompilation project: https://github.com/n64decomp/sm64

The port source code of the decompilation is still up on github and Nintendo hasn't taken it down in years, cause they can't since everything has been done with legal methods

This is false, the source code never leaked; it was meticulously and painstakingly decompiled by hand.

It sounds like, rather than a ground-up rewrite, COBOL should be treated as an object-code language, and "hand-decompiled" (ala efforts like https://github.com/n64decomp/sm64) into an HLL that can, at every point, be losslessly transpiled back into the original COBOL.

I know the tooling for doing that doesn't currently exist... but paying someone to develop it would be cheaper than any one of these ground-up rewrite projects!