As stated before PANIC SLOWLY
From a purely statistical analysis of firmware as I dont have unit in hand, any short term mitigation by FLIR will be futile. Why?
1. Almost unrestricted access to HW via programming interface.
We don't know for sure if any hardware proramming interface exists. It;s not uncommon for flash chips to be preprogrammed before assembly.
2. The use of a well documented application processor (iMX257 series) that doesn't have many security features enabled/available.
Any processor-level hack could require a lot of work. I've not looked but would bet even the full data is >1k pages
3. Haven't seen any mention of FLIR restricting downgrades.
We haven't seen any mention of anything.
- Mike's hack works on the premise of enabling certain features "post personality check" (see next point) such as the increased resolution. I think somewhere it was mentioned of finding other strings to put in the .cfg file but would need the .cfg from an E8 to be sure. While this hack is awesome to begin with I still think there is a better hack to be found/developed
- Keeping in mind that one FW pack (1.18.7) is used across all Ex models. That means your using a vanilla install (run-time image + rootfs) that is combined with something else (onboard not in FW update) that produces the final FW that contains the cfg we modify. This "something else" is the personality check I'm referring to. Where is this? Given the clues I have (i2c calls early in boot and exposed taps on the connector) I believe its on the smaller of the two non-volatile storages (EEPROM in the video). It would make sense to store the personality here as its small and can be configured easily. The larger flash device more than likely contains your rootfs and run-time image. Has anyone performed a protocol analysis at boot (better yet, while doing a stock fw upgrade)?
I am fairly sure that the config file is written at the factory, the eeprom has the serial number, which is baked into the config file by the CRC and cross-checked at startup. The serial number is the only thing unique to the unit - my guess is it gets written via I2C by the test system, and so is independent of any flash content.
I also think the resolution data found in the eeprom is just for backwards communication either to the bootloader or the FPGA
Bear in mind that 1.20
could just be some tidying up of debug interfaces and the one second-hand report of non-hackability
could just be user error doing the CRC0. Or a troll. I've had a few PMs from people who got the CRC01 wrong
Until we actually know something I don't see any point in endless speculation.