Flir E4 Thermal imaging camera teardown

[Rainer]

I had tested it under your guidance: you have to kill the AppServices first. Else you get a message "appcore is in use" or somthing like that.

[muvideo]

Hello
3D parts for E4:

I contacted lunevalley3d for a quote on the parts, their price is
very good but they told me that now print exclusively in PVA edit: see below, and
will not print in abs.
I've read that some forum members had the parts printed by lunevalley,
what kind of plastic did they use?

I dont like PVA since afaik it's unstable and moisture sensitive,
anyone knows a good 3d printing service with decent prices
that prints in abs?

Thanks.

Edit: it was a misunderstanding, they meant PLA and not PVA, that's
better.

[tomas123]

I had tested it under your guidance: you have to kill the AppServices first. Else you get a message "appcore is in use" or somthing like that.

ok, see my post here

Code: [Select]

ps -k appcore
ps -k AppServices


and your log

\>ps -k appcore
Failed to terminate process 0x4D20002 (170)

\>ps -k AppServices
Successfully terminated process 0x76E0002

\>ps -k Resmon
Successfully terminated process 0x79A0002

A minor change. I wrote about a untested concept...

[ds]

@ Rainer

Maybe you want to give this a try:

The attached ZIP file contains a modified configuration file for
"FlashFS\system\appcore.d\config.d\conf.cfc". What has been
modified:

- Serial Number of Rainer's E4 (of course)
- All settings adjusted according to the "E4->E8" hack
- "CRC03" adjusted
- Hash adjusted
- "Scrambled" using the SUID of Rainer's E4 (I won't call this XOR stuff encryption)

I don't know if this will work or if this will break anything but so far it is what
I think might be the new way to protect the configuration.

If you want to try it out please make a backup copy of your old conf.cfc and
replace it with the new one from the ZIP file. Cold-start your E4 and see what
happens.

Again, please note that I can't give you a guarantee what will happen.

[stefbeer]

@Rainer: If you really want to try out the .cfc-file from ds, please backup all logs you can find after booting with the new .cfc-file. Especially the prod.log from the /Temp directory.

@ds: Are you willing to share some background information on how you did that? I thought the CRC03 checksum hasn't been "cracked" yet?


EDIT: @Rainer: The config file from the zip file needs to be renamed, it is still called "conf.cfg"!!!

[ds]

@stefbeer

Those Windows CE executables are not that hard to "read" if you have some
experience in reverse engineering.

I think I understand how the "CRC03" is calculated and how the configuration
file is protected, if I apply this knowledge to the three plain, decoded "conf.cfc"
files of Rainer's E4 I get the same "CRC03" and also the identical protected
configuration file.

However if changing the configuration is enough to enable the higher resolution
is something else, maybe there are additional protection mechanisms. The modified
configuration also contains changes like enabling "Zoom", the effect of this should
be verified too.

Before releasing more details I would like to have some confirmation that it
actually works, otherwise it would confuse more than it helps.

[stefbeer]

@ds: That's the experience I'm missing. Of course, I understand that. Thank you for that insight!

I tried to decode your generated config file with the php script from tomas123: https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg401244/#msg401244
But I noticed some issues with the file. I'm not sure if it's the php script not working correctly or me doing something wrong. I just thought I'd share my findings.

At the end of line 6 there's a $ instead of a "
On lines 49 and 63 is a "ETX" (end of text) control character before the LF (and no CR).
On line 111 is a "VT" (vertical tab) control character before the LF (and also no CR).
Line 124 just seems to be junk.

Can you prove / disprove this?

EDIT: My fault, I didn't generate the correct key, thus the decoding didn't work properly. See: https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg402854/#msg402854

[tomas123]

The modified
configuration also contains changes like enabling "Zoom", the effect of this should
be verified too.

great idea to verify the crc03
the test is without risk

We know, that 1.21 boots successful without conf.cfc in native mode (80x60 without msx)

first i put the e8cfg in the folder, reset to factory-> no changes
next i delete the old conf.cfc-file, reset to factory->no changes

Code: [Select]

.caps.config: (3)
rw--r--------- 0 root   root   <e> image                           
r---r---r----- 0 root   root   <a> name                          ""    // empty configuration name!!!

.caps.config.image.settings: (4)
r---r--------- 0 root   root   <i> IRheight                      60 //no high res mode
r---r--------- 0 root   root   <i> IRwidth                       80


@ Rainer
check the loaded configuration with

Code: [Select]

rls -rl .caps.config

[mikeselectricstuff]

However if changing the configuration is enough to enable the higher resolution
is something else, maybe there are additional protection mechanisms.

Remember that one early discovery on the original hack was that it appears to use the eeprom to communicate the resolution, either to something early in the boot process, or possibly the FPGA itself.  The exact mechanism, or reason for doing it wasn't really explored.
An I2C bus analysis of the new FW might be interesting

[stefbeer]

your mistake:
You must generate the key.bin with a the original conf.crc file from E4!!
The edited config from user ds has to many differences to get a valid key...

You're right, that was my bad. After adapting the template file the decoded file looks much better. Except the "junk" from line 124 is still there. But that might be because of the hash or scrambling.
I should stay out of territories I'm not familiar with... Sorry if I caused any confusion.

[ds]

@tomas123

The tail of the protected configuration file contains the original size of the plain
configuration. The other values are fixed in the few samples I have seen, they
are some kind of flag to indicate for example how the XOR stream is generated.

Please note that there is also an additional MD5 hash with a few "secret" bytes
to further protect the configuration.

Regarding the XOR keystream: I did not yet try the tools posted here but use the
way how it is done in the firmware, basically the SUID determines the XOR keystream.

[Rainer]

How can i do this i2c-exploration? Because, i had scanned the whole bus and posted all data i found.

To the patched file: Is there any trouble with the file? you said, there are wrong characters in it?

There are many conf.crc in my TIC:
FlashFS\system\ui.d\config.d\  352 Byte
FlashFS\system\services.d\config.d\ 352 Byte
FlashFS\system\appcore.d\config.d\ 6,18 KByte

Which on i have to change?

[stefbeer]

To the patched file: Is there any trouble with the file? you said, there are wrong characters in it?

That was my own fault, I didn't generate the correct key for decryption. That's why my decrypted file showed some errors.

There are many conf.crc in my TIC:
FlashFS\system\ui.d\config.d\  352 Byte
FlashFS\system\services.d\config.d\ 352 Byte
FlashFS\system\appcore.d\config.d\ 6,18 KByte

Which on i have to change?

The original hack only changed (or added, to be more correct) a file in flashfs/system/appcore.d/config.d/. I'd say that's the one.

[Rainer]

I´m happy now, and @Taucher: You can modify your signature now

Get an impression:

The humidy-option is now working:


Two new Picture-Modes(PIP)


New Measurement spotting(Menue was already in Beta 3, but did not work. Now it does work)


New Temp-Scaling(same as in the Beta3 i patched before)


New Color palettes(Red above, Condensation, Insulation and Interval are new since Beta 3)


New zoom option:


And the Best at the end:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
Thermal resolution:


The txt-Files shows the -caps.config-Parameters.
alter_Zustand ist the old setting with Beta 3, but without the new config
neuer_Zustand is the new settings after this patch


All Options working absolutely fine
I´m very happy now. How can i help to patch all the other 1.21-TIC´s to say "Thank you" at all the supporters here?

[Fraser]

Great work 

Hopefully this will pull the rug from under the guys profiteering on 1.19.8 E4's on e*ay.

[Taucher]

I´m happy now, and @Taucher: You can modify your signature now

Congrats! 

[jakamil]

Quick question. It is possible to use the hack on camera - Flir E5?
Thank you for your response.

[Rainer]

It should be the same hardware in the E5. so why not.

But there are some difficulties with the firmware to clear. This Patch for the 1.21-Firmware is a special option for me atm.

[jakamil]

verze firmware je 1.19.8

It should be the same hardware in the E5. so why not.

But there are some difficulties with the firmware to clear. This Patch for the 1.21-Firmware is a special option for me atm.

Quick question. It is possible to use the hack on camera - Flir E5?
Thank you for your response.
[/quote]

[OrBy]

Rainer - lets see a pic of the non-MSX output! Show that upgraded puppy off.

[jakamil]

For sure the camera before buying it. I ask again.
Quick question. It is possible to use the hack (ADDMENU-BETA3) on camera - Flir E5? firmware version is 1.19.8
Thank you for your response.

[tom66]

Nice!! So how long has this taken to hack? From release of firmware about a month ago to being beaten?
How long til Flir release 1.22.0 with more countermeasures

[ds]

@Rainer

Great to hear that my configuration file worked for you !
I am surprised that even the resolution change worked and they
did not protect this harder.

I would like to do one or two more tests, could a user
with an E4 and the new firmware post the configuration
file "FlashFS\system\appcore.d\config.d\conf.cfc" here ?
(Please not more than two, this should be enough for
further testing).

I am thinking of how to proceed, either use the SUID (can
be displayed by suid.exe and also by other means) or try
to get the SUID from the "conf.cfc" file directly (this is possible
as long as the first few bytes of the configuration are the same
as it is right now).

The first method is more general, the second one is more convenient.
Probably I will take the second one if further tests work too, for the
next change by FLIR to defeat this most certainly the first method will
not work either.

[hgg]

Very Nice !     

[Rainer]

Nobody said to me, i have to upgrade to a 1.22-FW. So for me, it´s fine to have a hacked 1.21 and a 1.22 didn´t have response to me...

But the way is shown and the next hack will be possible anyways