Panasonic TZ10 firmware decode

[lundman]

Are we allowed to discuss the possibility to decrypt/decode the Panasonic firmwares, and if so, is in here ok, or some other sub-forum?

My goal would be to be able to change the language from Japanese to English. I've heard I can do so on TZ5 (?) but currently looking at TZ10.

[tyampel]

Are we allowed to discuss the possibility to decrypt/decode the Panasonic firmwares, and if so, is in here ok, or some other sub-forum?

My goal would be to be able to change the language from Japanese to English. I've heard I can do so on TZ5 (?) but currently looking at TZ10.

The TZ5 had an unencrypted firmware release.
The TZ7's firmware was encrypted.
I am afraid the TZ10 firmware will be too.
Makes it very hard to work with as one needs to break the encryption first.

[Vitaliy Kiselev]

Yes, encryption is the problem here.
TZ5 is not a problem, but I don't see any reason, as even Eenglish is extra cheap now.
So, is lundman will be able to understand how this thing work, it'll be very interesting.

[lundman]

I take the replies, without a ban, as an indication that it is ok to chat about it here.

TZ5 firmware is indeed not encrypted, and looks like this:

00000000  fc dc 00 00 08 54 f2 f0  2c 00 04 03 20 84 2c 00  |.....T..,... .,.|

which (i believe) translates as:

    mov   0x54080000, A0
    mov   A0,SP
    mov   0x400, D0
    movhu D0, (0x8420)
    mov   0x400, D0
    movhu D0, (0x8422)

Now, taking a look at TZ10 firmware, which starts with:

00000000  55 50 44 00 00 02 00 00  01 01 00 00 54 5a 31 30  |UPD.........TZ10|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 11 01 11 01  |................|
00000020  04 00 00 00 37 21 04 06  00 00 00 00 02 00 00 00  |....7!..........|
00000030  00 00 00 00 01 00 00 00  00 02 00 00 00 2c fd 00  |.............,..|
00000040  1e 4d 82 78 07 bb 65 26  4d 4a 17 f2 a8 9c ae 3d  |.M.x..e&MJ.....=|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Which seems to be your standard header. The bytes at 0x30-0x3f appear to be "number of files (1)", "starting offset (0x200)" and "file length (0xfd2c00)".

The bytes at 0x40-0x4f looks a lot like a digest, maybe md5 or something along those lines.

Now the first bytes of the actual TZ10 firmware are:

00000200  5b 2b 18 ac 43 b5 b2 dd  aa 58 4c 22 20 90 4e a7  |[+..C....XL" .N.|

and as comparison, the first few bytes of TZ7 firmware:

00000200  5b 2b 1e 9c 43 b5 b2 dd  aa 58 4c 22 20 90 4e a7  |[+..C....XL" .N.|

What is interesting there, is that there are 2 bytes that differ, and the rest are the same. This would suggest that they are not using AES/Blowfish or similar strong ciphers. As it happens, those two bytes (in TZ5) are the lower two bytes of the stack-pointer it loads. (Which could differ between the cameras after all). Ie, the 0000 in 0x54080000.

If that is indeed the case, 0x5b->0xfc, 0xdc->0x2b.

Checking XOR (and let's be honest, it is used far too much) but there are no discerning patterns that you tend to get. So perhaps something else, or based on offset or similar. Both encrypted firmware are about 90% identical in the first 200 bytes or so.

They do not appear to be compressed.

[Vitaliy Kiselev]

I did some firmware decryption reversing in case of Pentax bodies.

Here is method I suggest you to try.

Write small tool that will be able to xor TZ7 and TZ70 firmware files.
And run statistic analysys on resulted files (count number of each unique byte values).
For example, they can use simple RC4, it'll also result in identical values in case of same key.

[lundman]

Let me test RC4:

            {"Key", "Plaintext"},
            {"Key", "Ploantext"},

BBF316E8D940AF0AD3
BBF318E0D940AF0AD3

It does indeed behave the same way. I shall test this method next..

Edit:

I notice that the TZ5 firmware still has the checksum bytes every 32 bytes, and indeed, TZ10/TZ7 would appear to have the same, but if they do, they are computed after decode.

[lundman]

Been reading the materials available on RC4 and WEP, in particular the FMS paper on the IV weakness. But I am not entirely sure I can use that in this case.

The FMS method seems based on that each packet starts with 3 bytes of IV, followed by a known byte (0xaa). Then it waits for sufficient enough of weak IVs (A+3, 255, X) before it can work its magic.

In this case, we do know the first byte (and about 512 bytes at the start). But there is no IV, per se. Nor do I know how long their key even is (or if it is a standard RC4).

Presumably these devices do not use secure flash, so has any hardware hackers dumped a flash from FZ7/FZ10 cameras, or any others whose firmware file starts with "UPD" ?

[JFMw]

Comparing TZ6 and TZ7, we find exactly same data @2B44->@45AB(TZ7) and @2B98->@45FF@(TZ6)

Offset between those addresses is 84 bytes, it gives 3 possible hints:
(1) encryption may be a pattern computation (something like a sophisticated XOR)
(2) encryption pattern is <= 84 and 84 is a multiple of the pattern length
(3) pattern is probably the same for the whole firmware

Btw, I've also noticed TZ4 and TZ5 first x4000 bytes (unencrypted) are equal...

Ok, let's continue:
TZ6 @5A67->@85FF
TZ7 @5A1F->@85B7
TZ10 @5307->@7E9F

Interesting, offset is 72 bytes this time (TZ6-TZ7) and 1888 (TZ6-TZ10)...? (or 1816 between TZ10 and TZ7)

Ok, again:
TZ6 @4304
TZ7 @42B0
TZ10 @3BA8

Offsets are 1800 and 84 this time.... + 1816 and 72 => length is 4 bytes.

I won't have time to go deeper, but if we compare @0200->@0400 between TZ6, TZ7 and TZ10, we can extract "fixed" values and compare them to values seen in TZ4 and TZ5 (assuming fixed values will be the same across all firmware, which makes sense). This will give a partial "translation" table.

[Vitaliy Kiselev]

Sorry, don't get your logic and explanation fully.

84 offset can mean anything.

Offsets can arise from simple code changes and not related to encryption at all.

[DaLiV]

try analyze on firmwares of
TZ6 and ZS1 (one model , regional names) - very similar files (differ by header 3 bytes, CRC in header and 4 blocks by 3 bytes )