Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
1
Chrono Cross Modification / Fully reverse engineering Chrono Cross back into C code
« on: March 22, 2021, 01:46:44 am »
Given reverse engineering games is now the thing to do, could it be time for Chrono Cross to join the trend?
Though the approach I'd suggest is not loading the game up in Ghidra and manually going through everything, but instead I think the approach should be finding a simple Open Source PS1 emulator, preferably one that uses an interpreted core, and modify it to generate metadata as it executes the game.
I'm inspired by the tools they used in the Sonic Sega Genesis reverse engineering community:
https://forums.sonicretro.org/index.php?threads/sonic-the-hedgehog-prototype.39840/page-24#post-976359
The tool they talk about seems to only work for Sega Genesis games, but something like this for the PS1 could be beneficial to other PS1 modding communities.
Furthermore, by using a modded emulator, one could do cool things like, imagine a piece of game code reads from CD and writes to a buffer, the emulator could label that memory region as "CD", and then another set of game code reads the buffer and renders it, so now you can see a flow from CD to GPU.
Anything that touches a labelled region gets the labels smeared onto it. It can work in reverse too, where a piece of code writes to the GPU, and it gets "GPU" labels attached to it. Then using a "fill" tool like algorithm, whenever a piece of code is about to proceed to another instruction be it by PC increment, call, or simple jump, if the other piece of code is dirtied with a label, then smear the label onto the current piece of code. So then you slowly watch addresses of code get colored by what they touched. Things with multiple labels (GPU, SPU) mean that code is used for multiple purposes.
There'll still need to be manual work naming things, but the above hypothetical emulator would be doing most of the heavy lifting by automating the research part of reverse engineering.
Thoughts?
Though the approach I'd suggest is not loading the game up in Ghidra and manually going through everything, but instead I think the approach should be finding a simple Open Source PS1 emulator, preferably one that uses an interpreted core, and modify it to generate metadata as it executes the game.
I'm inspired by the tools they used in the Sonic Sega Genesis reverse engineering community:
https://forums.sonicretro.org/index.php?threads/sonic-the-hedgehog-prototype.39840/page-24#post-976359
Quote
Active Disassembly. This feature tracks offsets, code references, data references, array bounds, jump tables, PC relative addressing, and a bunch of other things within the emulator. In a nutshell, I designed it to automatically do in a few seconds what took me a month to do manually. Once it was done, I was able to generate a disassembly of Sonic 2 similar to the result I achieved manually, but in a matter of hours rather than a month. I think this feature is still not really known or understood well, so I figured I'd throw it at the Sonic 1 proto. I just messed around for about 30 minutes to be thorough, and got a pretty damn near complete disassembly out of it. Should be useful to someone.
The tool they talk about seems to only work for Sega Genesis games, but something like this for the PS1 could be beneficial to other PS1 modding communities.
Furthermore, by using a modded emulator, one could do cool things like, imagine a piece of game code reads from CD and writes to a buffer, the emulator could label that memory region as "CD", and then another set of game code reads the buffer and renders it, so now you can see a flow from CD to GPU.
Anything that touches a labelled region gets the labels smeared onto it. It can work in reverse too, where a piece of code writes to the GPU, and it gets "GPU" labels attached to it. Then using a "fill" tool like algorithm, whenever a piece of code is about to proceed to another instruction be it by PC increment, call, or simple jump, if the other piece of code is dirtied with a label, then smear the label onto the current piece of code. So then you slowly watch addresses of code get colored by what they touched. Things with multiple labels (GPU, SPU) mean that code is used for multiple purposes.
There'll still need to be manual work naming things, but the above hypothetical emulator would be doing most of the heavy lifting by automating the research part of reverse engineering.
Thoughts?
Pages: [1]