{"id":593,"date":"2010-08-26T02:20:34","date_gmt":"2010-08-25T18:20:34","guid":{"rendered":"http:\/\/www.computersolutions.cn\/blog\/?p=593"},"modified":"2010-08-26T03:07:49","modified_gmt":"2010-08-25T19:07:49","slug":"dell-mini-3i-firmware-exploration","status":"publish","type":"post","link":"https:\/\/www.computersolutions.cn\/blog\/2010\/08\/dell-mini-3i-firmware-exploration\/","title":{"rendered":"Dell Mini 3i (possibly also Dell Aero too) Firmware Exploration"},"content":{"rendered":"

As I’ve been reasonably successful in the past at figuring out file systems from flat files, I thought I’d have a go at the Dell Mini 3i 1.5 Firmware that surfaced at damipan (http:\/\/www.namipan.com\/d\/DELL_MINI3I_OMS1.5.rar\/a5ba3b06ab0bfc9baeb2f09b44f54aa40bac3457ee8ebc04<\/a>)<\/p>\n

The rar file unzips to a MFF file.<\/p>\n

This I’m probably guessing is probably named after Marvell File Format or Marvell Flasher File.
\nHere’s my initial work on the file system of MFF format, based on DELL_Mini3i_OMS1.5.mff<\/p>\n

Initial 80 bytes [0x0 – 0x080] (MFF HEADER)<\/strong><\/p>\n

0x00 – 0x03 : 3 Bytes Header MFF
\n0x03 – 0x07 : Still to figure out, probably file length or crc.
\nHave to grab another firmware file to check though..<\/p>\n

0x08 : Number of files? 9 listed, so quite probably…
\nRest of header padded out with zero’s to end of 80 bytes.<\/p>\n

[0x80 – 0x180] File Allocation Table<\/strong>
\n0x80 – our first file. Looks like 0x100 \/ 256 bytes per file listed, padded with 0x0’s<\/p>\n

File listing looks like this:<\/p>\n

File header (for each file)
\n8 bytes, then filename, padded with 0’s to fill 256 bytes length<\/p>\n

First 4 bytes – offset in MFF of start of file.
\nSecond 4 bytes – length of file.<\/p>\n

Remaining files repeat from next 256 byte intervals.<\/p>\n

eg
\n0x180 – 0x280
\n0x280 – 0x380
\n…<\/p>\n

[0x80 + 9 files x 0x100 bytes = 0x980] Start of Data.<\/strong><\/p>\n

How did I work this out?<\/p>\n

HEADER | Filename (not in hex below as easier to read)
\n80 09 00 00 34 BB 00 00 | Tavor Flasher_Samsung_ONENAND_h.bin<\/p>\n

0x0980 is the start of our first file data, so the first 2 bytes are definitely File Start.
\n0xBB34 looks quite possibly like File Length.<\/p>\n

We can check this easily with one of the plain text files.<\/p>\n

Flash_Protection_table.ini is prefixed with 63 EA AD 09 4B 00 00 00<\/p>\n

So it should start at 0x09 AD – hmm, readable text starts at offset 9AD D564.
\nNot quite right. Start offset looks close though.<\/p>\n

Lets look at another one.<\/p>\n

Tavor_saar_onenand.ini – prefix says
\n64 d5 ad 09 6f 01 00 00<\/p>\n

Ah, 0x9 AD D5 64 is actually our Tavor_saar_onenand.ini content. Cool, a match. So, the first 4 bytes are definitely our location pointer.<\/p>\n

Lets look at the Flash protection table again Flash_Protection_table.ini<\/p>\n

63 EA AD 09 | 4B 00 00 00
\nShould start at 09 AD EA 63, and go for 4B length. Bingo, it does \ud83d\ude42<\/p>\n

Our file contents for that area are:<\/p>\n

[PROTECTED_REGION_0]
\nBlock_Offset=0x100000
\nLength=0x20000
\nMode=SKIP_BLOCKS<\/p>\n

So, now we can start to split the files apart into their associated parts.<\/p>\n

factory_BENZ2GWIFI.fbf is probably going to be the most interesting, as its the largest.<\/p>\n

That starts at 0xC564, length of 0x09AD1000 and starts with “Marvell_FBF”
\nBasic math says that 0x9ADD564 (0x09AD1000 + 0xC564) should be our end of file.
\nWell, it is, as we know flash protection table.ini starts at 9add564.<\/p>\n

So, should be fairly easy with that info to write an unpacker tool to rip out the first interior files from the MFF file format.
\nSome of the files inside are also “packed”, but those appear to be fairly easy to rip apart also \ud83d\ude42<\/p>\n

I’m guessing with a bit more work I’ll be able to replace parts of the firmware with different versions quite soonish.<\/p>\n

The file I’m using off of namipan has the following files inside:<\/p>\n

TavorFlasher_SAMSUNG_ONENAND_h.bin
\nTavorFlasher_SAMSUNG_ONENAND_TIM.bin
\nfactory_BENZ2GWIFI.fbf
\nTavor_SAAR_OneNAND.ini
\nfactory_BENZ2GWIFI.mff.mlt
\nmagic_fbf.ini
\nmagic_fbf_inner.ini
\nNTIM_fbw.ini
\nFlash_Protection_Table.ini<\/p><\/blockquote>\n

I’m guessing that our fbf file will probably be able to be split into parts as per our ntim_fbw.ini data.
\nFBF = Flash Binary Format?<\/p>\n

some interesting files listed
\nntim.bin – non trusted image module?
\nblob_full.bin – from the borq’s blob gz?
\nTavor_M05_Poleg_AI_B0_Flash.bin – tavor = our product chip, as we’re running on a Marvel PXA935 (aka Tavor-P65)<\/p>\n

Interesting thing of note – our OEM UniqueID: 0xF00F00 in Unicode is what glyph?
\nHint – its not an orange, or a pear \ud83d\ude09<\/p>\n

NTIM_fbw.ini<\/strong><\/p>\n

Version: 0x030102
\nTrusted: 0<\/p>\n

Issue Date: 0x08142006
\nOEM UniqueID: 0xf00f00
\nBoot Flash Signature: 0x4e414e02
\nNumber of Images: 10
\nSize of Reserved in bytes: 0x40<\/p>\n

Image ID: 0x54494D48
\nNext Image ID: 0x4F424D49
\nFlash Entry Address: 0x0
\nLoad Address: 0x5c008000
\nImage Size To CRC in bytes: 0x0
\nImage Filename: NTIM.bin<\/p>\n

Image ID: 0x4F424D49
\nNext Image ID: 0x4F534C4F
\nFlash Entry Address: 0x20000
\nLoad Address: 0x5c013000
\nImage Size To CRC in bytes: 0x0
\nImage Filename: obm_full.bin<\/p>\n

Image ID: 0x4F534C4F
\nNext Image ID: 0x5349474E
\nFlash Entry Address: 0x80000
\nLoad Address: 0x83000000
\nImage Size To CRC in bytes: 0x0
\nImage Filename: blob_full.bin<\/p>\n

Image ID: 0x5349474E
\nNext Image ID: 0x494D4549
\nFlash Entry Address: 0x00120000
\nLoad Address: 0x84000000
\nImage Size To CRC in bytes: 0x0
\nImage Filename: signature_full.bin<\/p>\n

Image ID: 0x494D4549
\nNext Image ID: 0x4152424C
\nFlash Entry Address: 0x00100000
\nLoad Address: 0xBFEE0000
\nImage Size To CRC in bytes: 0x0
\nImage Filename: reliable_full.bin<\/p>\n

Image ID: 0x4152424C
\nNext Image ID: 0x47524249
\nFlash Entry Address: 0x00140000
\nLoad Address: 0xBF600000
\nImage Size To CRC in bytes: 0x0
\nImage Filename: arbel_full.bin<\/p>\n

Image ID: 0x47524249
\nNext Image ID: 0x62746C67
\nFlash Entry Address: 0x00840000
\nLoad Address: 0xBFF00000
\nImage Size To CRC in bytes: 0x0
\nImage Filename: tavor_full.bin<\/p>\n

Image ID: 0x62746C67
\nNext Image ID: 0x70636C67
\nFlash Entry Address: 0x00A00000
\nLoad Address: 0xBF300000
\nImage Size To CRC in bytes: 0x0
\nImage Filename: bootlogo_full.bin<\/p>\n

Image ID: 0x70636C67
\nNext Image ID: 0x464F5441
\nFlash Entry Address: 0x00A20000
\nLoad Address: 0x8F300000
\nImage Size To CRC in bytes: 0x0
\nImage Filename: prechangelogo_full.bin<\/p>\n

Image ID: 0x464F5441
\nNext Image ID: 0xFFFFFFFF
\nFlash Entry Address: 0x0EA40000
\nLoad Address: 0x80100000
\nImage Size To CRC in bytes: 0x0
\nImage Filename: fota_full.bin<\/p>\n

Reserved Data:
\n0x4F505448
\n0x00000002
\n0x55415254
\n0x00000010
\n0x00004646
\n0x00000001
\n0x50524F49
\n0x00000020
\n0x00000002
\n0x00000000
\n0x00000000
\n0x00000000
\n0x00000001
\n0x00000000
\n0x5465726D
\n0x00000008<\/p><\/blockquote>\n

Flash_Protection_Table.ini<\/strong><\/p>\n

[PROTECTED_REGION_0]
\nBlock_Offset=0x100000
\nLength=0x20000
\nMode=SKIP_BLOCKS<\/p><\/blockquote>\n

magic_fbf_inner.ini<\/strong><\/p>\n

[INTEL_FLASH_DEVICE_INPUT_FILE]
\nNumber_of_Images=20<\/p>\n

[IMAGE_HEADER_0]
\nStart_Address=0xfa00000
\nImage_Length=0x80000
\nEraseBlocks=1
\nWriteImage=0
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_1]
\nStart_Address=0xdd40000
\nImage_Length=0x800000
\nEraseBlocks=1
\nWriteImage=0
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_2]
\nStart_Address=0xeb40000
\nImage_Length=0x8c0000
\nEraseBlocks=1
\nWriteImage=0
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_3]
\nFilename=NTIM.bin
\nStart_Address=0x00000000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_4]
\nFilename=Arbel_NVM_SAC_NOCOMMRTC.bin
\nStart_Address=0x00140000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_5]
\nFilename=blob
\nStart_Address=0x00080000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_6]
\nStart_Address=0x0bd40000
\nImage_Length=0x02000000
\nEraseBlocks=1
\nWriteImage=0
\nVerifyWrite=0
\n[IMAGE_HEADER_7]
\nFilename=opl.img.yaffs
\nStart_Address=0x0bd40000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_8]
\nFilename=ramdisk_len.img
\nStart_Address=0x00c40000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_9]
\nFilename=ramdisk-recovery_len.img
\nStart_Address=0x00cc0000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_10]
\nStart_Address=0x00d40000
\nImage_Length=0x08000000
\nEraseBlocks=1
\nWriteImage=0
\nVerifyWrite=0
\n[IMAGE_HEADER_11]
\nFilename=system.img.yaffs
\nStart_Address=0x00d40000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_12]
\nFilename=TAVOR_LINUX_NTOBM.bin
\nStart_Address=0x00020000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_13]
\nFilename=Tavor_M05_Poleg_AI_B0_Flash.bin
\nStart_Address=0x00840000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_14]
\nStart_Address=0x08d40000
\nImage_Length=0x03000000
\nEraseBlocks=1
\nWriteImage=0
\nVerifyWrite=0
\n[IMAGE_HEADER_15]
\nFilename=userdata.img.yaffs
\nStart_Address=0x08d40000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_16]
\nFilename=zImage
\nStart_Address=0x00a40000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_17]
\nFilename=prdcfg.bin
\nStart_Address=0x00940000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_18]
\nFilename=precharge_logo.out
\nStart_Address=0x00a20000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p>\n

[IMAGE_HEADER_19]
\nFilename=logo_pic.gz.out
\nStart_Address=0x00a00000
\nEraseBlocks=1
\nWriteImage=1
\nVerifyWrite=0<\/p><\/blockquote>\n

Lastly, hi to the people at http:\/\/www.allphone.com.cn \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"

As I’ve been reasonably successful in the past at figuring out file systems from flat files, I thought I’d have a go at the Dell Mini 3i 1.5 Firmware that surfaced at damipan (http:\/\/www.namipan.com\/d\/DELL_MINI3I_OMS1.5.rar\/a5ba3b06ab0bfc9baeb2f09b44f54aa40bac3457ee8ebc04) The rar file unzips to a MFF file. This I’m probably guessing is probably named after Marvell File Format or Marvell […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[282,25],"tags":[283,284,197,286,285,196,194,287,288],"class_list":["post-593","post","type-post","status-publish","format-standard","hentry","category-firmware-2","category-technical-mumbo-jumbo","tag-borqs","tag-dell","tag-firmware","tag-marvell","tag-mini-3i","tag-mini3i","tag-ophone","tag-pxa935","tag-tavor"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts\/593","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/comments?post=593"}],"version-history":[{"count":6,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts\/593\/revisions"}],"predecessor-version":[{"id":595,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts\/593\/revisions\/595"}],"wp:attachment":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/media?parent=593"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/categories?post=593"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/tags?post=593"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}