Page 1 of 5 12345 LastLast
Results 1 to 10 of 44
  1. Collapse Details
    Panasonic TZ10 firmware decode
    #1
    Junior Member
    Join Date
    Jun 2010
    Posts
    8
    Default
    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.


     

  2. Collapse Details
    #2
    Senior Member
    Join Date
    Dec 2009
    Posts
    197
    Default
    Quote Originally Posted by lundman View Post
    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.


     

  3. Collapse Details
    #3
    Bronze Member
    Join Date
    Apr 2010
    Posts
    2,415
    Default
    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.


     

  4. Collapse Details
    #4
    Junior Member
    Join Date
    Jun 2010
    Posts
    8
    Default
    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:

    Code:
    00000000  fc dc 00 00 08 54 f2 f0  2c 00 04 03 20 84 2c 00  |.....T..,... .,.|
    which (i believe) translates as:

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

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

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


     

  5. Collapse Details
    #5
    Bronze Member
    Join Date
    Apr 2010
    Posts
    2,415
    Default
    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.


     

  6. Collapse Details
    #6
    Junior Member
    Join Date
    Jun 2010
    Posts
    8
    Default
    Let me test RC4:

    Code:
                {"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.
    Last edited by lundman; 06-22-2010 at 11:14 PM.


     

  7. Collapse Details
    #7
    Junior Member
    Join Date
    Jun 2010
    Posts
    8
    Default
    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" ?


     

  8. Collapse Details
    #8
    Junior Member
    Join Date
    Jun 2010
    Posts
    13
    Default
    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.
    Last edited by JFMw; 06-25-2010 at 08:28 AM.


     

  9. Collapse Details
    #9
    Bronze Member
    Join Date
    Apr 2010
    Posts
    2,415
    Default
    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.


     

  10. Collapse Details
    #10
    Senior Member
    Join Date
    Jun 2010
    Location
    Latvia
    Posts
    168
    Default
    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 )
    Last edited by DaLiV; 06-25-2010 at 09:48 AM.


     

Page 1 of 5 12345 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •