5

After trying to unsquash a firmware dump from a router without success, I am asking for help.

I have a router with a BCM68380 CPU. After desoldering the TOSHIBA NAND chip I dumped the firmware (link to the FW) and proceed to extract it. Binwalk shows the following:

DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 49788 0xC27C CRC32 polynomial table, big endian 589312 0x8FE00 CRC32 polynomial table, big endian 2289136 0x22EDF0 uImage header, header size: 64 bytes, header CRC: 0x5BEEE4BD, created: 2017-08-31 09:59:39, image size: 2689910 bytes, Data Address: 0x80010000, Entry Point: 0x804505C0, data CRC: 0x44FFEAF7, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "linux" 2703360 0x294000 uImage header, header size: 64 bytes, header CRC: 0x5BEEE4BD, created: 2017-08-31 09:59:39, image size: 2689910 bytes, Data Address: 0x80010000, Entry Point: 0x804505C0, data CRC: 0x44FFEAF7, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "linux" 3808793 0x3A1E19 MySQL MISAM compressed data file Version 5 5477496 0x539478 uImage header, header size: 64 bytes, header CRC: 0x1BD6643, created: 2017-08-31 09:59:50, image size: 26791936 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0x8212135E, OS: Linux, CPU: MIPS, image type: Standalone Program, compression type: lzma, image name: "rootfs" 5477560 0x5394B8 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 26790128 bytes, 2251 inodes, blocksize: 262144 bytes, created: 2017-08-31 09:59:50 32416240 0x1EEA1F0 PNG image, 921 x 359, 8-bit/color RGBA, non-interlaced 32686576 0x1F2C1F0 PNG image, 979 x 336, 8-bit/color RGBA, non-interlaced 46083560 0x2BF2DE8 uImage header, header size: 64 bytes, header CRC: 0x8F97D0FE, created: 2017-01-09 09:50:15, image size: 2688224 bytes, Data Address: 0x80010000, Entry Point: 0x8044DAD0, data CRC: 0x7E335D07, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "linux" 46497792 0x2C58000 uImage header, header size: 64 bytes, header CRC: 0x8F97D0FE, created: 2017-01-09 09:50:15, image size: 2688224 bytes, Data Address: 0x80010000, Entry Point: 0x8044DAD0, data CRC: 0x7E335D07, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "linux" 49270176 0x2EFCDA0 uImage header, header size: 64 bytes, header CRC: 0xFE9B6F73, created: 2017-01-09 09:50:20, image size: 25706496 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0xD5593BBC, OS: Linux, CPU: MIPS, image type: Standalone Program, compression type: lzma, image name: "rootfs" 49270240 0x2EFCDE0 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 25703081 bytes, 2266 inodes, blocksize: 262144 bytes, created: 2017-01-09 09:50:20 74999328 0x4786620 PNG image, 921 x 359, 8-bit/color RGBA, non-interlaced 75269664 0x47C8620 PNG image, 979 x 336, 8-bit/color RGBA, non-interlaced 91914240 0x57A8000 UBI erase count header, version: 1, EC: 0x17, VID header offset: 0x800, data offset: 0x1000

When extracted, the following files are shown (the squashfs.root folder is empty)

2EFCDE0.squashfs 5394B8.squashfs 57A8000.ubi squashfs-root

Then I tried to uncompress the squashfs filesystem. At first I tried with unsquashfs which gave me this result:

Lseek failed because Invalid argument File system corruption detected FATAL ERROR:failed to read file system tables

On the other hand sasquatch gave me this result:

SquashFS version [4.0] / inode count [2266] suggests a SquashFS image of the same endianess Parallel unsquashfs: Using 1 processor Lseek failed because Invalid argument read_block: failed to read block @0xbe23b7988e38debe read_uids_guids: failed to read id table block FATAL ERROR:failed to uid/gid table

I also tried the same with firmware-mod-kit:

Firmware Mod Kit (extract) 0.99, (c)2011-2013 Craig Heffner, Jeremy Collake Scanning firmware... Scan Time: 2020-11-03 13:49:05 Target File: /mnt/c/Users/Ismael/Desktop/Nueva/Flash_data.bin MD5 Checksum: 31b617568a1ca2e060bea93fd23de338 Signatures: 344 DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 49788 0xC27C CRC32 polynomial table, big endian 589312 0x8FE00 CRC32 polynomial table, big endian 2289136 0x22EDF0 uImage header, header size: 64 bytes, header CRC: 0x5BEEE4BD, created: 2017-08-31 09:59:39, image size: 2689910 bytes, Data Address: 0x80010000, Entry Point: 0x804505C0, data CRC: 0x44FFEAF7, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "linux" 2703360 0x294000 uImage header, header size: 64 bytes, header CRC: 0x5BEEE4BD, created: 2017-08-31 09:59:39, image size: 2689910 bytes, Data Address: 0x80010000, Entry Point: 0x804505C0, data CRC: 0x44FFEAF7, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "linux" 3808793 0x3A1E19 MySQL MISAM compressed data file Version 5 5477496 0x539478 uImage header, header size: 64 bytes, header CRC: 0x1BD6643, created: 2017-08-31 09:59:50, image size: 26791936 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0x8212135E, OS: Linux, CPU: MIPS, image type: Standalone Program, compression type: lzma, image name: "rootfs" 5477560 0x5394B8 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 26790128 bytes, 2251 inodes, blocksize: 262144 bytes, created: 2017-08-31 09:59:50 32416240 0x1EEA1F0 PNG image, 921 x 359, 8-bit/color RGBA, non-interlaced 32686576 0x1F2C1F0 PNG image, 979 x 336, 8-bit/color RGBA, non-interlaced 46083560 0x2BF2DE8 uImage header, header size: 64 bytes, header CRC: 0x8F97D0FE, created: 2017-01-09 09:50:15, image size: 2688224 bytes, Data Address: 0x80010000, Entry Point: 0x8044DAD0, data CRC: 0x7E335D07, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "linux" 46497792 0x2C58000 uImage header, header size: 64 bytes, header CRC: 0x8F97D0FE, created: 2017-01-09 09:50:15, image size: 2688224 bytes, Data Address: 0x80010000, Entry Point: 0x8044DAD0, data CRC: 0x7E335D07, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "linux" 49270176 0x2EFCDA0 uImage header, header size: 64 bytes, header CRC: 0xFE9B6F73, created: 2017-01-09 09:50:20, image size: 25706496 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0xD5593BBC, OS: Linux, CPU: MIPS, image type: Standalone Program, compression type: lzma, image name: "rootfs" 49270240 0x2EFCDE0 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 25703081 bytes, 2266 inodes, blocksize: 262144 bytes, created: 2017-01-09 09:50:20 74999328 0x4786620 PNG image, 921 x 359, 8-bit/color RGBA, non-interlaced 75269664 0x47C8620 PNG image, 979 x 336, 8-bit/color RGBA, non-interlaced 91914240 0x57A8000 UBI erase count header, version: 1, EC: 0x17, VID header offset: 0x800, data offset: 0x1000 Extracting 49270240 bytes of header image at offset 0 Extracting squashfs file system at offset 49270240 Extracting squashfs files... [sudo] password for ismael: Firmware extraction successful!

It didn't give me any errors but it didn`t extract any squashfs files.

To remove the OOB in the firmware I have used NandTool , which removes the OOB data.

Any help will be appreciated.Thanks.

Edit: Firmware with "Include Spare area" disabled link.

Improve this question
2
  • what did you use for dumping? does it account for OOB/spare bytes? Commented Nov 3, 2020 at 13:42
  • Thanks for responding. I am currently using the TL866II Plus Programmer with the Xgpro software. In the configuration I have "Include Spare area" enabled Commented Nov 3, 2020 at 14:21

2 Answers 2

Reset to default
2

Most likely your dump includes spare (or OOB) bytes while most file formats only consider user-accessible areas. You can either figure out the dump structure and remove OOB chunks or simply re-dump without the spare area. After that extraction should work.

Improve this answer
1
  • 1
    Thanks for responding. I have tried to read the NAND chip with the "Include Spare area" disabled. The firmware file is now 4mb smaller. However, I am getting the same errors as before. Thanks Commented Nov 3, 2020 at 15:07
1

I think you have a router very similar to mine after analysing your dump. Please check PRV3399BELT for what I've found so far.

As noted before, you have dumped raw data with OOB information; that must be cleaned before feeding binwalk.

And then binwalk is not giving reliable information since it is trying to guess common structures and many times it gives “false findings”. Don't trust too much this output.

Coming to your question, the firmware has been built with “secured boot” enable. This means that the images are encrypted and therefore cannot be read or manipulated.

Unless the RSA keys are known, your efforts are pointless.

You can learn a lot from Asuswrt-Merlin site. Especially these scripts. These are extracts from Asuswrt GPL sources. Unfortunately, BCM68380 is not included yet.

Note: I have checked that the dumped files are corrupted; not the place to explain it but the end of the cferom file (bootloader) at 0xd874 contains a JAMCRC32 of block 0x14->0xd773. You can even make a comparison of the two available dumps and you will notice some byte mismatches at the beginning. If possible, could you make available a safe dump?

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.