Fuji X100
Overview
- Firmware images (looking mostly at X100s): http://www.fujifilm.com/support/digital_cameras/software/firmware/x/compact/
- XOR with 0xFF -- strings appear, but with gaps.
- Total file size 01A1_85E8 bytes.
- Fuji's EXR CPU is clearly ARM based -- valid code sequences appear:
push {r4, r5, r6, r7, r8, r11, lr}
add r11, sp, #0x18
sub sp, sp, #0x34
bl sub_5ea4a0
mov r6, r0
mov r5, #0x0
strb r5, [#0xffffffdc](r11,)
strb r5, [#0xffffffde](r11,)
Header strings
Before XORing, are there 4 byte section types? Starts with 04 00 00 00, followed by 512 bytes of ASCII text containing values in the range 30 to 39. If that ASCII text is re-interpreted as a hex dump again, it becomes the string (for the X100s; the other cameras have a different value). Perhaps there are multiple updates included in the file and this is denoting which ones are present?
00026381 00026382 00026384 00026389 00000000....
Next section has values close to the file size (0x1a185e8) 0000240: 20 80 a1 01 20 80 a1 01 94 01 00 00 39 b0 ff ff ... .......9... 0000250: b4 81 a1 01 d8 01 00 00 80 c6 ff ff aa 55 00 ff .............U.. 0000260: 98 ba dc fe 10 32 54 76 ff ff ff ff ff fc ff ff .....2Tv........ 0000270: ee ff ff ff f7 ff ff ff ff ff ff ff ff ff ff ff ................
Marker 0xAA 55 00 FF (original) or 0x55 AA FF 00 (after XOR) every 0x200 bytes up to offset 0x7e50. Then switches to section type 0x13 00 00 eb, 64 KB each.
Section Markers
Markers:
| Offset | 4 byte Marker | Comment |
|---|---|---|
| 0x000000 | 04 00 00 00 | Start of file, 0x200 bytes of ascii-ascii-ascii |
| 0x000204 | 01 00 00 00 | Nothing? Empty section? |
| 0x000208 | 20 00 00 00 | Four bytes, 78 c1 b4 1b |
| 0x000210 | 01 00 00 00 | 0x28 bytes, all 0xFF |
| 0x000238 | 00 00 00 00 | 20 80 a1 01 20 80 a1 01 94 01 00 00 39 b0 ff ffb4 81 a1 01 d8 01 00 00 80 c6 ff ff |
| 0x00025c | aa 55 00 ff | Byte order markers, another 8 bytes of 98badcfe10325476, followed by 0x400 (minus 12) bytes of something. Repeats 32 times at 0x250, 0x650, ... 0x7e50. |
| 0x00825c | e7 0f 60 1a | Starts at 0x8250, repeats a few times then 0x100 bytes of someting and another 0x3F00 bytes of all 0x00. |
| 0x00c25c | 13 00 00 eb | (switching to inverted markers) 64 KB of ARM code |
| 0x01c25c | 13 00 00 eb | 64 KB of ARM code |
| 0x02c25c | ff ff ff ff | all 0xff until 0x48250 |
| 0x04825c | 00 00 00 00 | ? |
| 0x048260 | 00 00 04 00 | Followed by a0 d7 00 00 -- length? |
Section starting at 0x48260:
0048260: 00 00 04 00 a0 d7 00 00 20 00 04 00 00 08 0c 40 ........ ......@
0048270: 00 00 00 00 00 00 00 00 ff ff aa aa 00 50 a0 e1 .............P..
0048280: 43 0a 00 eb 00 00 50 e3 00 60 a0 03 a4 60 9f 15 C.....P.......
ffffaa looks like some sort of byte order marker? followed by a branch to a real function. Length of this section is 0xd780, so the green part must be a length field. Perhaps 0x40000, 0x40020 or 0x400c0800 is where it maps in RAM?
0x48260 + 0xd7a0 = 0x55A00, looks like lots of 0x00. later, at 0x58260 there is more code, also with length 0xd760, but mapped at 0xd0000?
all 0x00 or 0xff until 0x88250. no code there? all data of some sort.
a big section starts at 0xec260, header says 0x13b992 in length. that is the end of a section. lots of strings. no code? strings are corrupted? things like "ramebuffer_obje", where the leading F and trailing ct are missing. Bytes in the missing spaces are not in the ascii range:
011b9c0: <span style="color:red">0f</span> 72 61 6d 65 62 75 66 66 65 72 5f 6f 62 6a 65 .ramebuffer_obje
011b9d0: <span style="color:red">85 1a 91 33 06</span> 72 69 78 5f 67 65 81 2f 91 68 8f ...3.rix_ge./.h.
Reverse engineering Photography 2015