1. shin-ramen

    OP shin-ramen Newbie
    Newcomer

    Joined:
    Apr 19, 2020
    Messages:
    4
    Country:
    United States
    I have been recently hacking the Animal Crossing: Wild World ROM and have found a BCH file inside it. I looked up ways to open these files only to be stumped, as most of the applications opening BCH files were made for 3DS ROM hacking and none of them worked anyway. Thanks in advance. ;)
     

    Attached Files:

    Last edited by shin-ramen, Jul 6, 2020
  2. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    31,156
    Country:
    United Kingdom
    All the files there have the first bytes decode as "LZ77" which is a type of compression, one we technically see a lot of on the DS but not with that at the start of a file (maybe as an extension).

    Immediately after is is 10 in hex which is a common thing for compressed files to start with (there is a reason you will see things termed type 10 compression), however some of those don't immediately have what look like they could be file lengths which I would expect to see.

    Basically it looks like you have a custom compression.
    You can try using a compression scan on the file (crystaltile2 has such a thing), or you can try slicing it off and feeding it to the likes of https://www.romhacking.net/utilities/826/ or dsdecmp.

    If it is going to be truly custom then in my case I would probably start by seeing if I could find the result in game and if it is in game then it will probably be in decompressed form in the RAM. Bonus for you here is you appear to have what look like several similar file types so you could possibly see what they do that way -- replace one of those with another and see what happens to the game (I assume the various logo bch files do logos you can see the results of in game quickly enough, be careful with savestates though and see about resetting and loading from scratch every time). Most compression starts from the start and goes from there (though the DS does feature one that goes from the back) so the stuff earliest in those compressed files is probably uncompressed and thus you might spot some similarities with the RAM data.
    However it might also be that you have to play with a disassembler to figure out what it is doing ( https://www.romhacking.net/documents/361/ is for the GBA and a command line debugger at that where you will probably be using no$gba on the DS but makes for a reasonable crash course in tracing. http://members.iinet.net.au/~freeaxs/gbacomp/#BIOS Decompression Functions and https://ece.uwaterloo.ca/~ece611/LempelZiv.pdf for a nice overview of compress -- most custom compressions are but minor tweaks on a baseline standard, and if indeed it is LZ77 then that is the simpler form of it, however many people erroneously call things LZ77 which in fact are more complicated versions).
    I do have a worked example of how a compression format works in https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ as well, though how much good it will do you here I don't know.
     
  3. cubes

    cubes Newbie
    Newcomer

    Joined:
    Sep 16, 2016
    Messages:
    5
    Country:
    Gambia, The
    @FAST6191 Can you please give us more info about this? We don't know what to do to get a hold of the custom compression format. Most files of ACWW use LZ77 but it is not the case here. :wacko:
     
  4. FAST6191

    FAST6191 Techromancer
    Reporter

    Joined:
    Nov 21, 2005
    Messages:
    31,156
    Country:
    United Kingdom
    Most custom compression formats are minor variations on the standard theme.

    Generally every few bytes (distance can vary but will typically be one nicer for the hardware to handle -- most things prefer multiples of 8, 16 or the like rather than 13 or whatever) will be a flag saying either move along as there is nothing to see or there is another flag that is split between how many bytes to go backwards from this point to find what you want and how many to read once you get there*.
    Any customisation there will break a basic decompression tool but if you have source to it (like cue's and dsdecmp will) you can change them easily enough.

    *note that the bits you get for this value to read might need a +2 or however long the flag is as you don't want to have your compression increase the file size if you can help it (going back 30 bytes to read 0 being pointless after all, indeed worse as you have increased the size of the file for no gain).

    You can also read the source code for cue's stuff https://www.romhacking.net/utilities/826/ or https://github.com/barubary/dsdecmp if you want. http://members.iinet.net.au/~freeaxs/gbacomp/#Image Compression on GBA and http://problemkaputt.de/gbatek.htm#biosdecompressionfunctions

    Finding out what the format is can vary.
    You can try to make sense of it manually by looking at the file itself. Doable enough but tedious. I prefer text for this approach myself (at the start with nothing to reference the text starts out fairly clear/plain and then increasingly turns to gibberish as you get more and more repeats) but graphics are also kind of an option (they also start out OK but get worse as the compression goes on).

    If you can find out where the file is loaded in the game (say by swapping the files noted above around and seeing what changed in the game, maybe deleting them/blanking at first to see if something crashes or errors out) and dump the memory. Things tend to be held as decompressed in the memory so you now have an example of the compressed file and decompressed file.
    Referencing back and forth between the two is then far nicer to figure out the encodings used.

    Finally (assuming there is no other tool out there -- we have found zip, tar and .gz files in DS ROMs before, though usually stuff the developers left in there and forgot to remove when building the ROM) there is the assembly approach where you find the file being decompressed and follow along with what it does. It is not the hardest assembly out there but you will probably have several steps and have to figure out what the greater purpose of it all is.





    In normal DS compression/BIOS compression/BIOS compatible compression the file will start with 10 (older games and some newer ones), 11 (newer games) or 40 (originally I think it was Golden Sun but made it to a few others in even later ROMs) and then be followed by how big the file should be, and that arrangement is what it seems a lot of compression searching tools look for and I was attempting to spot above.

    If you have source you have recompression options as well but in a pinch you can continue assuming it is compressed but leave it uncompressed and insert the "nothing to see here" bytes throughout the file. In some cases the compression will be detected/noted in some other file and you can fiddle with that instead (the DS binaries, which use a subtly different take working from the back of the file, BLZ, have this).
     
    shin-ramen likes this.
Draft saved Draft deleted
Loading...

Hide similar threads Similar threads with keywords - files,