Computer Solutions Blog » firmware

Dell Mini 3i (possibly also Dell Aero too) Firmware Exploration

Lawrence Sheed — Wed, 25 Aug 2010 18:20:34 +0000

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 Flasher File.
Here’s my initial work on the file system of MFF format, based on DELL_Mini3i_OMS1.5.mff

Initial 80 bytes [0x0 - 0x080] (MFF HEADER)

0×00 – 0×03 : 3 Bytes Header MFF
0×03 – 0×07 : Still to figure out, probably file length or crc.
Have to grab another firmware file to check though..

0×08 : Number of files? 9 listed, so quite probably…
Rest of header padded out with zero’s to end of 80 bytes.

[0x80 - 0x180] File Allocation Table
0×80 – our first file. Looks like 0×100 / 256 bytes per file listed, padded with 0×0′s

File listing looks like this:

File header (for each file)
8 bytes, then filename, padded with 0′s to fill 256 bytes length

First 4 bytes – offset in MFF of start of file.
Second 4 bytes – length of file.

Remaining files repeat from next 256 byte intervals.

eg
0×180 – 0×280
0×280 – 0×380
…

[0x80 + 9 files x 0x100 bytes = 0x980] Start of Data.

How did I work this out?

HEADER | Filename (not in hex below as easier to read)
80 09 00 00 34 BB 00 00 | Tavor Flasher_Samsung_ONENAND_h.bin

0×0980 is the start of our first file data, so the first 2 bytes are definitely File Start.
0xBB34 looks quite possibly like File Length.

We can check this easily with one of the plain text files.

Flash_Protection_table.ini is prefixed with 63 EA AD 09 4B 00 00 00

So it should start at 0×09 AD – hmm, readable text starts at offset 9AD D564.
Not quite right. Start offset looks close though.

Lets look at another one.

Tavor_saar_onenand.ini – prefix says
64 d5 ad 09 6f 01 00 00

Ah, 0×9 AD D5 64 is actually our Tavor_saar_onenand.ini content. Cool, a match. So, the first 4 bytes are definitely our location pointer.

Lets look at the Flash protection table again Flash_Protection_table.ini

63 EA AD 09 | 4B 00 00 00
Should start at 09 AD EA 63, and go for 4B length. Bingo, it does

Our file contents for that area are:

[PROTECTED_REGION_0]
Block_Offset=0×100000
Length=0×20000
Mode=SKIP_BLOCKS

So, now we can start to split the files apart into their associated parts.

factory_BENZ2GWIFI.fbf is probably going to be the most interesting, as its the largest.

That starts at 0xC564, length of 0x09AD1000 and starts with “Marvell_FBF”
Basic math says that 0x9ADD564 (0x09AD1000 + 0xC564) should be our end of file.
Well, it is, as we know flash protection table.ini starts at 9add564.

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.
Some of the files inside are also “packed”, but those appear to be fairly easy to rip apart also

I’m guessing with a bit more work I’ll be able to replace parts of the firmware with different versions quite soonish.

The file I’m using off of namipan has the following files inside:

TavorFlasher_SAMSUNG_ONENAND_h.bin
TavorFlasher_SAMSUNG_ONENAND_TIM.bin
factory_BENZ2GWIFI.fbf
Tavor_SAAR_OneNAND.ini
factory_BENZ2GWIFI.mff.mlt
magic_fbf.ini
magic_fbf_inner.ini
NTIM_fbw.ini
Flash_Protection_Table.ini

I’m guessing that our fbf file will probably be able to be split into parts as per our ntim_fbw.ini data.
FBF = Flash Binary Format?

some interesting files listed
ntim.bin – non trusted image module?
blob_full.bin – from the borq’s blob gz?
Tavor_M05_Poleg_AI_B0_Flash.bin – tavor = our product chip, as we’re running on a Marvel PXA935 (aka Tavor-P65)

Interesting thing of note – our OEM UniqueID: 0xF00F00 in Unicode is what glyph?
Hint – its not an orange, or a pear

NTIM_fbw.ini

Version: 0×030102
Trusted: 0

Issue Date: 0×08142006
OEM UniqueID: 0xf00f00
Boot Flash Signature: 0x4e414e02
Number of Images: 10
Size of Reserved in bytes: 0×40

Image ID: 0x54494D48
Next Image ID: 0x4F424D49
Flash Entry Address: 0×0
Load Address: 0x5c008000
Image Size To CRC in bytes: 0×0
Image Filename: NTIM.bin

Image ID: 0x4F424D49
Next Image ID: 0x4F534C4F
Flash Entry Address: 0×20000
Load Address: 0x5c013000
Image Size To CRC in bytes: 0×0
Image Filename: obm_full.bin

Image ID: 0x4F534C4F
Next Image ID: 0x5349474E
Flash Entry Address: 0×80000
Load Address: 0×83000000
Image Size To CRC in bytes: 0×0
Image Filename: blob_full.bin

Image ID: 0x5349474E
Next Image ID: 0x494D4549
Flash Entry Address: 0×00120000
Load Address: 0×84000000
Image Size To CRC in bytes: 0×0
Image Filename: signature_full.bin

Image ID: 0x494D4549
Next Image ID: 0x4152424C
Flash Entry Address: 0×00100000
Load Address: 0xBFEE0000
Image Size To CRC in bytes: 0×0
Image Filename: reliable_full.bin

Image ID: 0x4152424C
Next Image ID: 0×47524249
Flash Entry Address: 0×00140000
Load Address: 0xBF600000
Image Size To CRC in bytes: 0×0
Image Filename: arbel_full.bin

Image ID: 0×47524249
Next Image ID: 0x62746C67
Flash Entry Address: 0×00840000
Load Address: 0xBFF00000
Image Size To CRC in bytes: 0×0
Image Filename: tavor_full.bin

Image ID: 0x62746C67
Next Image ID: 0x70636C67
Flash Entry Address: 0x00A00000
Load Address: 0xBF300000
Image Size To CRC in bytes: 0×0
Image Filename: bootlogo_full.bin

Image ID: 0x70636C67
Next Image ID: 0x464F5441
Flash Entry Address: 0x00A20000
Load Address: 0x8F300000
Image Size To CRC in bytes: 0×0
Image Filename: prechangelogo_full.bin

Image ID: 0x464F5441
Next Image ID: 0xFFFFFFFF
Flash Entry Address: 0x0EA40000
Load Address: 0×80100000
Image Size To CRC in bytes: 0×0
Image Filename: fota_full.bin

Reserved Data:
0x4F505448
0×00000002
0×55415254
0×00000010
0×00004646
0×00000001
0x50524F49
0×00000020
0×00000002
0×00000000
0×00000000
0×00000000
0×00000001
0×00000000
0x5465726D
0×00000008

Flash_Protection_Table.ini

[PROTECTED_REGION_0]
Block_Offset=0×100000
Length=0×20000
Mode=SKIP_BLOCKS

magic_fbf_inner.ini

[INTEL_FLASH_DEVICE_INPUT_FILE]
Number_of_Images=20

[IMAGE_HEADER_0]
Start_Address=0xfa00000
Image_Length=0×80000
EraseBlocks=1
WriteImage=0
VerifyWrite=0

[IMAGE_HEADER_1]
Start_Address=0xdd40000
Image_Length=0×800000
EraseBlocks=1
WriteImage=0
VerifyWrite=0

[IMAGE_HEADER_2]
Start_Address=0xeb40000
Image_Length=0x8c0000
EraseBlocks=1
WriteImage=0
VerifyWrite=0

[IMAGE_HEADER_3]
Filename=NTIM.bin
Start_Address=0×00000000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_4]
Filename=Arbel_NVM_SAC_NOCOMMRTC.bin
Start_Address=0×00140000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_5]
Filename=blob
Start_Address=0×00080000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_6]
Start_Address=0x0bd40000
Image_Length=0×02000000
EraseBlocks=1
WriteImage=0
VerifyWrite=0
[IMAGE_HEADER_7]
Filename=opl.img.yaffs
Start_Address=0x0bd40000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_8]
Filename=ramdisk_len.img
Start_Address=0x00c40000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_9]
Filename=ramdisk-recovery_len.img
Start_Address=0x00cc0000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_10]
Start_Address=0x00d40000
Image_Length=0×08000000
EraseBlocks=1
WriteImage=0
VerifyWrite=0
[IMAGE_HEADER_11]
Filename=system.img.yaffs
Start_Address=0x00d40000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_12]
Filename=TAVOR_LINUX_NTOBM.bin
Start_Address=0×00020000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_13]
Filename=Tavor_M05_Poleg_AI_B0_Flash.bin
Start_Address=0×00840000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_14]
Start_Address=0x08d40000
Image_Length=0×03000000
EraseBlocks=1
WriteImage=0
VerifyWrite=0
[IMAGE_HEADER_15]
Filename=userdata.img.yaffs
Start_Address=0x08d40000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_16]
Filename=zImage
Start_Address=0x00a40000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_17]
Filename=prdcfg.bin
Start_Address=0×00940000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_18]
Filename=precharge_logo.out
Start_Address=0x00a20000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

[IMAGE_HEADER_19]
Filename=logo_pic.gz.out
Start_Address=0x00a00000
EraseBlocks=1
WriteImage=1
VerifyWrite=0

Lastly, hi to the people at http://www.allphone.com.cn

IP Cam Hacking – pt#4

Lawrence Sheed — Thu, 29 Apr 2010 19:57:14 +0000

Spent a while checking out the different binaries available for the different OEM versions.
Some interesting things I’ve found.

If I take a look at a sample kernel – eg
lr_cmos_11_14_1_46.bin

ls -al lr_cmos_11_14_1_46.bin -rw-r--r-- 1 lawrence staff 1350539 Mar 15 13:47 lr_cmos_11_14_1_46.bin

Our file size for the file i have is 1350539 bytes.

A hexdump of the header shows:

PK is the standard file header for Zip compression (as Zip was invented by Phil Katz)
Zip fingerprint in hex is – 0x04034b50, which matches nicely in our second line – 50 4b 03 04

On the offchance it contained a zip file, I tried unzipping from the start of the PK.

We can totally misuse dd to write from an offset of 20 bytes to a test.zip file as follows:

lawrence$ dd if=lr_cmos_11_14_1_46.bin of=test.zip skip=0x14 bs=1


(check I actually did that right)

lawrence$ hexdump -C test.zip  |more

00000000  50 4b 03 04 14 00 00 00  08 00 3a 2e 87 3b 3b e7  |PK........:..;;.|

00000010  b8 16 03 cb 0b 00 bc d9  18 00 09 00 00 00 6c 69  |..............li|

Unfortunately this didn’t unzip.

However…

zipinfo test.zip Archive: test.zip 1350519 bytes 1 file -rw------- 2.0 fat 1628604 b- defN 7-Dec-09 05:49 linux.bin 1 file, 1628604 bytes uncompressed, 772867 bytes compressed: 52.5%

Says there is a valid zip file there, so we’re getting somewhere. It should be something like 772867 bytes + whatever Zip header / footer file bits in size.

If we take a look at the Zip file format, it says that the end of directory (aka end of zip file) marker is 0x06054b50

ZIP end of central directory record

Offset Bytes Description[4] 0 4 End of central directory signature = 0x06054b50 4 2 Number of this disk 6 2 Disk where central directory starts 8 2 Number of central directory records on this disk 10 2 Total number of central directory records 12 4 Size of central directory (bytes) 16 4 Offset of start of central directory, relative to start of archive 20 2 ZIP file comment length (n) 22 n ZIP file comment

If we search the file for that, we get:
000bcb70 78 2e 62 69 6e 50 4b 05 06 00 00 00 00 01 00 01 |x.binPK………|

So, from our Start PK 03 04 through to PK 05 06 we’re at position 0×14 through 0x0bcb79

If we write that out now –
dd if=lr_cmos_11_14_1_46.bin of=test.zip skip=0×14 bs=1 count=0x0bcb79

Then try unzip test.zip – we have a winner!

lawrence$ unzip test.zip Archive: test.zip inflating: linux.bin lawrence$ ls -al test.zip -rw-r--r-- 1 lawrence staff 772985 Apr 30 03:28 test.zip lawrence$ ls -al linux.bin -rw-------@ 1 lawrence staff 1628604 Dec 7 05:49 linux.bin

So, we know that the file has a header, then a zip file (which uncompresses to linux.bin, and has our linux binary), then more data.

If we take a look at what follows – ie the rest of the data in the original file after the end of the zip, it doesn’t look compressed

…

000bd969 50 7d 64 68 63 70 63 00 00 00 00 00 00 00 00 00 |P}dhcpc………|
000bd979 00 00 62 46 4c 54 00 00 00 04 00 00 00 40 00 01 |..bFLT…….@..|
000bd989 11 70 00 01 37 60 00 01 50 e8 00 00 28 00 00 01 |.p..7`..P…(…|
000bd999 37 60 00 00 02 b5 00 00 00 05 00 00 00 00 00 00 |7`…………..|
000bd9a9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
000bd9b9 00 00 1f 8b 08 00 f4 6b 45 3f 02 03 dc 5b 0f 70 |…….kE?…[.p|
000bd9c9 14 d7 79 7f bb 77 a7 bf 07 9c fe f0 c7 48 a0 95 |..y..w.......H..|
000bd9d9 50 88 5c 23 b3 02 19 64 23 e0 84 30 76 72 b8 9c |P.\#...d#..0vr..|
000bd9e9 31 50 6c 2b 58 06 d7 25 84 d6 ea 80 6d 02 8c 7d |1Pl+X..%....m..}|
000bd9f9 48 02 64 17 b0 00 91 12 17 fb b6 29 ed 60 86 c6 |H.d........).`..|
000bda09 4c aa 74 34 0e 71 0e 90 03 d3 d2 54 fc 51 87 30 |L.t4.q.....T.Q.0|

In fact it looks like more files...

bFLT is our flat ELF header..., and the other bits in-between look suspiciously like more files, and folders.
So, we probably have a filesystem in there.

Its late, and thats all for today, but it looks like we might even get to play around with both the linux image and the web UI image.

Just had another thought though - if you recall, our romfs size was 0x0008D000

Image: 6 name:romfs.img base:0x7F0E0000 size:0x0008D000 exec:0x7F0E0000 -a

What do we see here - in our header? 00000010 00 d0 08 00

00000000 42 4e 45 47 01 00 00 00 01 00 00 00 77 cb 0b 00 |BNEG……..w…| 00000010 00 d0 08 00 50 4b 03 04 14 00 00 00 08 00 3a 2e |….PK……..:.|

Seem to have a match, no? 0x 08 d0 00
I'm going to bet that our 0x 00 0b cb 77 also has some meaning too in our header 20 bytes, especially as the linux.bin zip file size is close to that at 0x00 0b cb 79.

Its highly probable I've miscounted something with the offset, and thats going to turn out to be the zip file size.

Now I've gotten this far, I'm too excited to go to sleep (its 4am here now!)

Lets try the filesystem from where we left off (aka from 0x0bcb79)
dd if=lr_cmos_11_14_1_46.bin of=unsure_what_filesystem.img skip=0x0bcb79 bs=1

mount -r unsure_what_filesystem.img
mount: unsure_what_filesystem.img: unknown special file or file system.

Nope.

Kyle's blog comment has this gem in

however the ‘-romfs-’ tag is offset by 0×14

so I used the line

fx 6 romfs.img 0x7f0a0000 0x7f0a0014 -a

the system then rebooted correctly…”

Lets use that as the start.

-rom1fs- starts at position 0x12 [which is another indicator that I'm off by 2 bytes somewhere - as they mention 0x14 bytes, and the 12bytes prefix I have prior to the -rom1fs- are going to be from our second file header, I'll bet...
0x0bcb79 - 2 = 0x0bcb77, which is what the previous header said, so that really makes me think thats the filesize now!

Our ROMFS works out to be 577 536 bytes, which is 0x8D000, which is also what the boot loader said, so getting a lot of good confirmation on these figures!]

Write that out to another file:
dd if=unsure_what_filesystem.img of=still_unsure.img skip=0×12 bs=1

Still doesn’t mount on my Mac, however, some more googling for rom1fs uclinux got me here

http://romfs.sourceforge.net/

Which specifically mentions –

Embedded projects using romfs

uClinux, the microcontroller Linux, is a port of the kernel, and selected user-space programs to capable, embedded processors, like some “smaller” Motorola m68k, and ARM systems.

ROMFS looks like:

offset content
+—+—+—+—+
0 | – | r | o | m | \
+—+—+—+—+ The ASCII representation of those bytes
4 | 1 | f | s | – | / (i.e. “-rom1fs-”)
+—+—+—+—+
8 | full size | The number of accessible bytes in this fs.
+—+—+—+—+
12 | checksum | The checksum of the FIRST 512 BYTES.
+—+—+—+—+
16 | volume name | The zero terminated name of the volume,
: : padded to 16 byte boundary.
+—+—+—+—+
xx | file |
: headers :

struct romfs_super_block
{

__u32 word0;

__u32 word1;

__u32 size;

__u32 checksum;

char name[0]; /* volume name */

};

Which looks to be a *very* good match for what that header has!
So, its in ROMFS format from the -rom1fs- start header.

(Mostly from here – http://zhwen.org/?p=articles/romfs)

Unfortunately my OSX box appears to be missing romfs support, so I can’t check it without going back to the office.

mount -o loop -t romfs still_unsure.img /mnt
mount: exec /System/Library/Filesystems/romfs.fs/Contents/Resources/mount_romfs for /mnt: No such file or directory

Booted up my Debian VM, and tried again.
debian:/mnt/hgfs/FI8908，FI8908W# mount -o loop -t romfs still_unsure.img /mnt/test -r debian:/mnt/hgfs/FI8908，FI8908W# cd /mnt/test/ debian:/mnt/test# ls -al total 4 drwxr-xr-x 1 root root 32 1969-12-31 18:00 . drwxr-xr-x 4 root root 4096 2010-04-29 16:19 .. drwxr-xr-x 1 root root 32 1969-12-31 18:00 bin drwxr-xr-x 1 root root 32 1969-12-31 18:00 dev drwxr-xr-x 1 root root 32 1969-12-31 18:00 etc drwxr-xr-x 1 root root 32 1969-12-31 18:00 flash drwxr-xr-x 1 root root 32 1969-12-31 18:00 home drwxr-xr-x 1 root root 32 1969-12-31 18:00 proc drwxr-xr-x 1 root root 32 1969-12-31 18:00 swap drwxr-xr-x 1 root root 32 1969-12-31 18:00 usr

We have a winner!

Full file listing below:

. |-- bin | |-- camera | |-- dhcpc | |-- ifconfig | |-- init | |-- iwconfig | |-- iwpriv | |-- mypppd | | |-- chap-secrets | | |-- options | | |-- pap-secrets | | `-- pppd | |-- route | |-- rt73.bin | |-- sh | |-- wetctl | `-- wpa_supplicant |-- dev | |-- console | |-- display | |-- dsp -> dsp1 | |-- dsp0 | |-- dsp1 | |-- fb0 | |-- hda | |-- hda1 | |-- hda2 | |-- hdb | |-- i2c0 | |-- i2c1 | |-- key | |-- keypad | |-- lp0 | |-- mixer -> mixer1 | |-- mixer0 | |-- mixer1 | |-- mouse | |-- mtd0 | |-- mtd1 | |-- mtdblock0 | |-- mtdblock1 | |-- nftlA1 | |-- nftla | |-- null | |-- ppp | |-- ppp1 | |-- ptmx | |-- pts | |-- ptyp0 | |-- ptyp1 | |-- ptyp2 | |-- ptyp3 | |-- ptyp4 | |-- ptyp5 | |-- ptyp6 | |-- ptyp7 | |-- ptyp8 | |-- ptyp9 | |-- ptz0 | |-- rom0 | |-- rom1 | |-- rom2 | |-- sda | |-- sda1 | |-- sda2 | |-- sdb | |-- sdb1 | |-- sdb2 | |-- smartcard0 | |-- smartcard1 | |-- tty | |-- tty1 | |-- ttyS0 | |-- ttyS1 | |-- ttyS2 | |-- ttyS3 | |-- ttyp0 | |-- ttyp1 | |-- ttyp2 | |-- ttyp3 | |-- ttyp4 | |-- ttyp5 | |-- ttyp6 | |-- ttyp7 | |-- ttyp8 | |-- ttyp9 | |-- urandom | |-- usb | | |-- lp.sh | | |-- lp0 | | |-- lp1 | | |-- lp2 | | |-- lp3 | | |-- lp4 | | |-- lp5 | | |-- lp6 | | |-- lp7 | | |-- lp8 | | `-- lp9 | |-- usi | |-- video0 | `-- video1 |-- etc |-- flash |-- home |-- proc |-- swap |-- usr `-- var `-- run

13 directories, 97 files

While I obviously can’t run any binaries locally, I can look at the text files to confirm that the ROMFS hasn’t just gotten the filesystem correct.

debian:/mnt/test/bin# cat init mount -t proc none /proc mount -t ramfs none /usr mount -t ramfs none /swap mount -t ramfs none /var/run mount -t ramfs none /etc mount -t ramfs none /flash mount -t ramfs none /home camera& sh

debian:/mnt/test/bin# file camera camera: BFLT executable - version 4 ram gzip

Looking *very* good.

Thats all for tonight, but it looks like we can easily add bits to the firmware using genromfs, dd, and a hex editor, or just genromfs, and someone willing to test a rebuilt user rom with an extra binary. Probably going to be telnetd as ssh requires a kernel recompile

Next step, actually doing that, and testing.

I’m definitely going to bed now – its 5:30am.

Tomorrow is a holiday though (in China), so happy May holidays!

Dell Mini 3i / OPhone Hacking thoughts / notes

Lawrence Sheed — Mon, 08 Mar 2010 20:48:16 +0000

Currently I have an iPhone (ancient 2G), and have just bought a Dell Mini3i (600RMB with an 18month contract @ China Telecom), as I donated my 3G iPhone to one of the extended family back home.

The Mini3i runs an Android variant called OPhone.

The 3i is a little underwhelming software wise.

Its quite crap at the moment as its sitting on Android 1.0 (OPhone 1.0), but for all intents and purposes Android = Ophone its pretty much the same underneath.

There are a bunch of similar phones to this – the Lenovo O1, LG GW880, Motorola something or other (can’t be hassled to go look) etc.

While I haven’t rooted mine just yet, I have been playing around, and reading the Chinese forums.

Boot loader appears to be similar on all the devices – its made by BORQ’s in Beijing, and appears to be quite basic.

Motorola and O1 seem to have the best support for now, the main problem in the Chinese forums is people bitching about being stuck on older versions.

Some are running 1.6, most on 1.5, and the unlucky few 1.0 “Ophone”
2.0 and 2.1 has yet to hit the mainstream here.

There are people with N1/G5′s (Nexus 1 / HTC G5) on 2.1 though (yes, thats you in Beijing Tom!), pretty much any phone is available, although anything with wifi is essentially grey import from overseas (HK mostly)

Back to the phone -

Thankfully you can install any apps as apk’s, no need to hack for that – so its fairly easy to get info on the innards.

RootExplorer is your friend

RootExplorer also allows you to remount partitions r/w, so root access is fairly easy too. There are precompiled su binaries for 1.5 out there, although I’ve yet to do my phone.

The Dell mini3 is running on a Marvell Tabor. Fast chip, nice touchscreen, decent resolution, just crap on 1.0.

Firmware files for most of the “ophones” (except motorola) are mff files.

The mff files appear to just be compressed images with instructions for how to write the various partitions out.

eg the Lenovo O1 mff has this in the “mff” zip

2010/02/25 10:53 147,111,936 factory_CHERRY.fbf
2010/02/25 10:53 249 factory_CHERRY.mff.mlt
2010/02/25 10:53 364 JADE_EVB_RawNANDx16.ini
2010/02/25 10:53 327 magic_fbf.ini
2010/02/25 10:53 2,692 magic_fbf_inner.ini
2010/02/25 10:53 10,236,719 mfw.pac
2010/02/25 10:53 54,180 MHLV_NTDKB_h.bin
2010/02/25 10:53 176 MHLV_NTDKB_TIM.bin
2010/02/25 10:53 858 NTIM_td.ini

magic_fbf_inner.ini has the layout

[INTEL_FLASH_DEVICE_INPUT_FILE]
Number_of_Images=24

[IMAGE_HEADER_0]
Start_Address=0×240000
Image_Length=0×40000
EraseBlocks=1
WriteImage=0
VerifyWrite=0

[IMAGE_HEADER_1]
Start_Address=0×6900000
Image_Length=0xf00000
EraseBlocks=1
WriteImage=0
VerifyWrite=0

(etc)

Different phones have different firmware writing software, the Motorola’s are using RSDLite, LG – SML_OMS, CTHall, others something homegrown called Firebolt, which is written by BORQS. I have all the firmware tools already, despite the Ophone8 forums lack of courtesy in sharing, grrr.

Most firmware tools appear similar though functionality wise.
Haven’t played around inside the phone yet to see if its easy to get jtag access, although that was mostly because i couldn’t work out how to remove the top part without breaking it.

If anyone wants more info, or a firmware dump let me know.

Hopefully there is some interest out there in the English speaking world for these!