Good decompiling program for hacks: Read

[Atari Charles]

Hi,

 

I tried Bit Hacker which isn't too bad for changing graphics, but I am looking for a program that with decompile the BIN into editable machine language. Easy to use like the Bit Hacker, but something that enable the hacker to change graphics, color, and sound. Ideally this same program would then allow me to save the data as a working BIN.

 

I read the lesson on the Homebrew forum. I understand some of it. I guess I learn best by actually doing the hacking

 

So which program(s) would suit this purpose?

 

Thanks,

Atari Charles

[atwwong]

I use Distella to decompile 2k-4k programs, but you'll need to sort out the code yourself if no commented code exists. There is a way to decompile 8k binaries; you can find it if you search the forums and do it if you have some inginuity.

[Nukey Shay]

Sorting out the code in 2k/4k binaries is virtually automatic. The vectors are known to Distella and it traces the rest of the program from those (though it will miss indirect addressing...as would all disassemblers). So the best way to approach it is to run a quick and dirty automatic disassembly, and then examine the remaining .byte lines for code that missed the cut (i.e. indirect jumps). Natually, this procedure goes much quicker when bitmaps are easily seen side-by-side with the data you are trying to decode, so you are better off creating a .cfg file to help Distella do it's job.

 

8k binaries are done the same way...though since Distella's automatic code detection will fail when decoding split bankswitched files, more of it will need to be done "by hand"...examining the resulting .byte data for routines that missed detection. To help in this case, I choose to create .cfg files that forces the entire binary to be disassembled into code...and examine the (huge!) resulting file for lines of gibberish or illegal instructions (a pretty clear indication that those lines are in fact DATA and not code). Then put all of that information into a better .cfg file.

 

Instructions:

 

First, any file over 4k must be split into 4k chunks. Use a freeware utility like Mastersplitter or HJsplit to do this.

 

Then, create a text file containing the following...

 

ORG FFFF

CODE F000 FFFF[/code]

 

Save this as a .cfg file...i.e. "Example.cfg"

 

Next, use that .cfg file with Distella to disassemble the binary (or one of the portions of a >4k file)...translating everything as code...

 

distella -pafscExample.cfg Example.bin > Example.asm

 

Distella will create a huge text file...usually well over 3mb in size. Open this file up and read through it to identify areas that either do not make sense or contain illegal opcodes (virtually no classic games seemed to use those). Keep notepad handy, and take down all of the addresses of those areas - this info will go into an improved .cfg file.

 

If you happen to notice that the JSR or JMP instructions aren't being labelled properly, it's probably due to an incorrect ORG address being used. Most 2k-4k games use $F000 as an origin...and 8k games utilizing the "standard" F8 bankswitching scheme are usually mapped to $D000 for the first section, and $F000 for the second.

 

Anyway, now that you know the addresses, you can have Distella translate the binary correctly. Edit the .cfg file to put your notes in...

 

(example)

ORG F000

CODE F000 F740

GFX F741 F7FF

CODE F800 FAAA

GFX FAAB FFFF

 

Note: I always use the GFX identifier instead of just DATA. This accomplishes 2 things...it allows me to pick up on graphics that I might have missed the first run through...and it will put each byte value on a seperate line in the disassembly - with the address that it was pulled from noted right next to it (along with a graphic bitmap of that value).

 

 

All of that is the easy part. The next is more challenging...finding all the indirect pointers and changing those into labels. And to get those, I do it the slow and headache-inducing way of taking a guess to what that data or immediate value is used for, editing it, and then seeing how that change affects the file when it's reassembled into a binary. Some are simple to guess at...like values that are immediately stored into a color or sound register...so I just begin with what I recognise, and reverse-engineer the binary going from there (labelling things as they are discovered).

[Nukey Shay]

Correction...

 

 

ORG FFFF  

CODE F000 FFFF  

 

Save this as a .cfg file...i.e. "Example.cfg"  

 

Next, use that .cfg file with Distella to disassemble the binary (or one of the portions of a >4k file)...translating everything as code...  

 

distella -pafscExample.cfg Example.bin > Example.asm

 

 

Damn I miss the edit button

[atwwong]

Leave it to Nukey to take the mysteries of the Atari and explain it in terms for us simple folk!