Hacking ROM Hack Translation Unknow encoding text

[hoothin]

I'm trying to hack Assassin's creed II for the DS, I've already unpack the Glob.bin, but I can't find any text from the rom.
The only dubious file is Strings_US.strings. I try to recognize the text from it but failed.
No encoding is matching, and I seach the words "attacks" in game with relative search and don't return any result.
I searched the internet and there's no more information about the strings file of nds. Is there anything known about these file formats and encoding?

 

[hoothin]

I just get a message "The format can be open in AutoDUMP project" when I try to open the string_us.strings with Tinke which confuse me.
Anyone has some idea for this?

 

[FAST6191]

Not sure what autodump is offhand. I presume you searched for it as well. That said you can use this as a learning exercise if you wanted.

That did not look compressed (I would generally not expect UO7 to be repeated that much that close together if it was) so there is that.


There is more than relative search (which assumes all the characters follow the traditional a,b,c,d... ordering, something that more or less only exists for English and some things also using the Roman character set but even those can be dubious) when it comes to figuring out encoding.

You have everything from distribution checks (most common character is actually likely to be space, every word has a vowel but a few which have a y instead, said space is not going to be more than about 7 characters on average between things, the same scorings in scrabble will probably also be the distribution...) to tracing (as in you go back from on screen to how it appears in RAM/ROM) to corruption/fiddling -- if you are reasonably sure that is the text (and strings with a bunch of country/language short form names/codes in their native language, though I am not sure what FC is, is a very good bet for it) then change characters around in that (preferably use a character you see in the text to stop from using an illegal one and the game not knowing what to do). Indeed even if relative search works for a given script you will probably end up changing characters to figure out punctuation, or fill in blanks as if you were playing a crossword (in this case a multidimensional crossword as it presumably has to work not only for that word and one crossing it but all other instances across the file/section that encoding is used for*)

*go back to the NES and you can get things that change screen by screen. I am not aware of anything like that for the DS but plenty of things have different encodings between menus and game and credits and whatever else.

 

[hoothin]

Thank you for the reply! That puts a different light on it indeed.
I checked the .strings file in hex view but still can't find any regularity. "UO7" doesn't appear in other position.
Then I analyse the font tile of this game and confirm the order from a-z is traditional.
So I guess maybe the .strings file is not a text file?
After that where can I find a guide how to disassemble & debug a nds game at runtime to find position the real text from since I know a little gba arm asm?
Thanks again!

 

[FAST6191]

Try editing the strings file to see what changes in the game (swapping characters around should do it).

Font order from graphics... it is more of a clue than anything hard and fast - it is good stuff for the NES but by the time of the DS then encodings could be quite custom/software defined.

As far as debugging goes. If you are already versed in the GBA then easy enough to jump up. ARM9 ( http://imrannazar.com/ARM-Opcode-Map ) does not rock the boat compared to ARM7TDMI of the GBA (not like going from old school arm https://heyrick.eu/assembler/ to modern mobile phone or anything). Indeed I would probably still link http://www.coranac.com/tonc/text/asm.htm as a crash course in ARM assembly despite that being for the GBA.
Still going to be all the same break on read/write/execute, log on said same or fiddling. Granted that is mostly the same whether you are on a Vic20 or the latest and greatest PC game.

Might even be the same emulator as no$gba is probably the foremost of things here
http://problemkaputt.de/gba.htm
http://problemkaputt.de/gbatek.htm#dscartridgeprotocol (and naturally gbatek in general for hardware info) covers the cart read command -- sadly unlike the GBA the cartridge is not visible in memory so you instead get nice B7 commands to go through. That said grab from RAM and search the ROM does pretty well.

https://melonds.kuribo64.net/ seems to be rising up in the estimations of some. Not inclined to make the jump myself.

You can probably also crowbar desmume into working with GDB which in turn brings in https://wrongbaud.github.io/posts/ghidra-debugger/ and maybe IDA, or just plain old GDB if you are more familiar with that (have seen a few go there, especially if no$gba is being a pain).
Crystaltile2 has limited options to pull things in from various emulators as well but that is not so much real time debugging as NEF files and memory dumps, though has a nice enough static disassembler/assembler.
Might as well have a copy of the venerable ndsdis2 as well.

If you need to handle compression then https://www.romhacking.net/utilities/826/ (binaries are not the normal DS compression, you want the BLZ tool in that. Also crystaltile2 often lies about the ARM9 and overlays being compressed).

For assembling then various choices. Most of the debuggers above will have options (do bear in mind that the ARM9 and overlays are in RAM and decompressed when there so you can tickle them with cheats https://doc.kodewerx.org/hacking_nds.html ). Single instruction/small in place stuff I have a very old script that uses the GNU assembly ARM EABI thing ( https://gbatemp.net/threads/crackers-ds-trainer-maker-tutorial.44410/ https://web.archive.org/web/20100209071934/http://crackerscrap.com/ ). Others will probably go for ARMIPS https://www.romhacking.net/utilities/635/ (might want to check the homepage for it as later versions/betas are a thing).

Have some worked examples of things in https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ as well.

 

[hoothin]

Thank you, FAST6191.
I've tried to read the asm code and get something.
This is the sub function which input r0 and write result strings.

This is my flowchart when I attempt to interpret the sub function.

And this is source byte find from pointer

This is the target of r3 in sub function

This is the result

I can make a tool to get the results now, but I don't how to convert the readable string to source.
I need your help to tell me is it available to find a easy way to get the relation between them?
Or can you give me some guide to get that relation according to your experience?
Again, Thank you very much.

 

[FAST6191]

That is an odd bit of code. Don't know if that is dubious coding or dubious compiler. It might help you get a firmer grasp on it if you simplified it as a lot of that is loops but done in assembly fashion (for instance the R1 last bit is 0 thing, the first branch in your flow chart, is the same, except it sets R0 as different things depending upon the result) or cleanup code for returning to the main loop.

Starts with a multiple of something, odd for text but you see it in 3d graphics and I have seen it in an archive format before on the DS, the principle is far older still though. After which is takes it time generating a final result.

Said final result apppears to be U16 unicode (basically ASCII text but with 00 between each character to make it 16 bits).
The DS (and GBA) does have a filtering option used mostly for graphics wherein changes are noted rather than absolute/final values which can make compression easier. I would almost wonder if this is something like that.

I have seen scripts and such looking like this in other DS games (quite often you will see runs of ascending values) but have not really investigated them.
Here nothing immediately jumps out at me as what it is doing.
Doesn't look like simple addition or anything like that.
If it is an amount to expand it is very convoluted.
The target of R3 looks like it is counting upwards but there are some notable jumps. Could be some kind of lookup.

I would want to play with the input data and see what the changes to the results are.

 

[hoothin]

Finally, I realize that it's just a custom huffman compress. [22bf0b4] stores the data of huffman tree. Source bytes are huffman bytes and need to be read by one bit.
Thank you and I can modify the text now.

 

[fciq]

I replace english voice into chinese voice. If can make a chinese ver.I can translate.
here is the video https://www.bilibili.com/video/BV1CZ4y1m7Xc/

 

[fciq]

Finally, I realize that it's just a custom huffman compress. [22bf0b4] stores the data of huffman tree. Source bytes are huffman bytes and need to be read by one bit.
Thank you and I can modify the text now.

Can you modify text into chinese?

 

[FAST6191]

Quite rare to see Huffman in this day and age, especially one looking like that. Congrats on figuring it out.