Decrypting Monster Hunter Frontier

To edit Monster Hunter Frontier (MHF), I had to decrypt and decompress its game files. Fortunately, I could build upon an existing C# solution called ReFrontier, which made this process more manageable.

Decryption

The first step in decrypting MHF files is understanding the encryption algorithm used by the game. A quick look at a hex editor reveals that Frontier files start with an “ECD” magic word, indicating they are encoded. The encryption scheme employs a combination of CRC32 and a pseudo-random array to achieve encryption. It uses little-endian convention.

To decode these files, you need to be aware of the following structure:

File Header:

65 63 64 1A 04 00 FB 7B 68 A8 70 00 6D 05 FA 5C

1. The first 4 bytes contain the magic word “ecd” (0-4 in red), followed by the ECD key (bytes 4-6).
2. Two ignored bytes (6-8).
3. The payload size (bytes 8-12).
4. The CRC32 hash (bytes 12-16).

The header translates to:

ecd 0x4 0x70A868 0x5CFA056D

Here we can notice that 0x70A868 is roughly equal to 7.3 MiB, the size of the file.

Payload: After the header, the encrypted data begins. To decrypt this payload, follow these steps:

1. Generate an initial encryption random value using the CRC32 hash.
2. Iterate through each byte.
3. Encrypt each byte using the ECD random value.
4. Update the ECD random value (using its value and an array).

After decryption, you’ll be left with a JKR file, which requires further processing to become readable.

Decompression

Monster Hunter Frontier files are also compressed using various algorithms to save space. A JKR file has its own header structure:

1. Magic word “JKR” followed by 0x0108 (08 01 in binary).
2. Compression type (a two-byte number between 1 and 4) and 0x0010.
3. Total size of the decompressed file.

Next, you’ll encounter the payload, which may use different compression schemes based on the header’s compression type (numbers 1-4). These are primarily based on LZ77 and Huffman algorithms, close to what is achieved in the DEFLATE algorithm.

Once decompression is complete, the resulting file should be readable. You’ll still find a magic word with the file extension at its beginning. It may often be “mhf”.

Reading data

When exploring MHF files, you’ll encounter various types, including unique “mhf” files like “mhfdat.bin”, “mhfinf.bin”, or other database files. These typically follow a straightforward structure:

1. Header : Contains pointers to block positions (e.g., item names).
2. Block Information : Start position pointer and end position pointer.
3. Array of Pointers : Between the start and end position pointers, you’ll find an array containing single datum pointers.
4. Datum pointer : is the position (in the file), of a single datum, such as a string.

Some data types can be read directly using a hex editor, while others may require decoding or special handling (e.g., text strings encoded in shift_jis 203).

A visualization of object names in mhfdat.bin with a hex editor

A good tool to explore the data structures is Monster-Hunter-Frontier-Patterns, as it highlights everything needed.

Packing back

To test your modifications, let’s assume you’ve added a new weapon name to “mhfdat.bin”. To integrate it back into MHFrontier:

1. Encode the string in shift_jis 203 for proper rendering.
2. Compress the file as a JPK type (3 or 4; either works). A good compression level is sufficient, such as 70.
3. Use the original header to encode the new file to an ECD file.
4. Replace the original “mhfdat.bin” with your modified version.

If done correctly, MHF should launch without issues.

Conclusion

Modding can be a fun and rewarding experience, requiring patience and understanding of various data structures and algorithms. In this case, decrypting and decompressing MHF files was a necessary step to access the game’s inner workings.