I just wanted to share something I discovered today. After disassembling the camera and stupidly (DO NOT unseat this camera if you can help it) removing the spring clip that holds the visual camera in place, the MSX was significantly off vertically upon reassembly. No amount of reseating of the visible camera could line up the images, it's almost like it wasn't seated properly at the factory before calibration... After toying with adjusting the calibration files for the new paralax, I ended up just placing a sliver of paper under the lip of camera as a shim. Problem solved with my favorite kind of engineering! I don't deserve nice things....
I can't stop thinking about some kind of self-destruct-mechanism as soon as you log in via FTP. Or it might be possible that I watch too much action movies...
Any form of active "destruct" functionality would be very stupid, as they'd just get a load of pissed off customers returning them as faulty.
Would be funny though if they added in functionality which when it detects a unauthorised cfg file has been added or changed... it will put the camera into lock down and every time you attempt to turn it on it will freeze and display a image saying "CAMERA DISABLED ATTEMPTED HACK <file name> DETECTED"......
haha it would clearly piss off alot of people ,but they cannot send it back and claim warranty since it isn't broken because of FLIR.
I can't stop thinking about some kind of self-destruct-mechanism as soon as you log in via FTP. Or it might be possible that I watch too much action movies...
Any form of active "destruct" functionality would be very stupid, as they'd just get a load of pissed off customers returning them as faulty.
Would be funny though if they added in functionality which when it detects a unauthorised cfg file has been added or changed... it will put the camera into lock down and every time you attempt to turn it on it will freeze and display a image saying "CAMERA DISABLED ATTEMPTED HACK <file name> DETECTED"......
haha it would clearly piss off alot of people ,but they cannot send it back and claim warranty since it isn't broken because of FLIR.
it would only piss off FLIR, as it is legal to return goods WITHOUT ANY REASON in EU within 7 days of receiving your mail order
it is legal to return goods WITHOUT ANY REASON in EU within 7 days of receiving
Partially true. In our country it is 14 days, BUT it must be in ORIGINAL CONDITION, so any sing of trying hack is reason to not accept the return.
If there will be any problem with Flir tools in future, just DO NOT USE it :-D Use BFIC (See my footnote and try windows version).
I can't stop thinking about some kind of self-destruct-mechanism as soon as you log in via FTP. Or it might be possible that I watch too much action movies...
Any form of active "destruct" functionality would be very stupid, as they'd just get a load of pissed off customers returning them as faulty.
Would be funny though if they added in functionality which when it detects a unauthorised cfg file has been added or changed... it will put the camera into lock down and every time you attempt to turn it on it will freeze and display a image saying "CAMERA DISABLED ATTEMPTED HACK <file name> DETECTED"......
haha it would clearly piss off alot of people ,but they cannot send it back and claim warranty since it isn't broken because of FLIR.
Nothing to do with warranty - in the UK at least, the liability for "faulty" goods is with the seller, and it would be down to them to prove the goods had been damaged.
"Dunno mate it just came like that..."
"The fragile USB socket just fell off..."
etc. etc.
Well, the look of that config file is a bit unexpected...
At least for me.
And only after opening the configuration file for like three or four times, I noticed the different file name "conf.cf
c". Just stating the obvious: the second c most certainly stands for crypted.
I'm not huge into hex or crypto stuff but I cannot recognize anything in that file...
Also, the only logfile in the backup /Temp/postlog.txt hasn't anything useful in it (at least as far as I can see).
Any ideas on how to start?
Well, the look of that config file is a bit unexpected... At least for me.
And only after opening the configuration file for like three or four times, I noticed the different file name "conf.cfc". Just stating the obvious: the second c most certainly stands for crypted.
I'm not huge into hex or crypto stuff but I cannot recognize anything in that file...
Also, the only logfile in the backup /Temp/postlog.txt hasn't anything useful in it (at least as far as I can see).
Any ideas on how to start?
the file has a #CFC near the end and some binary stuff after that ... I'd say that's a start
Here some stuff for you:
thanks, but you uploaded all your privat images from folder FLIR_BACKUP\FlashIFS\DCIM\FLIR_100 !
common DLL:
CCfc::initSignature(CCfc::CFC_SIGNTYPE_T) .text 0000000000105150 00000070 R . . . . . .
CCfc::CCfc(void) .text 000000000010523C 00000020 R . . . . . .
CCfc::CCfc(CCfc::CFC_SIGNTYPE_T) .text 0000000000105264 00000028 R . . . . . .
CCfc::CCfc(CCfc::CFC_SIGNTYPE_T,CCfc::CFC_PLTYPE_T) .text 000000000010528C 00000028 R . . . . . .
CCfc::calcSign(void *,long) .text 00000000001054FC 0000012C . . . . . . .
CCfc::setSignatureType(CCfc::CFC_SIGNTYPE_T) .text 00000000001057C8 00000020 . . . . . . .
CCfc::getSignature(bool &,int *) .text 00000000001057E8 00000028 . . . . . . .
CCfc::setSuid(unsigned __int64) .text 0000000000105810 0000000C . . . . . . .
CCfc::setPltype(CCfc::CFC_PLTYPE_T) .text 000000000010581C 00000020 . . . . . . .
CCfc::signatureSize(void) .text 000000000010583C 00000010 . . . . . . .
CCfc::cfcheader(void *,CCfc::CFC_SIGNTYPE_T *,CCfc::CFC_PLTYPE_T *) .text 000000000010584C 000000BC . . . . . . .
they removed all parts to get the High Resolution Service Mode (especially prodapp.exe)
removed binaries
./FlashBFS/system/bitapp.exe
./FlashBFS/system/camtorrent.exe
./FlashBFS/system/cemgrc.exe
./FlashBFS/system/cerdisp.exe
./FlashBFS/system/clientshutdown.exe
./FlashBFS/system/cmaccept.exe
./FlashBFS/system/conmanclient2.exe
./FlashBFS/system/conmanclient3.exe
./FlashBFS/system/dumpcoff.exe
./FlashBFS/system/fmqping.exe
./FlashBFS/system/fvd.exe
./FlashBFS/system/i2c.exe
./FlashBFS/system/pmic.exe
./FlashBFS/system/prodapp.exe
./FlashBFS/system/regsvrce.exe
added binaries
./FlashBFS/system/suid.exe
For the calibration Flir activate furthermore the high res mode.
see
$ exiftool ./FlashFS/system/maps/ds250C_we_ap_fi_le_static.gan
ExifTool Version Number : 9.53
...
Gain Dead Map Image Width : 320
Gain Dead Map Image Height : 240
Gain Dead Map Image Type : TIFF
Gain Dead Map Image : (Binary data 153804 bytes, use -b option to extract)
good news: your sensor is 320x240
also see unchanged FlashFS/system/service/appcore.d/config.d/conf.cfg
If you want to test something, you can send me a zip-file and some instructions.
Just a quick statistics analysis for the conf file - comparing .cfg and .cfc
Green is count of byte from 0x00 (left) to 0xFF (right) - red is the same count, just sorted by count descending.
Size indicates it's not compressed.
PS: Histograms were made with bytehist:
https://www.cert.at/downloads/software/bytehist_en.html
Just a quick statistics analysis for the conf file - comparing .cfg and .cfc
Green is count of byte from 0x00 (left) to 0xFF (right) - red is the same count, just sorted by count descending.
Size indicates it's not compressed.
PS: Histograms were made with bytehist: https://www.cert.at/downloads/software/bytehist_en.html
That look srather strange, not like real encryption. Notice the "notch" in the .cfc bytes green plot, whereas the "peak" in the .cfg is just after that. All in all not that random. Woul be interresting to see some more .cfc files from new cams, and compare them. Who knows, maybe just some silly XOR or bit-rotationg using the cam's serial (or whatever) number. After all, it's a rather small processor in there that is already struggling with providing a fluidly working UI, so burdening it with heavy encryption may be a no-go.
Oh, and has anyone tried to still feed it regular plain-text .cfg files? I mean, who says that the choice between .cfc and .cfg is mutually exclusive?
Greetings,
Chris
I just happened to be looking for a thermal imaging camera at the same time Flir was upgrading their firmware. I ended up placing 3 online orders. Cancelled the first 2 as they were on back order (as that would guarantee new firmware). Gambled that if the vendor had stock (order date 2/24/14) it would be the old firmware. Camera arrived 2/28 with old firmware. Carefully followed Mikes instructions and the resolution is now great! Thank you - Thank you - Thank you Mike (and contributors).
It's worth mentioning that I would not have purchased this item without the ability to achieve the higher resolution. The difference really is night and day.
maybe just some silly XOR or bit-rotationg using the cam's serial (or whatever) number
I bet so. Since we have original and the crypted one, it should not be to hard to find out the encryption key.
Quote from my first post:
Model E4 1.1L
Serial-No.
63914752Part-No. 63901-0101
SW-Version 1.21.0
If you need any further data of my TIC, please let me know about and i will do so.
@ the german "developers": Ich wohne in Berlin und kann gern auch mal persönlich mit der TIC irgendwo hinkommen, falls das hilft.
common DLL:
CCfc::initSignature(CCfc::CFC_SIGNTYPE_T) .text 0000000000105150 00000070 R . . . . . .
CCfc::CCfc(void) .text 000000000010523C 00000020 R . . . . . .
CCfc::CCfc(CCfc::CFC_SIGNTYPE_T) .text 0000000000105264 00000028 R . . . . . .
CCfc::CCfc(CCfc::CFC_SIGNTYPE_T,CCfc::CFC_PLTYPE_T) .text 000000000010528C 00000028 R . . . . . .
CCfc::calcSign(void *,long) .text 00000000001054FC 0000012C . . . . . . .
CCfc::setSignatureType(CCfc::CFC_SIGNTYPE_T) .text 00000000001057C8 00000020 . . . . . . .
CCfc::getSignature(bool &,int *) .text 00000000001057E8 00000028 . . . . . . .
CCfc::setSuid(unsigned __int64) .text 0000000000105810 0000000C . . . . . . .
CCfc::setPltype(CCfc::CFC_PLTYPE_T) .text 000000000010581C 00000020 . . . . . . .
CCfc::signatureSize(void) .text 000000000010583C 00000010 . . . . . . .
CCfc::cfcheader(void *,CCfc::CFC_SIGNTYPE_T *,CCfc::CFC_PLTYPE_T *) .text 000000000010584C 000000BC . . . . . . .
Let's hope that this isn't some sort of public-key crypto, or some patching will be needed...
FLIR Systems’ Customer Survey 2014 - E-seriesI think they got several feedbacks like this (see attachment).... Thanks again taucher and mike.
I can´t for the final page with field "general comments" or so.
you program give me an error message
Damn stupid message ! Please ignore it, I will remove it in the next release together with some minor bug fixes.
you program give me an error message
Damn stupid message ! Please ignore it, I will remove it in the next release together with some minor bug fixes.
Please check my excel sheet, the calculations with
atmosphere transmissivity are a great improvement.
furthermore the current cersion of exiftool readout the
measuring points ( a great hack from Phil Harvey
)
>exiftool -meas* FLIR0232-Tools.jpg
Meas 1 Type : Spot
Meas 1 Params : 152 111
Meas 1 Label : Sp1
Meas 2 Type : Line
Meas 2 Params : 181 157 291 149
Meas 2 Label : Li1
Meas 3 Type : Area
Meas 3 Params : 211 5 40 27
Meas 3 Label : Ar1
Meas 4 Type : Ellipse
Meas 4 Params : 105 177 151 177 105 153
Meas 4 Label : El1
Meas 5 Type : Difference
Meas 5 Params : 2 1 2 3 1 2
Meas 5 Label : Dt1
Please check my excel sheet, the calculations with atmosphere transmissivity are a great improvement.
...
furthermore the current version of exiftool readout the measuring points ( a great hack from Phil Harvey )
Sure, I have it on todo list. But these are more complex things, requiring more time to implement. So it will not appear in the next release.
I spent many hours on BFIC, so now I need to push other projects a bit too. Then I will get back to BFIC again.