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 )

 

[JFMw]

My mother tongue is not English, my explanations might be "encrypted" :huh:

Here is a simple example:
firmware TZ6_15, address @0204 => AA 58 4C 22 20 90 4E A7
firmware TZ7_14, address @0208 => AA 58 4C 22 20 90 4E A7
firmware TZ10_11, address @0204 => AA 58 4C 22 20 90 4E A7

Of course, it's almost sure that "AA 58 4C 22 20 90 4E A7" is the encrypted value for the same clear text in TZ6, TZ7 and TZ10, so (if we call F() the encryption function) we have F@0204(cleartext) = F@0208(cleartext) and we can assume F@0204() = F@0208().

=> F() doesn't depend on the "past", and F() length is <= 4 bytes

Also note:
TZ6 @0200 => 5B 2B 1F 9C
TZ7 @0200 => 5B 2B 1E 9C
TZ10 @0200 => 5B 2B 18 AC

I believe "5B 2B" is the encrypted value for the same clear text, which means that 3rd and 4th bytes don't change encryption for 1st and 2nd bytes.

 

[DaLiV]

0x200 - too early for clear texts, but some code possible
key of F() is not dynamic, as TZ6 and ZS1 is look very similar (only some bytes in middles).
F() lenght is more than 4 bytes (think at least one empty/pattern block in firmware will be - and that may be easy found visually in short cases)

 

[DaLiV]

TZ6 : @0x490510
00 CB E5 49 C5 18 A9 27 B6 53 DD 8B 6D CC 14 09
ZS1 : @0x490510
00 CB E5 49 CB 11 AE 27 B6 53 DD 8B 6D CC 14 09
T-Z = C5-CB : +0x71
Z-S = 18-11 : +0xBE
6-1 = A9-AE : +0x73

Possible "Panasonic TZ6" instead of space is 0x00

 

[Vitaliy Kiselev]

TZ6 : @0x490510
00 CB E5 49 C5 18 A9 27 B6 53 DD 8B 6D CC 14 09
ZS1 : @0x490510
00 CB E5 49 CB 11 AE 27 B6 53 DD 8B 6D CC 14 09
T-Z = C5-CB : +0x71
Z-S = 18-11 : +0xBE
6-1 = A9-AE : +0x73

Do you want to say that we have
Result = Source+Encryption ?
As if difference is still maintained it is not XOR

Total difference in this files (without header and checksums):

00000218: ED B0
00000219: CF E7
0000021A: 38 39

00004E0C: FD A0
00004E0D: AE 86
00004E0E: 8F 8E

00014514: 59 57
00014515: 53 5A
00014516: 6D 6A

00490514: C5 CB
00490515: 18 11
00490516: A9 AE

We always have groups of three bytes

 

[JFMw]

TZ6 : @0x490510


00 CB E5 49 C5 18 A9 27 B6 53 DD 8B 6D CC 14 09
ZS1 : @0x490510
00 CB E5 49 CB 11 AE 27 B6 53 DD 8B 6D CC 14 09
T-Z = C5-CB : +0x71
Z-S = 18-11 : +0xBE
6-1 = A9-AE : +0x73

Possible "Panasonic TZ6" instead of space is 0x00

I would vote for DMC-TZ6

TZ4@0152F0
50 61 6E 61 73 6F 6E 69 63 00 00 00 00 00 00 00 = Panasonic
44 4D 43 2D 54 5A 34 00 00 00 00 00 00 00 00 00 = DMC-TZ4

TZ5@0152F0
50 61 6E 61 73 6F 6E 69 63 00 00 00 00 00 00 00 = Panasonic
44 4D 43 2D 54 5A 35 00 00 00 00 00 00 00 00 00 = DMC-TZ5

 

[DaLiV]

Also: I've noticed that all clear firmware end the same way:
...
and then 34 bytes that differ

in encoded changed structure ... checksum (which was in last 34) moved to first 512 ... so helpless information ...
about end block - that will be easily visible pattern (however in encoded not observed any repeating patterns)

 

[JFMw]

in encoded changed structure ... checksum (which was in last 34) moved to first 512 ... so helpless information ...
about end block - that will be easily visible pattern (however in encoded not observed any repeating patterns)

... and why not a compressed format, followed byt a 4 bytes permutation?
That would explain the leading bytes @000200 (like a PK/LZ/Rar header...)

 

[DaLiV]

becaus in compression on change 1 byte in mddle you will get big block changes, not only some bytes.
header persist not only in compressed structures.

offtopic:
try any compressor on text file, change there 1 byte and create second compressed file - make diff between them and take a look how it differs on one byte changes ... then questions will be gone ... normally not possible to get for changing 1 byte in compressed file also changing of 1 byte ...
only Run-length encoding possible

 

[JFMw]

becaus in compression on change 1 byte in mddle you will get big block changes, not only some bytes.
header persist not only in compressed structures.

I have to disagree, (1) you still have blocks 100% untouched, (2) some blocks modified are still very close with only minor changes every 5 or 10 bytes (and some bytes missing, some bytes added), (3) and in fact this is exactly the same behavior when I compare TZ6 and TZ7...

(FYI, I've modified GH1_133, changing GH1.AHX to GH2.AHX, compressed with WinZip, and compared files the same way I'm comparing TZ6 and TZ7 files... try yourself, I'm pretty sure you'll be convicted)

Update 1: however differences between ZS1 and TZ6 should be more important than a few bytes... you're right.

Update 2:

00000218: ED B0
00000219: CF E7
0000021A: 38 39

00004E0C: FD A0
00004E0D: AE 86
00004E0E: 8F 8E

00014514: 59 57
00014515: 53 5A
00014516: 6D 6A

00490514: C5 CB
00490515: 18 11
00490516: A9 AE

Changes at the beginning and the end of the file look like the filename in a zip archive... that's strange.

 

[DaLiV]

blocks that is before changes may be untouched (depend on compressor and it usage of dictionary size), but after - changes is very big ... and size of .zip also changes ...