I thought this deserved its own topic as opposed to being thrown in the questions and answers thread, if I am wrong please forgive me. I have experimented a little bit with disassembling a Megadrive / Genesis rom but am a little confused as to how the steps one would go to form a disassembly in such a way as the Sonic disassemblies that we have. Would anyone be able to help with a step by step guide? my rough estimation would be 1) Go through rom with hex editor / tile editor / gens debug and find relative offsets and understand what they are. 2) Disassemble the rom 3) label the rom at the relevant offsets The only problem with my method is that it seems a little empty and lacks ability to rebuild the rom once split / disassembled. I am hoping some of you can help give me an insight into this and describe what steps you use to disassemble and hoping this thread can become a general disassembly help thread
Well I disassemble the entire binary into 68k assembly (using 68kd). I then convert all the disassembly into comments of the instructions and dc.w commands. This way I can assemble all the dc.w commands and ensure the "disassembly" assembles back into the original binary. I then go to the starting point and start uncommenting code as I figure out the code paths and data locations. After I get a good chunk of instructions uncommented, I start trying to figure out the intent and start replacing generic labels with descriptive names and adding comments about the code's intent. Since the rest of the disassembly is in the dc.w format, I can easily assemble the partial disassembly and verify I didn't break anything (and if I did figure out what small recent change broke it). Sometimes, I have to make additional tools (PERL scripts) that can analyse something or perhaps implement a decompression routine to emulate a custom 68k decompression routine. Actually, my main hobby right now is disassembling a certain game. It is a great puzzle with tons of tiny pieces. Eventually, I want to port this game to Sega CD and enhance the game.
The first Sonic 1/2 disassemblies were made using a modified version of Gens which generated some sort of script file, which could be read by IDA to disassemble all the code, leaving only data and pointer tables in raw form. We then had to go through labelling everything, converting the tables and correcting any mistakes. Nowadays I think I'd just start at the entrypoint and go through the code manually.
Actually, I released a Sonic 1 disassembly before that (back in 2004), and it was done manually, with the help of IDA. Without a doubt people have disassembled the Sonic ROMs even earlier, but I think my release might have been the first "complete" disassembly that could be recompiled into a working ROM. I say "complete" because it was more or less a proof of concept and for most parts of the ROM it lacked intelligible labels and other niceties of the current split disassemblies. However, it did get the ball rolling. If I remember correctly, it was Nemesis who then came up with the idea of using an emulator to determine which addresses of a ROM are code and which are data, and then use that information to generate a script for IDA.
Thank you all for the replies. @Bgvanbur - to comment all of the lines of the disassembly are you fluent in assembly language so you just kind of know what is happening at each step? @Hivebrain - I have fiddled around with IDA pro a little and have not got very far. From the top of my head I cannot remember where the entrypoint is for Megadrive / Genesis games. Also, how would you make sense of all of the commands when you have gone through and basically pressed C on all of the lines, does that require fluency of assembly language also? @Korama - I think I will try to stick to using IDA and doing it manually and attempting to label any offsets that I know. Could you recompile the rom in IDA? or did you write a separate script for it? Also, if I wanted to make a split disassembly by splitting the variety of data into separate directories, I would use a Split.bat and Build.bat (modified from the disassemblies that we have) but how would that work in regards to recompiling the rom. Would I need to set each loading section of the code to basically read in all files present to include as opposed to reading in a specific byte amount. I'm not sure how else to word that without it sounding convoluted. What I am hoping to do is include more content without it overflowing and corrupting the rom after the insertion point. It is also worth noting that while I have a very basic understanding of ASM, I am in no way fluent so it will be much more difficult for me to attempt anything like this. Note: Should I try to find some solid offsets which store things like graphics to have a solid idea of an offset?
To do a disassembly you need to know lots of things very well, including the assembly language and the (Genesis) hardware.
You also need to know lots about the game as well, what RAM address does what, etc. Making a disassembly takes time and effort. What game are you disassembling Elektro-Omega?
Well I was hoping to have a go at disassembling Micro Machines 2 :P Edit: I knew disassembling was a lot of work but I did not realise exactly how much work and how much software and hardware knowledge was needed. Do you think I should just attempt Hex editing until I know more about the overall disassembly process?
IDA can't do any recompilation by itself. I just saved the disassembly to a text file and recompiled that with snasm68k. If everything is labeled and aligned properly, adding more content shouldn't be a problem. Yes, it is a lot of work. Especially if you have no programming experience. But if you really want to learn disassembling, then you have to start somewhere, of course. An entire MegaDrive/Genesis game might be too big of a project for a beginner, but it depends on how much time and energy you are willing to invest.
To be honest, I have always wanted to run before I could walk when it came to hacking but recently since my time has been consumed with real life I have taken a step back and decided to take it slow and make it more about a learning process as opposed to having something physical to go by. I was reading up about using gens debug tools to help find offsets by creating game genie codes and isolating specific parts of the ram and using tracing. I have had very little luck with this but I will continue my efforts. Just wondering, when trying this method it is easy to locate things such as a timer but for locating graphics how would I go about it? I can see it in the VDP viewer but I cannot seem to figure out what to do with the sprite data from there.
I was curious about this myself, as I would really like to hack WWF Raw. I've been able to go inside and find some of the palettes, but thats about as far as I've gotten so far, haven't really done much else with it though. Do other Genesis games outside of Sonic use similar compression (such as the KENS formats?) or does each game have its own completely different formats?
@KingofHarts - I think some games share some compression formats. From what I remember the application SonikSprite could also (to some extent) read in Quackshot Sprites which I assume are all compressed by Nemesis Compression. I may be completely wrong on that though so don't take my word as definite direction. On a side note, I imported my rom into IDA, used the genesis IDA plugin 'mida.idc' which appeared to organise and produce a file which had the correct asm commands. I then exported this file to a .asm file and written a small batch file to build it into a rom using asm68k (I am on Windows 7 64bit so I couldn't use snasm68k) just to test if it could recompile correctly but I am met with a fair share of 'opcode not recognised' errors which all appear between line 25 and 92 which appears to be the majority of the error detection, traps and reserved area. Ignore that last bit, I am a dumb ass. I am met with a different array of errors now ranging from bad size on opcode to illegal value. Now I'm sure I have done something wrong.
My bad. I thought it might have been uncompressed art it edits but I had convinced myself it was Nemesis. Woops, sorry.
How did you use game genie codes to find offsets? Do you meaniInserting nops and rts to byoass subroutines? And freezing a ram value to see it’s effect? Was there any other things you used it for ? If so, like to hear. . Or if anyone else wants to add to how they use them to aid disassembly, I’m all ears.
Using a emulator with debugging features is going to help you with identifying offsets in a ROM and will be easier to set breakpoints than using game genie codes. It's what helped me with my various disassemblies I've made throughout the years.
The best modern way IMO would be to install smd_ida_tools2 by Vladimir Kononovich ( lab313ru / drmefistO ) https://github.com/lab313ru/smd_ida_tools2 plugin for IDA PRO. It has a loader for all the vectors / tables and can properly analyze a bunch of code of the go. From their you run the game with IDA PRO using smd_ida_tools2 Gens Emulator mod . It runs the ROM in the modified emulator and lets you debug it in IDA pro. ( IIRC ) just running the game and playing it will make IDA analyze more code. You can go back and fill in jump tables and data. The tool creates VRAM VSRAM and CRAM segments in IDA that you can set read write break points and can do DMA breakpoints also. His mod of gens has features in the tools that other Gens mods don't like setting VRAM to be be rainbow or greyscale ( nice to see VRAM in editor if all cram hasn't been assigned - it's black ) . The ym2612 debugger tool is cool also and reminds me of Exodus. It features a tile viewer and conditional breakpoints which is useful.
