Flir E4 Thermal imaging camera teardown

[Taucher]

Look for yourself - introduction of a new CRC algo ....
I wonder if service mode still stamps the template file with the CRC though..
..and what about updates done to old units which will have old-style CRC01-stamped config files?

I'm not sure if it's so "new" after all - but I'm pretty sure there could be something buried inside the code telling "convert 01 to 03" and add CRC32 lines...
Just the fact that they "armored" applaunch.dat with a CRC03 and removed hints on CRC calculation from the rdump helpscreen tells me there's something fishy...
On top of this a combination of CRCs got employed (doCRC function).

RIght now I have the gut feeling this is a "mild" measure - but we'll see

[Fraser]

As many will know....when a patch is issued for a software, it can often be reverse engineered to discover what vulnerability it is protecting from exploitation. Sadly this is a technique used by Black Hats to attack IT that is not kept up to date on its patching.

Now consider the new FLIR firmware and the fact that is is still compatible with Version 1.0 hardware....... I wonder what could be extracted from the changes that FLIR have done 

It is interesting to read that the FPGA code has been changed.

I am wondering if 'defence in depth' is being employed to improve the defences against modification.

[daves]

Hard to describe the feeling now...

You know... usually there is some BUS, which tells IT to prevent it against the hack. So IT SDO will force some PM who will force some TL to develop the antihack.

This forum is FLIRED = well monitored by FLIR.

If you will prove you can hack easily new version, someone will get fired 

So now it will be very well secured    OR    I do not understand it at all

[pomonabill221]

Aurora:

Problem with crc solved!

You are right (of course!), you can't see <crlf> or white spaces, or any hidden, non-visable characters, but they all count
towards the crc, check sum, or whatever method you use to establish file integrity.  I was about to view the
file with a hex editor to verify there was nothing there that shouldn't be there.

The problem was very simple, as most problems and solutions are.  I didn't realize, and I'm sure this has been
mentioned many times, immediately after the last character in the serial number, there should be nothing, nothing
but one blank line below.  To insure that, you can put your curser right after the last character and pound away
on the delete key or use any other method you choose.  Then tap the <enter> key one time.

Thanks everybody who answered my PM's and gave me good advise.

Jim H.

I note the comment about not having changed the original file. Would that not cause this issue as it will have a CRC entry present at the bottom of the file ? The very presence of the Checksum throws off the CRC calculation. You have to delete the original CRC checksum result from the file then run it through the CRC calculator and create the checksum. Compare this to the one you deleted. they should be the same. Just a thought. Not wanting to insult you at all but are you aware of what the CRC checksum is and how it is produced ? If not, please be aware that a CRC calculator takes EVERY character present in a file and produces a checksum representing that files content. If you have ANY additional characters present in the file it will destroy the checksum validity. Please take a look at the E4 e8.cfg file to see what it should look like at the end. You will see a position for the serial number to be entered, Then CRC is run, then resultant checksum is entered into e8.cfg file at the bottom.

Just to add my method...
I just "right cursor" and see where the cursor ends up.
If there are more than just an additional line (blank) with NO spaces, I know there is just ONE CRLF.
I use notepad WITHOUT wordwrap turned on.
just a FYI...

[pomonabill221]

New BFIC (version 0.9) available in my footer note. Now there is also support for interior.

That's some SCARY mold!!!

[ixfd64]

I wonder how hard it will be to reverse-engineer the new algorithm.

[SeanB]

Looks like older firmware will be a good seller on Ebay then for a while.

[daves]

Looks like older firmware will be a good seller on Ebay then for a while.

Yeah, its very kind from FLIR to do new firmware hack-proof, since now our tweaked E4 is raising its value

[Fraser]

So the 10 I have in my garage are now worh about 2K each then 

Just kidding 

[rsivan]

I have 10 units for sell, old fw.

[Fraser]

The dealers like PASS had better get ready for another mad rush to buy up FW 1.19.8 stock.

[muvideo]

I have 10 units for sell, old fw.

Wow 
Let's know how much you will ask for one

[rsivan]

Make offers

[stefbeer]

I'm just thinking out loud:
You have a hacked E4 with firmware version 1.19.8 or older and for whatever reason you want to install the update.
After installing the update you have the new software on your device. But the configuration files (especially our modified one) should still be the same. I took a short look at the camera.cmd, looks very much like the other ones except some new or removed files. They just move some files from here to there, delete some directorys, check some versions, ...
Now you power up your camera with the new software for the first time. There are two possibilities:

• It's just new software, the configuration file layout (or the checksum to be more precise) is the same. This is very very very very (did I already say very?) unlikely. I really don't think they just wanted to make the UI faster or something.
• The old configuration files have to get "updated" somehow. And that's the part where it gets interesting, I think. Because either...
  • the thing updates every configuration file it can find, or...
  • it just updates the first configuration file it can find, or...
  • it makes some kind of sanity check or plausibility check before updating.

If they really have done something like a plausibility check, the next question is: How do they determine which camera we have? Because it has been stated before that you can change the "E4" in the EEPROM.

And it would be also interesting to talk about ways or measures they could have taken to prevent firmware downgrade. Because Taucher already helped someone bringing a bricked device back to life with a small firmware downgrade. And it didn't seem to have caused any issues with the device.

[Taucher]

Please calm down and let us check that firmware first (or try on your own) - good things take a moment or two.

Preliminary checks indicate there are some countermeasures in place or they got prepared - but it's no 100% check yet.

[rsivan]

I checked stock on distrelec here in Italy, they have 10 units left, I got mine 1 week ago when stock was 16+ and fw is old one I done patch 100% ,price was €995+vat 22% ,also I see on ebay Germany one seller have 80> in stock,and auction claim to be fw 1.19.8.

[Fraser]

I have just emailed Dave at PASS to establish their stock levels for UK buyers.

I will post details here as soon as he responds.

I had a very good buying experience with PASS but you should deal directly with David Atkins as he knows all about the E4 and this Blog. If you really want an E4, you could do a lot worse than ordering one from PASS.

Contact details here:

https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg328110/#msg328110

[PA0PBZ]

Update on 1.21.0:
...
FPGA.bin:
- inner structure changed totally - but it's obvious it has 4 major segments

This could be the most interesting part of the update

[Fraser]

Hmmmm yes .... that was my thought as well. Why change something that is of no consequence. Someone didn't like the FPGA programming...... another vulnerability ?   

[ixfd64]

So... who's going to be the guinea pig?

[Taucher]

Update on 1.21.0:
...
FPGA.bin:
- inner structure changed totally - but it's obvious it has 4 major segments

This could be the most interesting part of the update

actually not - that code is auto-generated and even a small change could lead to massive deviations in the internal structures

[daves]

That's some SCARY mold!!!

Indeed. Its taken at 8th floor, humidity going up from lower 7 floors, so its over 70%. And you see, temperature there drops to 12°C (54°F), so its ideal place for mold. There is some problem with the frame insulation.

Good work! Some bugs,comments, suggestions

Thank you for your input. Its still under heavy development, Interior/Exterior switch was "quickly put it there before release" thing. You can override with settings per photo (blue button). Anyway, it will appear also on main screen in next version.

[Taucher]

Just a rough check (disregarding compression etc):
1.21.0: strings NK.bin | grep -i crc
# CRC
CRC%d
# doCRC %s %u %u
# doCRC
CRC04
CRC03
CRC02
CRC01
CRC00
CRC32
RCRC
rCrC

For comparison - 1.17.8 firmware:
strings NK.bin | grep -i crc
RCRC
rCrC

[Fraser]

This thread just got very interesting again 

I am fortuante enough to already have an E4(8+) but I still find it interesting to see what FLIR have done and their thinking behind the changes.

The problem for our resident code experts, like Taucher, is that they do not have the firmware running 'live' on a platform to see how it behaves. That makes life more challenging for them. I cannot see anyone sane installing this new firmware on an enhanced E4 if it then prevents further enhancement, or worse still, reverts the camera to standard spec.

[Taucher]

Just a small bump for anybody looking how to dissect NK.bin files - look here:
http://www.t-hack.com/wiki/index.php/NK.BIN_toolset

ViewBin... v1.18.7-NK.bin
Image Start = 0x80100000, length = 0x00A53D54 Start address = 0x80101000
Checking record #190 for potential TOC (ROMOFFSET = 0xFFEE478C)
Checking record #200 for potential TOC (ROMOFFSET = 0x00000000)
NOTICE! Record 200 looked like a TOC except DLL first = 0x4001C001, and DLL last = 0x4063C07B

ViewBin... v1.21.0-NK.bin
Image Start = 0x80100000, length = 0x00A871B0 Start address = 0x80101000
Checking record #195 for potential TOC (ROMOFFSET = 0xFFEB9350)
Checking record #206 for potential TOC (ROMOFFSET = 0x00000000)
NOTICE! Record 206 looked like a TOC except DLL first = 0x4001C001, and DLL last = 0x4063C07C

next stage - extract nb0:
cvrtbin -r -a 0x80100000 -w 32 -l 0x00A53D54 v1.18.7-NK.bin (in own directory (OLD)!)
cvrtbin -r -a 0x80100000 -w 32 -l 0x00A871B0 v1.21.0-NK.bin (in own directory (NEW)!)
# Memo: no warnings should be visible, otherwise offset error likely!

mkdir OLD\dump
mkdir NEW\dump

OLD>dumprom.exe -d dump -v -5 v1.nb0
NEW>dumprom.exe -d dump -v -5 v1.nb0

 

applauncher.exe is the file containing the new CRC functions (CRC04 CRC03 CRC02 CRC01 CRC00 CRC32) and some debug-messages:

# CRC
VerifyHash - [CRC error] : done
VerifyHash - [CRC OK] : done
VerifyHash -[CRC%d] : not accepted
# %19s %x
CRC%d
VerifyHash - [CRC not trusted] : done
%S [size]
%S [CRC]
# doCRC %s %u %u
# doCRC
verifyCRC - cannot open %s
Bad Argument(s)! Use "applauncher" for help.

and some additional blocks relating to integrity checking on startup and FAILING if check not passed:

APPLAUNCHER: Refuses to run launch specification file. Aborting!
FAD call fails:%d hndl:%d err:%d
No integrity check necessary
Integrity: %d
FAD1: