Re: M10 Spent 3 days getting a toolchain which can build ixus160 to a working .BIN state. Proved my toolchain is good by compiling 160 from source, then booting what I built-from-src in my 160. @Reyalp, the recommended prebuilt toolchain didn't work for me, nor did their OS-specific-pkg toolchain. Working toolchain was made by following gcc 4.6.4 version on Ubuntu 15.10, x86_64.
I am surprised that the pre-built toolchain didn't work out of the box. If you can give more detail about what specifically didn't work, that might other avoid the pain in the future. That said, if you don't want to dive back into this it's understandable
OPT_FIRMWARE_PC24_CALL=1
I would NOT suggest using that. I'm not sure if it works at all in the current source, let alone for thumb 2, but in any case known thumb2 firmwares don't meet the requirements specified in the buildconf.inc comment.
Took a lot of notes from the various and numerous failures. My toolchain also builds the "patched" capstone libs.
You should be able to build capstone with the regular x86/x64 gcc provided by your distro. I hope this is what you mean.
Using these tools, experienced devs and other informed ppl are able to determine that the M10 has DryOS v 57, and the sx280 & g7x are something else.
Other known r57 cams are G3x and sx710.
Philmoz has done quite a bit of work on g5x, which is r58.
sx280 is r52, and g7x is r55p6
I need to learn for myself how that value is determined within the BIN file - what address or sig represents the DryOS version?
For that one, I just open up the .bin file in vim and search for DRYOS
(finsig_thumb2 finds it too, using essentially the same method)
Same for rowpix vals, and all other critical vals. Not asking for gurus to solve it for me. Gotta learn this (and any pre-req's ! ) before proceeding. Using $DRYOSVERSION and $ROWPIX as learning examples.
It depends on the value. For raw dimensions on G7x, I used exiftool to dump a camera CRW and used the "Sensor Width" and "Sensor Height" values. (only applicable on cameras with native raw)
I checked this by searching the dump for "CRAW BUFF SIZE" (which I know from other cameras refers to the actual sensor data size), and finding the value printed with that.
fc4f1ffe: 492d ldr r1, [pc, #180] ; 0xfc4f20b4: (01de3e00)
fc4f2000: a02d add r0, pc, #180 ; 0xfc4f20b8: (57415243) *"CRAW BUFF SIZE %p"
fc4f2002: f63b fb06 bl loc_fc32d612
0x1de3e00 = 31342080 = (5632*3710*12)/8
This is the general method we use to find a lot of stuff:
Find some "landmark" that is somehow associated with the value in a known firmware (e.g. the sx280).
Find the equivalent landmark in your own firmware.
If you are lucky, the landmark is a unique string that is used with the value as in the example above.
If you are less lucky, it's something less straightforward, like the function that references some string is called by some other function, and that function also calls another function that is somehow related to the thing you are looking for. Or maybe you just know that two functions appear close together in the firmware, and you look at the disassembly to recognize the one you want.
From this it should be clear that it's a good idea to have several already known firmwares disassembled, in addition to the one you are working on. For the g7x, I used the sx280 and ixus140 mostly. Even though ixus140 is a different instruction set, much of the code is easily recognizable, and I already have it well analyzed because I did that port.
Some ports have comments on how things are found, but beware that comments are often blindly copied. I've been trying to leave a lot of comments on g7x (also my ixus140_elph130 and d10 ports). The comment usually refer to an address in the camera firmware, or some other landmark.
The "landmark" approach is essentially what finsig_thumb2 does. The bad news for you is that most of the things that are easy to find this way are already found. The stuff that it doesn't find is mostly tricky in some way, though in some cases it's easy for a human but hard to specify in code. There are also a few things I just haven't gotten around to yet.
If you are unlucky, the code related to thing you are looking for isn't similar to any known port. Then you have to do original research. How you do this really depends on what you are looking for.
Sorry for the wall of text, hopefully it's useful.