arm9.bin Hacking Guidance Needed

Discussion in 'NDS - ROM Hacking and Translations' started by riceball7852, Aug 27, 2012.

  1. riceball7852

    riceball7852 A person with a life.

    Dec 14, 2010
    United States
    I know this is my third time asking for help about hacking/translating a ROM.
    Okay, so here we go...

    I'm currently translating a game from Japanese to English (as a practice for the future to translate other ROMS) and I'm currently trying to extract/edit some contents within the arm9.bin file (ex. font table/data, some text, etc.)

    It would be nice if someone can point me out which tools are necessary for this process or tell me the steps in hacking the arm9.bin file.

    Thanks again for helping me out!
  2. FAST6191

    FAST6191 Techromancer

    pip Reporter
    Nov 21, 2005
    United Kingdom
    The ARM9.bin files are probably all going to be different without a simple method of extraction via a premade tool. Certainly you can direct a tool to trim the file to your desired sizes. (filecutter) and equally under documentation has some of the better worked examples of DS Assembly hacking out there. Perhaps the most notable of tools is something to handle the binary compression (the DS binaries and overlays use a custom type of compression called BLZ which differs from the standard LZ compressions otherwise seen on the DS) - crystaltile2 has issues recompressing to the format so for anything other than simple disassembly purposes it tends not to be used. Still and can handle extraction and compression. After that a disassembler, assembler and a debugging grade emulator for the DS are useful.

    Disassembly- IDA (the standard paid debugging tool for almost all hackers although the free version might be able to get something done), crystlatile2 and ndsdis2 ( ) and the emulators all afford a measure of static disassembly.

    Debugging emulator
    no$gba is the best right now but I am still not sure if it can be purchased again and running newer games is a pain as well.
    desmume has some debugging functions- disassembly, memory viewers and more but no no$gba or VBA-SDL-h grade tools.
    iDeaS ( ) has a basic run to selection command as well as stepping commands- not enough for a full tracing session but you can get an awful lot done with it.

    ARM ASM kit from which is a frontend to arm-eabi which also does
    Crystaltile2 and IDA have some abilities here as well.

    Tools and basic usage I covered most of in the recent version of my ROM hacking guide

    Text in the ARM9 then- many of the wifi debug messages are in the ARM9 and it is certainly not unheard of to have the text within either the ARM9.bin or an overlay for it. It it kind of unfortunate when it does as it makes life harder than it might be for the basic file level stuff most of DS translation is concerned with. It need not just be text either and I seen lots in there (mainly graphics, fonts and things like character stats) before we even get to the weird stuff like Rockman EXE Operation Shooting Star where almost everything was an overlay or otherwise in the binary.

    "font table/data"
    Do you want to run a debugger to find the text encoding and/or pointers because there are many easier ways to find the encoding if so.

    Frankly most of it is fairly normal but for the pointers- where on the DS they might be file or section level and so be fairly simple numbers here as the binary is loaded into and run exclusively from memory (same for overlays) the pointers are either fixed width/markup style (neither unheard of) or they are memory locations (or some minor maths on a given location).
    Better yet if you have the pointers you have the section lengths (or end markers for it) which can be used to guide filecutter or something like it. Short version is where your file level pointers are probably four or eight hex digits (00 padded in the case of eight) almost certainly starting at the file or the usual offset/relative stuff these will look something like 02?????? unless they have a 02?????? value to start with and then some more standard relative stuff (it is easy enough to add to a number and may even be quicker- certainly I have seen a pointer in a register and then things added to it from memory before).

    Then comes the space issue- repointing is fine if you do not change the overall length but that is easier said than done for most translations as far as making it the same or shorter. Frankly if it is a single word or phrase bust out the thesaurus but otherwise you are finding a location in the RAM (often far easier said than done) or making some (remember the wifi debug messages- they are always there in RAM, usually several kilobytes in length and rarely used so go nuts).

    After this I guess it is talking about font handling and similar such things. This more likely ties into graphics hacking unless you want to cover 16 to 8 bit encoding conversion which is another good way to generate more space actually. Short version is you find the location that deals with decoding the text and either get it to read 8 bits at a time or carry on with 16 but decode two characters from it.

    I know you tried not to but you have asked a really general question and I agree where a lot of it has not been covered in as much depth as other parts of either graphics hacking or text hacking it will be a repeat of some stuff or otherwise typing at length.
    1 person likes this.
  3. Castiel

    Castiel GBAtemp Advanced Fan

    Oct 15, 2010
    Ba Sing Se
    Is it the same game as from this thread? If, so, which game are you trying to translate?
  4. Chaosruler

    Chaosruler GBAtemp Fan

    Jun 5, 2009
    p1ngpong's dream
    If you want to learn more about decrypting the ARM bin file, ask cracker, he's the best person I know who can handle it