meta:
  id: m2cryptedobject
  endian: le
seq:
  - id: header
    type: header
  - id: magic_verification
    type: u4
    if: header.crypted_size == 0
    enum: cryptedmagic
  - id: crypted_magic_verification
    type: u4
    if: header.crypted_size != 0
  - id: crypted_content
    size: header.crypted_size
    if: header.crypted_size > 0
  - id: compressed_content
    size: header.compressed_size
    if: header.crypted_size == 0
types:
  header:
    seq:
      - id: magic
        type: u4
        enum: cryptedmagic
      - id: crypted_size
        type: u4
      - id: compressed_size
        type: u4
      - id: real_size
        type: u4
enums:
  cryptedmagic:
    1347633997: mcsp
    1515144013: mcoz

The format contains a 20 bytes header followed by the content (either crypted or compressed) of the data.

Header

Bytes colored in red (first 4 bytes): A FourCC code that identify the type of object.
Bytes colored in blue: Size of the data after being crypted
Bytes colored in green: Size of the data after being compressed
Bytes colored in yellow: Size of the data without any cryptation or compression (real data size)
Bytes colored in black: Crypted FourCC code, used to verify if the XTEA decryptation was successfull or not.

NOTE: If the Crypted object is not crypted, the bytes in black will contains the FourCC.

Data compression

The data is compressed by one of the following algorithm based from the FourCC code. A list of known compression algorithms is provided below.

Data cryptation

NOTE: If the blue bytes are 00 00 00 00 it means that the data is not crypted, therefore the game will not attempt to decrypt the content.
The data is crypted with the XTEA algorithm, therefore all the data requires some keys in order to function correctly, a list of known keys is provided down below:

This method went in disuse some time after 40k files, as today no official server still uses Texture caching.

RDCH format

• The first 4-bytes: Number of texture cached.
• Then, each texture cached is contained inside, at least 8 bytes per texture.
• First 4 bytes: Length of the cached texture (The name is a file contained inside the corrisponding EterPack)
• Next 4 bytes: Mipmap count
• Then it follows the name of the file without a null terminator.
• Last, the DDS texture for each mipmap compressed.

All the EterPacks are stored inside the pack/ folder of the game client, and they are load in a specified order, defined by the Pack Index file stored inside pack/ folder.

An EterPack consists of two files, the Index file (.eix) and the Content file (.epk).

The Content file is where the files are stored, either crypted or decrypted, while the Index file is where all informations of the files are stored. (An information might be the file's compression type or the directory where it should virtually mapped).

Index files are usually encrypted as a Crypted Object, therefore, before reading the header, the client must decrypt the file following the method described in the Crypted Object page.

Index file

An Index file contains 12 bytes as header, described as follows:

Bytes in red: FourCC (EPKD)
Bytes in blue: Version (Must be 2, it is not known if a EPK with version 1 exists)
Bytes in green: Number of files included in this EterPack.
Bytes in brown: Start of the file index information

From the number of files included in this EterPack, it follows one or more "Index File Information" or simply File information.

Bytes in red: A 32-bit number that identify the file, this number starts by 0
Bytes in blue: A filename encoded in ASCI (160 bytes + the null terminator)
Bytes in black (1): Padding bytes
Bytes in green: CRC32 of the file name
Bytes in yellow: Decompressed and decrypted file size
Bytes in gray: File size stored in the EterPack content file
Bytes in orange: CRC32 of the file content
Bytes in brown: Offset of the file position in EterPack content file
Byte in purple: Identify the type of algorithm used to crypt the file
Bytes in black (2): Padding bytes

Content file

An EterPack content file (.epk) just contains the data crypted by the specified algorithm (Also known as Type), there is no header or any format in this file, they are pure RAW files which could be accessed and used from the index file.

• The algorithm that is used changes from the file name, this means that new algorithms can be used and implement in newer versions
• The key and the IV are sent from the server (after a successfull login), forcing the user to bruteforce a key for every single file extension crypted.

The Hybrid cryptation is divided in two parts:

• The extension keys
• The file cryptation

Extension keys

The extensions keys is a 16 byte key and 16 byte IV associated to an extension. The keys does not change based from the cryptation type used. The keys are randomly generated during the creation of an EterPack.

An extension key is generated by performing the following actions:

1. Calculate an hash of the extension (the extension is written in lowercase and does not contain the . before the extension).
2. Generate two 16-byte values and associate them to the extension hash.

The hash used is simply a 32-bit FNV-1a hash function with the offset_basis set as 0. Written here, a modified version of a MIT implementation found here:

// License: MIT
// Famous 32 bits FNV-1a hash function by Glenn Fowler, Landon Curt Noll, and Phong Vo.
uint32_t fnv1a32(const char* apStr) {
    uint32_t hash = 0; // 32 bit offset_basis = 0

    for (uint32_t idx = 0; apStr[idx] != 0; ++idx) {
        // 32 bit FNV_prime = 224 + 28 + 0x93 = 16777619
        hash = (16777619U * hash) ^ static_cast<unsigned char>(apStr[idx]);
    }

    return hash;
}

File cryptation

A file is crypted with an unique key and IV generated from the extension key. Each file might be encrypted with a different cryptation type, as it's chosen during the cryptation of the file.

A file is encrypted by doing the following actions:

1. Calculate a CRC32 of the filename (the filename will contain the extension and it's all written in lower case).
2. Select the algorithm to use for cryptation.
3. Get the extension key for the file.
4. Generate the IV and key used for the algorithm from the extension key.

The algorithm is chosen by doing the module of the filename crc with the cryptation types (currently 3).
The key and IV are simply the extension key and IV XORed with the CRC filename (every 4 bytes of the key/IV is XORed).

Known cryptation types

• Camellia
• Twofish
• XTEA

Extra data

HybridCrypt Extra data (also known as Type5) is a special cryptation type, where some portion of the file are removed from the client cryptation and stored in the server.
This method ensures that it's impossible to fully retrive the content of a file without connecting to the server, despite being more consuming in terms of bandwidth.

A extra data cryptation will work as follows:

1. Choose a part at the end of the file to remove (From 64 to 128 bytes)
2. Crypt the file without the remaining 64/128 bytes with an usual HybridCrypt
3. Store the remaining bytes in the Server

The extra data will be sent to the client once the client has successfully logged in (same as the HybridCrypt keys)
The data sent from the Server is not encrypted in any form.

In the server, this file is used to process all the item (such as when you equip an item, if you can actually equip it).

In the client, this file is used to perform several client-side checks (in order to reduce the amount of data sent to the server) and what actually is displayed in the item information.

The Item proto must be in one of this two formats, MIPX format or MIPT format.

Although the client is able to load a MIPT Item Proto (as references exists in the binary), no MIPT proto has ever been found.

MIPX format

Bytes in red: FourCC (MIPX)
Bytes in blue: Version of the item proto (Generally 1)
Bytes in green: Stride (Size of the structure that contains the items)
Bytes in black: Number of elements
Bytes in gray: Size of the Crypted Object data
Bytes in orange: Begin of Crypted Object data

MIPT format

While references of this file format still exists in the executable, no public client that ships a MIPT proto has ever surfaced. It might have been used during development of Metin2 or in very old clients (like 2004 or 2003). The CryptedObject format is the same as a MIPX proto.

Bytes in red: FourCC (MIPT)
Bytes in blue: Number of elements
Bytes in gray: Size of the Crypted Object data
Bytes in orange: Begin of Crypted Object data

Structure: Generic 40k (Stride: 163)

// Item Proto applies and limits are the same.
typedef stuct Limits {
uint8 type;
int32 value;
} Applies;

Item table

//// Size: 163

uint32 id; // vnum
uint32 range;
char indexName[25];
char translatedName[25];
uint8 type;
uint8 subtype;
uint8 weight;
uint8 size;
uint32 antiflags;
uint32 flags;
uint32 wearflags;
uint32 immuneflags;
uint32 buyprice; 
uint32 sellprice;
Limits limits[2];
Applies apply[3];
int32 values[6];
int32 sockets[3];
uint32 refineditemid; //refinedvnum
int16 refineset;
uint8 altermagicvalues; //altertomagic
uint8 specular;
uint8 altersocketpercentage; //gainsocket

Consider this example:

• You have a big texture atlas of the minimap (like d:/ymir work/ui/minimap.dds), the sub file is used to tell the client where the button location is.
• All the options listed here are REQUIRED otherwise the file will not get loaded correctly.

Version

The version field is used to tell the client a specific base path where the file should be loaded.
Both directories supports multiple subdirectories.

1.0

The base directory of the file will be "D:/ymir work/ui"
Example: if "image" is "new_system/test.dds" the full image directory will be "D:/ymir work/ui/new_system/test.dds"

2.0

The base directory of the file will be the current directory where the sub file exists.
Example: if "image" is "new_system/test.dds" and the sub is stored inside "locale/en/test.sub", the full directory of the image file is "locale/en/new_system/test.dds"

There are two types of map that the client can load, Indoor and Outdoor maps.

Outdoor maps are all the maps that you freely stay on the outside (not in a closed place), an example of this could be a village.

Indoor maps are all the maps that are closed, an example of this could be the monkey dungeon or the spider dungeon. Indoor maps does not load an environment, as the presence of the sky and the sun should not exist.

Each chunk has it's own ID and represents an area of 128x128.

The chunks size are defined in the Settings file, when you warp to a coordinate, for example: (20, 0), the client will divide the current X and Y of the chunk size to the coordinates, and generate an X and Y id, the X id will be multiplied by 1000.

For example, (0, 20) will be chunk 000000, while chunk (128, 0) will be associated to chunk 001000.

MapProperty.txt

This file contains the type of the Map. This file is a text file that honors the Metin2 Script file.
NOTE: The type of this script MUST be MapProperty

Settings.txt

This file contains the configuration of the Map. This file is a text file that honors the Metin2 Script file.
NOTE: The type of this script MUST be MapSetting

Atlas minimap

The following minimap shown when you press M (internally called Atlas).

There are two known ways of setting up the atlas, first is by providing a file called "atlas.sub" inside the map directory, the second way is by creating a file called "atlas.sub" inside the following folder: "d:/ymir work/ui/atlas/(map name)".

If this image does not exist then the game will report that the Atlas map cannot be shown.
The sub file respect the style of a Metin2 Sub file.

Chunk files

The following files listed are contained in each chunk map folder.

attr.atr

This file defines the collision of an area.
The first 6 bytes MUST contain the following data:

0x4A 0x0A (File identifier)
0x00 0x01 (Width of the area, always 256)
0x00 0x01 (Height of the area, always 256)

What follows after is the collision data of every point of the map. The data lists each X coordinate for one Y coordinate. (From (0,0) to (256,0) then (0,1) and so on).
A collision byte contains informations inside it's bits.

water.wtr

This file defines the water height information, this defines how much space should the water occupy in the map.
The first 6 bytes MUST contain the following content:

32 15 (File identifier)
80 00 (Width of the water map)
80 00 (Height of the water map)

The 7th byte contains the number of water height contained in the map, if the number is 0, no map will be loaded.
The next data contains the water height numbers, the data lists each X coordinate for one Y coordinate. (From (0,0) to (256,0) then (0,1) and so on assuming 256 is the width of the chunk).

Each height number is stored in a 4-byte number.
For example, the coordinate (1,2) will start in the 2052th ( (2*256) + 1) * 4) position of the data array, assuming the map width and height are 256.

NOTE: The game references a support for 2-byte height, but they looks like they can throw a copy error / disabled.
NOTE: The client only supports width and height of 256, although is possible to make bigger chunks.

AreaProperty.txt

This file is a text file that honors the Metin2 [Script file].
NOTE: The type of this script MUST be AreaProperty

AreaData.txt

This file contains all the 3D objects that the chunk contains.
This file is a text file that honors the Metin2 Script file with nodes.
NOTE: This file starts with AreaDataFile not with a ScriptFile.

Based from the number of object counts, there will be one or more object information vector contained inside.
NOTE: Please note that the count starts from 0.

AreaAmbienceData.txt

This is another file that loads the 3D objects that a chunk contains, it is currently not known the difference between ambience data and normal data.
This file is a text file that honors the Metin2 [Script file].
NOTE: This file starts with AreaAmbienceDataFile not with a ScriptType.

Based from the number of object counts, there will be one or more object information vector contained inside.
NOTE: Please note that the count starts from 0.

minimap.dds

This texture contains a 256x256 representation of the chunk that will be used in this minimap:

shadowmap.dds

This texture contains a 256x256 used to draw the shadows of the minimap chunk.

height.raw

This file contains the information of the height of the terrain.
The file has a fixed size of 34322 bytes and it always represents a map chunk with width and height 131x131.
The Z axes of the map is expressed inside two bytes (hence why the size is 131*131*2).

tile.raw

The file usage is unknown.
This file has a fixed size of 66564 byes and it always represents a map chunk with width and height 258x258.

• In the server, this file is used to process the mob information (such as damage).
• In the client, this file is used to perform several client-side checks (in order to reduce the amount of data sent to the server) and what actually is displayed in the item information, another example if the mob directory.

The Mob Proto contains only one format (MMPT), which is then crypted as a Crypted Object.

MMPT format

Bytes in red: FourCC (MMPT)
Bytes in blue: Number of elements
Bytes in gray: Size of the crypted object data
Bytes in orange: Begin of crypted object data

• 4 bytes in black, only present at the beginning: Number of file entries included.
• One or more file entry

File Entry

• 32 bytes in green: Filename (Encoded in Windows-949).
• 4 bytes in purple: Offset of the file (relative to the stat of the tar file)-.
• 4 bytes in blue: Size of the file.
• Bytes in grey: beginning of a new entry.