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?
    – Igor Skochinsky ♦
    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
    – Ismael
    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
    – Ismael
    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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.