--------------- Created by sc0ty - sc0typl[at]gmail.com - http://sc0ty.pl ---------------

BlackBerry SFI/MFI software file structure description
	released:	09/13/2010

Structures description:
	Values in every structure are in little endian byte order. In structures below - first
	column is offset, second - size and third - description. Offset and size are given in
	bytes.

File format description:
	The file consist of 8 byte header followed by certain number of sections. Sections are
	located one after another. The last section is checksum section.

Header structure:
	00	4	file signature (hex: 7D 79 AB 59)
	04	4	version (see below - version field format description)

Sections description:
	Every section consist of 12-bytes header followed by data. Sections are identified by
	its unique id.

Section header structure:
	00	4	section id (see below for id list)
	04	4	section data size + 0x10 (data size is really 0x10 smaller than this field)
	08	4	version (see below - version field format description)

Version field format description:
	Version field is given as 4 byte number. Version format is 4-element dot-separated
	number (a.b.c.d) which every element correspond to one byte in the version field.
	The first element (marked as a) correspond to the last byte.
	E.g. version field hex: 0a 05 00 01 is version number 1.0.5.10.

Section id list:
	0x02	OS Firmware (contain JVM code)
	0x0E	DSPOS Firmware
	0x05	MFI file info (is presented only in MFI files)
	0x06	Checksum

Section 0x06 - Checksum section description:
	Always is the last section. Version number is always 0.0.0.0, data size is always four
	bytes (data size field in section header is 0x14). Data contains checksum of entire
	file except this section. Its negated CRC-32 checksum.

Sign description:
	Sections like OS and DSPOS firmware can be digitally signed. If it is signed, the last
	184 bytes contains sign structure. If structure is not signed, sign signature, id and
	data consist of 0xff bytes (sign size field is still 0x80).
	Sign data is probably RSA-SHA1 signature. Public key which is used to werify data
	integrity is:
	8F 7E DA AB 63 CE DB A7 1E 46 BE 4F 69 EA C9 64 DE E8 71 BF EC 46 17 D0 74 3D 62 63
	7E C5 A7 B8 C3 4F FF 14 55 7E B6 FA 21 9A 21 59 0D FB 61 AC 47 33 73 1A D0 47 9E BB
	89 9A 9D 4F 18 67 A8 E9 B4 68 42 7A 73 87 A9 45 98 02 02 71 F6 D7 59 A9 0C 43 BC 52
	B6 A5 48 4B BB 31 13 4E F0 5C 82 87 EA 1F D1 29 0E 0D 01 65 A9 4E 45 E0 E2 96 68 3A
	54 04 AE 77 73 57 72 6B 7A 35 B5 47 C5 0C A5 A7

Sign structure:
	00	20	sign signature (null terminated string: "RIMOSSA1" followed by 0x20 bytes)
	20	 4	signer id (always 0x31)
	24	 4	sign size (always 0x80)
	28	80	sign data
	a8	 4	dunno (always 0xB4)
	ac	 4	dunno (always 0x10000)
	b0	 4	dunno (always hex: 1F 2D C8 D7)
	b4	 4	dunno, variable values, maybe some kind of crc?

If you have any information about how this sign work - please contact me.

--------------- Created by sc0ty - sc0typl[at]gmail.com - http://sc0ty.pl ---------------