Flir E4 Thermal imaging camera teardown

[JSJFIN]

Ordered 5 November 2013 from tester.co.uk received today.

Calibration 9 November 2013
Firmware 1.19.8

Hacking worked like a charm, thanks all who participated in the hack development! Now lets test menu hack..

[mrflibble]

@TNT  - Any ideas on this:?
rls .image.flow.framebuffer.frameSum
frameSum          9.2842221e+008

AFAIK that is just the sum of all the sensor pixels. Been mucking about there too.

So in this case the average pixel value is 9.2842221e+008/(320*240) == 12089, which looks perfectly reasonable to me.

Edit: just to be clear, this is the sensor pixel as it is in the framebuffer, so NOT a raw sensor pixel value. There has been some processing done at that point already.

[amyk]

I talked to a few suppliers who all mentioned they generally get shipments weekly - but nobody is getting any more shipments for 3 weeks... which makes it sound to me like FLIR stopped shipping E4's to their dealers.  And I would guess it's because they are rolling out an updated firmware.

Or more mundanely, they could just be running out of stock due to the sudden demand and waiting for production to catch up... as of this post, a search for "flir e4" returns the Hackaday page as the 3rd result so they might be getting a lot more sales than we thought.

[mikeselectricstuff]

For i3 owners out there, this is a config from an i7 which someone kindly sent.
Someone mentioned a lack of measurement functions on a hacked i3 - these appear to be in gui.d\config.d - The e4 has a similar file that enables PiP, which I merged into the single e8.cfg file
flashfs\system\appcore.d\config.d :

# i7 Radiometric - Measurement active + 1 spot + 1 isotherm + 1 mbox
# + radiometric store, compatible radiometric format
#
.caps entry
.caps.config entry
.caps.config.name text "i7_2012"
.caps.config.revision text "1.0"
.caps.config.image entry
.caps.config.image.sysimg entry
.caps.config.image.sysimg.measureFuncs entry
.caps.config.image.sysimg.measureFuncs.enabled bool true
.caps.config.image.sysimg.measureFuncs.mbox entry
.caps.config.image.sysimg.measureFuncs.mbox.enabled bool true
.caps.config.image.sysimg.measureFuncs.mbox.maxCount int32 1
.caps.config.image.sysimg.measureFuncs.spot entry
.caps.config.image.sysimg.measureFuncs.spot.enabled bool true
.caps.config.image.sysimg.measureFuncs.spot.calcMask int32 514
.caps.config.image.sysimg.measureFuncs.spot.maxCount int32 1
.caps.config.image.sysimg.measureFuncs.isotherm entry
.caps.config.image.sysimg.measureFuncs.isotherm.enabled bool true
.caps.config.image.sysimg.measureFuncs.isotherm.calcMask int32 20
.caps.config.image.sysimg.measureFuncs.isotherm.dual bool false
.caps.config.image.sysimg.measureFuncs.isotherm.fixScale bool false
.caps.config.image.sysimg.measureFuncs.isotherm.interval bool true
.caps.config.image.sysimg.measureFuncs.isotherm.invInterval bool false
.caps.config.image.sysimg.measureFuncs.isotherm.maxCount int32 1
.caps.config.image.services entry
.caps.config.image.services.store entry
.caps.config.image.services.store.enabled bool true
.caps.config.image.services.store.radiometric entry
.caps.config.image.services.store.radiometric.enabled bool true
.caps.config.image.services.store.incompatible entry
.caps.config.image.services.store.incompatible.enabled bool false
.caps.config.image.services.store.incompatible.level int32 0
.caps.config.image.settings entry
.caps.config.image.settings.enabled bool true
.caps.config.image.settings.resIR int32 140
.caps.config.image.settings.fpgaResolution entry
.caps.config.image.settings.fpgaResolution.enabled bool true
.caps.config.image.settings.fpgaResolution.resIR int32 144
.caps.config.hw entry
.caps.config.hw.sdcard entry
.caps.config.hw.sdcard.enabled bool true
.caps.config.image.sysimg entry
# ID xxxxxxxx
# CRC01 xxxxxxxx

\flashfs\system\gui.d\config.d :

#
# gui.cfg - i7
#
.caps entry
.caps.config entry
.caps.config.name text "i7_2012"
.caps.config.revision text "1.0"
.caps.config.menu entry
.caps.config.menu.enabled bool true
.caps.config.menu.measurementMenuActive bool true
.caps.config.menu.measureAreaSubmenuActive bool false
# ID xxxx
# CRC01 xxxxxxxx

[Psi]

Rushing through a new hack-blocking E4 firmware is only going to..
1- Result in weak/rushed code which is easy to bypass again
2- Annoy people who purchased an E4 to hack but can't, which will promote more hacking on the new firmware since engineers love a challenge and to hack 'on principle'
3- Give everyone many opportunities to study the E4 and how it all works and how to bypass new firmwares. All this info will make it easier and easier to hack future firmware.

If they were smart they would get to work on a well designed anti-hack firmware fix but not roll it out until the E4 sales die back down to normal level and they are pretty sure their new fix is as secure as possible. (A few months at least).

An arms race between many hobby engineers all of the world and the engineers at Flir isn't going to end well for Flir.

[mikeselectricstuff]

Rushing through a new hack-blocking E4 firmware is only going to..
1- Result in weak/rushed code which is easy to bypass again
2- Annoy people who purchased an E4 to hack but can't, which will promote more hacking on the new firmware since engineers love a challenge and to hack 'on principle'
3- Give everyone many opportunities to study the E4 and how it all works and how to bypass new firmwares. All this info will make it easier and easier to hack future firmware.

If they were smart they would get to work on a well designed anti-hack firmware fix but not roll it out until the E4 sales die back down to normal level and they are pretty sure they're new fix is as secure as possible.

The current hacks could be fixed in a simple and low-risk way - if the info we've seen so far is correct, they've disabled the serial console and USB menu keypress, and possibly something else (It could be that the reported user just did the CRC01 wrong).
If Flir have any sense they probably don't care enough about the current hack to put major effort into stopping it, but probably want to be seen as at least doing _something_ if only to appease people like shareholders who don't understand the subtleties.

However the thing they really, really don't want is a framerate hack, as that would get them in all sorts of trouble due to export regs. If they have done their job properly, they have locked this down in the FPGA and won't be worried. If not, they should be be crapping themselves about now, but reacting by completely locking out a resolution hack is probably the most dangerous thing they could do as it would only intensify hacking efforts.
With the current situation, the hacked E4 is way good enough for most people, so hack efforts have already diminished, and will continue to do so.

If they were to lock out a resolution hack completely, the only route around it would be the "Zero day" method of adding a board to tap off the raw signal and process it with an FPGA or powerful ARM etc. This would not be especially hard or expensive (BTW No I'm not planning it as I already have all the thermal imaging I need). OK it would be a lot of work to get accurate thermometry this way but useable night vision would be pretty straightforward.
Locking out a firmware hack completely would only hasten this happening. The RC modelling community is gagging for a small, light, cheap, high framerate TIC so I have no doubt someone will do it eventually, either using an E4 or an automotive unit using the i or e series sensor.
Fixing that would need an expensive board revision and may have knock-on effects on their production/test processes.

I agree with Psi that a quiet rollout after the fuss has died down is the most likely outcome. Will be interesting to see if this has a different FPGA file (assuming we can find a way in to check).

An arms race between many hobby engineers all of the world and the engineers at Flir isn't going to end well for Flir.

..except in sales of the E4...
The problem with security is there will always be more people trying to break it than secure it. The only barrier is the cost of the hardware and perceived risk of bricking.



 

[mrflibble]

Since I notice some mention of images earlier on...

Code: [Select]

# set to where it should store things. Any location goes, but maybe somewhere on \FlashIFS\ is a good idea ;)
rset .image.services.store.filename <wherever>

# take a pic from your favorite script
rset .image.services.store.commit true

Regarding triggering stuff with a commit: Triggering a NUC can be either through the resource tree, or by executing "nuc.exe" on command line. Code snippets I use for some triggers.

Code: [Select]

   def triggerNuc(self):
        self.setResource(".image.services.nuc.commit", True);
        return;
   
    def triggerPhoto(self):
        self.setResource(".image.services.store.commit", True);
        return;

Incidentally, the pics I posted some time ago were done using this.

What's also fun is you can open/close the internal shutter. Handy if you want to:
- close shutter
- do some measurements + calculations
- open shutter

During that you can obviously also disable auto-nuc.

*** TODO: paste code ***

Also amusing ... you can check the entire image flow:

Code: [Select]

\>rls -ll .image.flow.order
rw--rw--rw---- 0 root   root   <a> order           "snoopRev;object;lens;shutter;baffle;TSens;detector;maps;globalCorr;digitalFilter;histogramHW;framebuffer;histogramSW;zoom;visualZoom;snoopFwd;"

As you can see in the above .image.flow.order is marked rw, but I couldn't get anything to write to that. I tried a few reorders just for the fun of it, but no dice.

You can however enable/disable things in the flow. For example:

Code: [Select]

# disable lens correction
rset .image.flow.lens.partOfImgFlow false

# enable lens correction
rset .image.flow.lens.partOfImgFlow true

Same goes for all the other items in the list. The lens correction is pretty subtle, but you can see it.
Dunno if it was mentioned or not, but you can zoom + set zoom point. Maybe Taucher's mod enables zooming as well? Don't know since I haven't used it yet. Too many other fun things to explore first.

Zooming:

Code: [Select]

    cli.setResource(".image.flow.zoom.factor", 2)

As for snoopRev and snoopFwd, haven't checked them out yet. Current guess is some sort of palette snooping, since there's also a spectral compont to it (currently set to NEUTRAL).

And seeing the .caps dump by Mike just now. I have said it, but since there's been no reaction to that I will say it again...

Be adviced the current hack is not one config file. It is TWO config files, that are combined into ONE running config.

This fact is also shown somewhere in the logs. Too lazy to dig it up the exact message right now, but no need since you can check for yourself:

Code: [Select]


\>rls .caps.config.name
name            "app E4 1.0 + app E8 1.0"

Which incidentally is precisely what you get when you combine the original E4 config with our E8_hack config.

The reason I mention it a bit more bold this time, is that you may want to keep in mind that the rather arbitrary "lets give it this filename" method used currently may very well affect the hack working or not working. As in, suppose the old firmware reads files in one order, and the new firmware in another order. Then 100% depending on how they implement combining resources you get either something working, or something that is not quite what you wanted. Hell, if they don't do any specific alphabetic or whatever ordering, it could even depend on how it's stored on your filesystem. (Oh this inode looks shiney! Lets do that first!)

I am guesing (haven't tested it yet, because stuff works right now  ) that you can change the order by changing filenames. And as sanity check you can then check the value of .caps.config.name. I am guessing that the following will happen:

Currently working config:
name            "app E4 1.0 + app E8 1.0"

Maybe working, oooooor maybe not working config:
name            "app E8 1.0 + app E4 1.0"

What I think happens is our E8 config is applied to the resource tree last. So any boring old E4 stuff is overwritten with the values we would like to see.

So should you get a situation where "the hack doesn't work", best check that first. Not even telnet required, just use the FlirInstallNet from Flir Tools to show resource .caps.config.name.  If that shows E8 first and E4 later, then the order is swapped for whatever reason. And if it shows just "app E4 1.0" then either you're doing it wrong (CRC01) or something else is going on.

[mikeselectricstuff]

I am guesing (haven't tested it yet, because stuff works right now  ) that you can change the order by changing filenames. And as sanity check you can then check the value of .caps.config.name. I am guessing that the following will happen:

I did confirm that it looks in alphabetical order with the .fif installer for USB modes, which is why the RNDIS is called zrndis.rsc

[mrflibble]

I did confirm that it looks in alphabetical order with the .fif installer for USB modes, which is why the RNDIS is called zrndis.rsc

Great.

In which case I will just post the executive summary for people with a non-working hack:

- Start FlirInstallNet
- Do "Get resource" for .caps.config.name
- "app E4 1.0": hack didn't apply. Recheck your CRC01. Still a problem ==> 
- "app E4 1.0 + app E8 1.0": hack did apply, so things should work. 
- "app E8 1.0 + app E4 1.0": hack did apply, wrong order. Check the filename for your config. It should alphabetically come after the original config file name.

Oh and pr0-tip. When you do that, be sure that appcore is actually running at that point in time. I just did the above just to check if the method was working. Huh! Why don't I get a resource result??    DOH!  I wasn't running appcore at that time. Yeah, not many resources to be listed then. 

[amyk]

I've noticed there's a few posts along the lines of "Flir should've had better security" and that along with some other recent events made me want to ask this: if you were Flir management that would probably be a natural thought, but is that really something you want to say as a user/consumer? The reason is that if you're saying that as a user, you're implying that you want your products locked down and "secured" against you. Is that what you want, for the corporations control everything about what you buy and you unable to resist? I've been seeing a lot of "security" being added to products lately, ostensibly because it's better for the user but actually it's diminishing user freedom and control. The reasoning they use seem to be along the lines of "do you want a more secure product? you'd be crazy not to!" without saying truly what they mean by "more secure". To me, security is good up to a point - i.e. until it goes against the will of user.

</rant>

[ovnr]

Got mine today, calibrated 7th November. Version 1.19.8.

Hack works like a charm, thanks everyone (but especially Mike)!

[tim_h]

Ordered mine today from our local test gear company http://www.alpha-electronics.com/. Looking at a week delivery as they don't hold stock and I assume it's coming from Flir.
Going to have take my chances on it being a new firmware model.

Salesman told me Flir said a price increase was imminent but could sell at the current price, not sure if this bullshit?
We have an trade account with them and he gave me a discounted price of £695 + VAT.

Thanks for your hard work on this.

[mikeselectricstuff]

Salesman told me Flir said a price increase was imminent but could sell at the current price, not sure if this bullshit?

Maybe an adjustment based on the higher ratio of sales of E4 to other models they're seeing... however a lot of their publicity has been based around the "Sub$1000" price tag

[olsenn]

Maybe an adjustment based on the higher ratio of sales of E4 to other models they're seeing... however a lot of their publicity has been based around the "Sub$1000" price tag

I aggree with Mike, the sub-$1k aspect of the E4 has been advertised quite a few times, and I doubt they would chenge that now. If they're going to try to cut costs they will more likely stop including the travel case with it.

I wonder if it would be cheaper for them to harden the FPGA logic into an ASIC? I'm not sure what is being doen by that device, but I doubt for something manufactured in such numbers as this it would be cheaper to go for a Cyclone IV.

[mikeselectricstuff]

Maybe an adjustment based on the higher ratio of sales of E4 to other models they're seeing... however a lot of their publicity has been based around the "Sub$1000" price tag

I aggree with Mike, the sub-$1k aspect of the E4 has been advertised quite a few times, and I doubt they would chenge that now. If they're going to try to cut costs they will more likely stop including the travel case with it.

I wonder if it would be cheaper for them to harden the FPGA logic into an ASIC? I'm not sure what is being doen by that device, but I doubt for something manufactured in such numbers as this it would be cheaper to go for a Cyclone IV.

I suppose that depends on the numbers - I have no idea what volumes would be on something like this. Another aspect is that the sensor is quite new, so I'm sure they'd want to keep their options open while they characterise it through production, so hardening the FPGA could be a bit of a risk.

[Loafdude]

I made the model to:
11,867mm diameter,
0,99mm radius on the 10 spokes

Attached the original version which could be cool to 3D print where I had added a grip

EDIT: link first feedback:
https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg330321/#msg330321

Thank you for this file Taucher!

For Canadians, Draft Print 3D was able to print and ship this piece for me in ABS for $12.00 + Tax
http://www.draftprint3d.com/ (In Toronto, shipped to Vancouver)

# Scratch that, apparently they misquoted and need to add freight. 12$ part cost only
Ended up being 13.56! Fair deal!

[gotvolts]

Okay, just got mine today with firmware code 1.17.1.  Will give it a shot to see if the hack works and report back.

[mrflibble]

Okay, just got mine today with firmware code 1.17.1.  Will give it a shot to see if the hack works and report back.

1.17.1? That's the lowest version I've seen so far. AFAIK most are 1.18.7 or higher. Will be interesting to see if it works there as well. Probably will. If it really is 1.17.1 (aka not a type) then you may have a relatively low serial number...

[Loafdude]

One other guy had 1.17.1 calibrated sept 20 while mine which is 1.18.x calibrated sept 16 has newer FW
It seems calibration sequence is not done in the same order as production.

[OrBy]

Jpeg compression level:
.image.services.store.quality                       85

How would one go permanently changing this to 100? (I am never going to have 500 images on this thing so they may as well look as good as they can)

Also has anyone else noticed that after charging for a while when off that the battery symbol seems to burn in a bit on the LCD? (persistence)

[_Sin]

Jpeg compression level:
.image.services.store.quality                       85

How would one go permanently changing this to 100? (I am never going to have 500 images on this thing so they may as well look as good as they can)

Remember this is really just for the preview image (basically a screen grab), the actual thermal image is stored non-lossy compressed in the same file.

[mrflibble]

Jpeg compression level:
.image.services.store.quality                       85

How would one go permanently changing this to 100? (I am never going to have 500 images on this thing so they may as well look as good as they can)

Enable RNDIS and telnet to it (192.168.0.2). Then do:

Code: [Select]

rset .image.services.store.quality 100
Although you are probably better of using png if you're concerned about picture quality.

Also has anyone else noticed that after charging for a while when off that the battery symbol seems to burn in a bit on the LCD? (persistence)

I haven't really notice any persistence on the lcd, but you could try:

Code: [Select]

rset .power.settings.screenSaverEnable true


[OrBy]

Remember this is really just for the preview image (basically a screen grab), the actual thermal image is stored non-lossy compressed in the same file.

If that's the case then it's not really that big of a deal then.

Enable RNDIS and telnet to it (192.168.0.2). Then do:

Code: [Select]

rset .image.services.store.quality 100
Although you are probably better of using png if you're concerned about picture quality.

I haven't really notice any persistence on the lcd, but you could try:

Code: [Select]

rset .power.settings.screenSaverEnable true


I noticed it after having it on the charger for a few hours then going into a dark room with the brightness on low and the color set to grey - I could see the outline of the battery and the bars. It did go away after a bit but it cant be good for the LCD in the long run. If you look closely you can see the screen back-light go off while it's charging but the LCD is still displaying the battery image witch is likely contributing to the persistence. I have had this issue before on a iPad2 and it got quite pronounced after a while but was able to repair it by running an app that flickered black and while colors over the whole screen and it would clear it away.

Thank you to you both for the quick info!

[mrflibble]

Just when I am testing some powersaving settings my battery is empty. Classic! 

[epistememe]

Ok, I am having difficulty with the hack.  First off, I am a Mac user and have rarely used Windows in the last five years.  I am also not very knowledgeable in the command line interface.  I have access to a windows 8 laptop and tried to follow the directions Mike posted bellow but was not able to get CRC01 to run.  I assume that all I have to do is enter "CRC01" and then hit return, if this is not the correct procedure what is the correct procedure (so about being so daft).  I also tried just running the expanded file on the desktop CRC01 but that did not work either.  I did a quick search on google for procedures but have not really found what I am doing wrong.

HELP!