Monster Hunter Online (.ifs)

[IionHermit]

Hey all! Sense the release of the game, they appear to of went from .pak files to .ifs.

There was this script originally for the Bench Mark of the game - http://aluigi.altervista.org/bms/monste ... r_nifs.bms

However it doesn't appear to work anymore. Below you can find a newer version of a .ifs

Any help would be great!


DL Link to latest .ifs patch: https://mega.nz/#!8JNkmL5Q!ft94YR202_yX ... kL8VMgEWaI

[MagicMuffinSyndra]

There is actually no need to translate this anymore (assuming that's what you are after). The patch is actually coming along very well and shouldn't take too much longer. Of course, if anyone DOES no a way to extract them, it would still be awesome.

[IionHermit]

I was thinking about doing a quick translate (aka Throw XML into a Translator, and throw it back into the file.)

However, as far as I've seen, I've only heard that the person doing it is actually doing it... I haven't seen the actual game translated so far.

I'm also interested in a few of their assets/songs/etc. But thats another story.

[MagicMuffinSyndra]

Oh, yeah I understand. If you are interested I can send you some links. But yeah, I'm with you there. I was looking into accessing the files as well. I am also trying to figure out how to access the ones from Frontier as that one is not being translated, but so far no one has answered.

[XatiX]

Well it's being compressed using this.
https://mega.nz/#!Y89F2I7D!OdMHtUJi06wN ... 1UrTlmKu4E

If someone can work off that then good luck, I'm interested but don't know enough the reverse engineer it.

[aluigi]

That archive is very strange and different than the others.
The offsets at the beginning point to sections containing "BET", "HET" and some 0xf1... data.
Most of the archive is a sequence of files with a "Crytek" magic but I don't see references to their offsets and sizes.

[IionHermit]

As a sidenote: There was also this which was made to use in conjunction with the IFSDLL Xatix uploaded, however it doesn't appear to work with the newest version/older version.

https://github.com/FreeTheTech101/ifs-tool

[XatiX]

Link to the main file we're trying to crack open.
https://mega.nz/#!olFnlZyI!KCIlLtsArzs7 ... 8FFmJu7RTc

[aluigi]

They are like resources without references (offset/size).
For example there is a flash file at offset 0x871fce0 of about 0x2126 bytes but it's linked nowhere.
And the same is valid for the first data between 0xac till 0x1e6f (followed by its md5), I see no references.
Probably the information table is obfuscated.

The first file is followed by its md5 but it's not valid for the others (I already tried to concatenate and so on) so it's not possible to apply the trick of the md5 scanner to dump the data.

[XatiX]

So we pretty much out of luck?

[XatiX]

Know this is now an old post but I'm still interested in trying to get these files open, considering it's been done before but people aren't sharing their programs/scripts.

Here's some information I scrounged up though not sure quite how accurate this still is.

DWORD dwSignature; // 0:3
DWORD HeaderSize; // 4:7
USHORT wFormatVersion; // 8:9
USHORT wSectorSize; // A:B
DWORD dwArchiveSize; // C:13
ULONGLONG BetTablePos64; // 14:1B
ULONGLONG HetTablePos64; // 1C:23
ULONGLONG MD5TablePos64; // 24:2B
ULONGLONG BitmapPos64; // 2C:33
ULONGLONG HetTableSize; // 34:3B
ULONGLONG BetTableSize; // 3C:43
ULONGLONG MD5TableSize; // 44:4B
ULONGLONG BitmapSize; // 4C:53
DWORD dwMD5PieceSize; // 54:57
DWORD dwRawChunkSize; // 58:5C


BYTE MD5_BlockTable[0x10]; // MD5 of the block table before decryption
BYTE MD5_HashTable[0x10]; // MD5 of the hash table before decryption
BYTE MD5_HiBlockTable[0x10]; // MD5 of the hi-block table
BYTE MD5_BetTable[0x10]; // MD5 of the BET table before decryption
BYTE MD5_HetTable[0x10]; // MD5 of the HET table before decryption
BYTE MD5_MpqHeader[0x10]; // MD5 of the MPQ header from signature to (including) MD5_HetTable

If someone can make a script out of that it would be amazing, if this doesn't solve an underlying issue I'm sorry to waste your time.

[Lhos]

If someone can make a script out of that it would be amazing, if this doesn't solve an underlying issue I'm sorry to waste your time.

I went ahead and wrote a simple script to analyze the IFS archives in MHO using that information. Seems like a long shot.

Code: Select all

Analyzed base_000_2016_02_22_17_52.ifs
signature: 6E696673   7366696E
headerSize: AC000000   000000AC
formatVersion: 0000   0000
sectorSize: 0500   1280   0005   5
archiveSize: 00C00B16   12585750   160BC000   369868800
betTablePos: 0000000084D80816   1608D88400000000
betTableSize: 7DC60200   2110128640   0002C67D   181885
hetTablePos: 000000004D9D0816   16089D4D00000000
hetTableSize: 273B0000   658178048   00003B27   15143
md5TablePos: 0000000000C00B16   160BC00000000000
md5TableSize: 00830500   8586496   00058300   361216
md5PieceSize: 00000000   0   00000000   0
bitmapPos: 0000000000431116   1611430000000000
bitmapSize: 2F580000   794296320   0000582F   22575
rawChunkSize: 00400000   4194304   00004000   16384
fileSize: 370252591
tables+BitmapSize: 3571189504   580819

It outputs the byte values found at the addresses you gave, showing big-endian first and then little-endian. Size values also show the decimal equivalent. I chopped most of the size values down to four bytes since only the latter four were ever used (much like table addresses). The only way any of the addresses you posted seem possibly correct is if the values are stored little-endian, since the stated archive size isn't anywhere near the file size otherwise. If the values are read as little-endian, though, then you consistently get an archive size of about 99.8% of the file size on disk, and summing the table sizes and bitmap size (contentSizeSum) amounts to about 0.11% of the file size.

EDIT: Guess who just read up on MPQ headers.

I'll mess around with this a bit more and see what kind of data these addresses and sizes will get me.

UPDATE: Got as far as extracting what should be the block and hash tables. I'm able to pull the first three fields of their headers from them, which include sizes for the remainder of their data that do match what's in the archive header minus the 12 bytes already read from each by that point. Stuck trying to decrypt the rest of the tables for the time being. Not sure if I've just got the wrong keys (probably) or if my code's not quite right.

[XatiX]

Well sounds like you're making progress at least, thanks for even trying

[Lhos]

Still working on decrypting things. I've been running on the assumption that the first three bytes in the block/hash table headers are decrypted since they seem to make sense as-is, and using the information there (namely the size values I find there and in the archive header), I'm trying to bruteforce the hash/block table encryption keys by starting with the encrypted tableSize field and ending with the value listed in the archive header. While this has given me some values that do wind up decrypting that one value fine, nothing else does, so it seems like I'm not decrypting properly - might need a different algorithm entirely (which could be in ifs2.dll somewhere, not that I know how to get at it). I'm pretty sure the tables aren't compressed, since if they were, you'd need to have some way of knowing how much data to read before decompressing, which isn't listed anywhere I can see.

EDIT: Here's where I'm at:

Code: Select all

Analyzed base_000_2016_02_22_17_52.ifs
signature: 6E696673   nifs
headerSize: 000000AC   172
formatVersion: 0000   0
sectorSize: 0005   5
archiveSize: 160BC000   369868800
betTablePos: 1608D884
betTableSize: 0002C67D   181885
hetTablePos: 16089D4D
hetTableSize: 00003B27   15143
md5TablePos: 160BC000
md5TableSize: 00058300   361216
md5PieceSize: 00000000   0
bitmapPos: 16114300
bitmapSize: 0000582F   22575
rawChunkSize: 00004000   16384
fileSize: 370252591
tables+BitmapSize: 580819



signature: 4245541A   BET
version: 00000001   1
dataSize: 0002C671   181873
tableSize: 0002C67D   181885
fileCount: D8A0849D   -660568931
tableEntrySize: 4ED11DD6   1322327510
bitIndexFilePos: 8B822CC9
bitIndexFileSize: 21C02A17   566241815
bitIndexCmpSize: 69F1DECF   1777458895
bitIndexFlagIndex: C515EE01
bitCountFilePos: 6F2FBDD7
bitCountFileSize: BD70F9EA   -1116669462
bitCountCmpSize: CB287661   -886540703
bitCountFlagIndex: CF1C00A7
totalBetHashSize: F3E0C101   -203374335
betHashSizeExtra: 71280DE6   1898450406
betHashSize: E2B746BB   -491305285
betHashArraySize: DF905468   -544189336
flagCount: 944FC191

Top section is archive header data, bottom is block table header data. I've gotten a key that properly decrypts the tableSize field (which should match betTableSize), but everything else in the block table header is junk using that key, so my algorithm is probably wrong. I wouldn't be surprised if they weren't using ancient MPQ encryption algorithms, but up to this point everything about the file seems to stick to MPQ standards... but since the last unencrypted field in the block table header is dataSize, maybe the header is only those first three values? Don't see how you'd get by without the rest of that header information though.

MOAR EDIT: Yeah, something's *SPAM* here - if tableSize is the size of the entire block table, header included, then it would have to include not only itself, but also the rest of the header, so dataSize - tableSize would have to be greater than 12, but we know what tableSize should be since it's in the archive header as well.

[XatiX]

Not sure if this is going to help with the encryption or not but there's references to libtomcrypt inside the IFS2.dll which is still posted in this thread.

Do a search for crypt in a hex editor and reference the files used here:
https://github.com/libtom/libtomcrypt/tree/develop/src

[Lhos]

Not sure if this is going to help with the encryption or not but there's references to libtomcrypt inside the IFS2.dll which is still posted in this thread.

Do a search for crypt in a hex editor and reference the files used here:
https://github.com/libtom/libtomcrypt/tree/develop/src

Interesting, though if they used that library for encryption, it presents a real problem since the algorithms listed there are much more robust than the simple MPQ one. Bruteforcing the key would be difficult, if possible. The reference to "pk\rsa\rsa_make_key.c" worries me the most.

EDIT: That key has to exist somewhere local, though. Digging it up is the tough part.

[Elrim]

If you could Handle it this would be amazing! i am Still searching for a solution since 2 month... allready tryed every tool i can find.

Aluigies tool is nice and i extracted a few chunks but they are uncomplete!

You can make it! I believe in you!

[Lhos]

If you could Handle it this would be amazing! i am Still searching for a solution since 2 month... allready tryed every tool i can find.

Aluigies tool is nice and i extracted a few chunks but they are uncomplete!

You can make it! I believe in you!

Appreciated, but I know absolutely nothing about monitoring a running process to sniff out values in memory. The only way I'd manage to decrypt anything would be to brute force it by taking chunks out of ifs2.dll and trying them with various encryption algorithms (IE if the key is in ifs2.dll, try every possible X-bit string of data in the file until something clicks). That said, the algorithms in libtomcrypt have much greater complexity than the simple, standard MPQ encryption algorithm, so bruteforcing those would take ages if it's even feasible.