I think you can learn anything with information from publicly available sources. I think the best way to learn something is fiddling with it for fun. Formal education can be useful for structuring information in your head and broadening your horizons, but it's not strictly necessary. The main thing is to actually desire to learn something.
I'm a programmer, been doing in for more than a decade. Usually I fiddle with relatively high level stuff, completely unrelated to program reverse engineering, malware analysis, cybersecurity, programming in assembly or anything like that. But still I have some general idea of how computers actually run our programs.
Instructions on how to read 'data.pac' is obviously stored somewhere inside the game's .exe file, as it reads the file during launch.
Here's what I did: I used a program from SysInternals called Process Monitor (procmon) to record system call "ReadFile" from the game to 'data.pac'. It recorded 364,688 such events with quite a bit of information associated with each event, some of which was very useful. Namely, byte offset into the file, length (amount of bytes read) and a stack trace at the moment of read. I've exported all this information as one huge 2.2 Gb XML file and wrote a bunch of throwaway Ruby scripts to process and analyze it.
I've merged all 364k stacktraces into a single graph, and generated a picture below using GraphViz.
I've used x64dbg and later a pirated copy of IDA Pro to disassemble the game's executable file and poke around inside it, focusing on addresses shown in the graph. That's when I found that after some of the reads reads an internal file path is decoded and stored into some structure in memory.
Path encoding works like this: first, all path are UTF-8 strings of 128 bytes or less. Every byte of the string is XORed with a counter that count from zero to 127 inclusively. Decoding process is exactly the same, because (a XOR b) XOR b = a.
I'm pretty sure that rusimarudou's friend wrote something like this:
C:
char buf[128] = "some/path.txt";
for (char i = 0; i < 128; ++i) {
buf[i] ^= i;
}
Example: let's assume the archive contains file "info.xml". This string encoded in UTF-8 looks like this byte sequence: [0x69, 0x6e, 0x66, 0x6f, 0x2e, 0x78, 0x6d, 0x6c, 0x00]. Then we XOR it byte-by-byte with sequence [0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08] and get [0x69, 0x6f, 0x64, 0x6c, 0x2a, 0x7d, 0x6b, 0x6b, 0x08, ...] (garbage up to 128 byte boundary). This is directly written to 'data.pac' at some offset.
So I quickly sketched out a script that goes through all the read events and tries to decrypt part of 'data.pac' specified by the event's offset as a file path. That's how I got that list of files.
Sorry for my sloppy language and overabundance of technicalities.
