12-26-2014, 11:28 PM (This post was last modified: 01-31-2015 10:02 PM by ムギ.)
Post: #1
Document Evangelion: Girlfriend of Steel 2nd
the THFS file structure.

0x00: THFS file signature (4 Bytes || 5448 4653)
0x04: File size (4 Bytes)
0x08: Number of files (4 Bytes)
0x0c: blank (0000 0000)

--Data starts at 0x10, Each file entry is 0x40 in size:
0x10: Filename hash (8 Bytes)
0x18: Filename (28 Bytes) *padded with zeroes*
0x40: File Start address (4 Bytes)
0x44: Filesize -compressed- (4 Bytes)
0x48: Compression flag (4 Bytes) *it's either 0100 0000 or 0000 0000 for enable/disable*
0x4c: Filesize -uncompressed- (4 Bytes)

** If compression is disabled, both size indicators have the same value.
** Compression used is zLib (file signature, 789C)

Thats about it for the THFS. No unknown bytes left.


*dat files inside BMP.THFS

These small files are image layout data configurations.
If you examine the game's main script, you'll occasionally run into lines that call these configs, such as "bmp.overlap title_bg". This line is found from title.txt which is the main menu script. What it does is call the title_bg.dat from BMP.THFS.

we'll be examining this file as i attempt to explain to you how it works.
keep in mind that these are binary files, and editing them with notepad or a text editor will just break them.

--here's what title_bg.dat looks like in hex editor:
0x00: 0004 01E0 0110 1A91 017A 576C 7336 0000
0x10: 0000 0000 0000 0001 0001 C7DB 5173 2E05
0x20: D082 0001 0000 0000 0000 E000 0001 32C9
0x30: 9CA0 AB8D 25C5 0000 0001 0000 B400 0001
0x40: 1000 32C9 9CA0 AB8D 25C5 0001 0001 0000
0x50: C600 E000 1000

Different segments of the hex are color coded to make it easier to read.

Lets break it down a little:

0x00: number of entries (plain HEX)
0x02: area size X (plain HEX)
0x04: area size Y (plain HEX)

this is the first segment that defines the number of entries in the file and the screen draw area size.
note that these bytes are PLAIN so DO NOT flip them in hex editor.
number of files 0004 stands for 4 entries.
size X 1E0 stands for x size (1E0 HEX = 480 in Decimal)
size Y 110 stands for y size (110 HEX = 272 in Decimal)

these are simply a 8-Byte string that is the filename hash (see THFS container structure above for it.) These configs call the source images by the hash value instead of filename.

Followed by the name hash is the addresses to draw. its 0x0c (12) bytes and 6 values, so 2 Bytes per value, These are not Plain unlike the start of the file, so remember to flip these to get real numbers.

lets take a look at the first ones:

0000 0000 0000 0000 0001 0001

now lets flip them:

0000 0000 0000 0000 0100 0100

lets change them to Decimal:

0, 0, 0, 0, 256, 256

the values decode as follows:

first 2 are the X/Y coordinates where the source image will be pasted to on the screen.
second 2 values are the X/Y coordinates of the start location of the area to display.
third 2 values are the X/Y size of the displayed area of the source image.

what this means is that the image with hash 1A91 017A 576C 7336 is layed on 0,0 of source screen, the visible area of the source image starts from 0,0 and the size of the visible area is 256x256 pixels. This is the left half of the main menu background.

second set of parameters follows this same pattern:
image with the hash of C7DB 5173 2E05 D082 is layed on 256, 0 of source screen,
the visible area of the source image starts from 0,0
and the size of the visible area is 224x256 pixels. This is the right side of the main menu background.

when you look at the hex of the source .dat file, you'll notice that the last 2 green hash values are the same.
since psp's screen is 480x272 in size, and the images in this game are built out of 256x256 pixel tiles, after laying 2 tiles, we have a 16 pixel blank at the bottom. The last 2 strings are present to load the additional pieces from another menu source file, that contains the bottom of the menu background along with few other menu graphics. (see below for the actual file.)

[Image: attachment.php?aid=104]

the game has several things hardcoded that i didnt really bother looking at since they're more or less irrelevant, such as the code that makes the "press start button" button blink. Or the position of the main menu.
You should be able to move them around with the .dat files but the initial values are propably hardcoded int othe executable.

My THFS tool can be downloaded from the Hack 'n Tools section of the forum.

Attached File(s)
.png  3188196.png (Size: 10.13 KB / Downloads: 499)
10-13-2016, 01:21 AM (This post was last modified: 10-13-2016 01:25 AM by ムギ.)
Post: #2
RE: Evangelion: Girlfriend of Steel 2nd
Some text strings in the game are embedded into the executable itself and therefore required some extra effort to poke at.
namely, the chapter names are there, along with a list of strings that are responsible for loading the location preview images that are displayed on the right when you are selecting a location to move into.

this table is rather straightforward and consists of 4 4-byte values that decode as follows.

- filename1 (the name of the script file that uses this string)

input string (the input string, has to 100% match the script file's string)

- filename2 (image ID of the location preview image to load (loads identically named dat from BMP.THFS))

- unknown unsigned integer

the unknown integer we didnt bother to figure out as it made no difference. We named it WTF, its irrelevant regarding operations. this value mostly defaults to FFFF FFFF, just leave it untouched. (the tool does not dump this value at all)

a tool was made to dump this table to a txt for easy editing.
Please note that the text string in this table must be a 100% match to the text string that calls it, othervise the location image does not load!
hence patching this table is necessary if any edits are made to the script files.

the specification of this data is as follows:

location of data pointers: 0x5C108
location of string table: 0x5B27C
number of entries: 0x274
executable base ram address: 0x8804000

the base ram address is needed when patching the offsets to the new modified strings, you dont have to worry about this as the tool provided will do the calculations for you. It is here merely for informative purposes.

the tool is also capable of reusing dublicate string entries which the game originally does not do, and hence gives you a lot more space to put your new strings into.
(this behavior can be changed from the sourcecode of the tool)

tool usage:

this tool requires a decrypted eboot.bin file to function.

evatable_parse.exe d <input.elf>
evatable_parse.exe r <input.elf> <locations.txt> <output.elf>

when using mode d the tool outputs the data to stdout.
use evatable_parse.exe d EBOOT.BIN > locations.txt
to generate a table file for editing.

when using mode r, an old elf is required for writing the new data into, it will not be overwritten but copied into <output.elf> which will include new data.

!! it is highly recommended that you generate an elf that has the entire string table deleted for the first time use !! as the tool is programmed to scan for dublicate entried and reused them if appliable, leaving the default strings into the elf when inputting new ones might leave undesired dublicates into the data.

the tool can be used on both headered and headerless elf file, however,
the produced output.elf WILL ALWAYS BE HEADERLESS, and must manually be added back to the elf before using it.
this is because i always work on headerless files and we got a bit lazy on coding.
the header is the first 0x54 bytes of a decrypted EBOOT.BIN (starts with the letters ELF)


Attached File(s)
.rar  evatable_parse.rar (Size: 4.33 KB / Downloads: 182)
.rar  evatable_parse_src.rar (Size: 2.65 KB / Downloads: 178)

User(s) browsing this thread: 1 Guest(s)