Tagged with g9 - Personal View Talks https://personal-view.com/talks/discussions/tagged/g9/feed.rss Sat, 23 Nov 24 11:13:52 +0000 Tagged with g9 - Personal View Talks en-CA Panasonic G9, m43 4K monster with LCD on top https://personal-view.com/talks/discussion/18085/panasonic-g9-m43-4k-monster-with-lcd-on-top Sun, 29 Oct 2017 11:02:49 +0000 Vitaliy_Kiselev 18085@/talks/discussions image

Specs:

Video modes

  • 3840 x 2160 @ 60p at 150 Mbps, MP4, H.264, Linear PCM
  • 3840 x 2160 @ 30p at 100 Mbps, MP4, H.264, AAC
  • 3840 x 2160 @ 23.98p at 100 Mbps, MP4, H.264, AAC
  • 1920 x 1080 @ 60p at 28 Mbps, MP4, H.264, AAC
  • 1920 x 1080 @ 30p at 20 Mbps, MP4 or AVCHD, H.264, AAC
  • 1920 x 1080 @ 60i at 24 Mbps, AVCHD, MTS, H.264, Dolby Digital
  • 1920 x 1080 @ 60i at 17 Mbps, AVCHD, MTS, H.264, Dolby Digital
  • 1920 x 1080 @ 23.98p at 24 Mbps, AVCHD, MTS, H.264, Dolby Digital

image

]]>
Lumix G9 firmware reverse engineering https://personal-view.com/talks/discussion/24266/lumix-g9-firmware-reverse-engineering Fri, 14 Aug 2020 08:31:54 +0000 jverbeek 24266@/talks/discussions Hey there, I recently got myself a Lumix G9 and was keen to look into the firmware. I'm hitting a roadblock, but maybe somebody can help me :)

The .bin firmware you can download from Panasonic (https://av.jpn.support.panasonic.com/support/share2/eww/com/dsc/fts/zip/G9___V22.zip) has the "UPD " magic, followed by 8 bytes I couldn't associate, and then what seems like a product identifier "MC471" (MC = mirrorless camera?)

The interesting stuff starts at 0x2EC, where something which looks like a partition table starts. This section is 4884 bytes long (including some padding I believe) and contains 48 partitions which I managed to reverse engineer:

// 92 bytes - index entry of the partition listing struct partitionIndexEntry { char name[12]; // 12 bytes - name of the partition int offsetFile; // 4 bytes - offset in the firmware file int size; // 4 bytes - size of the partition int offsetMemory; // 4 bytes - offset in the memory on the camera int encryption; // 4 bytes - whether the partition is encrypted (0x3) or not (0x2) char checksum[32]; // 32 bytes - SHA-256 checksum of unencrypted partitions? char key[16]; // 16 bytes - encryption key?, if encryption == 0x3 char padding[16]; // 16 bytes - padding };

Reading that in in my custom C tool I've written for this logs out 48 partitions with their offset (in the firmware file, the real data starts at 0x1600) and size. I added automatic dd'ing so I now got 48 .bin files which are the extracted partitions out of the big firmware file. Adding all the sizes of the partitions together is also exactly the size of the original .bin minus the 0x1600/5120 bytes at the beginning which are the headers and partition table. You can download the extracted partition files here: https://drive.google.com/file/d/1P4681aZkRlCUuaiL10nH_En1g70iRLKS/view

Now, they obviously seem to be encrypted, and I haven't been able to figure out how. As you can see I was thinking whether the 16 byte long key in the partition index might be a key, because it's filled with zeros if encryption is 0x2.

This is my progress, I greatly appreciate any hints!

]]>