wiki.mbirth.de/know-how/hacking/_posts/2009-02-02-asus-wl300g.md

---
title: ASUS WL-300g
layout: default
created: 2009-02-02 23:18:42 +0100
updated: 2009-02-02 23:18:42 +0100
toc: true
tags:
  - know-how
  - hacking
  - hardware
  - wifi
  - asus
  - firmware
---
Install DD-WRT
==============

**Download:** [dd-wrt.com](http://www.dd-wrt.com/dd-wrtv2/down.php?path=downloads%2Fv24-sp1%2FConsumer%2FAsus%2FWL300g/)


Patching firmware
-----------------

Older versions of DD-WRT didn't provide a firmware file for the WL-300g, but only for the WL-500gx. So I had to patch it for the WL-300g to accept.

The router ID was found quick: In the `dd-wrt.v23_asus.trx` at `0x356fc4`, there's the string

    57 4c 35 30 30 67 78

which is `WL500gx`. After changing it to `WL300g ` (with a space after the "g" to fill up the digit), the router didn't reject the
firmware directly, but initiated the update, then rebooted quickly after that and showed the old firmware again.

According to the [DD-WRT manual for the WL-500g](http://www.dd-wrt.com/wiki/index.php/Installation#Asus_WL500G</u>.28Original.29),
the router should have a recovery mode which you can enable by holding the Reset button while powering on the device. But seems this mode wasn't there in my router.

So there has to be some sort of checksum which tells the router whether the firmware file is corrupt or not. In the DD-WRT forums
I read somewhere, that there are only some informational bytes different between a normal DD-WRT binary firmware and the ASUS TRX format - maybe the ID-string at the end.

Therefore I compared the two files `dd-wrt.v23_asus.trx` and `dd-wrt.v23_generic.bin` and voilà: Besides the few bytes at the end of
the file, there were 4 additional bytes different at position `0x08`. This HAD to be the checksum. The remaining question was, from
which bytes it was calculated. Since the seemingly compressed data began at `0x28`, I tried from there to the end and used
[Hex-Workshop](http://www.hexworkshop.com/) to calculate different checksums, but nothing matched what was in these 4 bytes. The next
try was from `0x10` but also no match. Then I tried starting directly after the checksum in the header, from `0x0c` and bang:
The CRC32 checksum matched that in the header.

![Hex Workshop Screenshot]({{ site.url }}/assets/hexworks.png)

So I calculated the CRC32 of my modified file and changed the header - and now I could upload the DD-WRT file using the normal firmware
upgrade of the original firmware. After installing v23, you can easily update to v24 using the DD-WRT web interface.

![DD-WRT Version Info]({{ site.url }}/assets/ddwrt.png)