Flir E4 Thermal imaging camera teardown

[OrBy]

I am really surprised that they haven't locked this down more than they could have - RNDIS menu still there, same FTP password etc.
One of the main reasons the original hack was possible was how easy it was to gather lots of information about how it all worked!

My guess is they are still needed for post sales calibration and servicing unless they want to tear down every unit every time they get sent back and put them on a programming rig further risking calibration issues. Also does the FIF installer use those mechanisms to update devices? If so it would need to be updated with some sort of alternate method if they changed them. (witch could be then RE'ed) It could also be that the bean counters flipped their lids and demanded something be done but the engineers didn't feel the same vibe and did a "good enough".

Also looking back at my days with WinCE PDA's, DRM was never really that extensive in the applications never mind the hardware itself. They likely realized where there is a will - there is a way and didn't want to invest that deeply into it. I would more expect a 1.2 hardware variety is being spun with a hardware limited 80x60 senor ala the FLIR One that no level of hacking will be able to bypass and they are just stop gapping till thoes get in the supply chain.

What I think would be really interesting is getting a factory fresh 1.21 FW unit and some how scanning the free space to see if there have been production related goodies that may have been deleted that differ from the ones that the 1.21 updater deletes from the pre 1.21 units.

[fp]

Hi guys,

I got late in the party and just received an E4 with "upgraded" firmware (calibration from Feb 14 in Estonia).
I am still wondering whether to return it (being in Europe I have the usual 8 days), but while I weight options I suppose I could try and help with anything you suggest.

I did activate RNDIS mode via the right key, and after installing all relevant FLIR drivers on an old Windows XP laptop I could connect. Unfortunately the laptop crashed while in an ftp session, so I won't provide much info for now. All I can say is
- when connecting to the web server, the service menu is gone (that is, the link is there, it asks for the authentification and flir/vl3g works, but then I get "page not found")
- as mentionned earlier in the thread, the 1.1L appears to be linked to one of the software components (it can be seen without the computer, just looking at the info which is provided in the hidden service menu: in the "version information" submenu, one has e.g. appkit 1.0.16 and then confkit E4 1.1L and this is the only place where 1.1L is to be seen)

I will provide a zip of what I get through ftp tomorrow, when the darn laptop finishes verifying the FAT partition (I actually tried to connect to a mac with an RNDIS driver for android devices, but it did not work, I get to see the new interface but do not seem to communicate with it. So I guess I am stuck with windoze....).

If I am provided with clear instructions, I can play guinea pig #2, at least until the week-end. I am reluctant to brick a $1000 device, but I did brick and unbrick phones and wifi routers (I do like/know bsd/linux stuff better than WinCE, I am afraid....).

And thanks to all valuable contributors to this thread, took me a while to read most of it but I enjoyed it, despite being stuck with the low resolution (for now ? I would like to be optimistic but it's reasonable to assume they modified the bootloader).

[MrSquirrel]

I haven't an E4 within reach...
Can anybody post a terminal sequence to read out the hole EEPROM?

I2C.exe is still not making sense, correct me if i am wrong on any of this:

As Mike says you need to perform a selective read by writing the address byte first, otherwise you will start at a random address (where the last operation finished).

The following will read the first 256 (100h) bytes  from i2c address AEh, starting at 00h

Code: [Select]

\FlashBFS\system>i2c.exe r AE 100 00
Open I2C device
I2C read command 57 100 returned: 46 4C 49 52 20 45 34 0 0 0 0 0 0 0 [snip]
The "57h" i2c slave address byte makes sense:
From the CAT24C02 EEPROM data sheet:

Code: [Select]

57h = 1010111x (x=read/write flag)

MSB 1 - Fixed
--- 0 - Fixed
--- 1 - Fixed
--- 0 - Fixed
--- 1 - Address bit 2
--- 1 - Address bit 1
--- 1 - Address bit 0
LSB x - R/W Presumably this bit is tagged on (being toggled by the "r" or "w" switch for a read or write operation) and it is sent out on the bus.
Even if you specify a larger number of bytes to read, the command always returns "I2C read command 57 100 returned" which means it will only return 256 byte at a time, even when telling it to read more.

Also, if you specify a different start address, (say 33 bytes in) it will indeed start reading out from the 33rd byte in, but wrap around at address 256 and start spitting out bytes from the beginning.

There is more on the i2c bus at address AAh and 92h.

I'm guessing 92h is the temperature sensor as this ties in with an LM73 from Texas Instruments has a package marking of "T730" (Clearly shown in Mike's video) as i get some replies back from that address too.

[granz]

Quick question:

My E4 has a dead LCD pixel.  I don't see it when I download the images, just on the built in LCD.  From my quick searching this seems common on the E4, yes?  (I apologize if I missed a post somewhere about this).

[MrSquirrel]

Yes, my LCD has one dead pixel.

It is not visible on any of the images, only the LCD.

[granz]

Yes, my LCD has one dead pixel.

It is not visible on any of the images, only the LCD.

Ah.  Thanks for the fast response.  That makes me feel a bit less annoyed by it then.

[echen1024]

Funny my E4 doesn't have a dead pixel. This thread might actually reach 5k replies.

[Rainer]

Do you habe some instructions for the i2c-usage? Then i will do one more try to get the data from the TIC for a new 1.21-solution.

And what do you think,@taucher, is the target of a full patched 1.21-device near?

[Viss]

I just got my E4 today.
Sadly, it's also running the new 1.21 firmware.
I'm up for trying a variety of things - I'd prefer not to brick it, but I'd love to know if theres a way to downgrade the firmware!
Any help would be appreciated!

[fp]

Actually, if somebody with a copy of the last downloadable firmware which was known to work can provide a link to it (google did not help, looks like nobody is mirroring it), I am willing to see what happens when trying to downgrade (no expectation it will work, but we might learn something in the process)

[fp]

Here is a link to a zip with a backup of my E4 with 1.21 firmware. I didn't change anything prior to backup.

http://en.file-upload.net/download-8685956/BACKUP-FLIR-E4.zip.html

the zip also contains (at the root) the filezilla logfile of the transfer. Several files cannot be copied (be it with flir or root as ftp login), as Rainer noticed earlier.

I suppose one could try and see which files are unit specific between his backup and mine ?

[fp]

So, a "diff -qr" of the two trees from the 1.21 backup archives (mine and Rainer's) yields these files as being different:

/FlashFS/system/appcore.d/config.d/conf.cfc
/FlashFS/system/calib.rsc
/FlashFS/system/default.rsc
/FlashFS/system/default__services.rsc
Only in FLIR_BACKUP Rainer/FlashFS/system: default_a
/FlashFS/system/journal.rsc
/FlashFS/system/journal.rsc.old
/FlashFS/system/journal__services.rsc
/FlashFS/system/maps/ds250C_we.crs
/FlashFS/system/maps/ds250C_we_ap_fi_le_static.gan
/FlashFS/system/maps/ds_we_ap_fi_leExFOL7_LCFMap.fff
/FlashFS/system/maps/ds_we_ap_fi_le_LCFMap.fff
/FlashFS/system/services.d/config.d/conf.cfc
/FlashFS/system/torrent.d/err_checkpoint.rsc
/FlashFS/system/ui.d/config.d/conf.cfc
/FlashIFS/FLIRVers.rsc
/Temp/postlog.txt
/Windows/FTPD.tmp
/Windows/System.mky
/Windows/default.mky

[tomas123]

diff FW "1.21.0"  vs.  "1.19.8"

Code: [Select]

>diff -y \FlashIFS\FLIRVers_FW1.21.rsc" \FlashIFS\FLIRVers_FW1.19.rsc  | grep -e "|\|<\|>"
# Generated at 2014-03-06 10:17:40                            | # Generated at 2014-01-16 17:54:59
.version.SUID text "xxxxxxxxxxxxxxxxx"                        <
.version.hw.camcore.serial text "6381xxxx"                    | .version.hw.camcore.serial text "6380xxxx"
.version.hw.mainboard.revision text "11"                      | .version.hw.mainboard.revision text "09"
.version.hw.mainboard.serial text "2009xxxx"                  | .version.hw.mainboard.serial text "1995xxxx"
.version.kits.appkit.date text "10-Jan-2014"                  | .version.kits.appkit.date text "9-Oct-2013"
.version.kits.appkit.minor int32 16                           | .version.kits.appkit.minor int32 14
.version.kits.appkit.ver text "1.0.16"                        | .version.kits.appkit.ver text "1.0.14"
.version.kits.confkit.ver text "E4 1.1L"                      | .version.kits.confkit.ver text "E4 1.1"
.version.kits.osimgkit.build int32 2                          | .version.kits.osimgkit.build int32 1
.version.kits.osimgkit.date text "2013-11-26"                 | .version.kits.osimgkit.date text "2013-09-02"
.version.kits.osimgkit.minor int32 12                         | .version.kits.osimgkit.minor int32 10
.version.kits.osimgkit.ver text "16.0.12"                     | .version.kits.osimgkit.ver text "16.0.10"
.version.kits.prodkit.date text "12-Feb-2014"                 | .version.kits.prodkit.date text "16-Sep-2013"
.version.kits.prodkit.major int32 0                           | .version.kits.prodkit.major int32 1
.version.kits.prodkit.ver text "0"                            | .version.kits.prodkit.ver text "1.0.0.8"
.version.product.date text "2014-02-13"                       | .version.product.date text "2013-11-29"
.version.product.serial text "6391xxxx"                       | .version.product.serial text "6390xxxx"
.version.sw.AppCore.build int32 1                             | .version.sw.AppCore.build int32 5
.version.sw.AppCore.date text "01-Dec-2013"                   | .version.sw.AppCore.date text "09-Oct-2013"
.version.sw.AppCore.time text "Sun Dec 01 23:01:32 2013"      | .version.sw.AppCore.time text "Wed Oct 09 13:04:43 2013"
.version.sw.AppCore.ver text "22.0.0.1"                       | .version.sw.AppCore.ver text "22.0.0.5"
.version.sw.Bootloader.intermediate int32 1                   | .version.sw.Bootloader.intermediate int32 0
.version.sw.Bootloader.minor int32 5                          | .version.sw.Bootloader.minor int32 3
.version.sw.Bootloader.ver text "16.1.5.0"                    | .version.sw.Bootloader.ver text "16.0.3.0"
.version.sw.common_dll.build int32 7                          | .version.sw.common_dll.build int32 1
.version.sw.common_dll.date text "10-Jan-2014"                | .version.sw.common_dll.date text "23-Apr-2013"
.version.sw.common_dll.time text "Fri Jan 10 17:19:29 2014"   | .version.sw.common_dll.time text "Tue Apr 23 10:24:48 2013"
.version.sw.common_dll.ver text "1.9.0.7"                     | .version.sw.common_dll.ver text "1.9.0.1"
.version.sw.facet_core.date text "25-Nov-2013"                | .version.sw.facet_core.date text "12-Aug-2013"
.version.sw.facet_core.time text "Mon Nov 25 17:14:31 2013"   | .version.sw.facet_core.time text "Mon Aug 12 13:50:28 2013"
.version.sw.facet_ui_qml.date text "25-Nov-2013"              | .version.sw.facet_ui_qml.date text "12-Aug-2013"
.version.sw.facet_ui_qml.time text "Mon Nov 25 17:15:00 2013" | .version.sw.facet_ui_qml.time text "Mon Aug 12 13:51:04 2013"
.version.swcombination.fullver text "os16.0.12_appkit1.0.16_p | .version.swcombination.fullver text "os16.0.10_appkit1.0.14_p
.version.swcombination.ver text "1.21.0"                      | .version.swcombination.ver text "1.19.8"
E4 1.1L = hw.mainboard.revision 11
see new Bootloader.ver = 16.1.5.0

[tomas123]

Actually, if somebody with a copy of the last downloadable firmware which was known to work can provide a link to it (google did not help, looks like nobody is mirroring it), I am willing to see what happens when trying to downgrade (no expectation it will work, but we might learn something in the process)

1.19.8 was never downloadable
you need flir_ex_pn639_v1.18.7_update_pack.zip
can anybody upload this file?

Just checked:
http://cdn.cloud.flir.se/swdownload/assets/cameradownload/flir_ex_pn639_v1.18.7_update_pack.zip < DOWN
http://cdn.cloud.flir.se/swdownload/assets/cameradownload/flir_ex_pn639_v1.21.0_update_pack.zip < ONLINE

[fp]

My point in saying "the last downloadable firmware" rather than 1.19.8 
Hopefully someone uploads it !

So, anyway, indeed there are two different ".version.SUID" text strings in the 2 available 1.21 trees (I did not pay attention to the FLIRVers.rsc files which were different)

[tomas123]

Hopefully someone uploads it !

http://en.file-upload.net/download-8686493/flir_ex_pn639_v1.18.7_update_pack.zip.html

read pdf inside or try

Install FLIR tools
Go to the install folder\bin
Turn camera on and plug USB in
Run FLIRInstallNet
Browse to your .fif file

Click Run FIF

the FIF is a zip file
NK.bin is the Windows CE part see for  NK.bin Toolset https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg382279/#msg382279

camera.cmd is the update script - see inside !
I can't find a downgrade lock

only HW check

Code: [Select]

#old kit without gethwtype. Use os name for identify
type \windows\osimgkit.rev
[NAME ASCO*][$GOTO isOScorrect]
$FAIL "Update is intended for FLIR Z3-Series - not this camera - aborts install"
$GOTO end
your string in \windows\osimgkit.rev is "ASCO OS image"

[fp]

Thanks for the upload. I will try and see what happens tonight (I don't have the camera at hand, only the files from the zip).

On the other hand, the binary strings that follow the CFC in the conf.cfc files are the same in the 2 files

000018b0: 4346 4300 0300 1000 9918 0000 0200 0000  CFC.............
000018c0: 0a                                       .

[fp]

Actually, while we are at it, do you have a copy of the old FLIR tools ? (it makes sense to go and try with these, not the recent version, even if I expect the firmware to flatly refuse downgrading)

[tomas123]

try FlirTools from your CD - its surely the old version 

[fp]

Actually there is nothing on the CD, just a bunch of pdf files which send you back to their web site. Anybody with old FLIR tools around ? (not to mention that at the moment I certainly do not want to register to get the current ones....)

edited: I did find older FLIR tools (3.1), will see what happens...

[Yama13]

Could this be a source?

http://flir-tools.software.informer.com/versions/

edit: nevermind it's not

[schdiewen]

I took a look at the .cfc files from Rainers backup and yes, they are XORed. I attached the "decrypted" files and the extracted key.

But nothing special here, compared to mine they just differ in creation time, HW-version, ID (obviously) and CRC03 being used instead of CRC01.

The trailing 16 bytes at the end of the files starting with "CFC" contain some constants and the size of the original file. But the input files are also padded with some bytes prior to xor and I don't know if this is just junk or somehow important.

[daves]

I attached the "decrypted" files and the extracted key.

I expect now is time to change resolution to 320, put CRC03, crypt via this key and enjoy again ;-)

PS: keep an eye on Flir updates, we would be on right path when new version will came out 

[tomas123]

CRC03 its a task for Taucher

[fp]

@tomas123: yes, that's where I got my 3.1 tools. I'll grab the 4.0 anyway, thanks !

@schdiewen: impressive  , care to share how I can reproduce on mine ?

at any rate, even if we can change the config file, we still have to move over older binaries which have disappeared to set the higher resolution, am I right ?