Announcement

Collapse
No announcement yet.

Panasonic TZ10 firmware decode

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    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)
    russian forums about video. http://forum.videoediting.ru & http://forum.1dv.ru

    Comment


      #17
      Originally posted by DaLiV View Post
      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...)

      Comment


        #18
        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
        Last edited by DaLiV; 06-26-2010, 04:27 AM.
        russian forums about video. http://forum.videoediting.ru & http://forum.1dv.ru

        Comment


          #19
          Originally posted by DaLiV View Post
          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:

          Originally posted by Vitaliy Kiselev View Post
          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.
          Last edited by JFMw; 06-26-2010, 07:21 AM.

          Comment


            #20
            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 ...
            russian forums about video. http://forum.videoediting.ru & http://forum.1dv.ru

            Comment


              #21
              I do not believe in compressor as sizes are clearly round and TZ7 v1.20 and TZ7 v1.40 have exactly same size.
              Normally each compressor have frequency encoding (like huffman) for symbols and lengths.
              And byte boundaries are not preserved (only simple variations like LZO preserve bytes).

              Comment


                #22
                Originally posted by DaLiV View Post
                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
                Mind that A9-AE is negative... (I mean 6>1 and A9<AE)

                Comment


                  #23
                  At least a good finding...

                  @000200:

                  TZ10 16.592.384 = xFD2E00 (xFD2C00) => 5B 2B 18 AC
                  TZ9 10.290.688 = x9D0600 (x9D0200) => 5B 2B 10 9C
                  TZ8 16.057.856 = xF50600 (xF50400) => 5B 2B 11 9C
                  TZ7 10.028.544 = x990600 (x990400) => 5B 2B 1E 9C
                  TZ6 9.831.936 = x960600 (x960400) => 5B 2B 1F 9C
                  ZX1 9.274.880 = x8D8600 (x8D8200) => 55 29 18 9C
                  ZX3 10.825.216 = xA52E00 (xA52C00) => 55 29 1A 9C
                  FZ38 10.290.688 = x9D0600 (x9D0200) => 49 2B 1A A4

                  1st conclusion: it's not linked to the firmware size (FZ38 & TZ9)
                  2nd conclusion: it's, again, the camera name encrypted

                  T-Z = -(5B-55)
                  Z-X = 2B-29
                  1-3 = -(18-1A) [note that both 1 = 18 in TZ10 and ZX1, 3 = 2B in ZX3 and FZ38]
                  7-6 = -(1E-1F)
                  9-8 = -(10-11)
                  the strange point, and probably a key element, is in 8-7... (and the changing +/- sign)

                  More info:
                  FS15 = 49 22 18 A9 [1 = 18 again, and F = 49]
                  FS62 = 49 22 1F AE [6 = 1F again]
                  FT2 = 49 25 1B 9C

                  X-T = 29-25
                  but I can't explain T = 49, S = 22 and 2 = 1B
                  Last edited by JFMw; 06-28-2010, 01:01 PM.

                  Comment


                    #24
                    FYI : - (01 - 00) = 00 - 01 (with parity bit set)
                    T<Z 5b>55 +07/-F9
                    Z>X 2b>29 +D1/-2F
                    1<3 18<1a +e7/-19
                    7>6 1e<1f +e7/-19
                    9>8 10<11 +D7/-29

                    explanation - there is some added table (example by circle get values +2+4+5+4+6+7, in that example have period=6, but lenght of their is not unknown ...)
                    work must be done by iterations and searching known words, and based on that possible can be detected full table ...
                    russian forums about video. http://forum.videoediting.ru & http://forum.1dv.ru

                    Comment


                      #25
                      Originally posted by DaLiV View Post
                      FYI : - (01 - 00) = 00 - 01 (with parity bit set)
                      T<Z 5b>55 +07/-F9
                      Z>X 2b>29 +D1/-2F
                      1<3 18<1a +e7/-19
                      7>6 1e<1f +e7/-19
                      9>8 10<11 +D7/-29

                      explanation - there is some added table (example by circle get values +2+4+5+4+6+7, in that example have period=6, but lenght of their is not unknown ...)
                      work must be done by iterations and searching known words, and based on that possible can be detected full table ...
                      I don't believe in a +/- values long table: encryption seems to be less sophisticated. If you compare firmwares, for example @000200 to @000400, you'll notice that data is just a little different: some 32bits words are missing or inserted, but next words are unchanged. To illustrate, let's say we have blocks A B C D E in firmware 1, and A X B C E in firmware 2 => block X should have changed encryption scheme for block B in firmware 2... and this is not the case. If you compare the whole firmware with tools, you'll notice this at several places across the firmware: that's why I would look for a simple 32bits translation table/function. Then, in a translation table there is no reason for words "TZ10" and "TZ9?" to give an approaching encrypted value => a 32bits translation function is a better hypothesis.

                      Data @000200 tends to prove the function is working at byte level in 32bits words: I would suggest a combination of bits swapping, neg and xor-ing. What I discovered @000200 gives us several clear-encrypted values at a same position, for 3 consecutive positions... not that bad.

                      Comment


                        #26
                        I will go with what you guys suggest, and it starts with the model name, not the same as the plaintext TZ5.

                        If that is the case, this appears to work well:

                        XOR table:
                        0f 71 29 9c ...

                        Code:
                                                 XORed
                        TZ10 => 5B 2B 18 AC      54 5A 31 30  "TZ10"
                        TZ9  => 5B 2B 10 9C      54 5A 39 00  "TZ9" null
                        TZ8  => 5B 2B 11 9C      54 5A 38 00  "TZ8" null
                        TZ7  => 5B 2B 1E 9C      54 5A 37 00  "TZ7" null
                        TZ6  => 5B 2B 1F 9C      54 5A 36 00  "TZ6" null
                        ZX1  => 55 29 18 9C      5A 58 31 00  "ZX1" null
                        ZX3  => 55 29 1A 9C      5A 58 33 00  "ZX3" null
                        FZ38 => 49 2B 1A A4      46 5A 33 38  "FZ38"
                        FS15 => 49 22 18 A9      46 53 31 35  "FS15"
                        FS62 => 49 22 1F AE      46 53 36 32  "FS62"
                        FT2  => 49 25 1B 9C      46 54 32  00 "FT2" null
                        As for the rest of the table, I don't know.

                        Why do typing a reply in here go to a fish-tank whenever I push left-cursor key? It is extremely annoying.

                        Comment


                          #27
                          Originally posted by lundman View Post
                          XOR table:
                          0f 71 29 9c ...
                          You took the words right out of my mouth , XOR(0F 71 29 9C) for block @000200. Good start, only 16MB left to figure out...

                          Comment


                            #28
                            Some (good) news:

                            TZ6v15 @00001C: 4D 00 50 01 04 00 00 00 02 18 02 04
                            TZ6v15 @000210: C1 98 5D E8 34 27 36 2E AA F7 32 54
                            XOR => 8C 98 0D E9 30 27 36 2E A8 EF 30 50

                            TZ6v12 @00001C: 49 00 20 01 04 00 00 00 45 20 08 06
                            TZ6v12 @000210: C5 98 2D E8 34 27 36 2E ED CF 38 56
                            XOR => 8C 98 0D E9 30 27 36 2E A8 EF 30 50

                            XOR[000210] = 8C 98 0D E9 30 27 36 2E A8 EF 30 50

                            Update: as noticed previously, TZ7 has an inserted 32bits block @000204 => this block does roll xor masks
                            XOR-TZ6[000210] = 8C 98 0D E9 30 27 36 2E A8 EF 30 50
                            XOR-TZ7[000210] = F0 9B 9F F2 8C 98 0D E9 30 27 36 2E A8 EF 30 50
                            we can suppose 00 00 00 00 both before and after, which gives masks step-by-step:
                            XOR-TZ6[000204] = XOR-TZ7[000208] = AA 58 4C 22 20 90 4E A7 F0 9B 9F F2 8C 98 0D E9 30 27 36 2E A8 EF 30 50 B7 F5 10 BD

                            but again, what I really don't understand (yet) is this extra block "43 B5 B2 DD" in TZ7v14 @000204... any idea?
                            Last edited by JFMw; 07-01-2010, 07:54 AM.

                            Comment


                              #29
                              Hmm that is interesting. But it does not appear to work on the TZ10 firmware.

                              BTW, I believe that 1e and 1f bytes are the firmware version. Not sure about 1c 1d, which appear to have the same value on TZ10, but quite different on TZ6.

                              TZ10
                              Code:
                              00000010  00 00 00 00 00 00 00 00  00 00 00 00 11 01 11 01  |................|
                              V1.11 repeated twice.

                              TZ6:
                              Code:
                              00000010  00 00 00 00 00 00 00 00  00 00 00 00 49 00 20 01  |............I. .|
                              V1.2 build 73?

                              Yours would presumably be
                              v1.5 and v1.2 (build 77, and 73)

                              Since the header starts at 1c with the model name, TZ10, and it is encoded at 0200, do we think maybe that the header is copied again at 0200 for 'some length'?

                              Edit:

                              If I follow your suggestion, I get the following table:

                              Code:
                              00000200  0f 71 29 9c 43 b5 b2 dd  aa 58 4c 22 20 90 4e a7
                                               f0 9b 9f f2 8c 98 0d e9  30 27 36 24 53 c9 d4 54
                              which is the same until E9 30 27 36 ... then it differs.

                              The 'fishcam on left cursor key' has lost quite a few edits here, so I don't feel like posting for a while.
                              Last edited by lundman; 07-01-2010, 05:14 PM.

                              Comment


                                #30
                                red is unsure
                                green is (almost) sure

                                TZ10v11 @000200

                                Clear text
                                54 5A 31 30 00 00 00 00 00 00 00 00 00 00 00 00
                                11 01 11 01 04 00 00 00 37 21 04 06 FB 26 E4 04 <= this one is strange...
                                1F 18 20 ED

                                Xor mask
                                0F 71 29 9C 43 B5 B2 DD AA 58 4C 22 20 90 4E A7
                                F0 9B 9F F2 8C 98 0D E9 30 27 36 2E A8 EF 30 50
                                B7 F5 10 BD

                                TZ7v14 @000200

                                Clear text
                                54 5A 37 00 00 00 00 00 00 00 00 00 00 00 00 00
                                55 00 40 01 04 00 00 00 02 18 02 04 00 00 00 00
                                C4 40 AF 85

                                Xor mask (same as TZ10)
                                0F 71 29 9C 43 B5 B2 DD AA 58 4C 22 20 90 4E A7
                                F0 9B 9F F2 8C 98 0D E9 30 27 36 2E A8 EF 30 50
                                B7 F5 10 BD

                                TZ6v15 @000200

                                Clear text
                                54 5A 36 00 00 00 00 00 00 00 00 00 00 00 00 00
                                4D 00 50 01 04 00 00 00 02 18 02 04 00 00 00 00 <= guess (due to TZ7)

                                Xor mask (beware: 43 B5 B2 DD is missing!)
                                0F 71 29 9C AA 58 4C 22 20 90 4E A7 F0 9B 9F F2
                                8C 98 0D E9 30 27 36 2E A8 EF 30 50 B7 F5 10 BD

                                @00001E = @000212 = version
                                @000040 = checksum 16 bytes
                                @000220 = checksum 16 bytes (different)

                                Data after @000230 are very close again (TZ7 = TZ10, and TZ6 has again 4 bytes missing) => another block filled with a pattern
                                Last edited by JFMw; 07-02-2010, 05:00 AM.

                                Comment

                                Working...
                                X