Olympus e/mju/stylus series FW analysis

[Altsoph]

This topic started for decryption, structure analysis and disasm of Olympus e/mju/stylus series FW.

[Altsoph]

Olympus e/mju/stylus series web firmware filename always is
OLY_E_xxx_yyyy_0000_0000.BIN, where x,y -- any decimal digit.

Main structure of FW is:

<fw_block>[<fw_block>...]

where:

<fw_block> = <block_head><encrypted_data_block><block_tail>

<block_head> and <block_tail> sizes always eq 20h bytes.
<encrypted_data_block> has variable length.

Structure of <block_head> is:

<block_type_signature> (2b) -- always 4Fh 45h or 4Fh 4Dh. See some ideas about it below.
<model_signature> (2b)  -- camera code, always eq "xx x0" from FW filename.
<zero_padding> (4b) -- always zeros.
<loading_offset> (4b) -- probably, memory address, where data_block loaded after decryption.
<length_of_data> (4b) -- size of <encrypted_data_block>.
<update_version> (2b) -- version of block. First block (main update) version always eq "yy yy" from FW filename.
<zero_padding> (2b) -- always zeros.
<block_number> (2b) -- number of block in row. See some more info about it below.
<zero_padding> (6b) -- always zeros.
<zero_padding> (4b) -- always zeros (or checksum for <block_tail>).

First 1Ch bytes of <block_tail> always equals to same bytes from <block_head>.
Last 4 bytes contains checksum of block. Method of checksum calculation is not discovered yet

Some more info about block types and block numbering:
There are only two different block types known from existing FWs:
1. 4Fh 45h -- almost all blocks have this block type. Inside FW blocks of such type always go first. Numbers of such blocks are incremental (start from 01h 00h, continue by 01h 01h, 01h 02h, ...). Blocks of this type are loaded at memory always with big offset like 0x40XXXXXX or 0x60XXXXXX (depends on camera model).
2. 4Fh 4Dh -- strange rare blocks. In existing FWs there are maximum 1 such block per FW and this block always last in FW. Blocks of this type always contain 00h 00h in <block_number> field and offsets of such blocks are small (0x000E0000 or 0x0000B000).

Example of blocks list inside FW:

Code: [Select]

file: OLY_E_059_1001_0000_0000.BIN
type model ver     len          off           number
4F45 0590(1001) 003F7FC0 40040000 00000100
4F45 0590(1000) 002E7FC0 40438000 00000101
4F4D 0590(1001) 00018000 000E0000 00000000
Decryption of <encrypted_data_block> goes in two stages:
1. Each byte of data xored by FFh.
2. Each 10h bytes of data staffed by following scheme: string "0123456789abcdef" results in string "13026475ba98decf".

Blocks-extractor and data decryptor were attached by mx3 here: Olympus FW analysis

[Altsoph]

Some ideas about checksum calculation.

By comparing some FWs we can tell what different FWs (for different camera models) contain same or at least similar blocks:

OLY_E_052_1101_0000_0000.BIN:
mod   ver      size        offset
0520(0100) 000AFFC0 40A80000

OLY_E_056_1101_0000_0000.BIN
mod   ver      size        offset
0560(0100) 000AFFC0 40A80000

After depacking and decrypting these blocks it becomes clear, that data_blocks are identical.
<block_head>s have differences in field <model_signature> (05h 20h  VS 05h 60h).
<block_tail>s have same differences as <block_head>s.
Plus, checksum is changed from 18h B4h 02h 3Eh to 18h B4h 02h BEh.

So, we can tell what checksum calculated basing on data AND ( head or tail or (head and tail) ).
More interesting what only one byte of checksum changed.

Last thing not always correct:
type  mod  ver        size        offset      number   checksum
4F45 0550(0200) 0017FFC0 40410000 00000102 627B14D6
4F45 0560(0200) 0017FFC0 40410000 00000102 61A49AC0

So, the way of checksum calculation stays unclear

Any ideas?

[Altsoph]

One more thing about <offset> field.

I'm almost sure what this is exactly loading offset after comparing these blocks:

file: OLY_E_045_1102_0000_0000.BIN
type  mod   ver      size            off        number     chsm
4F45 0450(0100) 000AFFC0 60AD0000 00000104 BD87B418

file: OLY_E_052_1101_0000_0000.BIN
type  mod   ver      size            off        number     chsm
4F45 0520(0100) 000AFFC0 40A80000  00000104 3E02B418

I supposed what this is the same block in two different FWs.
But binary comparing of decoded data results in:

Code: [Select]

C:\>fc /b OLY_E_045_1102_0000_0000.BIN.04.body OLY_E_052_1101_0000_0000.BIN.04.body
00000006: AD A8
00000007: 60 40
0000000E: AD A8
0000000F: 60 40
...
0000023E: B6 B1
0000023F: 60 40
00000246: B6 B1
00000247: 60 40
So, it's look like changes in data are absolute address changes provoked by changing loading base.

[whim]

<block_type_signature> (2b) -- always 4Fh 45h or 4Fh 4Dh

wonder if it's just coincidence that 4F45 = 'OE' and 4F4D = 'OM' 

wim

[Altsoph]

4F45 = 'OE' and 4F4D = 'OM'

I have no idea what does it mean

[whim]

probably nothing, but maybe codes for Olympus E / Olympus Mju ?
just 'random' brainstorming though 

wim

[Altsoph]

Maybe

I still have no progress with chechsum reengineering
Any brainstorming thoughs?

[mx3]

bytes 14h-15h (maybe 16h,17h) - block type

Code: [Select]

example: OLY_E_049_1002_0000_0000.BIN
model ver  size     address  checksum flags
0490(1002) 0037FFC0 40040000 80754D99 00000100 - seems to be code. debug strings
0490(0200) 004EFFC0 405C0000 C95A30EA 00000101 - multilang block. - blocks of strings in different languages each precceded by binary sub-block
0490(0200) 0007FFC0 403C0000 2E6DEE86 00000103 - sounds - simple structure of block
0490(0200) 0017FFC0 40440000 5416253A 00000102 - jpgs - simple structure of block
0490(0100) 000AFFC0 40AB0000 5DB9B418 00000104 - more jpgs
0490(0400) 0001FFC0 40B60000 CD9033A6 00000105 - code. debug strings. some calibrator(?)


OLY_E_059_1001_0000_0000.BIN
model ver  size     address  checksum flags
0590(1001) 003F7FC0 40040000 4E2A1163 00000100 - code
0590(1000) 002E7FC0 40438000 95524F42 00000101 - hm. no strings. maybe different text encoding in e-series
0590(1001) 00018000 000E0000 B10CA47D 00000000 - have no idea. no strings

so block types are:
0x0100 - code
0x0101 - multilang block - font and messages - simple structure of block
0x0102 - jpgs - simple structure of block - easy to extract
0x0103 - sounds - simple structure of block - easy to extract
0x0104 - jpgs - simple structure of block - easy to extract
0x0105 - code

[Altsoph]

[mx3]

see attached file.
extracts sounds and jpgs :-)

[Altsoph]

Done with checksum 
Details later.

[Altsoph]

Checksum calculation is simple.

It's just starts from dword 0x00000000 and sub every dword of data from current checksum.
Checksum calculated from  <head>+<decrypted_data>+<tail> always equals zero.
So, checksum calculated from  <head>+<decrypted_data>+<tail without last 4 bytes> always equals dword, stored in last 4 bytes of tail.

Now, I think, we are ready to make our packer, and, if manual update thru /firmware/firmware.bin file works on e-series, we can make our correct updates from scratch and load it to camera.

Checksum calculator source is attached.

So, next step is to disasm some binary (code) block and find the way to make memory dumper -- thru memory card, USB or LEDs.

[PhyrePhoX]

you guys are geniuses. really.

[Altsoph]

Has anybody make some progress on decompiling something?
It looks not like normal ARM code for me