I am trying to do some reverse engineering to a Devolo dlan wifi 500 device (MIPS architecture). 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 (unmodified) update and changed one bit on the padding, uploaded it to the device and got the same error message.

If I knew where the checksum 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 engineering could help me.

I could try to brute force the sum. Since it is a sum, I could create a collision 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.

  • Find the error message in the extracted code, the verification routine should be nearby.
    – Igor Skochinsky
    Commented Mar 23, 2015 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
    Commented Mar 23, 2015 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). Commented Mar 23, 2015 at 17:56
  • can you give me some help to extract the bin from the downloaded .dvl file? Maybe this will help to debrick my dlan500 wifi
    – z3ky
    Commented Dec 25, 2020 at 10:37
  • If you have a new question, please ask it by clicking the Ask Question button. Include a link to this question if it helps provide context. - From Review
    – sudhackar
    Commented Dec 25, 2020 at 12:06

1 Answer 1


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. Commented Mar 23, 2015 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
    Commented Mar 23, 2015 at 19:37
  • I used IDA to analyse the binary I mentioned in the 'more details' part of the answer.
    – booto
    Commented Mar 24, 2015 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
    Commented Mar 24, 2015 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
    Commented Mar 24, 2015 at 11:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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