Hacking Hungry Ghosts (2003) ps2 translation-Help with ASM, file repacking and finding pointers
- Thread starter Deleted member 471298
- Start date
- Views 8,563
- Replies 24
now listen, i was approached by Tom regarding this because he's full well aware that it wouldn't take me more than half a hour to get the reversing done, but like i told him and assumably he told you, i dont have time to hack games for everyone everytime they ask, as Tom works on translating zill instead of tackling this for you, i am hacking it, instead of hacking this for you.
you have no reason to be butthurt to me about the fact that you dont know what IDA is supposed to be used for.
as for your pointers, have you even tried to analyze the contents of the files inside the pack.dat ?
are they multi file containers ? do they contain bytecode portions in addition to the actual text ? are there other filetypes packed along with the text inside the files ?
doing this sort of random "sjis" dumps you have done from the game's text serves no use really, you will have to figure out how the files holding the text are built, and how the game reads them.
for example, zill uses dat files for storing it's text which start with a byte indicating how many lines of text the file has, followed by an address pointing to each line. (these are your pointers you're so hard looking for) after that, each line of text is written, and terminated by a terminator byte.
copying the text out of it like you did with this game is easy, but unless you understand what the rest of the file does, copying the text out is completely useless.
now seriously, im all in for cheering up for people who want to do translation hacking, but lashing out on me for not knowing what to do and expecting someone else to do it for you is not the way to deal with it.
see here, (this is file 0.2.000D6E80.bin from your dump) the byte at 0x4 indicates the text start address (5004 0000) add to this the offset off the value and you get 0x458 which is where the text starts.
each line of text has a pair of bytes on it, like at 0x458 here you have 0x3 which is the length of the text string + a 0x0000 terminator byte pair.
same goes on for the rest of the file.
im not going to look int othis any further, but what you have to do is parse the table at the beginning of the file to see what it does, as i doubt that simply patching string lengths is enough (you can try tho, god knows you get lucky.)
the table at the beginning starting from 0x8 seems to be going in pairs of 8 bytes, and might or might not contain multiple portions of data, it could be text pointers, or simply event bytecode and not related to the strings, I didnt bother looking further.
- oh and yes, this was figured out by opening the file in hex editor and looking at it for roughly 20 seconds. you dont need autoasm makers or pointerfinder.exe to dump text. it's boring manual analyze work. AFTER you know what the bytes in the file do, then you deal with extracting and parsing it, not before.
you have no reason to be butthurt to me about the fact that you dont know what IDA is supposed to be used for.
as for your pointers, have you even tried to analyze the contents of the files inside the pack.dat ?
are they multi file containers ? do they contain bytecode portions in addition to the actual text ? are there other filetypes packed along with the text inside the files ?
doing this sort of random "sjis" dumps you have done from the game's text serves no use really, you will have to figure out how the files holding the text are built, and how the game reads them.
for example, zill uses dat files for storing it's text which start with a byte indicating how many lines of text the file has, followed by an address pointing to each line. (these are your pointers you're so hard looking for) after that, each line of text is written, and terminated by a terminator byte.
copying the text out of it like you did with this game is easy, but unless you understand what the rest of the file does, copying the text out is completely useless.
now seriously, im all in for cheering up for people who want to do translation hacking, but lashing out on me for not knowing what to do and expecting someone else to do it for you is not the way to deal with it.
see here, (this is file 0.2.000D6E80.bin from your dump) the byte at 0x4 indicates the text start address (5004 0000) add to this the offset off the value and you get 0x458 which is where the text starts.
each line of text has a pair of bytes on it, like at 0x458 here you have 0x3 which is the length of the text string + a 0x0000 terminator byte pair.
same goes on for the rest of the file.
im not going to look int othis any further, but what you have to do is parse the table at the beginning of the file to see what it does, as i doubt that simply patching string lengths is enough (you can try tho, god knows you get lucky.)
the table at the beginning starting from 0x8 seems to be going in pairs of 8 bytes, and might or might not contain multiple portions of data, it could be text pointers, or simply event bytecode and not related to the strings, I didnt bother looking further.
- oh and yes, this was figured out by opening the file in hex editor and looking at it for roughly 20 seconds. you dont need autoasm makers or pointerfinder.exe to dump text. it's boring manual analyze work. AFTER you know what the bytes in the file do, then you deal with extracting and parsing it, not before.
Last edited by Kitsu-neechan,
okay first of all, if the executable has no text forget it.
does your extractor need the executable file to extract the pack.dat ?
if not, forget ida. ida is a disassembler, it disassembles compiled code into assembly, which is human readable, unlike compiled code. it serves you no purpose to open anything else except the executable in ida.
multi file containers are just like they sound, they are like rar files. it's a file which contains multiple files inside it (pack.dat is a container)
i already answered to my question while i looked into the few .bin files from inside. the one i used as an example above, is indeed a single file, which is most likely a single event file, controlling the part of the game where the text contained in it appears.
as my example shows, there is a pointer at 0x4 in each of these files, that points to the location where the text is. At that location,each text string starts with a byte that tells the game how many bytes (or byte pairs in this case since each letter is 2 bytes) to read. After this there is again a byte that tells the game how many byte pairs to read. actually scrap that, it's something else.
to edit the text in these files, you will have to edit all those bytes to match your new text, othervise it will be quaranteed to not work.
like i said, i did not analyze the bytecode at the beginning of the file any more, so im unable to tell you what it does, or is editing it required for making changes to the text.
does your extractor need the executable file to extract the pack.dat ?
if not, forget ida. ida is a disassembler, it disassembles compiled code into assembly, which is human readable, unlike compiled code. it serves you no purpose to open anything else except the executable in ida.
multi file containers are just like they sound, they are like rar files. it's a file which contains multiple files inside it (pack.dat is a container)
i already answered to my question while i looked into the few .bin files from inside. the one i used as an example above, is indeed a single file, which is most likely a single event file, controlling the part of the game where the text contained in it appears.
as my example shows, there is a pointer at 0x4 in each of these files, that points to the location where the text is. At that location,
to edit the text in these files, you will have to edit all those bytes to match your new text, othervise it will be quaranteed to not work.
like i said, i did not analyze the bytecode at the beginning of the file any more, so im unable to tell you what it does, or is editing it required for making changes to the text.
Last edited by Kitsu-neechan,
0x4 means offset 0x00000004
in ps2, the code is little endian (read right to left) and the easiest way to analyze it is to go by pairs of 4 bytes. (32-bit values. It's not always 4bytes per value but lets just not go there.)
at the offset 0x4 a value is written 5004 0000, so when you read it RTL, you get 0x00000450 and since this offset is written at 0x4 (the 4 bytes starting from your offset) it means that you're now sitting at 0x8
add 0x450 to 0x8 and you get 0x458.
i looked at 3 files and this is always the offset of the first text entry.
nevermind the whole string length thing though, i edited that out of my previous post as it doesnt actually match. the byte at the start of the text is something else than length.
the way to figure out what each byte on the file do, is either you take a small text file and start pointing out if you can find offsets that match the text strings or string lengths.
and what i meant by pairs of 8 bytes, is that from the looks of it each entry on the bytecode table is 8 bytes, and most likely holds 2 values. if you align the file like that you can see a pattern of increasing numbers every 8 bytes.
another way to figure out what the bytes at the start of the text file do is to open the executable up with a debugger, and start tracing down the game code while you play. you will have to locate the function that reads these bytes and by looking at THAT assembly in IDA, you can read what the code does when it reads the file.
i prefer the way of simply flipping it open with a hex editor and doing pattern analysis until i've either figured out that it's a table and how it works, or if i cant figure anything out, try and edit a single file and throw it back to the game to see how it behaves, what error does it return if any, or what happens.
like i already told you, hacking games is not fun, it's boring, monotonous work that will drive you up a wall on hours end.
either way, i will stop here as i hae my own project to stare at with IDA already
good luck.
in ps2, the code is little endian (read right to left) and the easiest way to analyze it is to go by pairs of 4 bytes. (32-bit values. It's not always 4bytes per value but lets just not go there.)
at the offset 0x4 a value is written 5004 0000, so when you read it RTL, you get 0x00000450 and since this offset is written at 0x4 (the 4 bytes starting from your offset) it means that you're now sitting at 0x8
add 0x450 to 0x8 and you get 0x458.
i looked at 3 files and this is always the offset of the first text entry.
nevermind the whole string length thing though, i edited that out of my previous post as it doesnt actually match. the byte at the start of the text is something else than length.
the way to figure out what each byte on the file do, is either you take a small text file and start pointing out if you can find offsets that match the text strings or string lengths.
and what i meant by pairs of 8 bytes, is that from the looks of it each entry on the bytecode table is 8 bytes, and most likely holds 2 values. if you align the file like that you can see a pattern of increasing numbers every 8 bytes.
another way to figure out what the bytes at the start of the text file do is to open the executable up with a debugger, and start tracing down the game code while you play. you will have to locate the function that reads these bytes and by looking at THAT assembly in IDA, you can read what the code does when it reads the file.
i prefer the way of simply flipping it open with a hex editor and doing pattern analysis until i've either figured out that it's a table and how it works, or if i cant figure anything out, try and edit a single file and throw it back to the game to see how it behaves, what error does it return if any, or what happens.
like i already told you, hacking games is not fun, it's boring, monotonous work that will drive you up a wall on hours end.
either way, i will stop here as i hae my own project to stare at with IDA already
good luck.
the way hex editors work is that you have 16 bytes (0x10) displayed on each line.
each byte (0x00 or whatever) is one byte and you count up from there. if you read 4 bytes, you're at 0x04 and if you read 8 bytes you're at 0x8 (middle of the first row)
the way i look at it is that i go by pairs of 4 bytes like i said, so on the first line you have 4 values, one at 0x00, one at 0x04, one at 0x08 and the 4th one on the first row starts at 0x0C. once you read that value, you are at 0x10, which is the second row in your hex editor.
it doesnt become 5004 because you're reading bytes, not decimal numbers, one byte is represented by 2 numbers (8bits) in the hex editor.
the way little endian works is that if you have a value like AABBCCDD written there, you start reading it from right, one BYTE at a time, so you take the DD then you take the CC then you take the BB and then you take the AA
another example to further enlighten this is that if you have a value of 1234 5678 written in your hex editor, you take 78 then 56 then 34 and then 12. you are reading it from right to left by bytes, not by decimal numbers.
it's called hex editor because it displays shit in hexadecimal system, not decimal system.
here's a visual representation.
notice how there's 16 zeroes the offset where my cursor is on the line 0x450 ?
16 zeroes when put into bytes is 8 bytes (8 pairs of 0x00) which puts your cursor at 0x458
each byte (0x00 or whatever) is one byte and you count up from there. if you read 4 bytes, you're at 0x04 and if you read 8 bytes you're at 0x8 (middle of the first row)
the way i look at it is that i go by pairs of 4 bytes like i said, so on the first line you have 4 values, one at 0x00, one at 0x04, one at 0x08 and the 4th one on the first row starts at 0x0C. once you read that value, you are at 0x10, which is the second row in your hex editor.
it doesnt become 5004 because you're reading bytes, not decimal numbers, one byte is represented by 2 numbers (8bits) in the hex editor.
the way little endian works is that if you have a value like AABBCCDD written there, you start reading it from right, one BYTE at a time, so you take the DD then you take the CC then you take the BB and then you take the AA
another example to further enlighten this is that if you have a value of 1234 5678 written in your hex editor, you take 78 then 56 then 34 and then 12. you are reading it from right to left by bytes, not by decimal numbers.
it's called hex editor because it displays shit in hexadecimal system, not decimal system.
here's a visual representation.
notice how there's 16 zeroes the offset where my cursor is on the line 0x450 ?
16 zeroes when put into bytes is 8 bytes (8 pairs of 0x00) which puts your cursor at 0x458
Last edited by Kitsu-neechan,
like i said, this tool is called HEX editor because it counts numbers and bytes in hexadecimal numeric system (hexadecimal is a 16-number system, as opposed to the 10-number decimal system) this is really something you should know if you're even attempting to hack games to be honest, but here's how it works side by side.
decimal system: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Hexanumericals: 0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12 13 14
my editor is called hex workshop
but it's pretty much looking like any other really. In any hex editor that's even half-decent, you can adjust column widths (for me here it pairs by 2 bytes and alternates colors every 2 bytes)
and the colors are just changed to black background to not get eyecancer.
decimal system: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Hexanumericals: 0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12 13 14
my editor is called hex workshop
but it's pretty much looking like any other really. In any hex editor that's even half-decent, you can adjust column widths (for me here it pairs by 2 bytes and alternates colors every 2 bytes)
and the colors are just changed to black background to not get eyecancer.
Last edited by Kitsu-neechan,
if you're at 0xC and you read 4 bytes, you reach 0xF and then flip over to 0x10 which is the start of the next row
you just count each byte as one value, and advance by 1 in hexadecimal numerics. if you're at 0xC and you read 4 bytes you end up at 0x10 (0xC -> 0xD -> 0xE -> 0xF -> 0x10, just like you normally count from 13 -> 14 -> 15 -> 16 - 17)
you just count each byte as one value, and advance by 1 in hexadecimal numerics. if you're at 0xC and you read 4 bytes you end up at 0x10 (0xC -> 0xD -> 0xE -> 0xF -> 0x10, just like you normally count from 13 -> 14 -> 15 -> 16 - 17)
each hex editor does the same at the end so it's really down to preference at the end.
and yeah, if we take the first row of the file here it will go like this
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
------------------------------------------------
2C 00 00 00 50 04 00 00 B8 00 00 00 C4 00 00 00
some hex editors actually display the offsets at the top of the window, so if you feel more comfortable with that, might want to look into a hex editor that does that.
i just find it useless clutter so
anyway, here's the last thing i will contribute to your little adventure with this game.
the value at 0x0 is an entry count
the value at 0x4 is the offset of the text area
the values starting from 0x8 are 4bytes each, and they are pointers to the data area of the file. there is as many of these as is described at 0x0 in the file
each pointer in the the pointer table points into an offset in the data section of the file that is located directly after the pointer table.
each entry in this second table is 0xC in size (3 values, 4 bytes each)
now... i looked up but so far i havent found a clear logic of the data section values.
if i was you, i would attempt to alter the text strings and see what happens if you change their lengths.
if the game crashes, prints garbage or doesnt print anything, then the string lengths are definitely written somewhere.
and yeah, if we take the first row of the file here it will go like this
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
------------------------------------------------
2C 00 00 00 50 04 00 00 B8 00 00 00 C4 00 00 00
some hex editors actually display the offsets at the top of the window, so if you feel more comfortable with that, might want to look into a hex editor that does that.
i just find it useless clutter so
anyway, here's the last thing i will contribute to your little adventure with this game.
the value at 0x0 is an entry count
the value at 0x4 is the offset of the text area
the values starting from 0x8 are 4bytes each, and they are pointers to the data area of the file. there is as many of these as is described at 0x0 in the file
each pointer in the the pointer table points into an offset in the data section of the file that is located directly after the pointer table.
each entry in this second table is 0xC in size (3 values, 4 bytes each)
now... i looked up but so far i havent found a clear logic of the data section values.
if i was you, i would attempt to alter the text strings and see what happens if you change their lengths.
if the game crashes, prints garbage or doesnt print anything, then the string lengths are definitely written somewhere.
Last edited by Kitsu-neechan,
you will have to look up how the pack.dat stores it's files (it has an offset table somewhere describing whre each file is.) then you will have to write a tool to extract and rebuild the file and the table so that the game can find the files if you change their sizes.
if you tested and the text displays incorrectly in the game, that just means that tehre is somewhere pointers that point to the locations of the text strings (just like the 0x450 points to the first one) if you change the lengths of the text, you will have to fix these pointers to point to the new offset where the text starts.
if you correctly reverse engineer this file, you dont have to find free space or anything like that, you can simply generate a completely new file with whatever content you want. This is how files are correctly hacked.
as for editing them, yes, you could just do that with a hex editor, but that's a really slow and ineffective way to do it,
what i did for zill o'll for example was that i figured out the bytecode at the beginning, and made a tool that reads the bytecode to obtain the string pointers, then creates a txt file that has the text in it.
the text is then rewritten in the txt file, and my tool takes the txt and generates a new file and a new bytecode that matches the new text.
if you tested and the text displays incorrectly in the game, that just means that tehre is somewhere pointers that point to the locations of the text strings (just like the 0x450 points to the first one) if you change the lengths of the text, you will have to fix these pointers to point to the new offset where the text starts.
if you correctly reverse engineer this file, you dont have to find free space or anything like that, you can simply generate a completely new file with whatever content you want. This is how files are correctly hacked.
as for editing them, yes, you could just do that with a hex editor, but that's a really slow and ineffective way to do it,
what i did for zill o'll for example was that i figured out the bytecode at the beginning, and made a tool that reads the bytecode to obtain the string pointers, then creates a txt file that has the text in it.
the text is then rewritten in the txt file, and my tool takes the txt and generates a new file and a new bytecode that matches the new text.
i have no idea of any of that really...
if you know how to write programs in C for example, you can just write a program to do things to a file assuming you know what is where in the file to begin with.
im not actually much of a programmer myself, i wrote some simple things but the more complicated things i leave for other people.
i have a few pieces of sourcecode available on my site, but i dont think they will help you much, since they're tailored for doing one thing on one game, and unless your pack.dat is identical to whatever it was i made my tools for, it doesnt do 2 shit, and if you cant code with C, then i doubt looking at the sourcecode says much to you. Feel free to dig in though; https://bbs.blacklabel-translations.com/forumdisplay.php?fid=10
for tools to make tools, you dont need any. code is written into a text file, and then you just throw it into a compiler that takes your code and spits out an .exe
as for searching the contents table of the pack.dat, just open it in hex editor. The table is either at the start of the file, or at the end of the file.
if you know how to write programs in C for example, you can just write a program to do things to a file assuming you know what is where in the file to begin with.
im not actually much of a programmer myself, i wrote some simple things but the more complicated things i leave for other people.
i have a few pieces of sourcecode available on my site, but i dont think they will help you much, since they're tailored for doing one thing on one game, and unless your pack.dat is identical to whatever it was i made my tools for, it doesnt do 2 shit, and if you cant code with C, then i doubt looking at the sourcecode says much to you. Feel free to dig in though; https://bbs.blacklabel-translations.com/forumdisplay.php?fid=10
for tools to make tools, you dont need any. code is written into a text file, and then you just throw it into a compiler that takes your code and spits out an .exe
as for searching the contents table of the pack.dat, just open it in hex editor. The table is either at the start of the file, or at the end of the file.
Last edited by Kitsu-neechan,
well all you need is someone who can program tools for you (and reverse engineer the rest of the .bin file format)
from what i've seen the game doesnt really pose much of a challenge so i doubt it would take much to actually finish up the reversing process to the point it can comfortably be worked at (i mean come on, i figured out most of the script files within 10 minutes of on-off looking while replying to your questions.)
you already have a file extractor for the pack.dat and you even have the file offsets in the filenames. dealing with that is pretty much just looking at the file and writing a rebuild tool i suppose (i would still code a new extractor though, because WTF with those filenames omg!)
from what i've seen the game doesnt really pose much of a challenge so i doubt it would take much to actually finish up the reversing process to the point it can comfortably be worked at (i mean come on, i figured out most of the script files within 10 minutes of on-off looking while replying to your questions.)
you already have a file extractor for the pack.dat and you even have the file offsets in the filenames. dealing with that is pretty much just looking at the file and writing a rebuild tool i suppose (i would still code a new extractor though, because WTF with those filenames omg!)
Similar threads
Site & Scene News
New Hot Discussed
-
-
17K views
Pokemon Platinum PC port gets a surprise release
Seemingly out of nowhere a PC port for Pokemon Platinum has surfaced online, bundled alongside the source code for those interested in building and developing it for... -
12K views
Steam Deck gets a major price bump, more than 40% increase for US buyers
With very little in the way of announcement, Valve has today increased the price of the Steam Deck but some fairly considerable margins. Both of the available models... -
10K views
Nintendo president Shuntaro Furukawa explains Switch 2 price increases in recent Financial Results Briefing
As a part of their Financial Results Briefing for the previous year, Nintendo president Shuntaro Furukawa took to the floor to answer key questions around the Switch... -
9K views
Sony announces PlayStation Plus price increase for new customers starting May 20
Earlier this year, Sony announced major price increases for the PS5, PS5 Pro, and PlayStation Portal. Now the company is raising prices again, this time for... -
8K views
Forza Horizon 6 leaks online after Steam preload data was uploaded without encryption
We are once again here to tell you about a game leaking before its release, but for once, it's not one published by Nintendo. The game files for Microsoft's upcoming... -
8K views
Pokémon Crystal gets a PC port titled "suiCune" based on C/C++ language
Continuing with the great news of Pokémon Platinum getting a native unofficial PC port just a few days ago, today, yet another classic title from the franchise has... -
7K views
Paper Mario PC recompilation "ReCut" gets its first pre-release build
The latest in a growing number of native PC ports, Paper Mario ReCut got its first pre-release build earlier this week. Based on the N64 recompilation toolchain, the... -
6K views
Low-level 3DS emulator 3Beans released alongside setup tutorial video
When you talk about 3DS emulation, most people would jump to Citra. As the defacto choice since its first release it's seen tremendous success, and even after its... -
5K views
Nintendo Direct June 9, 2026 roundup - Ocarina of Time remake announced, Kingdom Hearts IV trailer
Nintendo's expected Summer showcase is here, offering up plenty of new announcements and exciting reveals. Let's see what they have in store in the latest Nintendo... -
5K views
PlayStation State of Play June 2, 2026 broadcast - new God of War announced
A whole hour of PlayStation content is on the way, thanks to the latest State of Play showcase. Headlining the stream will be Marvel's Wolverine, alongside a...
-
-
-
171 replies
Steam Deck gets a major price bump, more than 40% increase for US buyers
With very little in the way of announcement, Valve has today increased the price of the Steam Deck but some fairly considerable margins. Both of the available models... -
124 replies
Nintendo Direct June 9, 2026 roundup - Ocarina of Time remake announced, Kingdom Hearts IV trailer
Nintendo's expected Summer showcase is here, offering up plenty of new announcements and exciting reveals. Let's see what they have in store in the latest Nintendo... -
102 replies
Pokemon Platinum PC port gets a surprise release
Seemingly out of nowhere a PC port for Pokemon Platinum has surfaced online, bundled alongside the source code for those interested in building and developing it for... -
92 replies
Sony announces PlayStation Plus price increase for new customers starting May 20
Earlier this year, Sony announced major price increases for the PS5, PS5 Pro, and PlayStation Portal. Now the company is raising prices again, this time for... -
89 replies
What do you want to see in the next Nintendo Direct?
With rumours circulating about a Nintendo Direct in the coming days and weeks, fans are left speculating and hoping as to what might be included. At the centre of all... -
83 replies
Nintendo president Shuntaro Furukawa explains Switch 2 price increases in recent Financial Results Briefing
As a part of their Financial Results Briefing for the previous year, Nintendo president Shuntaro Furukawa took to the floor to answer key questions around the Switch... -
73 replies
Paper Mario PC recompilation "ReCut" gets its first pre-release build
The latest in a growing number of native PC ports, Paper Mario ReCut got its first pre-release build earlier this week. Based on the N64 recompilation toolchain, the... -
71 replies
Nintendo Direct to air on the 9th of June, set to feature 50 minutes of Switch and Switch 2 games launching this year
After much speculation and rumour, the fabled Nintendo Direct is upon us. Set to go live tomorrow, the 9th of June, at 3pm in the UK, it'll feature 50 minutes of... -
71 replies
PlayStation State of Play June 2, 2026 broadcast - new God of War announced
A whole hour of PlayStation content is on the way, thanks to the latest State of Play showcase. Headlining the stream will be Marvel's Wolverine, alongside a... -
63 replies
Call of Duty: Modern Warfare 4 to launch on Nintendo Switch 2 in October
For the first time in 13 years, the Call of Duty series will again return to Nintendo's consoles. Set to launch on the 23rd of October, the latest release, Modern...
-
