Why don’t firmware ‘downgrades’ work on the iSpot?

As you may have noticed, the iSpot’s web interface refuses to let you upload a firmware that isn’t “newer” that the current firmware.

When making this decision, the web interface looks to the “/etc/version.svn” file to see what the ‘current’ firmware version is.  The number stored in this file is the “####” part of the “2.0.0.0 [R#### … ]” software version string shown in the web interface’s firmware info page.

The code looks to the firmware update “.bin” file’s “svn version” header item to see what the new firmware’s version is (refer to “iSpot firmware download image file format” for details on the bin file header).

If the “.bin” file’s version is less than or equal to the current version, it refuses to accept the update.

Even if you were to ‘patch’ the “.bin” file’s header version to be greater than the current version (to make it appear ‘newer’), it may still fail to take the update.  The reason: “/bin/flash_program” contains a table of md5sums for older kernel/rootfs images that are ‘disallowed/blacklisted’.  If the incoming firmware’s kernel or rootfs md5sum matches any of the items in that table, then it will abort the flash programming process.

This blacklist allows Clear to fix ‘backdoors’ (such as the ability to enable telnet in older firmware).  Once you are on newer firmware, you can never go back to the old firmware with the backdoor.   At least that seems to be what they intended…

Disclaimer: information on this site is for educational purposes only, and intended to help iSpot owners experiment with their own devices. I do not condone any hacking for illegal purposes, such as stealing service, etc.

This entry was posted in Uncategorized. Bookmark the permalink.

1 Response to Why don’t firmware ‘downgrades’ work on the iSpot?

  1. Pingback: Release of ‘fwtool’ – firmware image manipulation tool | Hacking the iSpot

Leave a Reply