Acmlm's Board - I2 Archive - Rom Hacking - Anyone up for disassembling an entire game?
| User | Post |
Bit-Blade
Posts: 413/445 |
If you could crack Battle of Olympus you'd be the fucking MAN. I've been trying to get around it's graphics compression for a while... |
Sokarhacd
Posts: 1694/1757 |
I wouldnt mind helping a little, but not right now, ive been reading some nes docs and am understanding a lot of it, so when I do learn some more of it, I could help a little...not sure when, but ill let you know. it would be really cool, to get more people interested in this, and disassemble alot of roms, so they could be edited that way, and reassembled, this way it would be really easy if you knew alot of asm to make really cool hacks.
I have the latest IDA, so thats not a problem |
oman
Posts: 2/11 |
A good way to do this is to let IDA do major chunks of the disassembly automatically (starting at the locations provided in the interrupt table) then write IDC scripts that are smart enough to handle the jump tables or any other strange flow control techniques. Spending some time writing scripts for your disassembly now will save you tons of time in the future.
|
rg_
Posts: 17/26 |
Originally posted by HyperHacker
Really, the best way to do this is the emulator idea. If you know a lot of the game's RAM and/or ROM addresses, you can tell it what they are, and then it can create the disassembly appropriately, switching addresses with their names. Since it's executing the code, it should be able to tell which areas are code and which aren't, as long as you try to do as much as possible in the game so as to get as much code as you can executed. (Might be good to put a comment near jumps that jump to data areas, so that you can examine them and see if maybe they're really code.) If you managed to execute all the code (not too hard in a simple game), then the only things it would miss is code that gets copied into memory and code that never gets used, which would probably be pretty easy to spot.
You don't even need to execute all the code. While developing a small tool for someone on #rom-hacking I figured out that you can make "speed disassemblies" using FCEUXD and IDA Pro. You can quickly scroll down in the FCEUXD disassembly window and when you notice valid code (easy, as data interpreted as code doesn't lool like valid code at all) you can tell IDA Pro and IDA Pro can then disassemble the code from there. Using that technique I made an un-annotated (of course) disassembly of Zelda in 25 -30 minutes. I guess I separated more than 90% of all code from data that way. Getting to 100% shouldn't take too long either if you're already at 90% but I never tried that as a near-complete disassembly was nearly as good as a complete disassembly for the tool I made.
Originally posted by dan
There already is a disassembly of Castlevania, and I think Duck Tales also.
Right, thanks for pointing that out. I actually wanted to ask which games were already disassembled and if you guys have links to the disassembled code available.
Edit: Thanks for the link dan. |
dan
Posts: 748/782 |
There already is a disassembly of Castlevania, and I think Duck Tales also.
Edit - Forgot the link - http://www12.brinkster.com/hydesprojects/gamessources.asp |
HyperLamer
Posts: 7354/8210 |
I've considered doing this with Pokémon G/S, but those are 2MB.  Of course, I'd be using a disassembler which gives re-assembleable output. It's just a matter of making one. What I figure I'd do is add support to the program to mark areas as data (or even better, but harder to do, write an emulator that logs which parts are executed and which are just plain read), then go through it one ROM bank at a time, turning the disassembled code into something readable and re-marking anything that's incorrectly marked as code or data.
Really, the best way to do this is the emulator idea. If you know a lot of the game's RAM and/or ROM addresses, you can tell it what they are, and then it can create the disassembly appropriately, switching addresses with their names. Since it's executing the code, it should be able to tell which areas are code and which aren't, as long as you try to do as much as possible in the game so as to get as much code as you can executed. (Might be good to put a comment near jumps that jump to data areas, so that you can examine them and see if maybe they're really code.) If you managed to execute all the code (not too hard in a simple game), then the only things it would miss is code that gets copied into memory and code that never gets used, which would probably be pretty easy to spot. |
rg_
Posts: 16/26 |
I've been toying with the idea of disassembling and annotating an entire NES game for a few weeks already. However I don't want to do it alone, that's why I make this post.
I'm thinking about doing something like this first and after the annotation phase ended it should be possible to turn it into something like this which can be re-assembled.
I'm not thinking about some kind of project that takes up a lot of time and dedication and participants have to be present and report frequently. I'm thinking of some kind of project where you document another function or two when you have a few minutes to waste and don't know what else to do with your time. The entire thing would probably take months to complete. I also don't plan to set up a project site or anything, a thread here on this board where everybody posts his findings should be enough. I do however plan to include all findings into a single IDA Pro file which I then export to HTML to make it available for everyone.
Nevertheless I want the project to end one day. That means huge games should be avoided. My definition of huge is > 128 KB. Faxanadu is 256 KB and documenting it was *a lot* of work.
In fact I've already thought of a game: Battle of Olympus. The game is 128 KB large, yet it should be large enough to find cool unused stuff in the ROM (at least I hope so; I found a ton of unused stuff in the Faxanadu ROM). Alternatives could be Duck Tales 1, Kid Icarus and maybe Castlevania 1 but I'm open for more ideas. I want to avoid games that have already been hacked to death (SMB, Zelda, ...).
Benefits of participating include but are not limited to learning *a lot* of 6502 asm, eventually creating new ROM hacking tools (which would all be open source), learning new programming languages if new tools are created, learning everything about the game you ever need to hack it and most importantly I will think you're awesome.
I appreciate any input. |
|
hukka
