AZICKO

This page aims to explain the current two cryptation algorithms known to be used by M2 for encrypting and decrypting network data. Keys are reported as two 64-bit integers (first number, second number) in hexadecimal. NOTE: The encryption will start after a Phase packet once the Handshake is finished, therefore both the first Phase packet and the Handshake packets are not encrypted. XTEA Encryption This encryption is divided in two phases, Auth Phase and Game Phase. Every packet that uses this encryption gets encrypted and decrypted with the TEA algorithm and a TEA key. This encryption was used starting from 2004 to 2011/2013. (Before revision 34k was introduced) The encryption works by having two XTEA keys, the first one (Referred as Auth phase key) is a static 16 bytes key used in the first stage of the communication, this key will be used until a Client has attempted to log in into a Channel (any core that is not an Auth one) with the login key method. Once the client sends a Login packet to a channel, it will also send it's encryptation keys where the server's encryptation keys will be computed. The keys will be changed IMMEDIATLY, no extra packet or data is needed to change the keys. This generated second keys are referred as Game phase keys. The client computes it's decryptation key (likewise, the server computes it's encryptation key) by performing an XTEA of the encryptation key (decryptation key for the server) with a Special key. Key list Auth phase keys (Both for encrypting and decrypting) Usage First number Second number Notes Worldwide 0x7473657474736574 0x7473657474736574 ASCII: testtesttesttest European servers 0x6867666538373635 0x6463626134333231 ASCII: 1234abcd5678efgh Special keys The Special key was generated by the Client and the Server during the login into the Game core, it is known that in very old version of M2 (such as the Korean 2003 beta) the following hardcoded key might be used rather than a random generated one. Special keys Usage First number Second number Notes Korean server 0x6a6c48747854794a 0x726f484a566c4a48 ASCII: JyTxtHljHJlVJHor Diffie-Hellman key exchange The improved packet cryptation is performed by choosing a suitable cipher based from the shared secret that is exchanged with Diffie-Hellman. This encryption is used from 2011/2013 to today. NOTE: The handshake phase is not encrypted. Unified Diffie-Hellman key exchange Initialize RFC 5114's 1024-bit MODP standarized parameters (p, g, q) Randomly generate a Static and Ephemeral public and private keys with Unified Diffie-Hellman. Pass the shared secret length and public keys to the network and perform an agreement with the received public keys and shared secret length. Cipher choose Takes the remained of the first byte in the shared secret block with the shared secret size. This number will determine where the first cipher number that is stored in the shared secret block. Takes the remained of the second byte in the shared secret block with the shared secret size. This number will determine where the second cipher number that is stored in the shared secret block. Takes the remained of this two bytes generated from the secret block with the max algorithms supported and pick an algorithm. The shared secret block contain the algorithm's keys and a block data (a random block is being used because some algorithms do not support IV), that will be used to crypt the packets. The selected cipher will be processed with CTR Mode and the generated IV If the keys are generated by the server, the first cipher will be the encryptation cipher. the second will be the decryptation cipher. The keys are inverted in client side. (The lengths are the default lengths assigned to the algorithm) Appendix Secret block content: Start of shared data first key second key non important data second IV first IV End of shared data List of known algorithms: RC6 MARS Twofish Serpent CAST256 IDEA DES-EDE2 (Triple DES) Camellia SEED RC5 Blowfish TEA SHACAL2

The Mob Proto is a crypted file that contains all informations about the monsters and NPCs included in the game. This file is present both in the client and the server. 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

In Metin2, a Client map is divided in chunks (or areas), each chunk represents a portion of the map. 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 Options Name Description Possible values MapType Described the type of the map Either "Indoor" or "Outdoor" (with the commas) ParentMapName The map where this map is contained, this is used for boss rooms and guild village zones per each reign. A string (with or without comma) 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 Options Name Description Possible values CellScale ? Signed number (Always 200?) HeightScale ? Floated number (Always 0.500000?) ViewRadius ? Signed number (Always 128?) MapSize Width and Height of the map Two signed numbers BasePosition Base X and Y of the map (Although it is present in the Client but it is only used in the Server) Two signed numbers TextureSet The TextureSet file name A string Environment The name of the Environment file A string 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. Known collsion bits Number Description Bit 1 An entity can walk into that coordinate Bit 2 The coordinate is filled with water Bit 3 PVP is disabled in that coordinate Bit 8 A guild building can be built in that coordinate 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 Options Name Description Possible values AreaName ? A string with comma NumWater Number of water maps contained? A signed number 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. Options Name Description Possible values ObjectCount Number of objects contained in the map A signed number 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. Object vector Number Description Possible values 1 X position Float number 2 Y position Float number 3 Z position Float number 4 CRC32 of the file name (.prt) Signed integer 5 Rotation if the rotation value contains # then 3 float numbers are used to represent the yaw, pitch and roll (Yaw#Pitch#Roll), otherwise, only one float number is used to represent the roll 6 A number that will be added to the object height Signed integer (can start with - to indicate a subtraction) 7 to 15 The name of the portal point One or more name that represents the id of the portal (if the object is a portal), the ID of the portal starts from 0 to 7 (max numbers of portals is 8). 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. Options Name Description Possible values ObjectCount Number of objects in this map Signed number 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. Object vector Number Description Possible values 1 X position Float number 2 Y position Float number 3 Z position Float number 4 CRC32 of the file name (.prt) Signed integer 5 ? Signed integer 6 ? Float number 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.

The ScriptFile is a special type of text file used to declare several information, you can think of this format as the JSON of Metin2. The format is a simple Dictionary with the ability to contain Group and Lists. Each key and value is divided by a TAB (/t), do note that the "4 spaces" does not work in replacement of a tab. Comments are done with either * or // Example: ScriptType Test Usage: Key(TAB)Value1(TAB or SPACE)Value2(TAB or SPACE) Commas commas are used to let the client parse multiple values into one. Example: TestKey(TAB)TestNode TestNode2 In this case TestNode and TestNode2 would be readed as two different values. TestKey(TAB)"TestNode TestNode2" In this case TestNode and TestNode2 would be part of the same value. Groups Usage: Group (name) {} The groups are containers of keyvalue and are divided by the {} the key group MUST EXIST or the group is not considered valid Example: Group Foo { Test "1" Group2 33 } List Usage: List (name) {} Example: List Foo { 32, 55, 49, "bar" } Used in This specification is use for the following formats: .msm (Metin2 Script Mesh) .txt (various text files, see below) .mss (Metin2 Script Sound) .prt (Object Property) .mse (Metin2 Script Effect) .msf (Metin2 Script ?) .msa (Metin2 Script animation) .sub (Subimage) .msenv (Metin2 Script Environment) Text files (root/locale) atlasinfo.txt npclist.txt item_list.txt item_scale.txt loading_tip_list.txt grkblk.txt monster_card.txt monster_card_achiev.txt partymatch_info.txt race_height.txt skilltable.txt user_situation.txt locale/map/point txt files locale/shungmahee tower guildbuildinglist.txt itemdesc.txt locale_string.txt locale_quest.txt locale_quiz.txt locale_interface.txt locale_game.txt loading_tip_vnum.txt pet_skill.txt shop_deco.txt skilldesc.txt web_linked_banner.txt Maps AreaData.txt AreaProperty.txt AreaAmbienceData.txt Settings.txt MapProperty.txt

The Metin2 Subimage file (.sub) is a special type of Script file that is used to tell the client a rectangle that would be used as a rapresentation of the image. 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. Options Name Description Possible values title subImage Must be subImage version The version changes the image path that is loaded Either "1.0" or "2.0", see below for additional information image The name of the base texture String (includes the commads) left The X position where the image section should start Integer top The Y position where the image section should start Integer right The X position where the image section should end (must be the left+the width of the section) Integer bottom The Y position where the image section should end (must be the top+the height of the section) Integer 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"

The Item Proto is a crypted file that contains all informations about the items included in the game. This file is both present in the client and the server. 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 Id Number of the item (ie. Sword+0 = 10) Range The range is used to associate a certain item id range to one item in the item proto table. Index name Internally used in the game (such as in parsing server side tables) Translated name Actual name displayed in the client or in quests Type Type of the item, see List of known Item types Subtype Extra information which tells the item what it is based from the item type, see List of known Item types Weight Unused? Size How many cells does the item take Antiflags Bitflag that defines what you can't do without the item, see List of known Item flags Flags Bitflag that defines extra informations in what the item can be used for, see List of known Item flags Wearflags Bitflag that defines where you can equip the item, see List of known Item flags Immuneflag Unused? buyprice Price that you can buy the item sellprice Price that you can sell the item limits Limits certain usage of the item (Time expire for example) applies Standard bonuses that the item have values The usage of values vary from the type of item sockets The usage of sockets vary from the type of item refineditemid ID of the item that will evolve once it's refined (example: from Sword+0 to Sword+1, refineditemid will be 11) refineset Unused? altermagicvalues Unused? specular Sets the intensity of how the item will shine (The effect that +9 weapons have) altersocketpercentage Unused?

The hybrid cryptation is a new type of cryptation introduced somewhere around 40k files. What makes this cryptation secure from everyother ones are two key factors: 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: Calculate an hash of the extension (the extension is written in lowercase and does not contain the . before the extension). 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: Calculate a CRC32 of the filename (the filename will contain the extension and it's all written in lower case). Select the algorithm to use for cryptation. Get the extension key for the file. 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: Choose a part at the end of the file to remove (From 64 to 128 bytes) Crypt the file without the remaining 64/128 bytes with an usual HybridCrypt 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.

The EterPack is a proprietary Virtual File System used for containing all the Client assets (such as 3d meshes, sfx, textures). 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. Known EterPack types Type number Description Type 0 The file is RAW, no compression or cryptation. Type 1 The file is compressed with LZO but it does not use XTEA. Type 2 The file is compressed with LZO, then it's crypted with XTEA using the EterPack Content keys. (In other words, a MCOZ CryptedObject) Type 3 The file is crypted with Panama Type 4 HybridCrypt Type 5 HybridCrypt with extra data Type 6 The file is compressed with Snappy, then it's crypted with XTEA using the EterPack Content keys. (In other words, a MCSP CryptedObject)

The texture caching was an old method used by the old Metin2 autopatcher to reduce download time of big texture files. The autopatcher will download RDCH files, once this files have been downloaded, the patcher will read this files and generate a new EterPack called that ends with _texcache, meaning that this texture cache has been generated by the patcher. 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.

A Crypted Object is a Metin2 internal file format used to crypt and compress raw file informations. It is currently used used for the following files: Item Proto, Mob Proto, EterPack Index and EterPack Content with type 2 and 6. A kaitai structure file for reading this formats is available here : 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. Known compression algorithm FourCC Code Algorithm MCOZ LZO 1x MCSP Snappy 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: Known XTEA keys Used in Key (16 bytes) Item Proto A1 A4 02 00 AA 15 54 04 E7 8B 5A 18 AB D6 AA 01 Mob Proto 46 74 49 00 0B 4A 00 00 B7 6E 08 00 9D 18 68 00 EterPack Index B9 9E B0 02 6F 69 81 05 63 98 9B 28 79 18 1A 00 EterPack Content 22 B8 B4 04 64 B2 6E 1F AE EA 18 00 A6 F6 FB 1C