.Bin File Hacking Guidance Needed

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

Aug 15, 2012
  1. riceball7852
    OP

    Member riceball7852 A person with a life.

    Joined:
    Dec 14, 2010
    Messages:
    103
    Location:
    Building...
    Country:
    United States
    As a practice of hacking to translate a game from Japanese to English, I've found some text hidden within the arm9.bin and other .bin files.
    My main priority is to extract these text so I can translate them, and compress them back into it's original .bin file.

    My main problem is extracting the text from the .bin files so if anyone has any knowledge of this, please help me out!

    I tried using CrystalTile2 and Tinke... I'm not sure if there's more to it.

    Thanks!
     
  2. Auryn

    Member Auryn GBAtemp Advanced Fan

    Joined:
    Jul 21, 2011
    Messages:
    529
    Country:
    Switzerland
    The guidance for a bin file is that there is no guidance.
    A bin file can be everything from program to sound to graphics.
    Every bin files can be just one 1 file or a compressed 10000 files with sub archives like in AAI2.
    So if you want somebody helping you in here, you have to name at least the game and the file you are looking at or at least some screenshots of the beginning of it.
     
    2 people like this.
  3. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,746
    Country:
    United Kingdom
    "other bin files"
    Bin is a generic extension but if they are overlay????.bin then the same techniques as arm9.bin apply with one additional caveat, if it is utility.bin ignore it as it is the download play component and if it is another bin file somewhere in with the rest of the files then it is the same as a regular translation (figure out the format and go from there).

    Back on topic I am afraid you are probably in for a hard time- the arm9.bin is the main binary (the code that runs on the processor) for the DS which means where for regular text at worst you face line limits, maybe script size limits and some file level pointers here you get to play with assembly.

    The general idea will be somewhere else in the arm9.bin will be a number along the lines of 02XXXXXX which is where the text will end up falling in the main memory. The arm9.bin has a set location in memory and the caveat for the overlays is they also have a set location but a different one and it can be different between overlays- crystaltile2 will tell you what goes in the filesystem window. If it is just something like a menu, place names or something small like that then I would consider butchering the translation a bit/consulting a thesaurus to make it fit in the original Japanese locations but that is all but impossible to pull off when translating actual text beyond about three paragraphs I find.

    In the meantime you can follow regular text extraction methods- there will probably be something that indicates the start of the text, something that indicates a new line and something that indicates the end and there is no shame in finding the first or third by hand for now either. Likewise much of the text will probably be grouped together (maybe in a few sections but still grouped) meaning you do not have to find it scattered across the entire file.

    I will also note there is often more than just text in binaries and if you have found text it does seem to increase the chances of find more; technically including text in a binary is the sign of a lesser programming effort although a big asterix will want me to note modern compilers are odd things.

    Anyway once you have the text and the translation you are probably going to want to put it back in, you can rejig lengths of a given line easily enough but although expanding the length of a binary/overlay or otherwise working around a size limit is possible it is potentially quite hard to pull off unless you build in a function to pull things from the filesystem instead (and overwrite old text). My favourite hackjob workaround is most binaries will include maybe several kilobytes and certainly a few hundred bytes of text for wifi error messages which you might be able to commandeer.
    Back on topic so to speak if you are dealing with pointers and not fixed width sections or something you will probably find there is a bunch of the 02XXXXXXX type numbers somewhere corresponding to the text in RAM or it will be like regular pointers and after the initial 02XXXXXX there will be a bunch of numbers for it to add/calculate the location from like it does for regular pointers; 02XXXXXX is 32 bits and the ARM and especially THUMB instruction set can not handle a full 32 bit immediate in a single instruction meaning adding something to an existing 32 bit register and jumping to that is potentially far quicker. The former is potentially easier to do the wifi error messages workaround or if you are lucky and have a section of memory not used by the game but the latter is more akin to regular DS style text hacking.
    There are other workarounds you can try (dynamic decompression for instance) but I will wait to make sure you have the basic ideas here on lock before diving into those with you and you still have the more standard text hacks (16 bit to 8 bit encoding change, dual/multi tile encoding and such).
     
    2 people like this.
  4. riceball7852
    OP

    Member riceball7852 A person with a life.

    Joined:
    Dec 14, 2010
    Messages:
    103
    Location:
    Building...
    Country:
    United States
    Okay guys! Thanks for the help!
    I'm mainly aware that .bin is a generic type, due to my constant research.
    I'm just asking to gather bits and pieces.
     

Share This Page