I was wondering how to obtain the sprites, models and other game data of a psp game, specifically higurashi daybreak portable mega edition. They're held within gzpack.pck according to what I've found out, but I can't find any tools that will let me extract the contents. It looks like I'm 7 years too late to this because many of the sites they were hosted on don't exist anymore.
Was there evidence of a tool for this game or maybe some indication that an existing one would work?
Also https://web.archive.org/ , usually seen as things like https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial if you just wanted to copy paste the URL, is good stuff for trying to get old data back.
.pck, presumably short for pack, is perhaps not as common as .bin, .arc or .dat when it comes to the "I need a generic name for this extension" but still in the top 5. This is to say there might not be a tool as it could be completely custom to the developer or game itself and you get to modify it accordingly.
The thing starting its name with gz has me apprehensive -- gz is a popular type of compression (you tend to see it for program source code as blah.tar.gz). Though if it is simple gz then should be able to be initially decompressed with common programs (maybe even something as basic as 7zip) to then play unpacker.
I haven't got the game or file to look at but the following is my general approach to how I approach unknown archive files, and hopefully light introduction that you can follow along with.
Generally when it comes to archive and file bundling formats should I open it in a hex editor (old but still valid https://gbatemp.net/threads/rom-hacking-hex-editors-mid-2012-discussion.326873/ ) I usually expect to see
Some kind of basic header. Possibly a short string (aka magic stamp) to indicate the file type for the game or some tool being used internally by the devs, maybe a length of the whole file or a length of the sections within it.
After this (though it might be at the end of the file or might be in a separate file, usually one named very similarly or in the same directory/one up from it) there will be a list (or three or four) containing some of the following
name
file size
file location
any information regarding compression
In a sense all four of those (or however many more there might be if some other info is wanted) are optional, though in the vast majority of cases you would expect to have either file size or file location. For file size you get to add up everything that comes before it to get to the file you want. Sadly for many things names are often not included so it is more of a nice bonus when they do appear.
If the .pck does not have some immediate means of telling where the files are then they are either a fixed size (rare to see outside of text in menus or something) or maybe before each file is the file size and thus it can add everything up as it goes (usually see this more for scripting based things but can work as a file archive).
Anyway these file sizes/locations serve as pointers (programming term for value that tells you where something is, points the way if you will, a big list of them then serving as something akin to a contents page in a book) so if you change the files within to make them smaller or bigger you get to recalculate everything. If you are just unpacking it to look at separately then no great worry.
If you need a tool to feed a list of offsets with then I usually make a batch file (numbers gained from playing with a hex editor) with https://web.archive.org/web/20170218180937/http://min.midco.net/cracker/filecutter.zip to do it.
Pointers themselves, ignoring the sector stuff I cover a bit later, come in three main flavours
1) Simple location. Here the location of the file is written in a plain number. If you are editing a binary or something loaded in RAM then the RAM location might be used instead. For older systems it might be the location in the whole ROM (or whole ROM as it appears in RAM).
2) Offset. Rather than start from the start of the file it might say start counting from the start of the file section itself (or some other point). Basically add or subtract a fixed value to the pointers and you are good.
3) Relative. Take the current location of the pointer and add the value here to get to the ultimate location. A bit tedious but there are programming reasons some things choose to roll this way.
You need not try to make sense of the pointers in and of themselves. Recall earlier the part about magic stamps -- if they are at the start of the file you actually want to look at then you know where the file is within it and try to see where it and a few others might correspond to the header (the difference between one location and the next and the next should be mathematically related to the pointer section).
If you have a relative section and all the pointers are a fixed length (say 4 bytes) then you will see the location vs actual location become 4 extra bytes (or whatever it is) further out each time.
The bytes might be flipped (see big vs little endian) and I could almost expect to see sector addressing for the PSP (though more at iso level than file level).
I have also had number shifted for reasons known only to the devs.
When I mentioned compression before then sometimes the devs will use say the upper bits of the pointer value to indicate such a thing -- if you have 4 bytes that means you could theoretically fit gigabytes of data without doing sector addresses. As games on systems like this tend not to need it then you can afford to drop that a bit. It will however make the numbers harder to read plainly (though the rest of the number should be readable enough).
I doubt you will face encryption or other protections on a PSP game archive (at one point its eboots, aka the code the game runs from, were protected but all the keys have long since been sorted). If you find yourself on the PC and pulling apart games there in the future then this can change rapidly, some mobile phone games will also dabble in such things.
Beyond this we have the files themselves. Do what you will here. Things may be compressed individually (at the cost of some space savings it is easier to decompress individual files rather than have to unpack the whole file into the PSP RAM or something just to get a small file) beyond that but at that point we are backing to playing general ROM hacker, though actually much the same still applies (header, pointers and the data itself being a popular concept when it comes to systems with files, indeed still seen in many without files).
For simple archive formats on a non PC game I can't say I have ever had to bust out the debugging emulator* to figure it out like I might the files themselves but it is an option. This however gets into far more involved hacking as you follow along with what a program is doing to in turn replicate that yourself.
*though such things can be nice if there is compression involved as it might well copy it into memory and decompress it along the way. If there is any data generated on the fly or pieced together from disparate sources then grabbing it from RAM can also help.
Also https://web.archive.org/ , usually seen as things like https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial if you just wanted to copy paste the URL, is good stuff for trying to get old data back.
.pck, presumably short for pack, is perhaps not as common as .bin, .arc or .dat when it comes to the "I need a generic name for this extension" but still in the top 5. This is to say there might not be a tool as it could be completely custom to the developer or game itself and you get to modify it accordingly.
The thing starting its name with gz has me apprehensive -- gz is a popular type of compression (you tend to see it for program source code as blah.tar.gz). Though if it is simple gz then should be able to be initially decompressed with common programs (maybe even something as basic as 7zip) to then play unpacker.
I haven't got the game or file to look at but the following is my general approach to how I approach unknown archive files, and hopefully light introduction that you can follow along with.
Generally when it comes to archive and file bundling formats should I open it in a hex editor (old but still valid https://gbatemp.net/threads/rom-hacking-hex-editors-mid-2012-discussion.326873/ ) I usually expect to see
Some kind of basic header. Possibly a short string (aka magic stamp) to indicate the file type for the game or some tool being used internally by the devs, maybe a length of the whole file or a length of the sections within it.
After this (though it might be at the end of the file or might be in a separate file, usually one named very similarly or in the same directory/one up from it) there will be a list (or three or four) containing some of the following
name
file size
file location
any information regarding compression
In a sense all four of those (or however many more there might be if some other info is wanted) are optional, though in the vast majority of cases you would expect to have either file size or file location. For file size you get to add up everything that comes before it to get to the file you want. Sadly for many things names are often not included so it is more of a nice bonus when they do appear.
If the .pck does not have some immediate means of telling where the files are then they are either a fixed size (rare to see outside of text in menus or something) or maybe before each file is the file size and thus it can add everything up as it goes (usually see this more for scripting based things but can work as a file archive).
Anyway these file sizes/locations serve as pointers (programming term for value that tells you where something is, points the way if you will, a big list of them then serving as something akin to a contents page in a book) so if you change the files within to make them smaller or bigger you get to recalculate everything. If you are just unpacking it to look at separately then no great worry.
If you need a tool to feed a list of offsets with then I usually make a batch file (numbers gained from playing with a hex editor) with https://web.archive.org/web/20170218180937/http://min.midco.net/cracker/filecutter.zip to do it.
Pointers themselves, ignoring the sector stuff I cover a bit later, come in three main flavours
1) Simple location. Here the location of the file is written in a plain number. If you are editing a binary or something loaded in RAM then the RAM location might be used instead. For older systems it might be the location in the whole ROM (or whole ROM as it appears in RAM).
2) Offset. Rather than start from the start of the file it might say start counting from the start of the file section itself (or some other point). Basically add or subtract a fixed value to the pointers and you are good.
3) Relative. Take the current location of the pointer and add the value here to get to the ultimate location. A bit tedious but there are programming reasons some things choose to roll this way.
You need not try to make sense of the pointers in and of themselves. Recall earlier the part about magic stamps -- if they are at the start of the file you actually want to look at then you know where the file is within it and try to see where it and a few others might correspond to the header (the difference between one location and the next and the next should be mathematically related to the pointer section).
If you have a relative section and all the pointers are a fixed length (say 4 bytes) then you will see the location vs actual location become 4 extra bytes (or whatever it is) further out each time.
The bytes might be flipped (see big vs little endian) and I could almost expect to see sector addressing for the PSP (though more at iso level than file level).
I have also had number shifted for reasons known only to the devs.
When I mentioned compression before then sometimes the devs will use say the upper bits of the pointer value to indicate such a thing -- if you have 4 bytes that means you could theoretically fit gigabytes of data without doing sector addresses. As games on systems like this tend not to need it then you can afford to drop that a bit. It will however make the numbers harder to read plainly (though the rest of the number should be readable enough).
I doubt you will face encryption or other protections on a PSP game archive (at one point its eboots, aka the code the game runs from, were protected but all the keys have long since been sorted). If you find yourself on the PC and pulling apart games there in the future then this can change rapidly, some mobile phone games will also dabble in such things.
Beyond this we have the files themselves. Do what you will here. Things may be compressed individually (at the cost of some space savings it is easier to decompress individual files rather than have to unpack the whole file into the PSP RAM or something just to get a small file) beyond that but at that point we are backing to playing general ROM hacker, though actually much the same still applies (header, pointers and the data itself being a popular concept when it comes to systems with files, indeed still seen in many without files).
For simple archive formats on a non PC game I can't say I have ever had to bust out the debugging emulator* to figure it out like I might the files themselves but it is an option. This however gets into far more involved hacking as you follow along with what a program is doing to in turn replicate that yourself.
*though such things can be nice if there is compression involved as it might well copy it into memory and decompress it along the way. If there is any data generated on the fly or pieced together from disparate sources then grabbing it from RAM can also help.
Such an in-depth reply is greatly appreciated, unfortunately I am not experienced enough to even make heads or tails of what I get when I open the file in hex workshop
also I posted in the wrong section lol oops
also I posted in the wrong section lol oops
Similar threads
- No one is chatting at the moment.
