--------------- Created by sc0ty - sc0typl[at]gmail.com - http://sc0ty.pl --------------- BlackBerry COD file structure description first released: 15/10/2011 File format description: Values in every structure are in little endian byte order unless stated otherwise. Blackberry applications consist of COD files. Due to size limits of every segment (two segments, 64kB in every) in COD file, in most cases there is more than just one file. Multi-COD apps can be compressed with PKZIP and then stored as one file with COD extension. It is possible to distinguish this two COD format by PKZIP file signature (hex: 0x50 0x4B 0x03 0x04). Every multi-COD app contain one COD file with extra info (like name, description, icon etc) which I will call base COD. It is usually called like App-name.cod, and the other COD files are like App-name-1.cod, App-name-2.cod etc. The file consist of four segments: - header (0x2C bytes) - code segment (CODFILEHEADER.code_size bytes) - data segment (TCODFILEHEADER.data_size bytes) - footer (rest of the file) Header structure: typedef struct { uint32_t flashid; uint32_t section_number; //always 0 uint32_t vtable_pointer; //always 0 uint32_t timestamp; // created time uint32_t user_version; uint32_t fieldref_pointer; uint16_t maxtype_list_size; uint16_t reserved; //always 0xFF uint32_t data_section; //always 0xFFFF uint32_t module_info; //always 0xFFFF uint16_t version; uint16_t code_size; // size of the code segment uint16_t data_size; // size of the data segment uint16_t flags; // if bit 0 is clear - it is base COD file } CODFILEHEADER; Code segment: I hasn't investigated this segment yet. Data segment description: Data segment starts with header (0x34 bytes long), followed by classes and modules offsets, then resources. Data segment header: typedef struct { uint8_t flags; // if bit 0 is clear - it is base COD file uint8_t version; uint16_t num_icalls; uint8_t num_modules; uint8_t num_classes; uint16_t exported_string_offset; uint16_t data_bytes_offset; uint16_t empty_field; uint16_t class_definitions; uint8_t unknow1[14]; uint16_t aliases; uint8_t unknow2[22]; } DATASEGHEADER; Data segment layout: typedef struct { DATASEGHEADER header; uint16_t classes_offsets[ header.num_classes ]; // classes info uint16_t modules_offsets[ header.num_modules ]; // modules and libraries names uint16_t modules_versions_offsets[ header.num_modules ]; // versions of this modules uint16_t application_modules[ x ]; // application modules names DATARESOURCE resources[ y ]; // data resources } DATASEG; Each offset represent an address from the beginning of a data segment. - 'classes_offsets' are pointing to class information structures (need more research). - 'modules_offsets' - NULL terminated ASCII strings of modules essential to app, first one is always module from the base COD file. - 'modules_versions_offsets' - version strings of this modules (given in the same order as header.modules_offsets). - 'application_modules' - list of application modules, each of them is in separate COD file. Number of this modules isn't given per se, but they are located before the offset header.exported_string_offset. - resources are stored at offset header.exported_string_offset and before header.data_bytes_offset. Every offset in data segment should be not less than header.data_bytes_offset. Resource description: Every resource is identified by it's type. Types are NULL-terminated series of bytes (of variable length) located at CODRESOURCE.type_offset location in data segment. data_offset points to a resource data which size is defined (in bytes) by size field. Resources are stored usually (always?) in base COD file. Below I present resource structure, and then - resource types with description. Resource structure: typedef struct { uint16_t type_offset; uint16_t size; uint16_t data_offset; } CODRESOURCE; Resource type: 5f18704963107300 (application name): ASCII string (not NULL-terminated) preceeded by 2-byte big endian length. It could contain more than just one app name, if so - there will be another 2-byte length followed by next string. E. g. 000b476f6f676c652053796e63000b47... - x00 0x0b "Google Sync" 0x00 0x0b "G"... Resource type: 5f06736372698800 (application description): Description string(s) coded the same way as application name. E. g. 0x00 0x18 "GG client for Blackberry" Resource type: 5f76c91900 (vendor): Vendor name string(s?) coded the same way as application name. Resource type: 005f187049631073 (icon image): Icon file (usually PNG, but I saw a GIF once) preceded by two 2-bytes, big endian length field. Second one define file size in bytes, first one is file size+2 (maybe file size + size of the second length - I think it may be used to store more icons). E. g. 0x1F 0xEF 0x1F 0xED [PNG header and data] Other resource types (unknown, I seen this in some COD files): 5f0c736fae07947413731c7300: contains some strings like ".png" 0x0a ".jpg" 0x0a 5f18704172677300: strings like "autorun", "auto" preceded by 4-bytes length field 5f187046a7677300: one or two bytes, usually 0x01 or 0x00 0x03 5f1870a6a27400: one byte long small number 5f187094744963107300: dunno Footer segment: I hasn't investigated this segment yet. Links: http://drbolsen.wordpress.com/ http://docs.blackberry.com/en/developers/deliverables/7693/Elements_and_attributes_for_alx_files_513046_11.jsp Thanks to Dr. {B0lsen} --------------- Created by sc0ty - sc0typl[at]gmail.com - http://sc0ty.pl ---------------