Flir E4 Thermal imaging camera teardown

[Marty1920]

@Bud thanks a lot for your replies and all the hard work you put into this!

I confirmed that the thermal resolution indeed is 320x240. Awesome!

Unfortunately I wasn't able to get into an alignment menu in which I could manually change the xpan, so I did this using telnet (rset .image.fusion.xpanVal -10.0) until I found a value that worked. However that value isn't stored, so when the camera recalibrates, the alignment is off again. So I edited calib.rsc, and updated .calib.visual.fusion.leExFOL7.C1X double to the value I empirically found. Recalculated the CRC and uploaded it.

Seems to work But a menu would definitely be easier I'll go look for the manual!

Anyway, I'm not sure if is this is just the camera in combination with the focus problem. But I find the images a bit smeared and blurry. Since I have no reference so far, I'd like this know if this is more or less what to expect.

In total darkness, with cat

View of the room, with lights on, thermal image only, no cat

Image of corner of monitor and phone, all within 2 ft

[Bud]

Unfortunately I wasn't able to get into an alignment menu in which I could manually change the xpan,

I cannot recall anyone mentioning x offset issue. Perhaps your camera was dropped and physical cameras alignment shifted 
Impact may also have caused thermal camera focus issues. You can scan this thread for the lens adjustment tool info or perhaps just search 3D print sites for such tool for  E4 and 3D print one.

[Marty1920]

Thanks! I'll try to restore the camera to its original settings and see if the offset is still wrong.

Because of the sheer amount of information here, scattered all across the boards, I thought it would be ideal to have a tool that would automate all these processes. Eliminating the human-factor-error I've created a TypeScript version of the various tools on this platform here:

https://github.com/MarByteBeep/flirmod

So far it's able to automatically find a WIFI enabled Flir E4 on a local network, connect to it through FTP, download all the files to a backup folder, verify critical files are downloaded, decrypy/encrypt cfc/cfg files.

Next will be automatically modding the cfc file and use telnet to shutdown processes, replace the dll etc.

Feel free to take a look and let me know what you think!

[Bud]

Automation is great but you'd have to have good error handling. People who will use automation will be mostly inexperienced ones. "Error in line 47" type of messages will not do them any good. You will become the man to run HelpDesk for that automation issues. Sometime things do not work for some reason, they just do not. So try to foresee what may happen at each step and handle those situations.

[Marty1920]

Very true, I'll write this with that in mind! I'm checking and double checking every step and only continue when all signs are green

I do have a question though; do you happen to know what's allowed for sharing? Currently the code only contains a username and password, but am I for instance allowed to share the dlls and/or unencrypted config files? Were you guys ever visited by angry lawyers?

[Bud]

There is no "allowed" or "disallowed". But - where did you get the files from to liberate your camera?    Does this answer your question.

[Marty1920]

Got it! I'll give it a thought on what to do. Meanwhile I added a simple CLI option menu in which a user can quickly create backup. Up next, the actual modding

[Marty1920]

Does anyone still have a list of the commands which can be used to control the E4 via serial/telnet? Either my google-fu is weak or Flir deleted the relevant pdfs.

6 years later I am actually interested in that as well I know these

Code: [Select]

stopapp   
rset
rls

aside from the standard Win CE command like DIR/TIME etc.

But are there any others? For instance I'd like to know if I can enable/disable auto calibration through Telnet.

[Bud]

It has been a few years and I cant recall details but I think you change the parameters using rset command. Not all of them can be changed though and not all of them retain the change after a reboot.

[Marty1920]

I've some questions with regards to the CFC file. As far as I understand the CFC contains a CFG file which is just a regular text file (\r\n delimited) with at the bottom three lines:

# ID 123456789
# CRC03 1234abcd

(the last one being an empty line).

The ID represents your serial number. The CRC03 is calculated over the whole CFG, excluding the CRC line itself, using a modified CRMD160 algoritm. The source is available on this forum: https://www.eevblog.com/forum/thermal-imaging/flir-e4-thermal-imaging-camera-teardown/msg403480/#msg403480

First question:
in my test case I was able to perfectly recreate the CRC03 of my original unmodded CFC file, so is this CRMD160 algorithm seemingly works fine. Or were there some issues with it, that forced you to modify the common_dll.dll to skip the CRC03 check?

Now to convert that CFG back into a CFC file, you need to run the CFG file (including the ID and calculated CRC) through the RC4 encryption. And append to that two things: a signature and a tail.

The tail (16 bytes) contains a marker (CFC\0) and some seemingly hardcoded values and the encrypted size of the CFG.

Second question:
But my question is, what's inside the 128 byte signature? I do know that it probably contains data which is encrypted using FLIR's private key, hence it's impossible for us to create. But is the content of the signature static? Meaning it doesn't matter the content of the encrypted CFG file? Or does it change when the CFG changes? In the former case one could simply copy the signature from the original unmodded CFC file and apply it on a newly generated CFC file, but that's probably not possible... hence the reason to alter the common_dll.dll, to simply bypass the signature check?

[Bud]

My recollection is CRC03 was patched before people figured out what algorithm it was using, so it was patched to get it out of the way.
The digital signature protects  the integrity of the entire file. First a hash function is applied to the file, then the calculated hash is encrypted using the manufacturer's RSA private key, resulting in the signature which is appended to the file. Therefore if you change a single bit in the file, the hash will change and the signature will change, making it impossible to reuse same signature for two different files no matter how small the change was.

[Marty1920]

Got it, hence the only option is to patch that common_dll.dll, to skip that signature check altogether. I think I fully understand now. Thanks!

[Marty1920]

@Bud got a few more questions for you, hope you'll be able to help me out with them. I worked a bit more on the automated patching tool and so far I'm able to automatically patch the basic, advanced and christmas patches. However not everything seems to work as expected.

Basic
According to the toolbar-config.xml there should be a

<ToolBar name="measure_five_spots"/>

option, however that one seems to be absent from the menu. I see 7 options in the measurement menu, but none of them is the 5 spots option. Any ideas?

Advanced
So far seems to work! I did get some additional recording options and a medical color palette. Need more testing to see if it's working properly.

Christmas
I followed your steps and added the

.caps.config.ui.measure.presetException text "userPresets"

to the CFG. The options appeared in the main menu, however when selecting them I only see a black screen with an overlay menu. Also, the measurement menu suddenly only has three options. I also tried adding <Toolbar name="measure_user_1"/> to toolbar-config.xml, but that didn't do much either. Just like with the basic patch, somehow not all toolbare options seem to appear in the measurement menu. Any thoughts?

The patches are all located here, feel free to take a look at it, perhaps I missed some files?

https://github.com/MarByteBeep/flirmod/tree/main/data/patches

All files should be identical to the patches on this forum. I only added a dependencies.json for each patch in which I define which patches need to be applied first. This json will obviously not be synced to the camera.

How the tool applies an update?
* collect all files for the patch (+its dependencies)
* verify all RSC files for correct CRCs
* rebuild the conf.cfc based on the conf.cfg and verify that.
* automatically connect through ftp to the camera
* only if there is no error, upload all patched files to the camera
* reboot the camera (although it sometimes requires a "hard" battery-remove reset for changes to become available)

TODO:
* automatically mod the common_dll.dll, but I'm a bit hesistant on reverting back to my original dll to test that, as I don't want to brick the camera
* if user made backup, verify that backup is original (ie., check for unmodded dll and cfc containing signature), restore camera back to factory backup so user can sell it.

That's it for now. Hopefully you can shed some light on the measurement menu problems.

[Bud]

Man, you asking me what was 7 years ago, gee... how I can possibly remember 
What version are you trying to upgrade? I believe the last one I worked on was 3.12.0
If you enable user presets (I guess they by installing the Christmas Pack), I remember they change measurement menu, so that one is expected.

[Bud]

Switch the camera to digital camera view mode and press the 'Down' button for 10 sec, the screen should show the full package firmware version number which the menu files were made for.

[Marty1920]

Haha sorry, I didn't know it's been so long. I'm amazed by that you even remember so much. The menu (holding down 10 seconds and then press back button) you are referring to the credits screen: "This camera has enhanced capabilities. Unlocked and brought to you by yours truly )" etc.

As far as I can see that doesn't show any version information. But I'm on 3.16.0. Would this give you enough info? I can check out the qml files within the rcc to see if I can find the screen you are referring to.

Thanks for all your help, even after 7 years

[Marty1920]

I think I got it, it's pressing right in the camera information menu for a few seconds:

IRDM: 0.0.1.0
POLLUX: 0.1.0.0
POLLUX_FPGA: 8.7.6.0
(...)
appkit: 3.1.14
osimgkit: 23.1.12
prodkit: 0
AppCore: 34.0.0.1
AppServices: 34.0.0.1
Bootloader: 23.1.16.0
RestMoon: 34.0.0.1
WinCE: 6.0.0.0
appcore_dll: 1.22.1.1
common_dll: 1.22.1.1
facetcore: 34.0.0.1
facetcore_qml: 34.0.0.1
fvd: 23.0.94.0

[Marty1920]

Also, since the E4 has been discontinued and the last firmware ever will be 3.16.0; are you okay with me axing the boot popup?

[Bud]

You can do it on your camera but do not do it to the published files. This will put unsuspecting buyers at risk, as there will be disohnest people making business out of it. Applying official firmware updates to modified cameras is going to brick them, secondary buyers must know they bought unsupported modified device.

[Marty1920]

Valid points. Once a camera is bricked, will it still start its Telnet and FTP services? Provided of course that someone didn't wipe the entire camera

[Bud]

It should, providing the camera is in powered off state and it was configured into RNDIS mode. If it is not in RNDIS mode it should come up as a USB Camera mode, from which you switch it to RNDIS and then access via Telnet/FTP.