I know how to take a rom, mostly gba, open it in tlp and see if the font is encripted, i dont know what to do if it isnt. I can relative search and make a table, not quite sure about control codes but i think i can figure them out. etc. etc. There are two gba roms i want to try and just do a basic translation on, from japanese to english obv. I havent tried it yet but i would like to know the best way to go about and make a japanese table. I have advanced knowlege of kana, i just want to know to reletive search the values based on a i u e o ka ki ku ke ko sa ... = 00 01 02 03 04 05 06 07 08 09 0A or i saw somewhere else on line that had it going a ka sa ta ... = 00 01 02 03. Which is the way to go about it, and i dont think my current relative search wont work and display that. Just next level basic stuff really. And I heard of ROM hacking 101 pdf, but i can find it can someone point me to it.
The DS rom has a file system like CD games so while you have to trace stuff for the DS or go some brute force you can narrow it down quite a bit easier. It also means you do not have space issues half as much as you have with the GBA although this means IPS is out of the picture most of the time as it does not deal with shifting data well.
As for documentation I am working on some stuff (mainly a mess of links a couple of articles), stickied at the top of the forum:
http://gbatemp.net/index.php?showtopic=73394
Japanese DS roms frequently use a 16bit font so you might need to change your relative search, they also frequently use shiftJIS or unicode.
Control codes are normally simple things either in the pointer area or in the main body to make text appear bold/italic or start a new line or even be a space between characters.
Still tables.
Your best bet assuming it is not something like shiftJIS without messing with ASM is probably corruption:
find the text in the rom ( http://www.romhacking.net/docs/361/ ) and the place in the game (savestates are good here), hopefully compression is not used but the above technique should be able to tell you.
Now you can either tweak the rom or tweak the ram it ends up in.
By tweaking stuff you can work out what characters do what (nice as Kanji can appear in just about any order ranging from stroke count to what order they appear in to completely random).
Make a table from this info, dump the text and you are away.
As for documentation I am working on some stuff (mainly a mess of links a couple of articles), stickied at the top of the forum:
http://gbatemp.net/index.php?showtopic=73394
Japanese DS roms frequently use a 16bit font so you might need to change your relative search, they also frequently use shiftJIS or unicode.
Control codes are normally simple things either in the pointer area or in the main body to make text appear bold/italic or start a new line or even be a space between characters.
Still tables.
Your best bet assuming it is not something like shiftJIS without messing with ASM is probably corruption:
find the text in the rom ( http://www.romhacking.net/docs/361/ ) and the place in the game (savestates are good here), hopefully compression is not used but the above technique should be able to tell you.
Now you can either tweak the rom or tweak the ram it ends up in.
By tweaking stuff you can work out what characters do what (nice as Kanji can appear in just about any order ranging from stroke count to what order they appear in to completely random).
Make a table from this info, dump the text and you are away.
change my search like how, are there bigger intervals between letters, and just some terms i dont know. IPS... Arm?... Difference between 16 bit font and 8 bit(i assume 8 bit is default)... diference between shiftJIS(and what it is) and ASM
and how do i access these DS files that it uses, ive heard the word de-compiler before is it something like that i have to code in visual basic or something
and how do i access these DS files that it uses, ive heard the word de-compiler before is it something like that i have to code in visual basic or something
My apologies that was a rushed response.
8 bits are used but as that is just about enough to fit the kana, a roman alphabet and what appears to be a heart you need more info for kanji. The usual route is to only take what you need and hope but for the more inventive/lazy you can up it to 16 bits which amounts to 65536 characters: more than enough for just about every language going.
Conventional relative search takes one 8 bit string and then checks the next string to see if it is a value acceptable (think a=1, b=2 c=3) wanting the line acb and seeing 132 or more accurately a number with a first digit a second 2 higher and the last with 1 above the first or 1 below the last means there is a good chance you have the string responsible.
Unfortunately most games as already mentioned now use 16 bits to represent a character and as the old tools are geared for 8 bits it falls flat on its face.
Thus you need to find a relative searcher capable of 16bit intervals which again may be a problem as some games use 00 to end a line (8 bits) but if you can get it you should be OK.
At next reply yeah breakpoints and brute force, it is not glamorous but it works.
The file system (strictly it is a deconstructer, decompiling refers to turning binary code to high(er) level code), check the link in my signature about DS rom rips and enhancements for basics.
Also ndsts http://www.gbadat.altervista.org/tools.htm
ndstool (frontends include DSlazy and DSbuff)
Or you could even grab by hand:
http://nocash.emubase.de/gbatek.htm#dscart...roromfilesystem
IPS: international patching system (or something similar). It is an old patching system common in everything up to the n64, it only does files up to 16 megabytes though and it works by having an address and changing that. You shift the code but change nothing and the patch making app sees massive changes and makes a massive file. Therefore IPS is no longer used. Popular alternatives include xdelta, PPF, custom made patching types/tools and BSDiff (a lot of trainers other than those by cracker and bleep and patches from release groups use it).
ARM: (I do not recall mentioning it but OK) the type of processor the DS has. It has an ARM7 and ARM9. See the link I gave for the DS file system by hand for (much) more.
ASM: short for assembler/assembly. Binary is what the machine runs and source is what the developer makes. It normally refers to diassembled code where the binary is made to look nice to human eyes and the creation of code to be assembled.
8 bits are used but as that is just about enough to fit the kana, a roman alphabet and what appears to be a heart you need more info for kanji. The usual route is to only take what you need and hope but for the more inventive/lazy you can up it to 16 bits which amounts to 65536 characters: more than enough for just about every language going.
Conventional relative search takes one 8 bit string and then checks the next string to see if it is a value acceptable (think a=1, b=2 c=3) wanting the line acb and seeing 132 or more accurately a number with a first digit a second 2 higher and the last with 1 above the first or 1 below the last means there is a good chance you have the string responsible.
Unfortunately most games as already mentioned now use 16 bits to represent a character and as the old tools are geared for 8 bits it falls flat on its face.
Thus you need to find a relative searcher capable of 16bit intervals which again may be a problem as some games use 00 to end a line (8 bits) but if you can get it you should be OK.
At next reply yeah breakpoints and brute force, it is not glamorous but it works.
The file system (strictly it is a deconstructer, decompiling refers to turning binary code to high(er) level code), check the link in my signature about DS rom rips and enhancements for basics.
Also ndsts http://www.gbadat.altervista.org/tools.htm
ndstool (frontends include DSlazy and DSbuff)
Or you could even grab by hand:
http://nocash.emubase.de/gbatek.htm#dscart...roromfilesystem
IPS: international patching system (or something similar). It is an old patching system common in everything up to the n64, it only does files up to 16 megabytes though and it works by having an address and changing that. You shift the code but change nothing and the patch making app sees massive changes and makes a massive file. Therefore IPS is no longer used. Popular alternatives include xdelta, PPF, custom made patching types/tools and BSDiff (a lot of trainers other than those by cracker and bleep and patches from release groups use it).
ARM: (I do not recall mentioning it but OK) the type of processor the DS has. It has an ARM7 and ARM9. See the link I gave for the DS file system by hand for (much) more.
ASM: short for assembler/assembly. Binary is what the machine runs and source is what the developer makes. It normally refers to diassembled code where the binary is made to look nice to human eyes and the creation of code to be assembled.
I do not tend to do relative search (brute force and ASM work for me) but you can use wildcards every other character, it will knock down the efficiency somewhat but it is about all you can do.
DS games for ages and GBA games a lot of the time.
DS games for ages and GBA games a lot of the time.
ok now sorry to keep bugging you but you have been a huge help, like a 16 bit font just means that the font is stored in 4 hex digits like a could be 0001 instead of 01 and then b would be 0002? how does brute force work on that? and about the file thing so like somehow(not sure if i make my own program or what) but there are like txt and png files or others on a ds rom file that can be taken out and edited, then do i need to do editing on them in hex editors still or do i just get the files out or am i completely mistaken?
Yeah on the 16 bit part, it just means you have 65536 combinations rather than 256 although even if they are not relative they are normally grouped together and you can normally make a good guess based on what you see. Also take a look at the font file, they are normally in the order they appear in there.
To get the DS rom apart I normally use a batch file and ndstool:
http://ezflash.sosuke.com/viewtopic.php?t=457 but you can use one of the many tools available.
As for once you get a DS rom apart, some roms like the original phoenix wright and Tony Hawks games are another big file with their own file system so that is then another file system you need to figure out (most of the time it is just a list of offsets followed by a list of file names) or you can use GBA and earlier console methods.
Most games though have a whole bunch of files to do various things, a lot of these formats are given in the Nintendo DS SDK that they give to developers which means a lot have been reverse engineered (it is still worth learning to do it yourself though as it is not that easy all of the time).
A few roms use standard windows formats, namely electroplankton (wave files) and the official browser (most of the internals) but do not count on it. There are a couple of tools to edit but most of the time you either have to create your own (see a lot of deufeufeu's work) or tweak stuff to work with more general purpose tools (my usual route).
This is all covered in the links in the guide at the top of the forum but here is one to get you started:
http://tahaxan.arcnor.com/index.php?option...&id=7&Itemid=36
To get the DS rom apart I normally use a batch file and ndstool:
http://ezflash.sosuke.com/viewtopic.php?t=457 but you can use one of the many tools available.
As for once you get a DS rom apart, some roms like the original phoenix wright and Tony Hawks games are another big file with their own file system so that is then another file system you need to figure out (most of the time it is just a list of offsets followed by a list of file names) or you can use GBA and earlier console methods.
Most games though have a whole bunch of files to do various things, a lot of these formats are given in the Nintendo DS SDK that they give to developers which means a lot have been reverse engineered (it is still worth learning to do it yourself though as it is not that easy all of the time).
A few roms use standard windows formats, namely electroplankton (wave files) and the official browser (most of the internals) but do not count on it. There are a couple of tools to edit but most of the time you either have to create your own (see a lot of deufeufeu's work) or tweak stuff to work with more general purpose tools (my usual route).
This is all covered in the links in the guide at the top of the forum but here is one to get you started:
http://tahaxan.arcnor.com/index.php?option...&id=7&Itemid=36
i know you say you use brute force, but im not sure, i think, but not sure if this japanese game i want to translate(gba) has 8 or 16 bit font and how to find out? and maybe some tricks to fidguring out how get the codes without relative search i dont even know what part of the huge number of codes to look in like a section.
If you tell us what game it is maybe I can have a look and explain how I got a result.
Either way you do it the chances are you will have to tweak stuff to see what is what (on rare occasion you can see it but by and large experimentation is the key). Fortunately emulation is perfect for this.
Your best bet would be to find the text in the ram (the GBA/DS has sections for work ram (WRAM: where the text is) and video ram (VRAM: where the graphics are) so it should not be that difficult as with an emulator it is fairly easy to tweak values which enables you to see what is going on there.
Even better is that you should be able to dodge any compression by doing it this way and identify it (most roms but not all use the inbuilt decompression algorithms but even then you can still identify it). Better still if it is not compressed then you can find the text very easily by simply searching for what you just found (sidenote this is how I tend to find palettes for graphics so have a read of this guide as it can be adapted for text: http://etk.scener.org/?op=showtutorial&st=3 ).
Other ways of finding text: searching for pointers, the GBA has the cart mapped in memory (08XXXXXX for the first 16 megs and 09XXXXXX for the final 16 megs). Compression can muck this up and it is not unknown for a game to use the mirrored cart memory but it worth a look:
http://nocash.emubase.de/gbatek.htm#gbamemorymap
Basically search for 08 and if you end up with a list of them with 6 hex digits in between them you have your pointers which give you your text. If you have a nice search you can use wildcards to force six 6 hex digits between results which can cut down errors a bit (although as 08 is still more than possible in a pointer do not expect flawless results).
The final text thing I should mention is half width and 16bit flag (I should have done it already but forgot) encodings.
Half width is simply a mix and match approach where half of a character is an 8 bit value (it could be 16 but I have never seen it done as 16 bit is enough for nearly every language in existence to get a look in) and the other half another. Strictly it is a 16bit encoding but it can be a bit more complex in dumping it. It is quite similar to the dual/multiple tile encoding I mentioned above (where a string might be a whole word and sometimes the two methods are actually combined for various reasons: 8 bits for one half of the name and 8 for the other half)
16bit flag.
ASCII in the original form is 7 bits in an 8bit world, that is to say only the last 7 bits are used but each character is still 8 bits (the first is zero).
Now you can if you want use the highest bit (MSB- most significant bit) to say if I am a 1 here use one of the 16bit encodings/take the next 15bits as a character.
I have not met it so much when hacking GBA games but it was very prevalent in the SNES/megadrive era (the GBA actually uses a somewhat similar approach at processor level but that is a different story, if you want to go there for some reason read up on arm and thumb encodings at gbatek linked above).
Either way you do it the chances are you will have to tweak stuff to see what is what (on rare occasion you can see it but by and large experimentation is the key). Fortunately emulation is perfect for this.
Your best bet would be to find the text in the ram (the GBA/DS has sections for work ram (WRAM: where the text is) and video ram (VRAM: where the graphics are) so it should not be that difficult as with an emulator it is fairly easy to tweak values which enables you to see what is going on there.
Even better is that you should be able to dodge any compression by doing it this way and identify it (most roms but not all use the inbuilt decompression algorithms but even then you can still identify it). Better still if it is not compressed then you can find the text very easily by simply searching for what you just found (sidenote this is how I tend to find palettes for graphics so have a read of this guide as it can be adapted for text: http://etk.scener.org/?op=showtutorial&st=3 ).
Other ways of finding text: searching for pointers, the GBA has the cart mapped in memory (08XXXXXX for the first 16 megs and 09XXXXXX for the final 16 megs). Compression can muck this up and it is not unknown for a game to use the mirrored cart memory but it worth a look:
http://nocash.emubase.de/gbatek.htm#gbamemorymap
Basically search for 08 and if you end up with a list of them with 6 hex digits in between them you have your pointers which give you your text. If you have a nice search you can use wildcards to force six 6 hex digits between results which can cut down errors a bit (although as 08 is still more than possible in a pointer do not expect flawless results).
The final text thing I should mention is half width and 16bit flag (I should have done it already but forgot) encodings.
Half width is simply a mix and match approach where half of a character is an 8 bit value (it could be 16 but I have never seen it done as 16 bit is enough for nearly every language in existence to get a look in) and the other half another. Strictly it is a 16bit encoding but it can be a bit more complex in dumping it. It is quite similar to the dual/multiple tile encoding I mentioned above (where a string might be a whole word and sometimes the two methods are actually combined for various reasons: 8 bits for one half of the name and 8 for the other half)
16bit flag.
ASCII in the original form is 7 bits in an 8bit world, that is to say only the last 7 bits are used but each character is still 8 bits (the first is zero).
Now you can if you want use the highest bit (MSB- most significant bit) to say if I am a 1 here use one of the 16bit encodings/take the next 15bits as a character.
I have not met it so much when hacking GBA games but it was very prevalent in the SNES/megadrive era (the GBA actually uses a somewhat similar approach at processor level but that is a different story, if you want to go there for some reason read up on arm and thumb encodings at gbatek linked above).
Similar threads
-
@
RedColoredStars:
Im going to see the new Godzilla next week. Sure they aren't some cinematic masterpieces but the last few were all really great and fun popcorn flicks to see on the big screen. -
-
-
@
RedColoredStars:
Oh. Wait. I took my mom to see Elvis. I think that was the last time I went. I'll most likely see the new Planet of the Apes in a theater too.+1
-
-
@
RedColoredStars:
..since it's locked and I really dont want to be a part of their attention seeking nonsense any longer.
-
-
-
-
-
-
@
RedColoredStars:
Hey. I'm really tired too. Going to eat my ham, green beans, and stuffing then take a nap. lol+1
-
@
SylverReZ:
Lol. I've had two naps one in the morning, another in the afternoon. Didn't have much sleep last night. -
-
-
-
@
SylverReZ:
@AncientBoi, Very little on money right now, so not at this time. But I'd wish I had a fucking big mac.+1
-
-
-
-
-
-
-
-
] 