3 ms·

How do people do things like this? They manage to achieve pretty sophisticated modifications to compiled games without access to the source code. Is it really j

by gburt 9y ago

How do people do things like this? They manage to achieve pretty sophisticated modifications to compiled games without access to the source code. Is it really just disassembly and careful low-level work?

ZenoArrow 9y ago
I don't know how this particular hack was done, but you may be interested in how notaz carried out the StarCraft ARM port: https://hackaday.com/2014/07/31/playing-starcraft-on-an-arm/ https://hackaday.com/2014/07/31/playing-starcraft-on-an-arm/ https://pyra-handheld.com/boards/threads/starcraft.73844/ https://pyra-handheld.com/boards/threads/starcraft.73844/
pfedak 9y ago
Debugging tools in n64 emulators (such as nemu64) are sufficient to make tracking down particular game logic more in the neighborhood of a fun puzzle than a slog through (roughly) a megabyte of assembly. Super Mario 64 in particular has had an active ROM hacking community for over a decade, so there is a large body of knowledge about the game's internals, though it resembles folklore more than a systematic approach. The hard parts to discover through disassembly are the 3d graphics api and memory-mapped IO, but that was already worked out quite a while ago for emulators (based largely on patent documents). In fact, there are level editors for SM64! Kaze, the creator of this hack, occasionally streams development on twitch; it's a lot of cross-referencing different pieces of accumulated documentation. Edit: An example of some of the documentation, a list of ROM addresses of various textures: http://wiki.origami64.net/super_mario_64/textures http://wiki.origami64.net/super_mario_64/textures
T-R 9y ago
I can't speak to the complexity of this project, but for ROM hacking in general, it's not all too complicated, but it does take some persisence. First you need to find code relevant to what you want to do. You can take diffs of memory as you do things in the game to narrow down where the relevant addresses are, and then set breakpoints on read/write to those locations to find relevant code. After that, you can mostly just follow the assembly - you can even read backwards up the call stack by reading to what look like the beginning of a procedure, and searching for jumps to that address. Once you've found the code you want to modify, you just need to find some empty space in the ROM that you can branch out to to write your code. The trickier bit is if you're in a spot where you need to worry about timing. On older consoles, this included things like changing the HUD or wave effects, etc., since you need to make sure whatever work you do gets done in time for HBlank/VBlank. Some consoles also had some built in functions that would give you an idea of what code was for, like the lz77 compression on the GBA, which was mostly just used for graphics. Similarly, DMA was most often used for copying sprite data. On newer consoles where code was often compiled from C (rather than assembly with macros), I'm under the impression you can also do things like try to pattern match on the signature of standard library functions.

by gburt 9y ago

ZenoArrow 9y ago

I don't know how this particular hack was done, but you may be interested in how notaz carried out the StarCraft ARM port: https://hackaday.com/2014/07/31/playing-starcraft-on-an-arm/ https://hackaday.com/2014/07/31/playing-starcraft-on-an-arm/ https://pyra-handheld.com/boards/threads/starcraft.73844/ https://pyra-handheld.com/boards/threads/starcraft.73844/

pfedak 9y ago

Debugging tools in n64 emulators (such as nemu64) are sufficient to make tracking down particular game logic more in the neighborhood of a fun puzzle than a slog through (roughly) a megabyte of assembly. Super Mario 64 in particular has had an active ROM hacking community for over a decade, so there is a large body of knowledge about the game's internals, though it resembles folklore more than a systematic approach. The hard parts to discover through disassembly are the 3d graphics api and memory-mapped IO, but that was already worked out quite a while ago for emulators (based largely on patent documents). In fact, there are level editors for SM64! Kaze, the creator of this hack, occasionally streams development on twitch; it's a lot of cross-referencing different pieces of accumulated documentation. Edit: An example of some of the documentation, a list of ROM addresses of various textures: http://wiki.origami64.net/super_mario_64/textures http://wiki.origami64.net/super_mario_64/textures

T-R 9y ago

I can't speak to the complexity of this project, but for ROM hacking in general, it's not all too complicated, but it does take some persisence. First you need to find code relevant to what you want to do. You can take diffs of memory as you do things in the game to narrow down where the relevant addresses are, and then set breakpoints on read/write to those locations to find relevant code. After that, you can mostly just follow the assembly - you can even read backwards up the call stack by reading to what look like the beginning of a procedure, and searching for jumps to that address. Once you've found the code you want to modify, you just need to find some empty space in the ROM that you can branch out to to write your code. The trickier bit is if you're in a spot where you need to worry about timing. On older consoles, this included things like changing the HUD or wave effects, etc., since you need to make sure whatever work you do gets done in time for HBlank/VBlank. Some consoles also had some built in functions that would give you an idea of what code was for, like the lz77 compression on the GBA, which was mostly just used for graphics. Similarly, DMA was most often used for copying sprite data. On newer consoles where code was often compiled from C (rather than assembly with macros), I'm under the impression you can also do things like try to pattern match on the signature of standard library functions.