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:
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