Flir E4 Thermal imaging camera teardown

[PA0PBZ]

I changed the signature of cmd.exe from MIPS (0x166) to ARM (0x1C2) and IDA disassembles it perfecty as ARM. I'm beginning to think that someone somewhere has a weird sense of humor.

[SeanB]

Security by ROT13....................

[mikeselectricstuff]

Security by ROT13....................

...like renaming that .cab file as .fif.....

[PA0PBZ]

...like renaming that .cab file as .fif.....

That's just Flir Industries Firmware 

[dustout]

On the i3 I was able to pull up the Service Menu (by pulling up the menu then holding Play/Gallery button).  Lots of version information is displayed and a menu with the options:
* Dump Info (creates a postlog.txt & versions.rsc file on the SD card with various information inside)
* USB Mode -> MSD, RNDIS
* Update Firmware

Unfortunately I don't see any way to modify anything else within this.  I can enable RNDIS for USB using this method and it shows up on the computer as a 10Mbps Network Interface but unfortunately I've only been able to ping its gateway IP. No success with telnet, http, and ftp to the Flir Network Device's gateway (192.168.1.1 in my case) nor its DHCP server (192.168.1.2).  I did discover that if I hold Menu + Up Arrow on boot-up it will display some bootup text beneath the status bar as it boots although it is severely cut off as the text is within a small black box.

[mikeselectricstuff]

On the i3 I was able to pull up the Service Menu (by pulling up the menu then holding Play/Gallery button).  Lots of version information is displayed and a menu with the options:
* Dump Info (creates a postlog.txt & versions.rsc file on the SD card with various information inside)
* USB Mode -> MSD, RNDIS
* Update Firmware

Unfortunately I don't see any way to modify anything else within this.  I can enable RNDIS for USB using this method and it shows up on the computer as a 10Mbps Network Interface but unfortunately I've only been able to ping its gateway IP. No success with telnet, http, and ftp to the Flir Network Device's gateway (192.168.1.1 in my case) nor its DHCP server (192.168.1.2).

Time to look for some serial ports then...

I did discover that if I hold Menu + Up Arrow on boot-up it will display some bootup text beneath the status bar as it boots although it is severely cut off as the text is within a small black box.

E4 does that if any key is pressed at startup - same text as you get from the debug port, but not very readable

[mikeselectricstuff]

More i7 whispers :

The trick used to dump the i7 is via the visual studio remote debugging tools (you can copy files onto the device, right?). You *need* to be using visual studio 2008/2010. Once you have them installed, you can do a full file dump as well as other fun things like editing the registry.

http://msdn.microsoft.com/en-us/library/ms228708
http://msdn.microsoft.com/en-us/library/ms180714

[nitroxide]

So, I've been off this for a while, working on other stuff or enjoying the weekend , but I've been following the progress.

Now, late night I've done some work on the magic menu stuff. The function that gets called when the magic key trigger happens is found in facet_ui_qml (search "2hiddenMenuRequested()").

Reading about i3's gui.exe made me dig-up a bit and I've found this in "ui_remove_uicore_gui.rsc":

.appl entry
.appl.startup entry
.appl.startup.remove entry
.appl.startup.remove.0 index
.appl.startup.remove.0.name text "Gui.exe"
.appl.startup.remove.1 index
.appl.startup.remove.1.name text "uicore.exe"


I also know they are active running processes just by looking at "restartapp.bat":

set PATH=\windows;\FlashBFS\system\;
rset .watchdog.enable false
rset .services.log.active false
ps -k uicore
ps -k Gui
ps -k Prod
ps -k prod
ps -k MediaServer
ps -k appcore
ps -k AppServices
ps -k Resmon
ps -k Bit
ps -k syslog
ps -k Cam
ps -k cam
ps -k geni
ps -k dig
ps -k Dig
ps -k watch
ps -k Watch
ps -k RTP
ps -k fwa
ps -k progress
ps -k Med
delay 10
start appcore
delay 1
start prodapp

Sooo, it seems like someone learnt his lesson from i3 (at least partially ) taking precautions against hacking E4 "i3 style". Now, if Mike or anybody elese having an Ex can retrieve those files from the camera (I'm not sure yet where they're hidden or how they're loaded) then simply dissasembling gui.exe will probably easily solve this! (I took a look at gui.exe from iX firmware - it's indeed a piece of cake to understand as IDA decompiles it completely)

[mikeselectricstuff]

More snippets :
If you are buying an FFC cable, get one at least 200mm long, as that is long enough to be able to fit it permanently and route it down to be accessible as required from the battery compartment. Just make sure the exposed ends can;t short on the metal base when folded away.

Re. the rndis.rsc file :
Seems like the default behaviour if this file is not present, or the CRC is wrong is UVC and MSD
It does check the CRC in the file, which is why setting it to  RNDIS_UVC_MSD didn't work.

While playing with the rndis version of the file, something interesting happened  when I plugged the USB in- I saw some 'configuring' messages appear on my Windows icon bar, and then a new icon appeared (presumably something the Flir drivers installed).
This creates a drive which can access the user disk area, so sort-of equivalent to MSD, apart from having to have the RNDIS driver installed on the PC. My guess is it's probably just a wrapper for an FTP client

It would be really handy if someone could figure out the CRC algorithm on the files - I think this is the true key to opening many other goodies

By playing with the rndis.rsc file, I have established that the CRC does apply to comments, blank lines etc. so looks like a binary check, however adding stuff on the line after after the CRC does not break it, so it's probably CRCing only up until it sees the #CRC32.
Adding stuff between the last digit of the CRC and the newline does break it

There are plenty of sample files in the firmware .cab

[mikeselectricstuff]

More from my anonymous i7 contact, who whishes to be known as Zorro 

My i7 actually had the debug tools installed
already, but they were an older/crippled version? So I replaced them
and it worked fine. Also installing the IDA remote debugger for
windows CE helped me learn a lot about the system. For example: on the
i7, if you set .version.hw.det_board.article it looks like you can
enable 30 fps. But you need to do it at startup through the config
files, and I don't know how to fix the checksum on those yet.

Just remember that when you run conmanclient2.exe,
you need to use "start conmanclient2.exe", otherwise you will just
leave your terminal hanging.

[nilock2222]

It would be really handy if someone could figure out the CRC algorithm on the files - I think this is the true key to opening many other goodies

Looks like it is just a standard 32 bit CRC like used in the ZIP format. Here's a short python script to calculate it for a file:

Code: [Select]

import sys
import zlib
with open(sys.argv[1], 'r') as fp:
    crc = zlib.crc32(fp.read()) & 0xffffffff
    print '0x%08x' % crc


[mikeselectricstuff]

Possibly important Update
 I now suspect the CRC in the config.cfg file may be specific to the unit serial number, so the serial-only hack method may not work on other people's units.
Zorro thinks that files with CRC01 are related to the serial number, possibly with a RIPEMD160 derivative  whereas ones with CRC32 are a generic CRC.

If this is the case, then instead of using my hack files as-is, you will need to generate your own version of config.cfg by entering service mode (RNDIS + web interface) , and pulling your own config.cnf out of \Temp\appcore.d and copying into the \flashifs\hack directory.

A quick look suggests CRC32 is used for standard files (e.g. in the FW update) and CRC01 for files installed/generated in a particular unit, These files also have a #ID line containing the serial number.

One interesting thing I notice is the config file in the "service" dir doesn't have a CRC, so I'm wondering if part of the "Enter service mode" function takes this file as a template and generates a config file from it. If this is the case then There could be some interesting possibilities by editing this template file.
In fact, the only difference I can see between the "template" and the version in temp is the addition of the ID and CRC, so maybe we have a built-in CRC generation mechanism....

[mikeselectricstuff]

It would be really handy if someone could figure out the CRC algorithm on the files - I think this is the true key to opening many other goodies

Looks like it is just a standard 32 bit CRC like used in the ZIP format. Here's a short python script to calculate it for a file:

Code: [Select]

import sys
import zlib
with open(sys.argv[1], 'r') as fp:
    crc = zlib.crc32(fp.read()) & 0xffffffff
    print '0x%08x' % crc


Have you checked this with any of the files?

[nilock2222]

Have you checked this with any of the files?

Yep, I tried it on several of the .rsc files. Just have to delete the existing CRC line before using.

[nitroxide]

Lol, beat me to it. Just now I was previewing the post 
Just make sure to also delete the CRLF after last data line and it works! I've used: http://www34.brinkster.com/dizzyk/download/CheckCRC.zip

[mikeselectricstuff]

Too tired to experiment now, but if it turns out that service mode entry can be used as a way to put the unit-specific sum on a config file, there is likely to be much more fun to be had.... I have sat in console mode watching files appearing in \temp  as service mode chugs away...

BTW one other new feature I noticed in service mode, is the extra 2 palette options aren't just different colours but  "blue when colder" and "red when hotter" than a value which can be set using the  up/down arrows.

BTW is anyone else here actually playing with an E4, or is everyone waiting to see if I manage to brick mine..?

For some reason I keep getting this image in my mind of a bunch of Flir people watching this thread and feeling as if their child is being ripped to pieces by a pack of wolves...

[nitroxide]

Replacing ui_remove_uicore_gui.rsc with the attached one (modded + calc chksum) should have the effect of skipping the removing of gui.exe at start-up (maybe cold start is needed?). If so, the gui.exe could be retrieved for dissasembly and finding of magic key combination.

Mike, could you try?

I'm off to sleep now. 

[mikeselectricstuff]

Zorro says he hacked his i3 to an i7 in exactly the same way as  the E4 - rndis to do service mode, copy config files, modify applaunch.dat
Go for it!

[mikeselectricstuff]

something that I have been wondering about is the role of the eeprom. Especially seeing how the resolution bytes get changed when entering service mode, and how my earlier changes got mysteriously reverted.  Must do some I2C analysis traces to see what happens when service mode gets enabled.
I have a suspicion that it may be that it is only used as a simple way to communicate some configuration info between the main/service app and the bootloader, or maybe even read by the FPGA directly before the filesystem gets going.

[mikeselectricstuff]

I also know they are active running processes just by looking at "restartapp.bat":

set PATH=\windows;\FlashBFS\system\;
rset .watchdog.enable false
rset .services.log.active false
ps -k uicore
ps -k Gui

I don't think the presence of those in restartapp.bat means much. Looking at what ps says when the main app is running, most of the ones listed are NOT running. ps displays a message when any task is terminated (e.g. using stopapp), and you only get a few showing this when you stop the app.
 I suspect these being in the batch files  are just  as a precautionary 'clean-up' left over from debugging or old versions. The fact that it has upper and lower case versions reinforces this. 
I'm not sure there is a gui.exe in the E4 - if there was, it would probably be in the firmware .cab
I think the GUI is mostly done by the stuff named "Facet" - I think someone has previously pointed this out.
Might be worth a look at an i3 firmware file if there is one to compare.

[mikeselectricstuff]

This version of rndis.rsc enables all USB modes, however The Flir utility seems to get things in a knot - I think it tries to disable MSD to prevent clashes with its own drive letter, and things get into a bit of a mess, and ending up with the user file partition not getting mounted. To fix I had to close the Flir util, force it to unhacked mode by booting with USB in and swap the rndis file back.

 BTW the utility that gives the virtual drive is Program Files\FLIR Systems\FLIR Device Drivers\FLIR T3Srv\syx86\t3mon.exe

#
# USB mode MSD
#
.system entry
.system.usbmode text "RNDIS_UVC_MSD"
# CRC32 A18F2E3B

[mikeselectricstuff]

My hunch was right - adding stuff to
\flashfs\system\service\appcore.d\config.d\conf.cfg
DOES get baked into the checksummed version created by service mode entry, so for example adding

.caps.config.ui entry
.caps.config.ui.fusion entry
.caps.config.ui.fusion.PIP entry
.caps.config.ui.fusion.PIP.enabled bool true

to the end of the file makes PIP display mode work once you are in service mode, however you get an error message onscreen in hacked reboot - it still works but there's a menu in the way and the serial console doesn't work.
However MSD is still there so you can change it back. 
But replacing the previous conf.cnf in \hack still gives the error... hmmmm

Incidentally one advantage of using RNDIS and the FLIR virtual drive over MSD is you can take pics and upload them immediately - MSD locks out taking pics when connected to USB.

[mikeselectricstuff]

Not sure what happenned there - could be it saw the backup copy I'd made of the conf template file in \service. Unfortunately I forgot to make a copy of the CRC'd PIP config file so have to start again, however I've found some more out about the whole config & resource thing...

.rsc files in factory.d folders have CRC32

It looks at any & all files in the folder - e.g. renaming the file to set USB to RNDIS mode seems to still work

.cfg files in config.d folders have CRC01 , and it also appears to look at any and all files are looked at.

Items in these files get copied into the resource tree, so if there are items that can do fun things, they can probably be done as additional files instead of editing existing ones.

The question is can you add things like PIP and other goodies using a CRC32'd .rsc file...

I've modified the applaunch.dat to make it easier to play, so it will copy anything in config and factory folders

progressapp -f \flashbfs\system\bootlogo.bmp -g flashbfs\system\bocmd /c otlogo_
legal.bmp -d
# Start command shell on the RS-232 port
cmd /R
# Register a default user
defaultusr
cmd /C md \temp\appcore.d\
cmd /C md \temp\appcore.d\config.d
cmd /C md \temp\appcore.d\factory.d
cmd /C copy \flashifs\hack\__highres.cnf \temp
cmd /C copy \flashifs\hack\config\*.cfg \temp\appcore.d\config.d
cmd /C copy \flashifs\hack\factory\*.rsc \temp\appcore.d\factory.d
# Start appcore. Appcore starts other necessary processes
appcore

[mikeselectricstuff]

OK so it looks like service mode can be used as a CRC01 stamping tool

1) Copy your modified .cfg files to be stamped (without any checksum) into \flashfs\system\service\appcore.d\config.d\
2) Start service mode via web interface
3) Using serial or telnet console ( no need to wait for service mode restart) ,
copy the files from  \temp\appcore.d\config.d\*.*   to your user flash \hack dir
4) Delete the files you put in \flashfs\system\service\appcore.d\config.d\
(not sure if these are what caused problems before, but better be safe as it was a fiddle to recover)
Make sure the original conf.cfg is stil there.

You now have some CRC'd .cfg files in \hack, which you can try putting in your hack\crc folder to see what they do on the next cold boot.
Note it is not beyond doubt that some resource hacks might cause crashyness if you create resources that bork anything that runs beore applaunch,dat and progressapp (dunno if there are) , however it should in principle be recoverable by starting in E4 mode by cold booting with USB plugged in. Probably. YYMV.

Using this method to create a CRC'd PIP .cfg file from this

#
# Generated at CONFIG_DATE CONFIG_TIME
#
.caps.config.ui entry
.caps.config.ui.fusion entry
.caps.config.ui.fusion.PIP entry
.caps.config.ui.fusion.PIP.enabled bool true
.caps.hw entry

 the PIP display mode now works. 

I have tried putting a CRC32 on these files but it doesn;t work. CRC32 should for for .rsc files that go in the factory directory, but not sure if you can do anything useful other than change USB mode.
Detailed analysis of the resource attributes shown by rls -lll may give cluse about which reesources can be changed by which method.

now what else can we enable.....? Must read that Ex manual to see what other features the E8 adds...

Just to reiterate - cfg files with CRC01 are almost certainly  unit-specific, so need to be generated on the actual unit being hacked. 
As & when we find the hidden menu, this will all still be  possible without opening, over the RNDIS  connection. The only thing that the serial link is currently essential for is to enable USB RNDIS.

Incidentally, the first thing you should do before any other hacking, as soon as you have RNDIS running is make a copy of everything in \flashfs as this is all put on at the factory and not easily replaceable,

You can do this at the console by copying to the user partition but it's a pain as there are many directories.
I've not yet managed to get any FTP client other than Windows comamnd-line FTP to work ( have tried FTPsurfer and WinSCP)

[Monkeh]

Try Filezilla as an FTP client. Not a clue if it'll work, but nice client anyway.