Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 44
  1. Collapse Details
    #21
    Bronze Member
    Join Date
    Apr 2010
    Posts
    2,415
    Default
    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).


     

  2. Collapse Details
    #22
    Junior Member
    Join Date
    Jun 2010
    Posts
    13
    Default
    Quote 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)


     

  3. Collapse Details
    #23
    Junior Member
    Join Date
    Jun 2010
    Posts
    13
    Default
    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 at 02:01 PM.


     

  4. Collapse Details
    #24
    Senior Member
    Join Date
    Jun 2010
    Location
    Latvia
    Posts
    168
    Default
    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 ...


     

  5. Collapse Details
    #25
    Junior Member
    Join Date
    Jun 2010
    Posts
    13
    Default
    Quote 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.


     

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


     

  7. Collapse Details
    #27
    Junior Member
    Join Date
    Jun 2010
    Posts
    13
    Default
    Quote 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...


     

  8. Collapse Details
    #28
    Junior Member
    Join Date
    Jun 2010
    Posts
    13
    Default
    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 at 08:54 AM.


     

  9. Collapse Details
    #29
    Junior Member
    Join Date
    Jun 2010
    Posts
    8
    Default
    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 at 06:14 PM.


     

  10. Collapse Details
    #30
    Junior Member
    Join Date
    Jun 2010
    Posts
    13
    Default
    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 at 06:00 AM.


     

Page 3 of 5 FirstFirst 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
  •