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

81–90 of 90 posts

Re: Reverse engineering my router's firmware with binwalk

#81

Post by syntheticnature »

mrspeaker wrote: post #32
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 an…

The 72 bytes is from the difference between the uImage header and the lzma inside, from the post. 0x132b8-0x13270 = 72 (dec).

So you'll need to check what binimage says about your image, the uImage header isn't necessarily fixed in size. Also see the comment above about the --dd switch, though mind the reply to that pointing out you might want to check what it finds before just letting it write a pile of files.

Re: Reverse engineering my router's firmware with binwalk

#82

Post by syntheticnature »

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.

One thing hinted at by the other comment thread, but not brought up: in the embedded world, read-write filesystems as you know them are less common, and usually a failsafe mode is desirable. OpenWRT, for instance, uses a JFFS overlay on top of a squashfs (at least in a recent-ish build for a router I have). So you change out the squashfs (and try to figure out what to do with the overlay filesystem), rather than replacing individual files.

Re: Reverse engineering my router's firmware with binwalk

#83

Post by ggcdn »

hnick wrote: post #77
ggcdn wrote: post #63

Earlier quoted context omitted.

Ok thanks, I'll take a look. It's possible for me to generate these files for each of the various material settings so I can manually 'diff' them, simillar to what you're describing

If there are massive differences with minor changes that can be a clue that the data is compressed or encrypted in some manner. A good test would be if you can name/tag/comment items in the file, you can search for these strings.

I don’t think there’s compression or encryption. I can search and find the hex representation of text and values that I expect to be there. I guess I need to bite the bullet and spend some time tagging the parameters I know, then figuring out the pattern of padding that is in between.

Re: Reverse engineering my router's firmware with binwalk

#84

Post by throwaway2048 »

ggcdn wrote: post #51

A slightly related question for HNers: Is there any easy tool for a non-cs guy to reverse engineer a binary file containing numbers and text in some specific format? I have to work with some old structural analysis software. The material and element definitions come in an obscure file format ".PF3CMP". I know it contains text like the material names, and numbers/letters for the material properties. Ultimately its my…

If its helpful in any way, lots of tool specific file formats like that are basically C structs dumped to a file, then loaded when the file is loaded.

Re: Reverse engineering my router's firmware with binwalk

#85

Post by throwaway2048 »

gvb wrote: post #12
non-entity wrote: post #10

Earlier quoted context omitted.

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.

when you say a lot, the reality is this is the case with basically every single ARM SoC on the market (and a few x86 ones too!).

Re: Reverse engineering my router's firmware with binwalk

#86

Post by 12bits »

leeoniya wrote: post #59
12bits wrote: post #54

Earlier quoted context omitted.

Did you notice your wireless signal strength considerably lower when going to dd-wrt? I put openwrt on my c7 V5 and could barely get any bars. Flashed back to the stock and was back in business. Another thing I've read is the third party firmwares don't get hardware access to NAT resulting in speed hits. Cheers

yes, and i had throughput issues when running in full-width G/N mixed mode compared to my previous Tomato/Asus RT-N16 setup. my phone would also drop out and reconnect intermittently with the c7. but in dedicated AC it seems to be doing well thus far. i cannot say for sure whether this was due to DD-WRT or not as i did not do a thorough comparison to stock. > Another thing I've read is the third party firmwares don't…

Thank you for the reply, once we loose the last of our 2.4 devices maybe I'll re-try in AC only.

Re: Reverse engineering my router's firmware with binwalk

#87

Post by ggcdn »

PeterisP wrote: post #64
ggcdn wrote: post #51

A slightly related question for HNers: Is there any easy tool for a non-cs guy to reverse engineer a binary file containing numbers and text in some specific format? I have to work with some old structural analysis software. The material and element definitions come in an obscure file format ".PF3CMP". I know it contains text like the material names, and numbers/letters for the material properties. Ultimately its my…

Depending on how weird the format is, it might be more efficient to reverse-engineer the file-reading routines of that program which can work with these files.

Thanks but this sounds... above my level of computer competence

Re: Reverse engineering my router's firmware with binwalk

#88

Post by fr0ster »

I'm trying repeat steps from article. After next command: dd if=uImage of=Image.lzma bs=1 skip=72 I'm trying unpack lzma file: unlzma Image.lzma And get message: unlzma: Image.lzma: Compressed data is corrupt

Does it mean I downloaded corruption zip file from TP-Link site? How I can extract kernel image? Binwalk says about Image.lzma: 0 0x0 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 3164228 bytes

Re: Reverse engineering my router's firmware with binwalk

#89

Post by fr0ster »

fr0ster wrote: post #88

I'm trying repeat steps from article. After next command: dd if=uImage of=Image.lzma bs=1 skip=72 I'm trying unpack lzma file: unlzma Image.lzma And get message: unlzma: Image.lzma: Compressed data is corrupt Does it mean I downloaded corruption zip file from TP-Link site? How I can extract kernel image? Binwalk says about Image.lzma: 0 0x0 LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncom…

I don't understand how I can unpack Image.lzma, if "unlzma Image.lzma" doesn't work but "Binwalk -e Image.lzma" work correct?

Re: Reverse engineering my router's firmware with binwalk

#90

Post by Graziano_M »

ChuckNorris89 wrote: post #5
bluesign wrote: post #4

Earlier quoted context omitted.

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

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.

Coincidentally, this very router's OpenWRT isn't as fast as the manufacturer's firmware because it doesn't have proper drivers for the hardware NAT, so it has to do it in software.
Post reply on HN