5

I am trying to do some reverse engeneering to a Devolo dlan wifi 500 device (mips arquitecture). My objective is to put there some firmware modified by me.

This is where I got so far:

  1. Downloaded a firmware update from http://update.devolo.com/linux2/apt/pool/main/d/devolo-firmware-dlan500-wifi/
  2. Extracted firmware image from debian package
  3. Analyzed image with binwalk
  4. Extracted contents with firmware mod kit (present on google code).
  5. Modded image
  6. Rebuilded with fmk
  7. Used web interface of device to upload new firmware

It failed on step 7. I get a message saying something like "this file does not contain valid data". So, some sort of verification is performed by the device before installing updates.

So I kept investigating. The devolo image contains a devolo header/footer, a uboot and a uimage. The header/footer must contain some sort of checksum. I tried picking the valid (unadultered) update and changed one bit on the padding, uploaded it to the device and got the same error message.

If I knew where the cheksum is or how is obtained, I could change it after rebuilding the image. However I found no documentation about the devolo formats. To try to find the sum I compared the hexadecimal of two devolo images: wifi and wireless(the wireless image is on the same site from where I downloaded the wifi image; could not post this link and the fmk link because I have less than 10 reputation :( ). The headers/footers are very similar in most fields, though I found no 32byte field to be a sum. Perhaps someone more experienced on reverse engeneering could help me.

I could try to brute force the sum. Since it is a sum, I could create a colision by adding bits to the padding areas. For this I have two ideas:

  1. Send through the network every combination possible;
  2. Use the downloaded image's libraries to test the sum locally;

Option 1 would probably take a few years...

For option 2, I tried using a qemu virtual machine and compile there, and cross compiling, with no results, due to the devolo libs using an old libc version (https://stackoverflow.com/questions/29153924/how-to-solve-c-conflicts-between-system-and-library-dependencies).

My last idea is to somehow emulate the downloaded firmware in my amd64 machine, to compile some code there that would use the devolo libs, thus circumventing the dependency problems.

So, I would thank any tips/mistakes on my previous steps, and any pointers on how to run the downloaded image on my pc.

Thanks in advance (if for nothing, for reading my rather long post).

  • Find the error message in the extracted code, the verification routine should be nearby. – Igor Skochinsky Mar 23 '15 at 11:24
  • Found the message. It is in an executable, so it's rather hard to get something from there. But it was a nice idea – Camandros Mar 23 '15 at 11:59
  • If you've already set up your system for cross compiling, you'll have a mips objdump somewhere. Run it on your executable, then inspect the code; mips assembler is (imho) much easier to learn than x86 or arm. You could also use www.onlinedisassembler.com instead of objdump, or check if the Retargetable Decompiler works better with MIPS now (it didn't, last time i looked, 3 months ago). – Guntram Blohm supports Monica Mar 23 '15 at 17:56
2

Each section in the firmware file has a crc32 over its contents.

See this.

It should make option 1 more viable.

More details: Inside the squashfs image there's whole heap of busybox based tools and a handful of standalone programs. There's one (/usr/sbin/chunk) that looked likely to have logic concerning the traversal of the firmware files. It contains a number of the 32bit values that matched the values in the firmware file that look like magic/fourcc values. strings(1) output was also pretty encouraging.

  • I like this answer, but a little bit of "how do you know?" would make it even better. – Guntram Blohm supports Monica Mar 23 '15 at 18:26
  • Dude, wow. Just wow. It works perfectly. Thanks for the code. Can you please please PLEASE tell me how you did this? – Camandros Mar 23 '15 at 19:37
  • I used IDA to analyse the binary I mentioned in the 'more details' part of the answer. – booto Mar 24 '15 at 1:44
  • Yeah but why usr/sbin/chunk? Amongst all binaries, why that one in particular? Or you analyzed all of them? (thanks again btw) – Camandros Mar 24 '15 at 10:59
  • I had a quick look at a few (it wasn't the first), and it looked like it was the best one to check out in greater detail. Multiple references to manipulating firmware, and the fourcc values (e.g. DVCO, VRNT, etc) all make an appearance. The format of the file itself seems to have some similarities with PNG, (?) of all things (crc is a bit different, and the firmware format supports some basic encryption). – booto Mar 24 '15 at 11:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.