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

31–40 of 90 posts

Re: Reverse engineering my router's firmware with binwalk

#31

Post by vlovich123 »

bshipp wrote: post #22
josteink wrote: post #21

Earlier quoted context omitted.

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.

They're "like PCs" in the sense that the instruction set has of the CPUs has caught up and in theory you can attach more complicated peripherals. However, unless your embedded product has MMC flash attached (for many applications it doesn't due to cost + physical size) you're SOL for the following reasons:

1. For M4s your storage is typically some kind of SPI flash which doesn't act like the traditional desktop flash you're dealing with. You have to manually specify the address you're reading/writing & you have to do it on block boundaries (multiple KB). You're generally looking at 8-64MB. 2. For M0 your storage is typically flash built-in with potentially even more restrictions. 3. These devices have very little RAM. Decompression means you have to have a way of enforcing constraints on the amount of space you'll need. Aside from the space needed regularly for decompression you may need to buffer the decompressed content in-memory to align with block boundaries. All of this means development time, increased costs & risk for something you may not be able to pull of.

If your vendor actually internally compresses their image then great but generally they don't for all the same reasons (+ sometimes this is touching ROM code in the chip).

Re: Reverse engineering my router's firmware with binwalk

#32

Post by mrspeaker »

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…

I'm wondering how these values are determined too. I'm "following along at home" without any idea what I'm doing (though all the files, bytes, and offsets are matching with the tutorial... Also, if the original author finds this thread: amazing write-up - got me really interested in the topic!).

At the step where they remove the header with

    dd if=uImage of=Image.lzma bs=1 skip=72
It results in a file that if I try and un compress it with `unlzma Image.lzma` it complains with "Compressed data is corrupt"

I don't know where the magic number "72" comes from. Is it likely that could be different on my machine (a mac)?

[edit: I think there's something else wrong - if I use `mkImage` to examine the uImage file I only get:

    mkimage -l uImage
    GP Header: Size 27051956 LoadAddr 78a267ff
Instead of image information]

Re: Reverse engineering my router's firmware with binwalk

#33

Post by tenebrisalietum »

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…

I think firmware images are typically not the fixed ROM code the CPU first encounters upon startup, even if they contain U-Boot. Especially if stored in NAND flash they probably aren't.

AR7 platform, for example, the MIPS core runs a small ROM that initializes RAM, then reads some blocks from flash. Not sure how much code you'd need to unpack a tar.gz but completely possible.

Re: Reverse engineering my router's firmware with binwalk

#34

Post by souprock »

JoeAltmaier wrote: post #14

Cool tool! I wrote something for reverse-engineering code, as a consultant years ago. They had a radio module but the manufacturer had lost the source code. So the tool was called Golem. It had tables for defining opcode to assembler pattern matching, that could be written for any machine (instead of just the one I was cracking). It worked iteratively. You ran it over the binary once, it produced arbitrary labels fro…

You were on your way to cloning IDA Pro, Ghidra, Binary Ninja, or Hopper Disassembler. To varying degrees, sometimes as a pay-extra option, those tools can produce source code.

Re: Reverse engineering my router's firmware with binwalk

#35

Post by JoeAltmaier »

souprock wrote: post #34
JoeAltmaier wrote: post #14

Cool tool! I wrote something for reverse-engineering code, as a consultant years ago. They had a radio module but the manufacturer had lost the source code. So the tool was called Golem. It had tables for defining opcode to assembler pattern matching, that could be written for any machine (instead of just the one I was cracking). It worked iteratively. You ran it over the binary once, it produced arbitrary labels fro…

You were on your way to cloning IDA Pro, Ghidra, Binary Ninja, or Hopper Disassembler. To varying degrees, sometimes as a pay-extra option, those tools can produce source code.

Um. I think they post-dated me! But I didn't go anywhere with it.

Re: Reverse engineering my router's firmware with binwalk

#36

Post by josteink »

leeoniya wrote: post #27
josteink wrote: post #19

Earlier quoted context omitted.

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…

Flashing the OpenWRT “factory” (as opposed to sysupgrade) image in the web UI should probably work fine, but don’t quote me on it.

That’s how I flashed from stock to OpenWRT on 3+ Archer units anyway. Make sure not to keep settings.

Re: Reverse engineering my router's firmware with binwalk

#37

Post by SpikedCola »

leeoniya wrote: post #27
josteink wrote: post #19

Earlier quoted context omitted.

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…

Going from dd-wrt to openwrt should be as simple as a firmware flash from the web gui, and an nvram reset. Worst case, you can flash a "revert to stock" image from ddwrt to go back to factory, then flash openwrt as if the device was factory.

Openwrt also has a handy failsafe built into a lot of models. It boots a stripped down http server where you can upload recovery firmware.

Used to swear by dd-wrt, now I prefer openwrt.

Re: Reverse engineering my router's firmware with binwalk

#38

Post by monocasa »

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…

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

In the past, each of those would be a separate MTD partition with a seperate device file. You just dd them over those files.

Re: Reverse engineering my router's firmware with binwalk

#39

Post by rahuldottech »

prashnts wrote: post #8
ChuckNorris89 wrote: post #5

Earlier quoted context omitted.

So how did OpenWRT manage to build firmware with up to date components for it? The Qualcomm chips inside of it seem fairly modern for such an old kernel.

Note that openwrt has a big community of contributors and not all devices/features are supported. In contrast the manufacturer firmware is at least feature complete and easy for regular users to set up.

OpenWrt is also free. Both as free software, and free of cost. When you're paying a manufacturer for a product, surely it's not too much to expect them to ship with functional software that also happens to be up-to-date and secure?

Re: Reverse engineering my router's firmware with binwalk

#40

Post by souprock »

JoeAltmaier wrote: post #35
souprock wrote: post #34

Earlier quoted context omitted.

You were on your way to cloning IDA Pro, Ghidra, Binary Ninja, or Hopper Disassembler. To varying degrees, sometimes as a pay-extra option, those tools can produce source code.

Um. I think they post-dated me! But I didn't go anywhere with it.

IDA Pro started as a 16-bit MS-DOS program. It's real old. I'm pretty sure I was using it back in 1992, when it was already a well-developed program.

Ghidra is old too, although only recently public. It couldn't be older than Java, which is from 1996.

Post reply on HN