What is it?
ROMSearcher is a program which searches through any binary file for a specified text string. It is different from most other text searchers in that it is specified for video games. It can search through a ROM file, identifying any occurrences of a text string -- even if the game uses a nonstandard ASCII mapping for its alphabet.
What does that mean?
Well, some videogames, for example, Nintendo games, don't store their text information in a way that is directly accessible. This makes it harder for hackers or pirates to get to that information. They encode the text sometimes by having their text data mapped to different locations in the graphic data. Now, most computers are standardized -- they have to be -- and use the ASCII alphabet for representing text information. This means that if you look into a binary file, the letter 'A' is represented by 65 in ASCII; the letter 'B' by 66, and so on. Console games don't have to be as standardized as this. They can choose their alphabet to start at 0, or 10, or 192; anything, as long as the letters of the alphabet are mapped out in a sequential order. ROMSearcher takes advantage of this property.
How does it work?
ROMSearcher searches for a text string like this: the user types ROMSearcher and then the filename of the file to search at the command line. ROMSearcher will ask for a text string which must be longer than 2 letters long, and less than a predefined limit. If the string were less than 3 characters long, the searching algorithm would come up with too many matches. The longer the string to search, the more accurate the match. ROMSearcher finds a matching string under any representation of alphabet by searching not for individual characters, but for a match in the differences between individual characters. If you give me a string like "DOG", I know that there is a difference of 11 characters between the letters 'D' and 'O'. You know, you have to go up the alphabet by 11 letters to get from 'D' to 'O'. Furthermore, I know that there is a difference of -8 characters between 'O' and 'G'. I would have to go down the alphabet by 8 letters to get from 'O' to 'G'. If you give me encoded words like CNF or EPH, the differences between the letters are still exactly the same, and so I know that "CNF" is just the word "DOG" shifted down by 1 letter; and "EPH", up by 1 letter. It's like those decoder rings your grandparents (ha-ha!) used to play with as kids.
So how do I use this on games, then?
I'll show you. The examples below show how you can search for strings in Zelda, for example. Let's say I wanted to find out where the Dodongo (a triceratops-like boss creature) is mentioned in the game. Since I know that in this particular game, all messages to me are shown in UPPERCASE text, I know that it is most prudent to enter my search string as UPPERCASE text. In the example below taken from my Amiga's shell, my writing (typing?) is bolded. The rest is output from the program.
0.9.Ram Disk:> ROMSearcher Zelda.nes
ROMSearcher v1.0, ©1998-99 Chris Covell (ccovell@direct.ca)
Searches for text hidden in game ROMs and other files.
Enter search string of length 3-16: DODONGO
Match found at offset 17158, shifted by -55 Letter 'A' in CHR Bank should be at position 10
No Further Matches Found.
Would you like to Shift the bytes in the file? (Y/N) Y
Bytes shifted by 55 into file 'Shifted.BIN'.
You can make all your modifications now.
Would you now like to shift it back? (Y/N) Y
Bytes shifted back to original position into file 'Output.ROM'.
|
Or, if I wanted to look for ZELDA...
0.9.Ram Disk:> ROMSearcher Zelda.nes
ROMSearcher v1.0, ©1998-99 Chris Covell (ccovell@direct.ca)
Searches for text hidden in game ROMs and other files.
Enter search string of length 3-16: ZELDA
Match found at offset 40699, shifted by -55 Letter 'A' in CHR Bank should be at position 10
Match found at offset 44530, shifted by -55 Letter 'A' in CHR Bank should be at position 10
Match found at offset 107697, shifted by -55 Letter 'A' in CHR Bank should be at position 10
Match found at offset 108015, shifted by -55 Letter 'A' in CHR Bank should be at position 10
Match found at offset 131067, shifted by 0 Letter 'A' in CHR Bank should be at position 65
No Further Matches Found.
Would you like to Shift the bytes in the file? (Y/N) Y
Where should the letter 'A' be in the CHR bank? 65
It doesn't get shifted anywhere!
|
The results it gives you are rather informative. The offset is the position relative to the beginning of the file where instances of the matched string were found. The amount shifted represents where, relative to a normal ASCII alphabet, the matched string was found. The final peice of information is especially helpful for NES games. It tells you where the letter 'A' would be found in the game's CHR-ROM or Character bank. This bank on the NES is a 16x16x2 region of graphics memory that holds graphic and typographical characters; however, this information could be useful for other video game systems which use a similar graphics tiling system.
After ROMSearcher looks for and finds a text string, you can choose to 'shift' the bytes in the file. (A special note: If text strings are found shifted by 0, there is no need to, and ROMSearcher won't, shift the file in any way.) This allows you to read and edit text which may be hidden due to an encoding process. The following images demonstrate this.
You can see that before shifting, the text information in the original .NES file is just garbage. After shifting, the raw text data is visible. Using a HEX editor, you can modify the shifted binary file, and then acknowledge ROMSearcher's request to shift the file back. The final output file is nearly identical to the original input file, but your modifications have been incorporated into it.
MORE!