Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse engineering my router's firmware with binwalk

embeddedbits.org

Post reply on HN
Print view View original

21–30 of 90 posts

Re: Reverse engineering my router's firmware with binwalk

#21

Post by josteink »

tasubotadas wrote: post #15

I am really surprised that firmware images are not just .tar.gz files renamed to .bin :/. That's how I would have implemented a distribution of new firmware.

And how do you partition boot-loaders, kernels, and rootfs and such in that tar.gz?

Embedded device will be hard coded to look at a fixed point and start booting from there, there’s no UEFI. How will you ensure boot-loaders get unpacked precisely where they need to be?

And that doesn’t even touch the idea of having a router understand a file system before any firmware code is loaded.

Routers really are quite different from PCs.

Re: Reverse engineering my router's firmware with binwalk

#22

Post by bshipp »

josteink wrote: post #21
tasubotadas wrote: post #15

I am really surprised that firmware images are not just .tar.gz files renamed to .bin :/. That's how I would have implemented a distribution of new firmware.

And how do you partition boot-loaders, kernels, and rootfs and such in that tar.gz? Embedded device will be hard coded to look at a fixed point and start booting from there, there’s no UEFI. How will you ensure boot-loaders get unpacked precisely where they need to be? And that doesn’t even touch the idea of having a router understand a file system before any firmware code is loaded. Routers really are quite differen…

True enough, but I think they used to be even more unique and over time they've become more like PCs.

One of these days I'm going to log in to the admin interface and find candy crush installed.

Re: Reverse engineering my router's firmware with binwalk

#23

Post by magduf »

leeoniya wrote: post #11

glad i flashed latest dd-wrt beta on my archer-c7 v5 :D. though my wan-facing device runs OPNSense. i actually prefer to run Tomato, but archer c7 is not broadcom :( can anyone offer advice about dd-wrt vs openwrt (considering trying openwrt).

>i actually prefer to run Tomato, but archer c7 is not broadcom :(

Not being Broadcom is a very good thing.

Re: Reverse engineering my router's firmware with binwalk

#24

Post by LeonM »

GEBBL wrote: post #3

This is amazing! I’ve used binwalk extract for ‘capture the flag’ challenges but I never really thought about the practical applications of it. Wow! Thank you

Funny, I always assumed that there would be no application for binwalk other than for extracting binary firmware images of embedded devices.

Using binwalk for CTF challenges is actually a new insight for me :)

Re: Reverse engineering my router's firmware with binwalk

#25

Post by beefhash »

LeonM wrote: post #24
GEBBL wrote: post #3

This is amazing! I’ve used binwalk extract for ‘capture the flag’ challenges but I never really thought about the practical applications of it. Wow! Thank you

Funny, I always assumed that there would be no application for binwalk other than for extracting binary firmware images of embedded devices. Using binwalk for CTF challenges is actually a new insight for me :)

Conversely, it's a convenient tool for obfuscation. You can trigger plausible false positives all over, while also making sure that there's nothing of immediate use with binwalk left.

Re: Reverse engineering my router's firmware with binwalk

#26

Post by commandlinefan »

From the output I see:

  23296         0x5B00          LZMA compressed data, properties: 0x5D, dictionary size:

                                8388608 bytes, uncompressed size: 97476 bytes

  64968         0xFDC8          XML document, version: "1.0"
So it looks like the size of the bootloader should be 64968 - 23296 = 41672. But he extracts 41162:

  $ dd if=archer-c7.bin of=u-boot.bin.lzma bs=1 skip=23296 count=41162
Curious if anybody knows why 41162; is this a block-size alignment requirement?

Re: Reverse engineering my router's firmware with binwalk

#27

Post by leeoniya »

josteink wrote: post #19
leeoniya wrote: post #11

glad i flashed latest dd-wrt beta on my archer-c7 v5 :D. though my wan-facing device runs OPNSense. i actually prefer to run Tomato, but archer c7 is not broadcom :( can anyone offer advice about dd-wrt vs openwrt (considering trying openwrt).

Latest version of OpenWRT (19) runs noticeably better on this device, with better HW offloading support and based on a nearly mainline, modern Linux kernel and a brand new device-tree for the Atheros SoC. What reasons do you have to stay on dd-wrt?

> What reasons do you have to stay on dd-wrt?

mostly that i've used it before. can i gui-flash to openwrt from dd-wrt? i've done tftp flashes before but they're pretty fiddly with getting the stupid 30-30-30 or whatever timing right. also i think these routers try to "pull" from a tftp server rather than having you push to one that they bootstrap - i've never been able to get the "pull" variant to work.

would be hell of a lot easier if the router could be booted into something like android's (arm's?) fastboot or flashmode mode so i can just push an image.

Re: Reverse engineering my router's firmware with binwalk

#29

Post by zerocrates »

commandlinefan wrote: post #26

From the output I see: 23296 0x5B00 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 97476 bytes 64968 0xFDC8 XML document, version: "1.0" So it looks like the size of the bootloader should be 64968 - 23296 = 41672. But he extracts 41162: $ dd if=archer-c7.bin of=u-boot.bin.lzma bs=1 skip=23296 count=41162 Curious if anybody knows why 41162; is this a block-size alignment req…

The 41162 bytes comes from the preceding uImage header, you'll see it listed in that big description. I'm not sure what the 510 bytes of padding are, though. Just padding? A checksum?
Post reply on HN