Hacking Trying to decode text from Apollo Justice (DS)

[AnonymousWaddleDee]

I'm trying to edit Apollo Justice: Ace Attorney's text for a project I'm doing, but I'm a little stuck figuring out how to access that text. I know almost for a fact that the dialogue is in the mes_all.bin file, just based on the name and by comparing with other Ace Attorney and DS Capcom games, but I can't decode the text in it. I've tried relative searching and decompressing it with the standard compression formats, but it didn't work. Unless I've missed it, I don't see any signs of standard compression, and I don't see any recognizable text at all in the file, which I've seen in other compression examples. I'm currently trying to see if I can find the text at runtime, but it's not working so far and I'm not sure how to proceed.

Can anyone help me figure out what's going on here? Is there custom compression that I'd need to reverse engineer, or am I missing something obvious?

I'm a beginner to DS romhacking, coming from SNES romhacking, so while I've read all the documentation I can find, there's a lot of stuff here I'm not used to yet. Thanks for your help.

 

[plasturion]

Usually NDS roms have some variations of lz compression, and japanese text usually is encoded in shift-JIS.
Ndstool, Crystaltile2 or Tinke are recommended tools to dive into file structures to preview or modifie text or graphics data.
Fortunally someone before make a tool to make own cases in Phoenix Wright series, it make gives you some hints: here or here

 

[AnonymousWaddleDee]

Thanks for your reply. I've been using both Tinke and CrystalTile2.

I didn't get a solution, but I've made some progress by referencing the links you gave and studying the file. Here's what I know about the mes_all.bin file that has the dialogue:

It seems to be some kind of custom archive containing compressed text. There's no header, but the first part of the file (until around 0x300) is a table. One item in the table is eight bytes, consisting of four bytes for what might be the uncompressed size of the text, followed by a four-byte pointer to a piece of text, with the offset counting from the start of the file. Each pointer points to a "10" byte, so I'm taking that to mean the compression is LZ10.

But I still have no idea about the text itself. When I try to decompress it using Cue's tools, I get something that doesn't look at all like text in any encoding (and for some reason, decompressing it makes the file size go way down). I would attach the mes_all.bin file for other people to look at, but I'm not sure whether posting it is allowed. It's easy to find in the ROM, anyway.

Do you have any idea what's going on here with the text or what I could try to get readable dialogue out of it?

Edited to add: I also did a memory search and located the table part of the file in the RAM. It's at a static address, but although I was hoping to see the decompressed text, there's nothing nearby.

 

[plasturion]

So it seems it's a pointers table to files, so if you can make a code for slice to a smaller files where 10byte starts.
Not sure, but did you tried to decode data with this charset? https://github.com/Missingmew/phoenixtools/blob/master/scripting/charsets.c

 

[AnonymousWaddleDee]

I hadn't seen that, I'll keep it in mind. But the reason I said that what I get after decompressing isn't text is because it all looks like this. There can't be any sentences there. The weird pattern going on, as well as the file size decreasing instead of increasing (when I try to decompress only smaller part of the file, I get a result that's zero bytes), makes me think it wasn't decompressed correctly. But with a 10 at the start of every section, I'm sure it must be LZ10. I had to delete the table in order for the decompression to work, so maybe something is off there.

 

[bilibili2011]

as indicated here https://github.com/Missingmew/phoenixtools
use tool to extract scripts from mess all.bin
then use convert text messages to see text.
author messed up his git as some files disapeared, find them here
good luck for editing, looks complex. didnt even look on how to compress it back.

 

[AnonymousWaddleDee]

Thanks! I was looking for convert-text-messages before, but I couldn't find it. I'll check it out and see if it helps.

 

[AnonymousWaddleDee]

(Question in the second paragraph)

I compiled convert-text-messages.exe (after a lot of work), and using that information I successfully figured out how to edit the text. It turns out this was more obvious than it seemed: it's just an archive of LZ10 compressed files, like I thought. The part where I got stuck was that I didn't realize the characters are encoded with two bytes rather than one. That's why my relative search on the extracted file didn't work, and why it looked like there couldn't be text with all the zeroes there. The game uses two-byte encoding rather than one-byte because it has lots of special commands the text engine uses in mes_all.bin assigned to hex values. The upside of this is that I can theoretically edit music, sound effects, animations, graphic effects, and text, all from one document. As long as I don't need to do any mass-editing, I also don't need to write my own program to reinsert the text, because I can just use the crude method of recompressing the edited text and copying those bytes back into the original mes_all.bin file and then replacing the mes_all.bin file in the ROM with Tinke.

I have a question, though. Will it be a problem if the mes_all.bin file I insert into the ROM is bigger than the original was, since I want to add text? On the SNES, I'd just find some empty space and repoint the text, but I can't do that here with a file with no empty space. If I expand the file to add more text (and change the table at the top of the file accordingly to match), will that mess up the code in the rest of the ROM? How should I go about this?

 

[plasturion]

mes_all.bin is not arm9.bin or overlay.bin so It doesn't load to memory and stay as exacutable, so it's not so much restricted in size i guess. It doesn't load full content in ram too, so only some parts of it are extracted and decompressed. Pointers table, yes all the pointers should be recalculated acroding to made even a single change(should be, but if you don't want touch rest of them, changed data only even in size or smaller will be accepted). Everything should works fine. if you build rom with ndstool, dsbuff. Files structure dosen't change but files table of nds filestystem will be automaticly updated by tool itself so no need to worry about a thing. Hope you don't mean to add more text by add more pointers, more compressed data. It could be more complicated then. However it's not obvious how big should be uncompressed script in ram. You need to test yourself by trying to check available space, but I think authors didn't make anything too tight leaving enough space to work with.

 

[AnonymousWaddleDee]

I've been having success adding more compressed data to the file, so you're right, making it bigger doesn't seem to be a problem. But I admit I was also thinking about adding additional pointers for additional sections of text. Assuming I can find where the code switches between the sections of mes_all.bin it decompresses and loads into RAM (it only loads one section corresponding to a pointer at a time), what problems could I encounter from trying to add more pointers?

As a related question, how do you actually edit assembly? Do you insert the byte code into arm9.bin with a hex editor? You mentioned a problem with making arm9.bin larger, but I'm not sure how restricted the size is.

 

[plasturion]

So there's a way to add a pointers, nice! Game itsef only points previously defined pointers I suppose. Adding new pointers you should tell the game about it isn't that so (in arm9.bin i guess, if not it seems mess_all.bin pointers table store in example a "case" counter and game can handle somehow by its auto routine) ? If you found it then it's fine. As for me i did in my previous romhack minor changes with few bytes so yes, I used No$gba debugger to apply changes test it, and read the machine codes and edit that with hexeditor. Maybe there's a better more elegant way, but for some minor changes is enough.
It depends, overlay files are the ways to deal with not big amount of ram and share space for other data. It works like standard file loading into memory but it's loded in case of different game modes, it overlays some arm9.bin executable space. So if developers use that kind of tricks, it's tight i guess. Can't tell how much is restricted for this game, maybe dozen of kB, less or more, idk, just try. Didn't look in rom yet, so just I'm only guessing.

 

[AnonymousWaddleDee]

I probably said something wrong, I haven't found a way to add pointers. For the past few days though I've been using Ghidra to look through the assembly and try to figure it out. When I try to add another pointer to mes_all.bin to some example text, the game softlocks before it makes it to the title screen. It gets softlocked in the BIOS area, around 1FF87BC, where it gets stuck in an endless loop a few instructions long. Because it's the BIOS area, I assume it has something to do with decompression or something like that, but I'm not sure. I'll keep looking into it, but I'm not sure why adding a pointer would cause this.

The way it works is that the game chooses which text section to load into memory, and then shifts that index left by three bits to make a pointer, which it uses to reach the correct pointer in mes_all.bin to the text section it wants. mes_all.bin starts with "71" for the number of pointers/text sections it has, so I changed it to 72, but that wasn't the problem. I don't think I need to tell arm9..bin about the new pointer besides that I need the game to choose it, but I'll look into that too. I know which value determines the text section the game wants, so I was planning to use an Action Replay code to make it choose my pointer. I can't test that until I make it to the title screen, though.

I don't think it's possible for anyone without game-specific knowledge to help, but have you seen anything like this before?

As a side question: does arm9.bin break if you add additional instructions to the assembly? I need to add more instructions, but it seems like it would mess up all the memory addresses.

 

[plasturion]

bit shifting to get a pointer? I know that memory address often starts at 0x20000000h or something like that so to count absolute value in ram usualy you need add/sub this segment for pointer. I also met before with relative pointers... they points from other one begining in similar way. So your pointers table has something like pointers counter (72), in this case you should be good to go.

Did I see? more or less but i think i didn't. : ]

depends if is not an overlayed space, hard to say, I didn't tried, maybe someone else can help here.