Flir E4 Thermal imaging camera teardown

[ixfd64]

I wonder if a method like this could be used to find unofficial upgrade paths.

[realdoc]

Ok so I have been following progress on the hack for a while and took the plunge to find out I've got an e4 with the new firmware!

I'm having the same issue putting it into RNDIS mode, I can get to the menu and then select it but it never actually changes mode.

Oddly I'm not having driver issues as stated, I can view the camera video using Flir player.exe etc.

Any tricks I can try to get the camera to respond in RNDIS? Happy to provide any details necessary.

Maybe you can try the SetRndisTemporary.fif from the attachment to the post of Mike
https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg321956/#msg321956

That only runs one command to change the USB mode and should not persist through reboots. Do be aware however, that it might not work or wreck something. You should be able to run it using the FlirInstallNet.exe command in your FLIR Tools directory.

BTW, can you make a screenshot of your device manager with the FLIR devices expanded? So I can compare with is different with me. And maybe check which driver you are using?

[realdoc]

]FlirInstallNet needs a device. But if you don't have a device...

But doesn't he have a device? You don't need your camera to be in RNDIS mode to install a fif file, from what I understood.

[realdoc]

@realdoc.

I know it would not help this community but in your position I would be looking at returning your E4 for a refund as it is not fit for purpose due to the FLIR Tool connectivity issue. I would then put my efforts into finding an E4 with version 1.22 or earlier firmware. They are still available if you look around. There is the very real possibility that FLIR have done a decent job of locking down the platform this time. Nothing is unhackable if it has an I/O port BUT it may take a great deal of effort to succeed this time and such relies on 'others' having the time to assist. The fact that the E4 no longer communicates with its OEM software may even be an indicator of how locked down the new firmware is. As I have stated, an open I/O port is a vulnerability and FLIR know it. There are ways to ensure that a platform will only provide limited connectivity via its external ports and only to a specific application that is in itself locked down to prevent its easy use as an attack vector.

FLIR read this forum and will be learning from the conversations that occur here. If you wish to take the risk that they have missed an attack vector in their latest release then stick with it, but they have had plenty of time to perfect their defensive strategy and that new hardware revision makes me think they may have advanced to combined firmware and hardware lock downs. I may be totally wrong but while there are still older firmware cameras available, I would make life easier for myself and get one of those while you have the good treason to return your 2.1.0 camera.

Just my 5 Cents worth.

I just don't want to sit here lurking around with a half-broken camera, without helping the community to go forward. I do actually feel very committed to also get this firmware opened up. I will send the unit in for a replacement this weekend and if the new one is still unlockable or broken, I still have enough time to send it back and get a refund. Let's see what happens and if we can make any progress with the unit of oddy.

[realdoc]

]FlirInstallNet needs a device. But if you don't have a device...

But doesn't he have a device? You don't need your camera to be in RNDIS mode to install a fif file, from what I understood.

That's right. Also in UVC + MSD mode (default mode) you can run FlirInstallNet to install a fif file. But you must have some device. --> https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg454513/#msg454513
I think, with incorrect driver FlirInstallNet does not work. FlirInstallNet needs a UVC or RNDIS device.

I know. My camera is broken, but oddy also has one now, with the 2.1.0 firmware. So he can take the first steps while mine is replaced by the supplier

[FireBird]

A friend of mine received his E4 today (FW 2.1, HW 1.2L) and also wasn't successful with connecting it to his PC. The device manager just showed the hardware with an exclamation mark. I currently do not have more details but can ask if someone is interested.

[Fraser]

One of the dangers of an OEM changing firmware, and/or hardware, to prevent hacking is you can effectively go from a known stable platform to an unknown or unstable one. It looks like FLIR may have an issue with FW 2.1.0 and because the cameras cannot connect to to a PC I can't see how a firmware update will be of any use. Anyone with such a camera should think seriously about getting a refund. The alternative may be having to send the camera into a service centre for 'upgrade'. Do you really want the hassle ? When I spend $1000 I expect a unit to work and don't really want someone messing around with it at a SC as that may involve disassembly. At this point, in spite of reports that some have PC connectivity to FW 2.1.0, I would consider it a duff build and not bother attempting a hack of it until such time as FLIR issue the fixed version, which may be different again !

[FireBird]

My guess is that the 2.1 FW is incompatible with the available drivers and a not yet released driver will fix it.

[Fraser]

That view is supported by the fact that good old Linux can see the camera but Windoze cannot. Still a cr*p situation for FLIR to have created though. Stinks of poor pre-release Alpha and Beta Testing.

[mikeselectricstuff]

My guess is that the 2.1 FW is incompatible with the available drivers and a not yet released driver will fix it.

My understanding was that some people have found it does not enumerate as a UVC or MSD device under Window - this should not need any driver from Flir, and if this is actually the case, it's a firmware bug that needs fixing.

As regards being able to select RNDIS with the menu but not connect, remember (AIUI) RNDIS is not a standard protocol, and needs Flir's driver, so they could have done all sorts of things to restrict what can be done here.
As the appear to use their own flavour of protocol over UVC for firmware updates, I'm not sure why they would even bother leaving RNDIS in there, though it may be used by their factory cal process.

[realdoc]

As regards being able to select RNDIS with the menu but not connect, remember (AIUI) RNDIS is not a standard protocol, and needs Flir's driver, so they could have done all sorts of things to restrict what can be done here.

It is a standard, using default WinCE functionality. There is a suggestion somewhere in this thread to actually use Linux to connect to the camera over RNDIS to the camera if nothing else works when it is in RNDIS mode.

On the positive side, the NK.bin (kernel image) in the latest 2.1.0 version still includes RNDIS support:
#define CE_MODULES_RNDISFN 1

[oddy992]

Ok so looking in my device manager with the camera attached I get a USB video device with the following USB VID/PID:

VID:09CB PID:1007

*Edit* : "UVC and MSD = 09cb:1007" so I should be able to use UVC to send the fif file over to the camera.

No exclamation mark. .... so I might actually be able to send commands ...

Mike, how dangerous is the set temp RNDIS command? whats the danger of bricking it? .... a 80*60 E4 is better than no E4 ...

[oddy992]

Ok I'm in ...

RNDIS in temporary mode and I've telnetted to the camera.

Went to see if I could get the conf.cfc and have it but I'm getting errors trying to decrypt it using fool.exe. Error is:

Tail part 2 invalid

Any thoughts ... I guess they've changed the enc key?

[oddy992]

Also, just my 2 cents but the changes to the FPGA code in this version may be due to the new image mode available (overlay) and the extra processing required by the FPGA to provide this. A neat new feature is being able to change the alignment distance from the main menu too, you don't need to go into settings etc.

[realdoc]

Any thoughts ... I guess they've changed the enc key?

Can you use FileZilla (or TIConfig) to create a FTP backup from the camera. FTP credentials should still be root/3vlig, as far as I can see. Then, put the zip online so we can have a look at it.

That zip should then also include your conf.cfc file, but you can always also post it seperately.

Thanks!!

BTW, Which hardware version do you have? 1.2L?

[oddy992]

BTW, Which hardware version do you have? 1.2L?

Yeah 1.2L, I'll see about doing a backup & posting. Connects over Filezilla so shouldn't be a problem, just at work at the moment so having to fit it in around my day job 

[oddy992]

  bugger, just looking through the files in the FlashBFS directory and the earlier comment about replacing them with Lepton cores might not be off the mark ....

next to fpga.bin there is a file named "fpga_lepton.bin"

Also I have noticed that the imager "takes a moment" when starting up from cold, not something I noticed on the E4 I had to play with some months ago.

Hardware version 1.2L .... Lepton core, no more 320*240 

[oddy992]

Where is Ftool.exe from? If it is Flir, have they released an update?

[realdoc]

bugger, just looking through the files in the FlashBFS directory and the earlier comment about replacing them with Lepton cores might not be off the mark ....

next to fpga.bin there is a file named "fpga_lepton.bin"

Also I have noticed that the imager "takes a moment" when starting up from cold, not something I noticed on the E4 I had to play with some months ago.

Hardware version 1.2L .... Lepton core, no more 320*240 

What makes you so sure it's a Lepton core? Only the small wait in the new firmware and the fact that there is an extra binfile, that might well go unused? When I went through my rsc file on the MSD of myt broken 1.2L that I was able to view on Linux, I saw it using a something called Pollux and the FPGA release version and date matched the fpga.bin data, not the fpga_lepton.bin data.

[Fraser]

Suggest the presence of the LEPTON Core fpga file is not proof of a LEPTON core in the E4. This was noted previously in the 2.1.0 firmware release on FLIRs site. The view was that now the FLIR ONE is about to be released this could just be a common firmware that will also support LEPTON core cameras. There is no evidence yet that FLIR would fit the LEPTON into only the E4. What about the E5, and E6 ? these could not use the low resolution LEPTON, so FLIR would effectively have to tool up for what would be a unique camera....the "E4 LEPTON". Keep calm and carry on 

[Fraser]

If you really want to scare yourself, do some research on the FLIR manufactured Autoliv thermal cameras that are deployed in some Audi and BMW cars. Mike has an sample that he was looking at and has posted a thread on here about the internals. From what I have read, these cameras are 320x240 30 or 60 fps ..... and ITAR export controls enforced some pretty nasty lockdowns on the platform. The camera is married to the host cars computer and will not operate independently of its host. Some earlier models could be fooled into 'thinking' they were still in the correct car but later versions are smarter, and from what I have seen, no one has managed to hack one to get it to wake up. Now the killer blow.....there are reports that if you try to 'probe' the camera module in an attempt to hack it, it basically kills itself    Imagine if FLIR used the knowledge that they already have on hacking defences and applied it to the Ex series.....you are fine until you try to hack it and then it will be a non warranty RTB for a rebuild if the camera locks down. Such measures are common in the world of hardware encryptors. There is no evidence that FLIR are doing this on anything but the high resolution car cameras but if the incentive is there, they might.

[bookaboo]

If there were significant hardware differences (i.e. a totally different sensor) would the Flir part number not need to be changed in line with ISO9001. Or is the declaration of a hardware version sufficient?

I once worked on a project where the customer sold most of the units through Farnell, at one point there were 3 different part numbers for what was essentially the same piece of equipment, just a radio module was changed. No one would ever have been able to tell without a complete tear down but this customer did stuff totally by the book and his ISO consultant insisted we created new part numbers each time.

[mikeselectricstuff]

Now the killer blow.....there are reports that if you try to 'probe' the camera module in an attempt to hack it, it basically kills itself 

I'd take that with a huge pinch pf salt. Could be it sets an eeprom flag, but in practice this sort of thing just causes headaches for the supplier as it's hard to prove anything to the extent needed to be able to deny warranty replacement.
 
I think Lepton is too new to see it as a replacement sensor in an established product line - Flir have yet to ship anything with a Lepton, and I would think they'd start with new product lines before risking anything that new on an established line.
My guess is they may even discontinue the E4 and replace with a new Lepton based unit.

[Fraser]

Thanks Mike, it did sound an extreme countermeasure but in the car industry anti tamper seems to be a more common element of designs these days. Have you had any time to look at the Autoliv camera recently ? I was offered one at a decent price but chickened out as I do not have the required skillset to hack it....I bought a FLIR SC3000 cooled camera instead 

[oddy992]

Sorry, was just voicing my fears / concerns not confirming it has got a Lepton core. Sounds reasonable logic (above) so I'll crack on and keep my fingers crossed. I guess its still a bit up in the air and the only proof will be opening it up or at least decrypting the cfc ...