i cant find that much info about editing them but i did find this:
https://gbatemp.net/threads/how-to-open-pac-files.554465/#post-8893898
along with this:
https://wiibrew.org/wiki/Data_Containers#PAC.2FPCS_Files
https://gbatemp.net/threads/how-to-open-pac-files.554465/#post-8893898
along with this:
https://wiibrew.org/wiki/Data_Containers#PAC.2FPCS_Files
.pac is about as generic an extension as .bin
Every dev that just made an archive, a bunch of packed files if you will, and is needing an extension because it is 4:45 on a Friday tends to pick it.
This means thousands of entirely different variations on the theme are out there, and I would not be surprised at all to find mutually incompatible .pac files within the same game.
I don't think .pac is anything Nintendo provided for the GC (.arc is, related to .narc/carc on the DS, and .arc on the wii and 3ds) so probably not going to get much there. Nintendo games (and Warioware would fall under that) tend to use the formats provided as well if available, though sometimes with a minor twist.
That said it is an archive file so I would expect a fairly standard general approach
You will have the file
It might have magic stamp, and file size.
Archive files need a means to tell where the files it contains are. Enter pointers, file lengths and such like. Usually related to the file itself rather than how it might look in memory on the system. Sometimes this data will be in a separate file. Standard, offset, relative, sector and lengths being the main approaches.
If you are lucky then there will also be names of the files, extensions and such.
Things that might make it fun. The file might have some maths done to it. The .narc stuff referenced above is noted as using the first bit in the pointer (32 bits, 32 bits does about 4 gigabytes which nobody is going to use on a DS, or GC for that matter, 31 bits is still some 2 gigabytes) to indicate that the file is actually in a subdirectory. I had another DS game (touch detective) do a shift on the numbers for reasons best known to itself.
Compression of individual files within the archives.
Some kind of additional information that is included with the pointers. For text then I often see what character is talking, formatting for the text, length as well as pointer value (can be less than next pointer - current, or just be useful as it is quicker for some things), for audio you might have a whole bunch of things (frequency, number of samples, channels, bit depth...) and so on. This can usually be left for a bit while you sort it out -- again pointers count upwards in most cases so it is usually fairly obvious here how long each file's attributes are.
I mentioned subdirectories above, if the file is multiple directories then the nice initial pointer scheme might be momentarily interrupted by the arrival of such a thing but don't worry too much about that and sort what you have before tackling extras.
In some really annoying cases the file names and pointers are merged and file names can be any length.
I usually start by looking at the file -- pointers tend to be numbers that get larger as you go down the list (tends to correspond to files being further and further from the point you are at after all). After that I might try to find a file (if there are nice names to give me an idea of extensions and magic stamps I might find that, if not then files tend to have magic stamps, or things get padded after a file before the start of the next which tends to be obvious as a run of all FF or 00) and then see if I can find the corresponding pointer. If you are lucky then between the files there will be some kind of indicator, however that is rare for archives and tends to be more of a text thing (which is also where pointers come up a lot).
Every dev that just made an archive, a bunch of packed files if you will, and is needing an extension because it is 4:45 on a Friday tends to pick it.
This means thousands of entirely different variations on the theme are out there, and I would not be surprised at all to find mutually incompatible .pac files within the same game.
I don't think .pac is anything Nintendo provided for the GC (.arc is, related to .narc/carc on the DS, and .arc on the wii and 3ds) so probably not going to get much there. Nintendo games (and Warioware would fall under that) tend to use the formats provided as well if available, though sometimes with a minor twist.
That said it is an archive file so I would expect a fairly standard general approach
You will have the file
It might have magic stamp, and file size.
Archive files need a means to tell where the files it contains are. Enter pointers, file lengths and such like. Usually related to the file itself rather than how it might look in memory on the system. Sometimes this data will be in a separate file. Standard, offset, relative, sector and lengths being the main approaches.
If you are lucky then there will also be names of the files, extensions and such.
Things that might make it fun. The file might have some maths done to it. The .narc stuff referenced above is noted as using the first bit in the pointer (32 bits, 32 bits does about 4 gigabytes which nobody is going to use on a DS, or GC for that matter, 31 bits is still some 2 gigabytes) to indicate that the file is actually in a subdirectory. I had another DS game (touch detective) do a shift on the numbers for reasons best known to itself.
Compression of individual files within the archives.
Some kind of additional information that is included with the pointers. For text then I often see what character is talking, formatting for the text, length as well as pointer value (can be less than next pointer - current, or just be useful as it is quicker for some things), for audio you might have a whole bunch of things (frequency, number of samples, channels, bit depth...) and so on. This can usually be left for a bit while you sort it out -- again pointers count upwards in most cases so it is usually fairly obvious here how long each file's attributes are.
I mentioned subdirectories above, if the file is multiple directories then the nice initial pointer scheme might be momentarily interrupted by the arrival of such a thing but don't worry too much about that and sort what you have before tackling extras.
In some really annoying cases the file names and pointers are merged and file names can be any length.
I usually start by looking at the file -- pointers tend to be numbers that get larger as you go down the list (tends to correspond to files being further and further from the point you are at after all). After that I might try to find a file (if there are nice names to give me an idea of extensions and magic stamps I might find that, if not then files tend to have magic stamps, or things get padded after a file before the start of the next which tends to be obvious as a run of all FF or 00) and then see if I can find the corresponding pointer. If you are lucky then between the files there will be some kind of indicator, however that is rare for archives and tends to be more of a text thing (which is also where pointers come up a lot).
Had a similar discussion in https://gbatemp.net/threads/extracting-assets-from-spore-creatures.591227/ if it helps.
Anyway older games tend to bundle everything into one mega file. Things based on floppy discs, CDs, DVDs, other optical media or that are the DS or newer don't and instead are based on a file system, as you see there by it giving you a bunch of files to look at.
As you seem to have grasped then the names, sizes, extensions (also magic stamps which are short sections of text or hex strings, usually found right at the start or very close to the start of a file, that serve to identify the file type) can be used. However there is no mandate for devs to do things a given way and any dev can do whatever they like, indeed that is what makes ROM hacking hard as they often do whatever they like.
.bin, short for binary as in binary data or binary as in code what runs on the CPU, is probably the most common of the utterly generic names that devs will pick in a pinch but .pac (one packs and unpacks files from an archive file) is probably top 5 along with .dat (data) and .arc (archive) and something indicating compression.
This means there are a million different formats, generally mutually incompatible, with the same extension.
In the case of generic extensions you can sometimes narrow it down by developer, publisher, game itself ( http://wiki.xentax.com/index.php/Game_File_Format_Central https://wiki.multimedia.cx/index.php?title=Category:Game_Formats ) if someone has gone before you.
Most times though you are on your own.
This is not so bad though as most generic formats are usually quite basic and only include the bare essentials (though sometimes this means you might lacking names as technically you don't need names -- give the file at position 20 is actually probably quicker in many ways to retrieve something). This essentials list and common aspects list I was covering in the previous post.
The absolute essentials are where a file is, and the data of the file itself. Technically you could outsource the locations of all the files to a separate file (many times a separate file will be a thing -- easier to paw through a kilobyte or two of table of data rather than slice off a few megabytes of file to look at that instead, this will usually be a file with a similar name, or obvious name like table of contents/toc, in the same directory or the directory above) but I will leave that for now.
Computers don't know and it is computationally expensive to decode files like your web browser probably decoded this and automatically started new lines depending upon your magnification and resolution. Similarly for games it is not like the files are going to change (the Read Only part of Read Only Memory tending to speak to that one).
To that end we have pointers, these are small values that indicate the location, point the way if you will, of some data.
I usually liken them to the contents page of a book if I am going to make an analogy.
There are 5 main approaches, though mostly 3 are what the non PC hackers are concerned with.
1) Standard pointers.
Take the value as shown in the pointer, go to that location in the file (or maybe memory in some systems and setups)
2) Offset.
Take the value as shown in the pointer, add or subtract a given amount, and go to that location. The amount you add is usually going to be the same as the length of the header/pointer section/to get to where the data starts. To go back to the table of contents analogy then many books will have "front matter" use Roman numerals (i,ii,iii,iv,v,vi,vii,ix,x,xi...) to label the first few pages with the introduction and whatever else and leave Arabic numbers to the main content of the book. Similar idea really. You will tend to find this out by comparing what the pointers say to what you think should be the location of the files (again if they start with magic stamps or something then you can search for those and look for location. What they say vs what you expect and the difference being the same (go find a spreadsheet -- I still use one for these sorts of purposes) tends to mean this.
3) Relative.
For historical reasons and some technical ones these are still a thing. Here you take the location you are at, and the value of the pointer and add them together.
Directions are often given this way -- I could say relative to the corner of the room move 10 paces right and 10 up or I could say from where you are now then 4 paces right and 3 up. Computers have much the same thing at times where it knows where it is at and can jump relative to that location rather than some other reference.
Here if you take the difference of expected vs what the pointers say the difference will be different each time for the first (pointer 1 might be 4 bytes out, pointer 2 might be 8 bytes out, pointer 3 then being 12...) and 4,8,12 there is not a coincidence -- if each pointer is 4 bytes long then that means an additional 4 bytes out each time.
Remember to look up the difference between little endian and big endian too as it will save you some time when you run into it first.
The other 2 are
Simple length values. Literally that and is just the lengths of each file. I have seen it before that the length precedes the file/section and I have seen them before as basically a long list of pointers.
Sector addressing.
32 bits (4 bytes) can address files up to around 4 gigabytes. This is a lot of data but you probably have files with more in it. Rather than dedicate ever expanding numbers of bits to addressing data you will then meet sectors. Here sectors are chunks of a given size and you can then say sector blah, bytes [these]. Unused ends of sectors might waste some space but when you are talking in gigabytes you probably have this to spare. This is also why your files on Windows might have "size of file" and "size on disk" when you view their properties.
Text might have things like fixed lengths (every value on this menu is 10 bytes, don't care if you waste them, you will also not have more) too.
Pointers and the files are then all you really need but it is often really nice to have file names, extensions and such too. Hopefully they are included in this, but not all will.
I will spare the discussion of the weirdness and wonderful things that can also be present or happen, mainly as I covered a bit of it before and a session on those two links up above will give you some more ideas. Generally in ROM hacking you want to always be asking "if I was a dev how would I do it), or if you prefer the "archive, hidden, subdirectory, read only, file hash, compressed size vs uncompressed size, date modified..." that you might have seen when you compress files or see their attributes on your PC are also useful things that may or may not have made it into the archive format.
I have a general guide to ROM hacking
https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/
It is aimed at the GBA and DS but the Wii is similar enough to a lot of it
Chapters 14 and 15 of http://hitmen.c02.at/files/yagcd/yagcd/frames.html are also going to be good stuff here.
http://www.amnoid.de/gc/ is similarly old but also good.
For some more general stuff
https://awesomeopensource.com/projects/reverse-engineering
https://awesomeopensource.com/project/vitalysim/Awesome-Hacking-Resources
If you want to have a quick read of how file formats are generally programmed, or programming languages tend to approach using files (everything from boolean logic and bitwise operations to some of the things mentioned, to how something like C language programming represents things to help make more sense of some format listings) then that will also help.
If you need a hex editor then
Commercial world
http://www.hexworkshop.com/
https://www.sweetscape.com/010editor/
Freeware world, will probably want all of them to match the features of either above
Hxd, somewhat basic but the one I turn to if I am not on my machine and need an editor. The author has also been adding some features of some interest to ROM hackers
https://mh-nexus.de/en/hxd/
ICY hexplorer. Mostly about editing one file at a time but has some serious features. May or may not want to change the theme it comes with.
https://sourceforge.net/projects/hexplorer/
XVI32. Looks ancient but its scripting beats some of the commercial stuff
http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm
Tiny hexer. Website has died quite a while back now but still one of the best freeware editors.
https://www.softpedia.com/get/Others/Miscellaneous/tiny-hexer.shtml
There are some ones more aimed at text parts of ROM hacking.
Some new to ROM hacking seem to end up thinking hex editing is some ancient art known to ROM hackers. It is not. Being a master of a hex editor is a bit like being a master of a word processor and expecting that to allow you to write a novel with proper characterisation, pacing and no plot holes. Hex editors are crude tools, but as they expose the entire file and only edit what you say then they can be useful or at least usable. Your hex editor will show the same as mine as well so I can say open this in a hex editor, go here, edit this and you can replicate that, or expand upon it without needing to do anything fancy. If you see a ROM hacker edit something or decode something with one then it is not magic hex skills but in fact the coding stuff I mentioned above about operations, general approaches and more. It is also why you will not typically find videos that are useful/helpful on learning ROM hacking.
There are three parts
Usually on the left is the address.
This is the location in the file, usually given as hexadecimal.
In the middle is the data
This will be hexadecimal aka hex. You edit this by typing values 0 through 9 and A through F that correspond to the bits that make it all up.
On the right will be the data decoded as some form of text, usually ASCII unless you have a fancy editor/ROM hacking editor and tell it otherwise.
https://ascii-code.net/ but it still forms the basis of a lot of things. You can type on this if you want to change things.
ASCII (American Standard Code for Information Interchange) is a very old means of decoding hex as text (and not everything uses it, especially not non English language stuff, instead various other things culminating in unicode is where you look for that https://www.joelonsoftware.com/2003...-about-unicode-and-character-sets-no-excuses/, though being games then it can be completely custom)
Down the bottom of the editor depending upon what it is might be some random extra decodes or readings of the currently highlighted section, and results of any searches you might have done. Beyond that if you can use a word processor you can use a hex editor.
Similar threads
- No one is chatting at the moment.
