Panasonic TZ10 firmware decode

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).
 
DaLiV said:
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
Click to expand...

Mind that A9-AE is negative... (I mean 6>1 and A9<AE)
 
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:
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 ...
 
DaLiV said:
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 ...
Click to expand...

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.
 
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.
 
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:
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:
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:
Vitaliy Kiselev said:
My differential analysys show some matching bytes sequences, but they are very few and end at about 20% of file length.
Click to expand...

I use to work with HexEdit and CSDiff. There are several parts almost identical across the firmware. These blocks are not at the same @, and some bytes are changing sometimes, but anyway it remains pretty close. However, most parts are totally different. I have several experiments to do yet, but I need time to write some C code for this...

Update: firmware contains some textual parts, if the XOR mask is repeated several times it might be possible to find, somewhere, a clear textual sequence. I've written a small code to test all position for this mask in TZ7 and TZ10 and report any "ascii-like" (I mean like the ones found in clear firmware) => failed, nada. Not even an abnormal dispersion of data anywhere (except at the position already known for this XOR sequence, of course). That's annoying...
 
Last edited:
Another request for English on TZ10

Another request for English on TZ10

Vitaliy Kiselev said:
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.
Click to expand...

Like Lundman, I also need an English menu for my TZ10.
If/when you or whomever finds a solution, I'll be happy to explore it.

Thanks.
 
Should be nice if we can put the ZS7 firmware on the TZ10, doing so, we remove the video lenght 30 minutes limit on TZ10!

Anyone who successed this?
Vitaliy Kiselev can you help us?

- Panasonic Lumix ZS7 => US version
- Panasonic Lumix TZ10 => EU version with video duration limit at 30 minutes
- Leica V-Lux 20 => I don't know if it comes with unlimited movie recording

Anyway these 3 models are the same hardware camera. This should be useful for decrypt, I think, for diffs in firmwares.

http://leicarumors.com/2010/07/10/leica-v-lux-20-firmware-update-v2-0-now-available.aspx/
http://panasonic.jp/support/global/cs/dsc/download/TZ10_ZS7/index.html (TZ10 and ZS7 firmwares)
 
Last edited:
anyone can help?
I don't really know how to do something like this!

I mean, it should be nice searching in the firmware for the video limit section, and then we can hack that...
 
manwithtz10 said:
anyone can help?
I don't really know how to do something like this!

I mean, it should be nice searching in the firmware for the video limit section, and then we can hack that...
Click to expand...

This is encrypted fimware.
And this is section for developers. Didn't you noticed that?
 
encrypted firmware = no hack ?
I noticed that is all freeze on july 2010...
For what I understood we (I mean you) can try to decrypt the firmware and then we can try to hack it removing the video time limit on TZ10...
Is this thread about TZ10 decryption? I'm just trying to ask you if you can work on this, because it was everything stopped on july of this year.
 
Last edited:
I am still around, but have not had any further luck or insight.

Is it possible that those with more Hardware knowledge than me can read the NVRAM off the camera to obtain the decrypted firmware?

Would it be beneficial to use the 16bit checksum, every 16 bytes, in the encrypted firmware to further guess each 16 bytes of XOR values? How many possibilities would there be where the 2 bytes checksum was valid?

Still no cameras with new firmwares that go from plain-text to encrypted ?
 
The junk camera part is easy, there is a TZ7 on the auction for 980yen (about $10). The rest I am not sure about, I'll ask around.
 
manwithtz10 said:
- Panasonic Lumix ZS7 => US version
- Panasonic Lumix TZ10 => EU version with video duration limit at 30 minutes
- Leica V-Lux 20 => I don't know if it comes with unlimited movie recording
Click to expand...

AFAIK, ZS7 v11 and TZ10 v11 are exactly the same file: ZS7_V11.zip contains a file named ZS7_V11.bin, but if you open it with an hexa viewer you find a TZ10 firmware in fact... I'll have a look at v12 tonite.

Update: same with V12 (I mean ZS7 update = TZ10 update)
 
Last edited:
You must log in or register to reply here.
Back
Top