Verifying an installed firmware

Installing and Using OpenWrt
1

I would like to verify that a device is actually running the exact firmware that it is supposed to be running. Is there any easy method for me to do that?

The reason for this is that I will be having branded routers manufactured in China with an OpenWRT firmware that I am supplying. I want to make sure not modifications have been made to the firmware in the process.

I have identical devices here flashed by myself with the same firmware that I could compare to. I can of course check the checksums of single files but I would like to be able to check the integrity of the entire firmware if possible.

2

make a dump of the devices' firmware, compare with the check sums of the ones you've flashed ?

might even be able to run a checksum on the whole partition using md5sum, or some other crc generation tool.

worked for me:

root@OpenWrt0:~# cat /proc/mtd
....
mtd11: 00400000 00010000 "os-image"
mtd12: 01900000 00010000 "rootfs"
mtd13: 01600000 00010000 "rootfs_data"
......
root@OpenWrt0:~# dd if=/dev/mtd12 bs=512 | md5sum
1d52ecbc26e79f798ea6d0517af03d12  -
51200+0 records in
51200+0 records out
3
4

Thank you, this appears to work for my u-boot and kernel mtds, but the rootfs, rootfs_data, art and firmware mtds return a different checksum every time I run the command.

These are the available mtds:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "u-boot"
mtd1: 0015082c 00010000 "kernel"
mtd2: 00e7f7d4 00010000 "rootfs"
mtd3: 00a00000 00010000 "rootfs_data"
mtd4: 00010000 00010000 "art"
mtd5: 00fd0000 00010000 "firmware"
5

I would assume they're not static (read only), like the kernel.

You want to make it fool proof, uboot a initramfs-kernel, then you can access
on the partitions without touching them.

This should be the 1st thing you do, after you get the unit(s) from factory.

Once booted the content will change.
It's enough for a time stamp to differ, on a file, for the crc to differ.

But sooner or later it'll be simpler for you to just reflash the devices.

Not sure what's in the firmware partition though.

1 Like
6

I guess if the bootloader and kernel checksums match the ones of the kernel and bootloader I supplied, I can safely assume that the device is really running my firmware, right?

7

no,

if they change something, it'll most likely be in the rootfs & rootfs_data.

2 Likes
8

Booting an initramfs kerlen requires a serial console, right? Cause that would mean having to break open the device and soldering in my case...

I tried mounting the rootfs and rootfs_data partitions read-only. That worked, so I now get consistent checksums every time I run the md5sum command. Unfortunately, the md5 sums are not consistent between two devices running the same firmware or the same device flashed again with the same firmware. I guess that makes sense since the partitions will have already been altered by the time I can mount them read-only...

9

The best way to deal with the possibilty someone tampered with rootfs_data is to erase it. This will return to a "factory" state where the only filesystem is the squashfs rootfs i.e. the "ROM". Hashes of rootfs (which is both the squashfs and the rootfs_data area reserved for the jffs) should then be consistent.

The next reboot will rebuild the jffs overlay into default configuration. You can set up default files in the ROM.

2 Likes
10

ART is different for each individual WiFi chip.

1 Like
11

Well it depends on your device.

But you could have set up a multi boot in the boot loader (u-boot ? ), which would attempt to boot other media (USB, TFTP, etc) before it booted from flash.

Or nc up and running for a couple of seconds during the boot loader countdown

12

I have now tried this approach which I think is good, but I'd like to hear some expert opinions:

I created a list of all md5sums of all files in the /rom directory by running:

root@openwrt:/# cd rom
root@openwrt:/rom# find -type f -exec md5sum "{}" + > /tmp/checklist.chk

Then I transfered /tmp/checklist.chk to a device flashed with a (supposedly) identical rom and ran:

root@openwrt:/# cd rom
root@openwrt:/rom# md5sum -c /tmp/checklist.chk

All files showed as OK.

In order to further test this, I flashed one of the devices with a slightly different ROM (a few different network configs mainly). The result was:

root@openwrt:/# cd rom
root@openwrt:/rom# md5sum -c /tmp/checklist.chk
md5sum: WARNING: 55 of 1400 computed checksums did NOT match

I assume this is good enough, I'm just not 100% sure that everything I need is inside the /rom folder and the kernel partition.

13

Good thinking.

But, your existing check sum file won't catch files added to the flashed rom.
They could add files, and you won't notice, since you're verifying files know to
you, through the template image.

You should compare in the other direction, from the flashed rom to the template
image. Then the added files (if any) should pop up as missing when compared
to your template.

14

That's what I did, sorry for not making that clearer in my post. What I am wondering is do I need to check other stuff like /overlay as well if all checksums in /rom as well as the checksums vor dd if=/dev/mtd0 bs=512 | md5sum (u-boot) and dd if=/dev/mtd1 bs=512 | md5sum (kernel) match?

15

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.