# Fuji X100

## Overview

push       {r4, r5, r6, r7, r8, r11, lr}
sub        sp, sp, #0x34
bl         sub_5ea4a0
mov        r6, r0
mov        r5, #0x0
strb       r5, [#0xffffffdc](r11,)
strb       r5, [#0xffffffde](r11,)


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.


Last update: November 8, 2020