Flir E4 Thermal imaging camera teardown

[OrBy]

Last thing: i shot a thermal foto with full 320x240 , but lost the MSX-Option

Well ain't that a wee little kick in the junk? 

Mind posting a shot?

[tomas123]

Last thing: i shot a thermal foto with full 320x240 , but lost the MSX-Option

It is hardly believable that is was so simple
please post an image

in the next step we can edit your startup script applaunch.dat
please wait patiently until I saw an image

unfortunately i2c.exe dumps only the first 256 Byte from EEPROM

Code: [Select]

$ cat i2c.txt | gawk '{for(i=1; i <=NF; i=i+1) {tmp="00"$(i);tmp=sprintf ("%s",substr(tmp,length(tmp)-1)); printf " %s", tmp }}'| xxd -r -p | hexdump -C -v
00000000  ca 54 31 39 38 32 38 33  00 00 00 32 30 31 33 36  |.T198283...20136|
00000010  30 31 36 00 00 31 31 00  00 00 00 00 00 00 00 ed  |016..11.........|
00000020  9c ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000040  ff 0a f4 3c 00 00 00 00  00 00 00 00 00 00 00 00  |...<............|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 46  |...............F|
00000060  f4 54 31 39 38 33 30 34  00 00 00 36 33 38 31 33  |.T198304...63813|
00000070  38 30 38 00 00 30 31 00  00 ff ff ff ff ff ff f2  |808..01.........|
00000080  9f 50 00 3c 00 00 01 00  00 00 00 00 00 00 00 8c  |.P.<............|
00000090  01 ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000000b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
000000c0  00 46 4c 49 52 20 45 34  00 00 00 00 00 00 00 00  |.FLIR E4........|
000000d0  00 00 00 00 00 36 33 39  30 31 2d 30 31 30 31 00  |.....63901-0101.|
000000e0  00 00 00 00 00 36 33 39  31 34 37 35 32 00 00 32  |.....63914752..2|
000000f0  30 31 34 2d 30 32 2d 31  33 00 00 30 31 00 00     |014-02-13..01..|


but we see the changes in format with a I2C dump from FW 1.19

Code: [Select]

>cat 1.txt | awk "{for(i=1; i <=NF; i=i+1) {tmp=sprintf (\"%s \",\"0x\"$(i)); printf \"%c\", strtonum(tmp) }}" | hexdump -n
00000000: 40 01 F0 00 00 01 00 00 - 00 00 00 00 00 00 30 03 |@             0 |
00000010: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF |                |
00000020: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF |                |
00000030: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF 00 |                |
00000040: 46 4C 49 52 20 45 34 00 - 00 00 00 00 00 00 00 00 |FLIR E4         |
00000050: 00 00 00 00 36 33 39 30 - 31 02 0D 30 31 30 31 00 |    63901  0101 |
00000060: 00 00 00 00 00 36 33 39 - 30 30 30 30 30 00 00 32 |     6390xxxx  2|
00000070: 30 31 33 2D 31 31 2D 30 - 30 00 00 30 31 00 00 E1 |013-11-xx  01   |
00000080: D4 54 31 39 38 32 38 33 - 00 00 00 31 39 39 35 30 | T198283   1995x|
00000090: 30 30 30 00 00 30 39 00 - 00 00 00 00 00 00 00 F9 |xxx  09         |
000000a0: AD FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF |                |
000000b0: FF FF FF FF FF FF FF FF - FF FF FF FF FF FF FF FF |                |
000000c0: FF 0B 15 7D 00 00 00 00 - 00 00 00 00 00 00 00 00 |   }            |
000000d0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 88 |                |
000000e0: 15 54 31 39 38 33 30 34 - 00 00 00 36 33 38 30 30 | T198304   6380x|
000000f0: 30 30 30 00 00 30 31 00 - 00 FF FF FF FF FF FF F9 |xxx  01         |

[mikeselectricstuff]

unfortunately i2c.exe dumps only the first 256 Byte from EEPROM

From memory I think i2c.exe doesn't know about eeproms specifically, so you need to use a write+read operation to write the address first before reading the data - if you just do a read it may be reading a random page.
I don't recall the syntax but it's fairly obvious from the /? help

[tomas123]

if you just do a read it may be reading a random page.

Oops! 

if I compare the output ... then you have right, its only a offset

@Rainer
after activating the high res mode there are some new files in folder
/Temp
/Temp/appcore.d
please post this files

did you have a folder \mod\servicemode\appcore.d\ ??



first check of your rls
differences to FW 1.19

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

.caps.config.image.targetNoise: (2)
r---r--------- 0 root   root   <b> enabled                    false
r---r--------- 0 root   root   <i> targetNoiseMk                  0 //where is the noise generator?

.dump: (6)
rw--r---r----- 0 root   root   <b> commit                     false
rw--r---r----- 0 root   root   <a> file            "\mod\servicemode\appcore.d\factory.d" //a new folder

.registry.system: (2)
rw-dr---r----- 0 registry factory <a> usbmode                "UVC_MSD"  // RNDIS

.version: (8)
r---r---r----- 0 root   root   <a> SUID            "2A4BD5020080241B"  // this is a new number
did you saved this file before you gone to the service mode?
odd

PS: If you are right with successful activated resolution 320x240 (send an image):
Copy the e8.cfg to folder "FlashFS/system/service/appcore.d"
and then try to start the highres mode. (don't delete conf.cfg in this folder)
...check msx function


My guess is a bad news:

you have no valid configuration file,
your resolution is furthermore 80x60,
but you killed the noise generator and the image looks better

Code: [Select]

2014-03-04 20:38:40 ERROR: No Configuration name found. Bad camera serial number ??[64]
2014-03-04 20:38:40 Configuration name: ""
good news: you started binaries from an old version -> let's wait of a hack from Taucher

step-by-step (please send the requested files)

 

[Rainer]

Now i'm fully confused?¿

Have a look to my pictures in FLIR_BACKUP. The Thermal-Fotos are already in 320x240? Did the TIC store the 80x60 in a higher resolution? Or is this a side-effect of the rotating-display?

There are some newer files. I will post them later today(i'm at work now).

EDIT:

I did all the things in the way you instructed me. So i do the rls right before copy and run the prodapp.exe. Today afternoon, i want to make a second rls-textfile after prodapp and check the resolution in the TIC.

[mrflibble]

Now i'm fully confused?

Perfectly normal. It's the human condition.

The Thermal-Fotos are already in 320x240? Did the TIC store the 80x60 in a higher resolution?

Also perfectly normal. A standard E4 will also save the image at 320x240 resolution. Even when only 80x60 thermal pixels are available. This behavior is probably described somewhere in the manual that I didn't read.

[stefbeer]

The saved .jpg file has always a resolution of 320 x 240 pixels (at least with the Ex-series). Crucial is the resolution of the embedded thermal image.

The easiest way to tell the real thermal resolution: Turn your TIC on, open the gallery, open a saved image, open the menu and choose "Info" (english: "Information"). There should be a line that says "Infrarotauflösung" (english: "Thermal resolution"). Please tell us what it says

[Fraser]

The issue of how the E4 generates its 80x60 thermal image for display at 320x240 was disscussed way back in this thread and is likely well buried by now.

The Ex series cameras are calibrated at 320x240 with all microbolometer pixels active. The 320x240 pixel microbolometer output is then processed by the platforms chipset to produce the specific models resolution. In the case of the E4, it is believed that the chipset carries out a 4x4 pixel clustering and averaging function, effectively using 16 true pixels to produce 1 'E4 pixel' for display on the camera. This technique would also make it possible to use microbolometers that have many dead pixels as the 4x4 pixel averaging could use the remaining good piixels in a 'cluster' to produce a meaningful output. From what I have seen, most E4 microbolometers meet the manufactureers 99.8% functional pixels spec so this is less of an issue for us anyway.

The Ex series will always produce a 320x240 output image no matter what thermal resolution it is producing after pixels clustering.

Why didn't FLIR just use the central 80x60 pixels of the Microbolometer ? Well that makes life difficult on the hardware front. It is very likely that the same thermal lens is used on all models. As such, the lenses illumination of the microbolometer remains the same with all 320x240 pixels 'in play'. If only the central 80x60 pixels were used, it would produce an electronic zoom like function and the resulting Field of View for the camera would change. All Ex series cameras have the same field of view and FLIR realised that processing the 320x240 thermal image to produce lower resolution images eneabled them to use a single lens rather than different lenses for each model. For FLIR it was also offereing the benefit of a single hardware platform that could be configured to any specification, purely through software with only labelling differences. A pretty good business model for the 'bean counters'.

With the arrival of the 'FLIR One' and its new imaging chip, future FLIR low resolution cameras may sadly use the same low resolution chip, making an upgrade no longer viable due to hardware limitations rather than software lock-downs. The E4 cameras are likely to be the best 'bang per buck' cameras to have ever been produced, as a direct result of the common hardware platform and ease of upgrade. I doubt we will see such a 'mistake' again in future models. 

[Rainer]

1. : I checked the old pictures  (80x60)

2. : I delete them, made a hard reset(with battery) and after that, i delete the prodapp in the FlashFS/system
3. : I copied the prodapp in FlashBFS/system,
4. : I call rls to make the rls1.txt
5.: I start the prodapp in FlasBFS ->ps says prodapp is running with 18 threads
6.: I call rls to make the rls2.txt
7.: I made a thermal foto, but is only in 80x60
8.: I check the sensor resolution with telnet ->80x60

------------------------------------------------------------------------
Now i go on to the next level

Welcome to the Windows CE Telnet Service on IRCAM4752

Code: [Select]

FLIR Command Line Interpreter
Version 0.4.3 running on WinCE 6.0

\>set PATH=\windows;\FlashBFS\system\;
Bad command or filename

\>set PATH=\windows;\FlashBFS\system\;
Bad command or filename

\>set PATH=\windows;
\>set PATH=\windows;\FlashBFS\system\;

\>rset .watchdog.enable false
rset: .watchdog.enable: bad data

\>rset .watchdog.enable false
rset: .watchdog.enable: bad data

\>rset .services.log.active false

\>ps -k uicore
\>ps -k Gui
\>ps -k Prod
\>ps -k prod
\>ps -k MediaServer
\>ps -k appcore
Failed to terminate process 0x4D20002 (170)

\>ps -k AppServices
Successfully terminated process 0x76E0002

\>ps -k Resmon
Successfully terminated process 0x79A0002

\>ps -k Bit
\>ps -k syslog
\>ps -k Cam
\>ps -k cam
\>ps -k geni
\>ps -k dig
\>ps -k Dig
\>ps -k watch
\>ps -k Watch
\>ps -k RTP
\>ps -k fwa
\>ps -k progress
\>ps -k Med
\>ps -k appcore

\>start appcore19.exe

\>ps
Process NK.EXE          (64 threads), id 0x00400002, loaded at 0x80100000
Process udevice.exe     ( 2 threads), id 0x01510002, loaded at 0x00010000
Process udevice.exe     ( 1 threads), id 0x015E0002, loaded at 0x00010000
Process udevice.exe     ( 1 threads), id 0x01F20002, loaded at 0x00010000
Process udevice.exe     ( 1 threads), id 0x03230002, loaded at 0x00010000
Process servicesd.exe   (14 threads), id 0x03820002, loaded at 0x00010000
Process ChargeApp.exe   ( 1 threads), id 0x046E0002, loaded at 0x00010000
Process cmd.exe         ( 1 threads), id 0x04C50002, loaded at 0x00010000
Process CMD.EXE         ( 1 threads), id 0x08EF002E, loaded at 0x00010000
Process appcore19.exe   (35 threads), id 0x05050036, loaded at 0x00010000
Process AppServices.exe (15 threads), id 0x04DF0166, loaded at 0x00010000
Process Resmon.exe      (14 threads), id 0x0778000A, loaded at 0x00010000
Process ps.EXE          ( 1 threads), id 0x082E019A, loaded at 0x00010000

\>start prodapp

\>ps
Process NK.EXE          (64 threads), id 0x00400002, loaded at 0x80100000
Process udevice.exe     ( 2 threads), id 0x01510002, loaded at 0x00010000
Process udevice.exe     ( 1 threads), id 0x015E0002, loaded at 0x00010000
Process udevice.exe     ( 1 threads), id 0x01F20002, loaded at 0x00010000
Process udevice.exe     ( 1 threads), id 0x03230002, loaded at 0x00010000
Process servicesd.exe   (14 threads), id 0x03820002, loaded at 0x00010000
Process ChargeApp.exe   ( 1 threads), id 0x046E0002, loaded at 0x00010000
Process cmd.exe         ( 1 threads), id 0x04C50002, loaded at 0x00010000
Process CMD.EXE         ( 1 threads), id 0x08EF002E, loaded at 0x00010000
Process appcore19.exe   (36 threads), id 0x05050036, loaded at 0x00010000
Process AppServices.exe (15 threads), id 0x04DF0166, loaded at 0x00010000
Process Resmon.exe      (14 threads), id 0x0778000A, loaded at 0x00010000
Process prodapp.EXE     (18 threads), id 0x096802F6, loaded at 0x00010000
Process ps.EXE          ( 1 threads), id 0x096C0302, loaded at 0x00010000

last thing: i start prodapp and set the prodapp-parameter

Code: [Select]

\>rset prod.preparation.command restartHighRes

\>rls -l .caps.config.image.settings
.caps.config.image.settings: (4)
r---r--------- 0 root   root   <i> IRheight                      60
r---r--------- 0 root   root   <i> IRwidth                       80
r---r--------- 0 root   root   <b> allowForcedCase            false
r---r--------- 0 root   root   <b> enabled                     true
------------------------------------------------------------------------------------------

Oops, i copied the e8.cfg in the wrong folder. Next try:

Code: [Select]

Welcome to the Windows CE Telnet Service on IRCAM4752
FLIR Command Line Interpreter
Version 0.4.3 running on WinCE 6.0

\>set PATH=\windows;\FlashBFS\system\;
Bad command or filename
\>set PATH=\windows;\FlashBFS\system\;
Bad command or filename

\>set PATH=\windows;

\>set PATH=\windows;\FlashBFS\system\;

\>rset .watchdog.enable false
rset: .watchdog.enable: bad data

\>rset .watchdog.enable FALSE
rset: .watchdog.enable: bad data

\>rset .services.log.active false

\>ps -k uicore
\>ps -k Gui
\>ps -k Prod
\>ps -k prod
\>ps -k MediaServer
\>ps -k appcore
Failed to terminate process 0x4D20002 (170)
\>ps -k AppServices
Successfully terminated process 0x71C000A
\>ps -k appcore
\>ps -k Resmon
Successfully terminated process 0x75B000A
\>ps -k Bit
\>ps -k syslog
\>ps -k Cam
\>ps -k cam
\>ps -k geni
\>ps -k watch
\>ps -k Watch
\>ps -k dig
\>ps -k Dig
\>ps -k RTP
\>ps -k fwa
\>ps -k progress
\>ps -k Med

\>start appcore19.exe
\>start prodapp

\>ps
Process NK.EXE          (64 threads), id 0x00400002, loaded at 0x80100000
Process udevice.exe     ( 2 threads), id 0x01510002, loaded at 0x00010000
Process udevice.exe     ( 1 threads), id 0x015E0002, loaded at 0x00010000
Process udevice.exe     ( 1 threads), id 0x01F20002, loaded at 0x00010000
Process udevice.exe     ( 1 threads), id 0x03230002, loaded at 0x00010000
Process servicesd.exe   (16 threads), id 0x03710002, loaded at 0x00010000
Process ChargeApp.exe   ( 1 threads), id 0x046E0002, loaded at 0x00010000
Process cmd.exe         ( 1 threads), id 0x04C50002, loaded at 0x00010000
Process CMD.EXE         ( 1 threads), id 0x06912D2A, loaded at 0x00010000
Process appcore19.exe   (35 threads), id 0x0342003A, loaded at 0x00010000
Process AppServices.exe (15 threads), id 0x07FB0016, loaded at 0x00010000
Process Resmon.exe      (14 threads), id 0x06920016, loaded at 0x00010000
Process prodapp.EXE     ( 7 threads), id 0x06830636, loaded at 0x00010000
Process ps.EXE          ( 1 threads), id 0x096304D2, loaded at 0x00010000

\>rset prod.preparation.command restartHighRes

\>rls -l .caps.config.image.settings
.caps.config.image.settings: (4)
r---r--------- 0 root   root   <i> IRheight                      60
r---r--------- 0 root   root   <i> IRwidth                       80
r---r--------- 0 root   root   <b> allowForcedCase            false
r---r--------- 0 root   root   <b> enabled                     true

\>


[tomas123]

thanks for good work

now all informations make sense.

Code: [Select]

.caps.config: (3)
rw--r--------- 0 root   root   <e> image                           
r---r---r----- 0 root   root   <a> name                "app E4 1.1"
I think your last rls from this post
https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg399587/#msg399587

Code: [Select]

.caps.config: (3)
rw--r--------- 0 root   root   <e> image                           
r---r---r----- 0 root   root   <a> name                          ""    // empty configuration name!!!runs without the conf.cfc file.

next i delete the old conf.cfc-file, reset to factory->no changes

you generated a nice "E4 self signed" config file in  \Temp\appcore.d\config.d\conf.cfg with old CRC01 key 

some notes:
(1) don't start prodapp.exe (service mode) after appcore19.exe. This was one step to much.
(2) please make a rls with running appcore19.exe
(3) Works the camera GUI with appcore19.exe in process list fine? (take image, msx ..)

I have currently no new ideas but I think a downgrade is nearby
see this post

Un-Bricking an Ex + Version differences HW 1.0 <-> HW 1.1

but do nothing!! wait on Taucher

[Fraser]

Please do not forget that the new E4 version is not HW1.1, it is 1.1L. I don't think the differences between HW 1.1 and 1.1L have been established yet. It was of concern to me that FLIR advised that I should not just install their 1.21.0 firmeware update, but rather, return the camera to them for a special upgrade ! We all know what the result of that action would have been, and FLIR would love to 'upgrade' my camera for me 

The question has to be....has FLIR done something to the hardware platform to sabotage any attempt to increase resolution in firmware or OS ? It is also a possibility that the HW1.1L change is not about a resolution upgrade countermeasure, but rather a frame rate upgrade countermeasure 

It would be very useful to compare images of Mike's V1.0 camera PCB and the newer V1.1 and  V1.1L PCB.

[ixfd64]

Has anyone actually tried applying the original hack to the new cameras? I don't imagine it'll work, but I'm still curious as to what actually happens.

[Taucher]

Ok, first off I strongly suggest to take a second look at my comparison old-new where I listed differences etc.

Any attempt to successfully modify a new firmware version would have to take a serious look at the NK.BIN - especially the contained applauncher.exe and anything FAD related!
There have been changes to the common_dll.dll (seems to contain all relevant classes) where the CFC stuff got added.

Regarding the SUID:
Suid.exe is just reading the SUID as HEX-Code (8 byte to hex / printf("%16.16llX")) from FAD1: (read 30 bytes) and printing it - my guess is it's either a serial number or some camera specific key to be used for encryption.
Note: if a SUID was not found then the exe shall return "00000000000000000000000000000000" (printf("%16.16llX",0)).

Also there's a ressource tree entry .version.SUID (thx to Thomas123 for pointing it out) ... so the suid.exe seems to be just for convenience.

@Applauncher - just take a look at the strings:

Code: [Select]

# 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.
APPLAUNCHER: Not starting duplicate cmd.exe
%[^
cmd
%[^ #
%[^#
APPLAUNCHER: Refuses to run launch specification file. Aborting!
FAD call fails:%d hndl:%d err:%d
No integrity check necessary
Integrity: %d
FAD1:
Failed to open the launch specification file. Aborting!
cmd.exe
APPLAUNCHER: Usb charging finished
APPLAUNCHER: Starting usb charge App
ChargeAppFinished
ChargeApp.exe
Bad Argument! Use "applauncher" for help.
LaunchFileAlt
LaunchFile
Failed to open registry settings. Aborting!
SOFTWARE\FLIR Systems\Applauncher
%[0-9]
Usage: applauncher [options]
-f <filename> Execute commands in file <filename>
-r Execute file specified by registry setting.
(number) Automatic mode (OS internal).
CRC04
CRC03
CRC02
CRC01
CRC00
CRC32
AshIrV:
ZeP0a_K
RSDS
Those are most interesting to me:
AshIrV:
ZeP0a_K
RSDS
FAD1:

[Taucher]

Has anyone actually tried applying the original hack to the new cameras? I don't imagine it'll work, but I'm still curious as to what actually happens.

I think some of the the last posts were exactly on that topic- just read them a bit

[Rainer]

All Tests with my TIC are tests with the 1.1L.

@tomas:

but do nothing!! wait on Taucher

This is not my best fortitude/strength...

I do all the steps again but without the prodapp and generate a new rls for you.

The camera works fine with the appcore19. All normal E4-Options doing there job, but there are no extra menues or something like that.

[Taucher]

All Tests with my TIC are tests with the 1.1L.

@tomas:

but do nothing!! wait on Taucher

This is not my best fortitude/strength...

I do all the steps again but without the prodapp and generate a new rls for you.

The camera works fine with the appcore19. All normal E4-Options doing there job, but there are no extra menues or something like that.

you can try the menu hack - it will not show all functions due to crippled caps - but extra colors should show.

[Fraser]

OK, I am about to show my ignorance of this platforms configuration so please be gentle with me.

If I am presented with two similar (near identical) embedded computers, one 'protected' from change, one not, I would look at a complete firmware and OS transplant to overcome the protection systems in the firmware. Now this would not be simple if there were calibration settings and CRC's in play but it would be a start.

In a perfect world the approch would be:

1. Take a complete firmware and OS image from an unprotected E4 (data donor)
2. Overwrite the protected firmware and OS on a protected E4 with the unprotected E4 image.
3. Change all the CRC's to match the protected cameras serial number or clone the serial number from the donor unprotected E4 camera.
4. Deteremine where the Calibration data is held in the E4 and transplant the correct calibration data from the protected E4 firmware/OS into the newly installed unprotected firmware/OS.
5. Correct the CRC in the file that contains the calibration data. 
6. Enjoy a previously protected camera that is running an unprotected image 

Life is rarely this simple though and I expect challenges with CRC's hidden in files structures and also likley countermeasures in the new Version 1.1L hardware to prevent such an attack vector.

The approach would also be very much 'open case' and requiring IC programming tools.

No harm in blue sky thinking though 

[mikeselectricstuff]

Please do not forget that the new E4 version is not HW1.1, it is 1.1L. I don't think the differences between HW 1.1 and 1.1L have been established yet. It was of concern to me that FLIR advised that I should not just install their 1.21.0 firmeware update, but rather, return the camera to them for a special upgrade ! We all know what the result of that action would have been, and FLIR would love to 'upgrade' my camera for me 

The question has to be....has FLIR done something to the hardware platform to sabotage any attempt to increase resolution in firmware or OS ? It is also a possibility that the HW1.1L change is not about a resolution upgrade countermeasure, but rather a frame rate upgrade countermeasure 

It would be very useful to compare images of Mike's V1.0 camera PCB and the newer V1.1 and  V1.1L PCB.

There is one very specific thing I'd like to compare if we can get pics of a 1.1L
If you've seen the teardown, you may be able to guess what it is.

[Taucher]

Please do not forget that the new E4 version is not HW1.1, it is 1.1L. I don't think the differences between HW 1.1 and 1.1L have been established yet. It was of concern to me that FLIR advised that I should not just install their 1.21.0 firmeware update, but rather, return the camera to them for a special upgrade ! We all know what the result of that action would have been, and FLIR would love to 'upgrade' my camera for me 

The question has to be....has FLIR done something to the hardware platform to sabotage any attempt to increase resolution in firmware or OS ? It is also a possibility that the HW1.1L change is not about a resolution upgrade countermeasure, but rather a frame rate upgrade countermeasure 

It would be very useful to compare images of Mike's V1.0 camera PCB and the newer V1.1 and  V1.1L PCB.

There is one very specific thing I'd like to compare if we can get pics of a 1.1L
If you've seen the teardown, you may be able to guess what it is.

My gut feeling tells me it's that FLIR would add a SUID entry to the I2C prom (when @factory) ... and encrypt the config while DIY-upgrades would probably just have SUID = 0 set.
Also please note from the version info that the L comes from confkit (if I remember correctly) and probably has little to do with the read HW

[mikeselectricstuff]

OK, I am about to show my ignorance of this platforms configuration so please be gentle with me.

If I am presented with two similar (near identical) embedded computers, one 'protected' from change, one not, I would look at a complete firmware and OS transplant to overcome the protection systems in the firmware. Now this would not be simple if there were calibration settings and CRC's in play but it would be a start.

In a perfect world the approch would be:

1. Take a complete firmware and OS image from an unprotected E4 (data donor)
2. Overwrite the protected firmware and OS on a protected E4 with the unprotected E4 image.
3. Change all the CRC's to match the protected cameras serial number or clone the serial number from the donor unprotected E4 camera.
4. Deteremine where the Calibration data is held in the E4 and transplant the correct calibration data from the protected E4 firmware/OS into the newly installed unprotected firmware/OS.
5. Correct the CRC in the file that contains the calibration data. 
6. Enjoy a previously protected camera that is running an unprotected image 

Life is rarely this simple though and I expect challenges with CRC's hidden in files structures and also likley countermeasures in the new Version 1.1L hardware to prevent such an attack vector.

The approach would also be very much 'open case' and requiring IC programming tools.

No harm in blue sky thinking though 

Depends on what level you can access the filesystem. You can't copy the NAND flash chip directly as the bad-block map will be different.
If you can access the filesystem just above the bad-block mapping level, probably doable, but it may depend on what they've done. They could do something at bootloader level - I don't know enough about WinCE and this processor to know how the bootloader process works, but it probably starts at a lower level than the main filesystem, and may be difficult to transfer as chances are it's in a dedicated area of flash seperate from the main filesystem. It may be that a newer bootloader will refuse to boot old firmware.

There does appear to be a fairly low-level firmware programming mechanism via the serial debug port - it may be that this happens before anything that Flir (is likely to) have written runs (e.g. binary blob provided by WinCE), but you'd need to know what sort of file it's expecting.
IMO the most likely reason for the RTB "Upgrade" is to update the bootloader. There may be a secondary reason that may be apparent from pictures.

[Rainer]

So, tauchers BETA3 is installed:

1) colors: special palettes ( working fine
2) temperature scale: manual fixing of the scale works fine(all options)
3) measure spot:
                   working: normal modes(Center spot on/off)
                   not working: special options(hot/cold etc) dont work and camera system freeze(you have to restart the TIC)
4) Image mode: no changes
5) settings:
                 working is: new focus fine tuning,ambient relative humidy, device settings new usb-Mode,
                 not working: condensation-menues

[mikeselectricstuff]

Also please note from the version info that the L comes from confkit (if I remember correctly) and probably has little to do with the read HW

My guess is that the HW version is used by firmware to know what HW environment it is running on, so if they change something that matters (e.g. sensor), the same firmware can run on multiple hardware variants

[mikeselectricstuff]

So, tauchers BETA3 is installed:

1) colors: special palettes ( working fine
2) temperature scale: manual fixing works fine(all options)
3) measure spot: normal modes(Center spot on/off) doing fine, special options dont work and camera system freeze
4) Image mode: no changes
5) settings: new focus fine tuning,ambient relative humidy, device settings new usb-Mode, not working: condensation-menues

I am really surprised that they haven't locked this down more than they could have - RNDIS menu still there, same FTP password etc.
One of the main reasons the original hack was possible was how easy it was to gather lots of information about how it all worked!

[tomas123]

Code: [Select]

\FlashBFS\system>i2c.exe r AE FF

unfortunately i2c.exe dumps only the first 256 Byte from EEPROM

From memory I think i2c.exe doesn't know about eeproms specifically, so you need to use a write+read operation to write the address first before reading the data - if you just do a read it may be reading a random page.
I don't recall the syntax but it's fairly obvious from the /? help

My gut feeling tells me it's that FLIR would add a SUID entry to the I2C prom (when @factory) ... and encrypt the config while DIY-upgrades would probably just have SUID = 0 set.
Also please note from the version info that the L comes from confkit (if I remember correctly) and probably has little to do with the read HW

I haven't an E4 within reach...
Can anybody post a terminal sequence to read out the hole EEPROM?

Code: [Select]

Usage: i2c [2] {r|w} <address> <no of bytes if read> <data to write>
       i2c [2] f <filename>
Write example:  i2c w A0 11 22 33 - Write 11h 22h 33h to A0h
Read example 1: i2c 2 r A0 10     - Read 10h bytes from A0h on I2C2:
Read example 2: i2c r A0 10 80    - Write 80h and Read 10h bytes from A0h
Read example 3: i2c r A0 10 80 40 - Write 80h 40h and Read 10h bytes from A0h (16-bit addressing)
File example 1: i2c f vf.txt      - Read command from file
File syntax: {r|w} <address> <no of bytes if read> <data to write>
             d <delay ms>

Have been playing around with i2c.exe, it is a bit scary not knowing what it is actually doing on the bus. Especially when it comes to the read/write option and the effect it has on the read/write flag on the address byte being sent out. The read/write flag on the DS1388 Real time clock is inverted!!!

[Taucher]

So, tauchers BETA3 is installed:

1) colors: special palettes ( working fine
2) temperature scale: manual fixing of the scale works fine(all options)
3) measure spot:
                   working: normal modes(Center spot on/off)
                   not working: special options(hot/cold etc) dont work and camera system freeze(you have to restart the TIC)
4) Image mode: no changes
5) settings:
                 working is: new focus fine tuning,ambient relative humidy, device settings new usb-Mode,
                 not working: condensation-menues

You could edit the menu to remove the crashing functions/parts - that way you'd at least have a somehow "extended" E4.