The market seems to have dried up for pre-2.x.x E4s. Cheapest on ebay is going for $1700 unmodified.
Might be worth looking for old-stock E5's
I am assuming that this is 'on-line' only as I did not see a download option. it is the sort of utility that I like to keep backed up in case the web site disappears or the owner decides to remove it. Hopefully unlikely in this case though.
Aurora
As far as I know it is online, but judging from the sourcecode it won't be difficult to save a local copy - in fact I had a go and it has kept the majority of functionality. Can't hurt to ask them though if you do want a copy of it - they've put it online for a reason surely?
This message is for Sofia and other people who can not reach their web service screen of their E4s. As solution described by TurboTom; updated firmwares don't have web reachable service menus from browsers and it can be replaced from older firmwares' web clusters. Then system config menu (Eeprom config etc.) can be available over browser. (On any browser by writing 192.168.0.2 adress, RNDIS mode E4s are openning their system config menu with username:flir and password:3vlig). But for newer devices 1235 Eeprom unlock password is not working; it should be something different.
However I'm adding web service cluster to be copied to device with Filezilla:
copying adress /FlashBFS/system/web
Cheers to everyone
Tugbay
This message is for Sofia and other people who can not reach their web service screen of their E4s. As solution described by TurboTom; updated firmwares don't have web reachable service menus from browsers and it can be replaced from older firmwares' web clusters. Then system config menu (Eeprom config etc.) can be available over browser. (On any browser by writing 192.168.0.2 adress, RNDIS mode E4s are openning their system config menu with username:flir and password:3vlig). But for newer devices 1235 Eeprom unlock password is not working; it should be something different.
However I'm adding web service cluster to be copied to device with Filezilla:
copying adress /FlashBFS/system/web
Cheers to everyone
Tugbay
Thank you for your help:-)
I have upgraded my FLIR E4 using the TIConfig utility. My E4 is 1.22 version.
Apparently the upgarde worked (I perceived the increase in resolution), but some minutes after the upgrade I got the following error (displayed in a MessageBox type window):
"Application Error" (An OK button displays on the top right corner)
"Application appcore.exe encountered a serious error and must shutdown".
The E4 was working on the background despite the error. But I had to restart the unit to rid of the error message.
I have upgraded my FLIR E4 using the TIConfig utility. My E4 is 1.22 version.
Apparently the upgarde worked (I perceived the increase in resolution), but some minutes after the upgrade I got the following error (displayed in a MessageBox type window):
"Application Error" (An OK button displays on the top right corner)
"Application appcore.exe encountered a serious error and must shutdown".
The E4 was working on the background despite the error. But I had to restart the unit to rid of the error message.
I recall that happening on my unit, haven't had a problem since.
Which is the parallax error I should expect in MSX mode for a 1 meter distance ?
I get about 3 cms.(in real size) offset between the camera and the thermal image, so MSX it is not usable at that distance.
At a distance of about 3 meters and beyond I get a decent mix between picture and thermal image.
Which is the parallax error I should expect in MSX mode for a 1 meter distance ?
I get about 3 cms.(in real size) offset between the camera and the thermal image, so MSX it is not usable at that distance.
At a distance of about 3 meters and beyond I get a decent mix between picture and thermal image.
check out your camera's settings-menu ... distance setting...
Do people use the MSX feature at all? Or is it better to use photoshop?
Do people use the MSX feature at all? Or is it better to use photoshop?
I use MSX and set the distance. I'm sure PS would do well, but it significantly increases the time to process the images.
This message is for Sofia and other people who can not reach their web service screen of their E4s. As solution described by TurboTom; updated firmwares don't have web reachable service menus from browsers and it can be replaced from older firmwares' web clusters. Then system config menu (Eeprom config etc.) can be available over browser. (On any browser by writing 192.168.0.2 adress, RNDIS mode E4s are openning their system config menu with username:flir and password:3vlig). But for newer devices 1235 Eeprom unlock password is not working; it should be something different.
However I'm adding web service cluster to be copied to device with Filezilla:
copying adress /FlashBFS/system/web
Cheers to everyone
Tugbay
Hello,
did not find anyone to Eprom password? 1235 does not work.
Thank you
Hint to Flir. Couldnt be the offset between thermal image and actual picture be set automatically by software ?
Hint to Flir. Couldnt be the offset between thermal image and actual picture be set automatically by software ?
It should be possible to make a pretty good guess based on a correlation between the images
the Flir cameras with auto/manual-focus fit the offset between thermal image and actual picture
with exiftool you can read out the focus distance and the offset
if you have a fixed focus camera (like E4) you can try this way for automatic overlay:
(sample with a 8 bit autolevel grayscale thermal image
thermal.png and a real image
real.jpg)
http://studio.imagemagick.org/discourse-server/viewtopic.php?f=1&t=23318#p97884but it's better to use this algorithm:
- the offset between thermal image and real picture is a line as a function of distance
- take two pictures (macro and infinite) and find out the first point and the last point of the line
- check your images with all possible offsets around the line with (write a script)
compare -metric rmse ( see
http://www.imagemagick.org/script/compare.php )
and find the best match
Hi there
Newbie here
I just bought a new Flir E4 with firmware 2.3.0. Any experiences with that version regarding the
hack tuning? Has someone suceeded to do that version?
Ah yes, just in case someone cares... 3vlig (trevlig in swedish) means "nice" or "pleasant". It's not just a random string of characters
Anyone knows a place where i can get a E4 with old Firmware 1.19 at the moment ?
Ah yes, just in case someone cares... 3vlig (trevlig in swedish) means "nice" or "pleasant". It's not just a random string of characters
Wow, that's pretty cool! I was wondering why they chose such an odd password.
Regarding E4 with updated firmware:
The new "protection" is based on the fact that the per-device config files (FlashFS\system\appcore.d\config.d\conf.cfc, FlashFS\system\ui.d\config.d\conf.cfc, FlashFS\system\services.d\config.d\conf.cfc) are now encrypted and signed.
The encryption algorithm is RC4 with the key being the SHA1(key || "2A00"), where "key" comes from the "FAD1:" device, ioctl 0x800040C0. That ioctl, which I don't fully understand what it's actually doing, returns 0x18 bytes, with the last 8 bytes being the key (not sure if it's per-device or generic), and the second word indicating whether the config-files have to be globally signed or just including a hash. On my camera (1.2L, came with 2.3.0) it indicated that they have to be signed. common_dll.dll checks for the config file signature, and uses a RSA1024 bit public key to verify the signature.
So far, that's all bad news.
You can patch your config-file, and patch common_dll.dll to disable the signature check (and because I couldn't get CRC03 to compute correctly, I patched that as well), but then the camera doesn't auto-boot anymore since applauncher.exe verifies the CRCs from applaunch.dat (which fails for my patched common_dll.dll), and applaunch.dat itself is signed (applaunch.sig).
BUT: It appears that CRMD160 is very fundamentally broken for byte values >= 0x80 (talk about not compiling with /J, hehheh). This allows to conveniently patch the signature check in a way that applauncher.exe doesn't notice. (Unfortunately the config signature check uses MS Crypto Provider, not their custom stuff.)
I was able to apply this hack on my E4 but it's a very dirty hack. I haven't fully understand the config loading yet, maybe there's a better way, like manipulating on of the existing files instead to override the per-device config? Has someone played with that yet? (like: remove the per-device config, and then hack one of the .rsc to set the stuff that's otherwise set in the .cfc).
Well, sounds like you deserve some congratulations
I'd even say: feel free to post details about the applied patches. Regarding FAD1: I remember posting about that device and that I was pretty sure it's naming was a decoy... this just confirms my assumption.
My gut feeling tells me it's just some SN or version from the FPGA... not that one couldn't patch that driver to always return the required data... just an idea
NK.BIN contains hints to MISCDEV_LIB.dll
Regarding Applaunch: just take a close look into NK.bin from the update file... many neat strings in close proximity - like CRC04
I can even imagine that looking at the internal registry (SOFTWARE\FLIR SYSTEMS\APPLAUNCHER) could yield some additional insights).
Don't have a 2.3 cam anyway... so can just do rough static checks - I remember the µC having secure boot features ... still I doubt they would resist elaborate efforts.
Also there might be some option using one of those strings:
eFLIRInstall_cont.dat
autoload.fif
Regarding E4 with updated firmware:
The new "protection" is based on the fact that the per-device config files (FlashFS\system\appcore.d\config.d\conf.cfc, FlashFS\system\ui.d\config.d\conf.cfc, FlashFS\system\services.d\config.d\conf.cfc) are now encrypted and signed.
The encryption algorithm is RC4 with the key being the SHA1(key || "2A00"), where "key" comes from the "FAD1:" device, ioctl 0x800040C0. That ioctl, which I don't fully understand what it's actually doing, returns 0x18 bytes, with the last 8 bytes being the key (not sure if it's per-device or generic), and the second word indicating whether the config-files have to be globally signed or just including a hash. On my camera (1.2L, came with 2.3.0) it indicated that they have to be signed. common_dll.dll checks for the config file signature, and uses a RSA1024 bit public key to verify the signature.
So far, that's all bad news.
You can patch your config-file, and patch common_dll.dll to disable the signature check (and because I couldn't get CRC03 to compute correctly, I patched that as well), but then the camera doesn't auto-boot anymore since applauncher.exe verifies the CRCs from applaunch.dat (which fails for my patched common_dll.dll), and applaunch.dat itself is signed (applaunch.sig).
BUT: It appears that CRMD160 is very fundamentally broken for byte values >= 0x80 (talk about not compiling with /J, hehheh). This allows to conveniently patch the signature check in a way that applauncher.exe doesn't notice. (Unfortunately the config signature check uses MS Crypto Provider, not their custom stuff.)
I was able to apply this hack on my E4 but it's a very dirty hack. I haven't fully understand the config loading yet, maybe there's a better way, like manipulating on of the existing files instead to override the per-device config? Has someone played with that yet? (like: remove the per-device config, and then hack one of the .rsc to set the stuff that's otherwise set in the .cfc).
Here we go again....!
Have you noticed anything that sheds light on the report of the unit that was upgraded and was still able to use an old file ?
Seems like this might be a useful avenue to explore if you can trick the FW into convincing it that it's an old unit.
Is it not possible to patch applauncher.exe?
applauncher.exe is part of nk.bin, so it's not easily replaceable. (I'm sure people know the required magic to patch nk.bin, but unfortunately I don't.) But with their CRC-screwup, it's easy enough to patch useful changes into the CRC'ed binaries.
(It only appeared now to me that tnt's original tool, which doesn't replicate the signedness-screwup, works fine on configuration files because they do not contain any characters >= 0x80).
An upgraded unit will not have a strong signature for the config data, since it's device-unique and the private key is - likely - not embedded in the updater; there is no opportunity to create a strong-signed config file for those units. However I think that's what the "alternative" code path is for, that supports hashed-only encrypted config files. (The result of the FAD1:-IOCTL determines wether it requires a strong signature - likely for units that were calibrated with updated firmware - or just encrypted-and-hashed configuration files - likely for units that were calibrated before they added the countermeasure).
We should look into what the FAD1:-Ioctl really does. If we can trick it into returning that this is an old, updated unit, then a valid configuration file could be produced.
Ok... I understand that you people are working hard on the new firmware. I'd like to help but I have no experience with the USB/RNDIS networking. Could someone provide me some basic guidance?
First (eventual) problem: Choosing the RNDIS mode in the hidden menu looks odd. I can move the selector bar to the RNDIS item and press OK then it jumps immediately to the previous menu. There is no indication which mode is chosen. Is this normal?
Second problem: I actually get a new network connection on my PC (XP) called "LAN Connection 4 - Windows Video...something" ist this correct and what IP settings do I need? Is it to be set to DHCP? Does the camera provide the IP address or do I have to install a DHCP server??
Nice video... but it starts where I am stuck. There ist no word about the IP settings.
I need the 5minute video before that one Update: I played a bit with the camera and it seems that it is not possible to set RNDIS mode.
I get into the hidden menu, I see the USB mode menu, I can scroll through the items but nothing changes. I still see an USB mass storage device and a webcam (that's where the LAN4 - Microsoft TV/Video-connection comes from). Do I have to reboot the camera? I tried that too but.... no success.
I've troubled as you. Then a friend suggested Mike's first posts for injecting RNDIS file to device. His file package includes related FIF files to activate it. It worked for me.
'If you search through Mikes original hack you can enter RNDIS mode using flirinstallnet and the FIF files from Mikes earlier hacks.'
Thanks for the hint... I will try this. Where can I find this tools and how do I "inject" the files?
In Mikes video, he's playing with a serial connection and displaying some startup logs. Has someone ever tried to communicate with the cam through that serial port? I wonder which pins a re used...
Sometimes amazing things can be achieved with a simple RS232 connection. Maybe even activating hidden menus or options.