Encrypted firmware, need some hints

Question

I'm relatively new to firmware reverse engineering but it has been a very interesting journey, loved it!

I am currently trying to crack open the firmware of my Panasonic Lumix DC-G9 camera to see if I can bypass a recording limit. However, it seems like they did a great job of encrypting the firmware.

You can download the .bin firmware file here.

I tried Binwalk, but the output only shows one entry, which might be a false positive:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
26453361      0x193A571       gzip compressed data, has header CRC, has 28967 bytes of extra data, last modified: 2052-10-14 16:14:25 (bogus date)

I tried extracting that, but gunzip only reports that the header checksum is not equal to the computed checksum. So could still be a false positive.

I also tried to plot out the entropy of the firmware:

Seems encrypted to me? Next step was to check if I could read any hints of the basic strings command:

MC471
panasonic
MC471
loader1
loader2
loader3
program
storage
postboot1
postboot2
postboot3
postboot4
postboot5
dram_sleep
eep_ow_a
eep_ow_b
eep_adj
eep_fix
music
osdover
osddata
koutei_kao
avchd_info
eep_net_a
eep_net_b
eep_act_a
eep_act_b
zboot
zimage
rootfs1
rootfs2
apu0_data_i
apu0_data_e
apu0_code_i
apu0_code_e
usbcharge
ipu_data
ipu_code
rc_data
rc_code
nr_data
nr_code
hm_c_prog

Seems like zboot is the bootloader?

Since I'm still pretty new, are there any hints on how I could progress on this? I really hope it's not cracking open the camera and trying to debug any hardware ROM which stores the keys!

Answer 1

Assuming this is a firmware file, a good first step would be to identify where execution starts. You could do this by:

• finding the type of processor / microcontroller / system-on-chip and checking for the reset vector (try searching for product approvals, e.g. from the FCC, which might contain interior images).
• scanning the file for known byte sequences associated with code, for example function prologues.
• reading the manual for the potential boot loader and looking for code associated with it. For example the linker file might identify where initialisation code lives.

This would enable analysis of the overall code structure, which is likely compressed or encrypted if your entropy graph is correct.

Depending on how firmware updates are delivered it’s possible this file is encrypted and would be decrypted by the microcontroller.

This could happen:

• during update, if the existing firmware decrypts and validates the update before writing to flash.
• on boot, if the target system supports encrypted firmware.

In both of these cases it’s much harder to analyse the system. You’d typically need a combination of hardware hacking and firmware reverse engineering to make progress.