So, I was digging through more of the update. Saw this...not sure if it refers to just image files or all of them, but it has a switch for forcing a file to load with a broken CRC...
usage: ftest [-q] [-n nr] [-e] [-x] [-i imageid] [-g groupid] [-s siteid]
[-l 0|1] [-t <tag>:<subtag>:<rev>:<file>] [-j <file>] [-d <tag>]
[-m] [-f] [-c <file>] [-r <x>:<y>:[e:]<file>] [-a <file>]
[-v <file>] [-b <file>] <image1> [image2] ...
-q quiet mode, only print error messages (on stderr)
-n read file <nr> in seq file, or \"iter\" to iterate whole file
-e extract parts to file
-x extract each image in a sequence
-i replace EXIF image ID with <imageid>, \"rand\" creates new
-g replace EXIF group ID with <groupid>, \"rand\" creates new
-s replace EXIF site ID with <siteid>, \"rand\" creates new
-l replace stitchLast with 0 or 1
-t replace/add <tag> with data from <file> at revision <rev>
-j replace JPEG pixels with data from <file>
-d delete <tag> from file
-m force map stats calc on image
-f force loading by ignoring broken CRCs
-c create color JPEG <file> from FFF data
-r rescale to size <x>x<y> in <file> (add :e: for exact rescale)
-a resave using original format to <file>
-v save IR pixels as temp values as csv data in <file>
-b save image1, image2,... to seq <file> (.csq = compressed)
Here are the pinouts I've determined so far on the hidden bottom connector of the i7, for those interested. Is such a connector present on the E-series?
BTW I'm pretty sure the i7 hack was using rset - image resolution, noise turned off, so if you can find a console UART or USB networking mode you may be in.
The hidden menu was 2 keys, one of which was one of the arrows, pressed after powerup.
As the front keypad acts like a keyboard ( You can fake buttons with bt.exe and enter/arrows navigate WinCe menus clears menus ), it may be a case of hitting keys at a certain time rather than hplding down from powerup.
rset does have an optional password so could be that making it fail.
Still unsure of the relationship between resources and the files.
Looking at facet_Z3.rcc would seem to suggest they are using Qt for their gui. Which is a good thing, as Qt doesn't suck.
And it would also seem to suggest that at least that part was made in Sweden.
As for crc ... I noticed in camera.cmd it does this:
Check if crc have changed
kitcrc -c \FlashBFS\system\kits.d\appkit.rev
[*FAIL*][$GOTO failed2]
kitcrc -c \FlashBFS\system\kits.d\prodkit.rev
[*FAIL*][$GOTO failed2]
So you might be able to use kitcrc to adjust things to your liking. At any rate, camera.cmd is full of inspiration.
Duh. blind. of course they use Qt.
./FlashBFS/system/QtDeclarative4.dll
./FlashBFS/system/QtCore4.dll
./FlashBFS/system/QtGui4.dll
./FlashBFS/system/QtNetwork4.dll
./FlashBFS/system/QtScript4.dll
rset does have an optional password so could be that making it fail.
appcore.exe has a string Reference to "Lock, Unlock: 1235"...possibly related?
Let me know if I'm just clogging up the thread with useless junk...
Here are the pinouts I've determined so far on the hidden bottom connector of the i7, for those interested. Is such a connector present on the E-series?
BTW I'm pretty sure the i7 hack was using rset - image resolution, noise turned off, so if you can find a console UART or USB networking mode you may be in.
The hidden menu was 2 keys, one of which was one of the arrows, pressed after powerup.
As the front keypad acts like a keyboard ( You can fake buttons with bt.exe and enter/arrows navigate WinCe menus clears menus ), it may be a case of hitting keys at a certain time rather than hplding down from powerup.
rset does have an optional password so could be that making it fail.
Still unsure of the relationship between resources and the files.
Found another TX port, which spits out " \> [6n" consistently on hard boot. Can't get any of the other ports to respond, though.
That looks like the console port - run a terminal program and send carriage returns to pins to find RXD until you see that prompt repeating.
The E4 gives a short version string at boot so may be slightly different :
FLIR Command Line Interpreter
Version 0.4.3 running on WinCE 6.0
\>
Doesn't look like those .cfg files do much - it will start with the file not present - suspect they are debug output etc.
Looking at what & when it reads from eeprom. Looks like most records have a 2 byte check at the end - anyone good at CRC-spotting? CRC in bold.
Quite a few sections get read multiple times - I've omitted duplicates
AEW is eeprom address
D0W is realtime clock
Following read at power-up only
Time Restart Address Data
-388.0us AEW 80
-40.78us X AFR 0B 91 39 00 00 00 00 00 00 00 00 00 00 00 00
1.860s AEW 40
1.860s X AFR 54 31 39 38 32 38 33 00 00 00 31 39 39 36 37 37 33 30 00 00 31 30 00 00 00 00 00 00 00 00 F7
1.900s D0W 0
1.901s X D1R 27 54 23 01 21 10 13 ; RTC
1.930s D0W 0
1.931s X D1R 27 54 23 01 21 10 13
2.246s AEW 0
2.246s X AFR 46 4C 49 52 20 45 34 00 00 00 00 00 00 00 00 00 00 00 00 00 36 33 39 30 31 2D 30 31 30 31 00 00 00 00 00 00 36 33 39 30 33 37 37 31 00 00 32 30 31 33 2D 31 30 2D 30 32 00 00 30 31 00 00 DC C7
4.419s AEW C0
4.419s X AFR 50 00 3C 00 00 06 00 00 00 00 00 00 00 00 8C 06
50 00 = 80 decimal, 3C 00 = 60 decimal - VERY INTERESTING!!! also 60Hz/6=10 - could the 06 be framerate?
Following read at app restart from console, and after above at powerup
1.233s AEW A0
1.234s X AFR 54 31 39 38 33 30 34 00 00 00 36 33 38 30 34 35 38 35 00 00 30 31 00 00 FF FF FF FF FF FF FB 98
1.251s AEW 0
1.252s X AFR 46
1.254s AEW D0
1.255s X AFR FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
1.482s AEW C0
1.483s X AFR 50 00 3C 00 00 06 00 00 00 00 00 00 00 00 8C 06
3.661s AEW 0
3.662s X AFR 46 4C 49 52 20 45 34 00 00 00 00 00 00 00 00 00 00 00 00 00 36 33 39 30 31 2D 30 31 30 31 00 00 00 00 00 00 36 33 39 30 33 37 37 31 00 00 32 30 31 33 2D 31 30 2D 30 32 00 00 30 31 00 00 DC C7
3.673s AEW 0
3.674s X AFR 46
3.675s AEW 0
3.676s X AFR 46 4C 49 52 20 45 34 00 00 00 00 00 00 00 00 00 00 00 00 00 36 33 39 30 31 2D 30 31 30 31 00 00 00 00 00 00 36 33 39 30 33 37 37 31 00 00 32 30 31 33 2D 31 30 2D 30 32 00 00 30 31 00 00 DC C7
19.86s AEW A0
19.86s X AFR 54 31 39 38 33 30 34 00 00 00 36 33 38 30 34 35 38 35 00 00 30 31 00 00 FF FF FF FF FF FF FB 98
29.66s AEW 40
29.66s X AFR 54 31 39 38 32 38 33 00 00 00 31 39 39 36 37 37 33 30 00 00 31 30 00 00 00 00 00 00 00 00 F7 A8
hang on a minute.... I think I spotted the check method
50 00 3C 00 00 06 00 00 00 00 00 00 00 00
8C 0650 00
3c 00
00 06
00 00
....
00 00
Check is 8C 06
It's a simple 16 bit checksum FFS!!!!
Let's check with another one to see how the carry works..
54 31
39 38
32 38
33 00
00 00
31 39
39 36
37 37
33 30
00 00
31 30
00 00
00 00
00 00
00 00
F7 A8Add them up (Lsb:Msb) - 1A8F7 - Yesss!
Hmmm - changed eeprom and it changed it back....!
Hmmm - changed eeprom and it changed it back....!
That's... odd. It must be cross-checking with something on the flash so you can't just change one place.
But if it's just going to overwrite the eeprom, why even have the eeprom?!
That looks like the console port - run a terminal program and send carriage returns to pins to find RXD until you see that prompt repeating.
The E4 gives a short version string at boot so may be slightly different :
No carriage return, but sending anything to the port above the TX2 port (likely RXD) makes it appear on the serial monitor -- that doesn't happen with any of the other ports. Question marks don't do anything -- perhaps the [6n is asking the device what position the keyboard is in, so that it can trigger CLI mode?
Had to enable NL & CR in terminal!
For comparison, remember this is from i7, not E4!
\>[6n?
? alias attrib beep bootdeletecall cd chdir
choice cls copy date del delete delay dir
dirs echo echos echoerr echoserr erase exit for
free goto help history if irqlog memory md
mkdir move path pause popd prompt pushd rd
rem ren rename restart replace rmdir rcd rpwd
rls rset rclone rcreate rdelete rdump rfind rpatch
rreload screen set shift start time timer type
ver
\>[6nhelp
List of all available commands (+ description)
command /? For more information on a specific command
? List all available commands without description).
ALIAS Sets, removes or shows aliases.
ATTRIB Displays or changes file attributes.
BEEP Beep the speaker.
CALL Calls one batch program from another.
CD Displays the name of or changes the current directory.
CHOICE Waits for the user to choose one of a set of choices.
CLS Clears the screen.
CMD Starts a new instance of the FLIR command line interpreter.
COPY Copies one or more files to another location.
DATE Displays or sets the date.
DELETE Deletes one or more files.
DIR Displays a list of files and subdirectories in a directory.
ECHO Displays messages, or turns command echoing on or off.
ERASE Deletes one or more files.
EXIT Quits the CMD.EXE program (command interpreter).
FOR Runs a specified command for each file in a set of files.
FREE (free) disc space.
GOTO Directs the FLIR command line interpreter to a labeled line in
a batch program.
HELP Provides Help information for FLIR commands.
HISTORY List all commands which has been used
IF Performs conditional processing in batch programs.
MD Creates a directory.
MKDIR Creates a directory.
MOVE Moves one or more files from one directory to another
directory.
PATH Displays or sets a search path for executable files.
PAUSE Suspends processing of a batch file and displays a message.
POPD Restores the previous value of the current directory saved by
PUSHD.
PROMPT Changes the command prompt.
PUSHD Saves the current directory then changes it.
RD Removes a directory.
REM Records comments (remarks) in batch files.
REN Renames a file or files.
RENAME Renames a file or files.
REPLACE Replaces files.
RMDIR Removes a directory.
SCREEN Move cursor and optionally print text.
SET Displays, sets, or removes FLIR command line interpreter environment variables.
SHIFT Shifts the position of replaceable parameters in batch files.
START Starts a separate window to run a specified program or command.
Executes command.
TIME Displays or sets the system time.
TIMER Allow the use of ten stopwatches.
TYPE Displays the contents of a text file.
VER Displays the FLIR command line interpreter and Windows CE version.
Time to explore resources with rls and rcd...
fvd.exe and fvd.dll look interesting - I think this is the first thing run at boot time - contains the downsampling message as well as references to eeprom checksum error.
Hmmm - changed eeprom and it changed it back....!
Here's hoping it didn't just increment a tamper counter. Strike 1 hehe.
\>[6nrls system
MACaddr "censored"
eeprom
focus
fvd
powerButton
restart false
restartDelay 1
sync ""
tempsens
tempsensActive true
tempsensError "0 0"
tempsensValid true
time
usbmode "MSD"
webpasswd "IRCAM"
\>[6n
Still trying to figure out how to use rls/rcd...
The resource stuff like a tree. rcd is a convenient way of sitting at a deep level so you don't need to specify the full path.
e.g. to see teh time value you can do
rls system.time
or rcd system
rls time
rls [path] -r will show the whole subtree
-l shows more info including attributes
rset allows values to be changed once you've used rls to find the key and format
rdump allows a tree to be dumped to a file
most of these utils have some inbuilt help using /?
Also have a look in the flashBFS\system dir for other executables.
Hmmm - changed eeprom and it changed it back....!
That's... odd. It must be cross-checking with something on the flash so you can't just change one place.
But if it's just going to overwrite the eeprom, why even have the eeprom?!
Another possibility is that there is data stored in the sensor itself (possibly in OTP), as is often done for regular camera chips.
I accidentely stumbled upon the attached file.
It might be helpful in some way (commands/parameters), it might not.
I accidentely stumbled upon the attached file.
It might be helpful in some way (commands/parameters), it might not.
Yes - that's the one linked from the PDF I mentioned earlier - some parts are out of date but some useful snippets in there
wonder how difficult it would be to decompile the *.exe and figure out what's happening when the downsampling messages are printed?
wonder how difficult it would be to decompile the *.exe and figure out what's happening when the downsampling messages are printed?
fvd.exe and fvd.dll aren't very big, so should be fairly doable, given a decent cross-referencing diassember
It is an ARM processor though so availability of those for EXE files may be scarce, probably IDA Pro will do it but I don't know.
Good Video, I enjoyed watching it.
I was looking at them with the demo of IDA Pro. It does have the option for ARM but you can't access it in the demo...it would do it as a generic binary and I got what looked like assembly, but I'm not good enough to make heads or tails of it. I was just digging out the strings from the exe's in the update and posting them earlier since I still don't have my camera.
Okay,
I'm not good enough to make heads or tails of a lot of what I'm seeing here. I don't have a full version of IDA Pro so I can't disassemble for ARM, but I can as a generic binary. I'm still learning but maybe this will mean something to someone else. Attached are the results of IDA's disassembly and code generation.
The free/demo version of ida pro only do windows 32 x86 code.
At best you can read the strings in the binary.
Im sure some others around here have the pro version, required for rigol hacks.
Dont know any arm decompilers off the top of my head.
Sorry for being late to the party. Wanted to say thanks Mike for this vid and the review. And the x-ray machine vid.
I watch them here and there after downloading them (slowly) and forget to say ta!
I've been silently following the E4 related threads for some time. Must say, juicy information
I don't have an E4 (yet... - that may change
) but I've tried to put together some bits of information that I've found around in this thread. IMHO the simple way to go is using the Web Interface (you can access most, if not all, camera settings from there - including a special Service Menu) - all menus conveniently listed in FlashBFS/system/web/ and sub-folders
..and if you send a <space> to the UART during boot....
SETTINGS:
0) IP address: 0.0.0.0
1) Subnet Mask: 0.0.0.0
2) Boot delay: 1 seconds
3) DHCP: Enabled
4) Reset to factory default configuration
5) Autoboot: NK from NOR
6) MAC address: 00:40:7F:0B:91:39
7) Host connection: (USB MSD)
Option 7 may be intersting - options are USB BSD, ETHERNET and USB RNDIS, which provides virtual ethernet over USB - fairly sure the latter is what enabled the i7 hackAs Mike said, if 7) is changed to USB RNDIS (and may be that IP address and subnet mask also need to be set manually and DHCP disabled - if the PC doesn't assign them automatically over USB), the web service can be accessed.
Now, as for the A310 FLIR (the attached PDF with Technical Notes), it must be password protected, but I see that the password is already known:
webpasswd "IRCAM" Therefore (stating the obvious) the login info should be:
Username: flir
Password: IRCAM
Could someone try this?
P.S. With the risk of being Cpt. Obvious, I just want to be involved in this and help if I can do so