3

I'm trying to extract GoPro hero 3+ camera firmware but I'm getting a weird output from binwalk.

This is the binwalk output (Uploaded to pastebin):

http://pastebin.com/raw.php?i=yVZFGZT6

As you can see there are a lot of lines including mcrypt, RSA and other lines but the firmware is not encrypted. Also checking the hexadecimal of the file I can see the following:

000006f0  55 55 55 55 66 66 66 66  77 77 77 77 88 88 88 88  |UUUUffffwwww....|

As far as I know this is related to UBoot. And this other two lines showing some squashfs headers:

0151d040  45 3d cd 28 88 4f 39 80  68 73 71 73 bc 4f 39 80  |E=.(.O9.hsqs.O9.|
02557250  8a f3 0d 00 68 73 71 73  90 f3 0d 00 72 65 65 62  |....hsqs....reeb|

Also, I can see some other lines related to CPIO but I can't figure out how to separate this file into extractable pieces.

The firmware image can be downloaded here: http://software.gopro.com/Firmware/HD2/HD2-firmware.bin

perror
  • 19,083
  • 29
  • 87
  • 150
Nucklear
  • 725
  • 2
  • 8
  • 17

2 Answers2

2

There will always be false positives with binwalk, especially for lzma and the likes. What you can do is use the -M option to try and binwalk multiple layers deep and also use -r option to remove files that didn't decompress well.

0xea
  • 4,904
  • 1
  • 23
  • 30
  • I already tried it but it gives me unidentified files except two folders /root (empty) and /dev . I also found this script https://gist.github.com/nezza/2394361 that splits the firmware in multiple images that I'm not able to uncompress either. According to some strings GoPro Hero3+ uses this technology and it's processor is ARM http://www.ambarella.com/uploads/docs/A7LS-Brief-121713.pdf – Nucklear Nov 03 '14 at 12:52
2

Strings suggests this is using the UbiFS file system:

$ strings HD2-firmware.bin | grep -i ubifs
console=tty0  lpj=2334720 ubi.mtd=lnx root=ubi0:linux rootfstype=ubifs
LNX_VIF="../../../src/linuxinfo/ubifs.info"
CONFIG_BOSS_SECONDARY_CMDLINE="console=tty0  lpj=2334720 ubi.mtd=lnx root=ubi0:linux rootfstype=ubifs"
console=tty0  lpj=2334720 ubi.mtd=lnx root=ubi0:linux rootfstype=ubifs

There are only two places where I see the UbiFS super magic bytes (0x24051905, see http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/fs/ubifs/ubifs.h):

$ binwalk -m ubifs.sig HD2-firmware.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
23734456      0x16A28B8       UbiFS, little endian
23741868      0x16A45AC       UbiFS, little endian

For reference, the contents of ubifs.sig are:

0   lelong  0x24051905      UbiFS, little endian
0   belong  0x24051905      UbiFS, big endian

EDIT:

The above seems to be a false positive. After creating a UbiFS image of my own, here's what it looks like in hex:

00000000  31 18 10 06 dc 6a 3b 2d  4e 00 00 00 00 00 00 00  |1....j;-N.......|
00000010  00 10 00 00 06 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 02 00 00 00 00 02 00  0d 00 00 00 64 00 00 00  |............d...|
00000030  00 00 16 00 00 00 00 00  04 00 00 00 02 00 00 00  |................|
00000040  01 00 00 00 01 00 00 00  08 00 00 00 00 01 00 00  |................|
00000050  04 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 ca 9a 3b fb 7e 13 36  |...........;.~.6|
00000070  91 29 47 3b 8b dd 46 95  27 cc 8a 30 00 00 00 00  |.)G;..F.'..0....|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00020000  31 18 10 06 4a 3d 6b 5a  4f 00 00 00 00 00 00 00  |1...J=kZO.......|
00020010  00 02 00 00 07 00 00 00  45 00 00 00 00 00 00 00  |........E.......|
00020020  00 00 00 00 00 00 00 00  02 00 00 00 03 00 00 00  |................|
00020030  0c 00 00 00 d8 05 00 00  bc 00 00 00 0b 00 00 00  |................|
00020040  0c 00 00 00 00 08 00 00  98 06 00 00 00 00 00 00  |................|
00020050  00 26 05 00 00 00 00 00  38 03 00 00 00 00 00 00  |.&......8.......|
00020060  30 d0 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |0...............|
00020070  00 24 00 00 00 00 00 00  07 00 00 00 2a 00 00 00  |.$..........*...|
00020080  07 00 00 00 00 02 00 00  07 00 00 00 36 00 00 00  |............6...|
00020090  00 00 00 00 00 00 00 00  0a 00 00 00 01 00 00 00  |................|
000200a0  01 00 00 00 0d 00 00 00  00 00 00 00 00 00 00 00  |................|
000200b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00020200  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

Note the little endian magic number at the beginning of each node: 0x06101831.

This pattern appears in the GoPro firmware, and it looks like the UbiFS image may start at 0x22C6100; however, I was unable to mount either my UbiFS image (created with mkfs.ubifs) or the image from the GoPro firmware, so I cannot verify that this is true.

devttys0
  • 2,714
  • 13
  • 10
  • Awesome answer. I can identify 2 times "31 18 10 06" on the original gopro firmware but I don't see those references on 0x22C6100. Also after extracting the UbiFS images from the firmware I tried to mout it following this instructions http://elinux.org/UBIFS#Mounting_UBI_Image_on_PC_using_nandsim with no success. – Nucklear Nov 03 '14 at 16:18