Browsing all articles tagged with firmware

Apr
30

IP Cam Hacking – pt#4

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!

April 30, 2010 // IP Cam, Technical Mumbo Jumbo // 5 Comments // Tags: bflt, bneg, firmware, foscam, ipcam, linux.bin, pkzip, uclinix

Mar
9

Dell Mini 3i / OPhone Hacking thoughts / notes

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!

March 9, 2010 // China Related, Technical Mumbo Jumbo // 5 Comments // Tags: dell mini3i, firmware, mini3i, ophone

Find out more about advertising here!