Skip to content

Instantly share code, notes, and snippets.

@aug2uag
Forked from gdzhu/0_rev_R33.md
Created September 20, 2021 20:39
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save aug2uag/4fad59dad285e2e17f29e9631017ccb8 to your computer and use it in GitHub Desktop.
Save aug2uag/4fad59dad285e2e17f29e9631017ccb8 to your computer and use it in GitHub Desktop.

reverse R33-sysupgrade-20180510-910b5192.bin

file

Just to make sure it is a firmware image instead of a zip file:

1

strings

to check the content of file and see whether there is anything of interest

2

from the strings output, we can see there is kernel, U-Boot bootloader and what seems to be configurations which hints that the there might be a Linux based filesystem.

3

hexdump

A quick look at the hexdump reveals what might be the model which this firmware is for, which is MT7620-N. Other than that, there is nothing interesting.

4

binwalk

binwalk is able to identify two uImage headers, one for U-Boot (no compression) and the other for the os kernel (LZMA with property 0x6d). Followed by the LZMA compressed data, there are a list of xz compressed data sections reported by binwalk, which might be the obfuscated or encrypted filesystem.

5

hexdump again

with the output of binwak, we go back to the output of the hexdump. This time, we are going to take a look at the content at the end of the kernel image and at the beginning of the xz archives.

6

From the screenshot we can clearly see there is a squashfs header in the firmware, wonder why binwalk is not picking this up.

lzma & hsqs

Check the squashfs manually and see if there are anything interesting.

7

and try the unsquashfs from the squashfs project:

8

It seems like the properties in the header are all messed up. Judging from the reported version together with all the available versions of squashfs as well as the datetime this firmware is created, an educated guess is that the version property is masked by 0xffff.

Unmask the version with vim and try again:

9

Since we can clearly see the xz headers in the firmware hexdump, it is very likely that the utility can not locate the data properly with the metadata in the header section. Take a look at the output of the hexdump again, it seems like the inode_count and compression_id sections are also masked. unmask these two sections as well:

10

However, the extraction failed again with another error message. After side to side comparison between the squashfs header and the Squashfs Binary Format. It seems like while the flags field (0x06C0) indicates there is a compression options section in the squashfs header, it is actually not included. So change this to 0x02C0 and try again:

11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment