Live data from Hacker News

Reverse engineering my router's firmware with binwalk

embeddedbits.org

11–20 of 90 posts

Re: Reverse engineering my router's firmware with binwalk

#12
post #6

Earlier quoted context omitted.

Most routers run 2.6.32 kernel.

Is there any particular reason for this? Like some feature that was removed in later versions?

The primary reason is likely because the hardware (SoC peripherals) drivers were written for 2.6.x and not forward ported to newer versions of the linux kernel. A lot of hardware drivers were (are) written by the hardware (chip) manufacturers and then abandoned.

Re: Reverse engineering my router's firmware with binwalk

#13
post #4

>Although the firmware was released last year (August 2019) as I write this article, it uses an old Linux kernel version (3.3.8) released in 2012 compiled with a very old GCC version (4.6) also from 2012! This is what happens whey you pay peanuts for embedded devs and outsource development to the cheapest sweatshop you can find so your products can meet a competitive price point. Sadly this will not change until ther…

It is mostly related to drivers to soc, not about paying devs

Exactly. What I see is that the SoC provider just freezes everything at a given version and supports just that. For example I am currently building Android 9 on a QCOM SoC with a 4.9 Kernel. I don't think it will receive any future update...

Re: Reverse engineering my router's firmware with binwalk

#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 from jump-points. You could annotate that output by changing the labels to something human-readable (e.g. Loop-back, Main, TimerISR etc) and add comments.

The next iteration would read that back in to build a symbol table, rescan the binary and re-output. But this time it would understand that the symbols were always on opcode boundaries, distinguish data table from code entry points (because you marked them) etc. So it would do a better job of staying in sync with the code.

Once I was done with that project (and had re-compilable source for the radio module) I put it away and never thought of it again.

Re: Reverse engineering my router's firmware with binwalk

#16

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’m running OpenWRT and the Archer c7 is on the list of supported devices. I’d say give it a try.

Re: Reverse engineering my router's firmware with binwalk

#18
This is indeed a cool tool! I've used it before when forensically analyzing a cell phone, and found interesting things. For example, I found that a web browser had cached the unencrypted bytes from an HTTP message. Binwalk identified the gzip header's magic number (1f 8b), and after decompression there were interesting results.

Another cool tool I learned about recently is signsrch. It's more for reverse engineering binaries of software that implements encryption of some type. It'll find signatures in the binaries of these encryption methods, giving you a place to look when, for example, reverse engineering a file format that you suspect is encrypted in some way.

https://www.oreilly.com/library/view/learning-malware-analys...

Re: Reverse engineering my router's firmware with binwalk

#19

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?

Post reply on HN