ROM Hack Translation [Absolute Novice] How do I view packfile.pak from Spongebob & Friends Battle for Volcano Island


New Member
May 22, 2022
United States
What's the big picture of what I'm trying to do?
In order to dip my toes into ROM translation, I want to do something incredibly basic by taking the European version of a short licensed game I played as a kid, and Americanising the Spanish/French text, or even *gasp* replacing one of the languages with Catalan. To this end, I have attempted to use multiple hex editors (2 of which were on Pop!_OS before I read that the best tools are Windows-only) on the .nds file, getting the furthest with Tinke, but obviously I got stuck.

How so?
I've been spinning my wheels in the mud figuring out how to open the packfile, which seems to be where pretty much all the data I would want to change (i.e. the game's text and possibly the flag images, should I wish to change the flags that appear in the language select screen, which are animated). I tried opening the .pak file as text using all encoding options, exporting the file and attempting to open it in many different programs, including WinZip and FireFox, renaming it as a .zip file and trying to extracy its contents in WinZip, but so far, no dice. Also the View button is greyed out when I select the packfile.

I also tried Googling answers, coming across this forum, multiple times, finding out that not all .pak files are created equally.


Editorial Team
Nov 21, 2005
United Kingdom
Interesting twist in the "ROM uses one big archive" thing we sometimes see.

There might not be an existing tool if tinke does not have one. Can still get a lot of things done with spreadsheets and tools like though, including making enough to put it back together afterwards. Or if you know a programming language then should also be relatively doable here if the format is as simple as it looks, but that is getting ahead of things.

Had a quick look.

607AD7 being the last selectable byte and it looks like the numbers go up that high by no further if you flip things around (see big endian vs little endian), indeed the last byte might be an archive size (odd as things usually start out with that but hey)
Normally for this sort of thing you try to find a file within the archive and see if you can match it to the data there, or if you have a nice list of what looks like locations (for a 6 meg file then that is a reasonable amount of files to house) then you can try visiting those to see what you find. I am seeing a lot of "FPAK" in there which has me curious (either the devs used it as a format for everything* or it is some kind of bounding part of the format so every section starts with it) but I will leave that for now.
No apparent names or extensions or anything which is a pity but not unexpected in these scenarios.

*if you made your game pull everything from a big FPAK archive then it can make sense to view every file within the game through the lens of the mighty FPAK format.

Going with the apparent locations thing.
019C appears to be the end of the useful data in the header and it is all FFFF from then on until 01AC (another pointer by the looking of things and also has FPAK). FFFF being there is odd in some ways but could also be in case they want to add more data or could be padding (for some purposes it can be easier to pad things out to line up at certain addresses/sizes of data).
That said immediately after 01AC we have 00016BB8 which is considerably ahead in the file. Could be an archive within an archive so I will leave that for now (or I could analyse the new FPAK but as I know so little then that might not do much good -- though analysing small examples of formats can be useful). Going down through the file I did not notice anything until I got to 16324 wherein I saw FPAK, and several times in fairly quick succession. Archives within archives again or relative pointers (sometimes apparent locations are not directly but you add the current location to the value at it to get where you want to go, hangover from legacy computing really but still seen on the DS and does make some maths a bit quicker) being what I would be suspecting, though 16bb8−01ac = 16A0C which is still rather ahead of things so unlikely to be relative.
Anyway at 16BB8 we get another FPAK and following a run of FEFE which is odd for a padding value. FPAK again is not too interesting but I do see RECN a bit further down which is the indicator of the NCER graphics related format and some data to match what I would expect there[469]nds_formats.htm#NCER
Comparing to that link though I think it might be compressed (the further aspects of the file have their own magic stamps, here though separated by other values which usually means LZ compression of some format, , though I don't see the 10 or 11 or even 40 somewhere before that which I would usually expect to see before it as indicators of normal compressions. As a quick test I did a basic zip of the packfile.pak and it dropped from 6 megs to 4.2 so likely not compression on everything in the file, did not check what this current "segment" might compress as though.

0682F4 is next value which is a bit of a jump but if it is archives in archives then OK. If it was the highest bit then sometimes those are sacrificed to denote subdirectories, compression or something but this is not that -- if each of these what I am calling entries is 32bits long then 2^32 is up in the 4 gigabytes range, losing a single bit to indicate compression slams you down to 2 gigabytes which is still more than enough for most purposes on the DS.
Just in case then 0182F4 is in the middle of nothing in particular.
0682F4 is however another FPAK (and immediately above is I see RLCN which is another on the common formats list, in this case a palette format for 2d images)

0815D4 has another FPAK and soon after RECN and RLCN.

All appear to land me on a section starting with FPAK.
Picked a random one later in the list. 392f20 lands me in some blank section of FF, the next value is 392f30 which is the start of another FPAK. Curious. Going back from there it is every 10h for a small run which is more FF. Could be some files removed and replaced with blanks (various companies around this time had policies to make sure beta code or hidden messages did not leak out because some dev did not clean up properly).

If you wanted to then you could probably split things up with the filecutter too mentioned at the start (it has an offset command so you can tell it to slice out this much from this section, make a list of however many dozen commands that would be with a spreadsheet and you have a crude but effective extractor (hint, use the locations as names as you don't have any, sizes are the next value minus the current one which a basic fill command on a spreadsheet should handle nicely). If it is all going to be FPAK or simple runs of FF then I don't know what you will really gain, though it could be a good start peeling back layers.
  • Like
Reactions: bilibili2011
General chit-chat
Help Users
  • No one is chatting at the moment.
    KenniesNewName @ KenniesNewName: