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 differin 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 ...

[Vitaliy Kiselev]

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).

[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

Mind that A9-AE is negative... (I mean 6>1 and A9<AE)

[JFMw]

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

[DaLiV]

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

[JFMw]

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.

[lundman]

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



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.

[JFMw]

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

[JFMw]

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?

[lundman]

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


00000010 00 00 00 00 00 00 00 00 00 00 00 00 11 01 11 01 |................|
V1.11 repeated twice.

TZ6:


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:



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.

[JFMw]

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

[JFMw]

My differential analysys show some matching bytes sequences, but they are very few and end at about 20% of file length.

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

[dooglesb]

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.

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.

[manwithtz10]

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)

[manwithtz10]

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

[Vitaliy Kiselev]

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

This is encrypted fimware.
And this is section for developers. Didn't you noticed that?

[manwithtz10]

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.

[lundman]

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 ?

[lundman]

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]

New firmware for TZ10, but is not interesting, I suppose... http://panasonic.jp/support/global/cs/dsc/download/TZ10_ZS7/index2.html

[JFMw]

- 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


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)

[manwithtz10]

Maybe, it's not a firmware flash, but a sort of update file and the camera can use it to update its flash.
Otherwise, again maybe, this .bin should be entirely flashed in the rom camera, then the camera use wether the ZS7 or TZ10 section of the firmware depending on its model ID.

Those .bin seemed updates to me, because 1.1=>1.2 took a very little time to update, 1.0=>1.1 took longer time, so it seems like is not flashing it entirely, but the camera use the file to update its flash, only what it needs of the .bin files.

[lfarah]

Vamos esperar algum vietnamita desvendar o misterio de como incluir outros idiomas na TZ10.
Se depender do caboclo ai que so sabe falar dificil e nao ajuda em nada, estamos fodidos !!!

[hoelzlmani]

Maybe, it's not a firmware flash, but a sort of update file and the camera can use it to update its flash.
Otherwise, again maybe, this .bin should be entirely flashed in the rom camera, then the camera use wether the ZS7 or TZ10 section of the firmware depending on its model ID.

Those .bin seemed updates to me, because 1.1=>1.2 took a very little time to update, 1.0=>1.1 took longer time, so it seems like is not flashing it entirely, but the camera use the file to update its flash, only what it needs of the .bin files.


i bought the zs7 and there are only 2 languages on it. can i use the
tz10 firmware to get german language on it? is this working and possible or not?

thanks for helping me

[Vitaliy Kiselev]

Consider thread closed.

TZ10 firmware is dumped, all discussion move to

http://www.personal-view.com/talks/discussion/15/official-tz10-hack-project-discussion (http://www.personal-view.com/talks/discussion/15/official-tz10-hack-project-discussion)