Linux on a D-Link DI-524

Introduction

I bought a D-link DI-524 to serve as a simple access point when my Linux AP machine kicked the bucket. I decided to buy a dedicated AP because energy prices got higher and I started looking for ways of reducing the energy consumption of things that run 24/7. All well and good, but now I got a new connection, and they gave me a integrated router with an AP, so I have no need for it anymore. 

Then my attention turned to my Wifi Link. I have a point to point like with a friend via modified Sky satellite dishes. As it stands my end is connected to an old PII laptop and cardbus card (the modified Kcorp, hacked to run @ 100mW). It works well, but the laptop does draw quite a bit of power. So I decided to see if I could get the D-Link to run Linux and act as a client. One of the reasons I bought the D-Link was because it uses the RP-SMA connector, which is the connector I decided to standardise on for my Wifi Kit. As such it would be a direct replacement for the Laptop, assuming I get it to work as a client.

 My AP:

On the base are some useful details:

So my router is of the "B4" hardware revision (serial number and MAC blacked out). Looking around I found out the firmware for it and guess what. It's built on open source software. From what I read the Dlink already runs Linux! This opens up the possibility of just modifying the Linux system on it, rather than having to build our own version of Linux. Dlink was also nice enough to actually release the whole source code once the router was discontinued. This means we can attempt to modify the stock firmware to do what we want it to do.

 

31 March, 2008

Getting the source

First thing to do is to download  from D-link. You can find all of D-links resources here. Download the source code and name it something. Mine is called "DI-524_E1_GPL.tgz", and thats what I will be using.

First we unzip it to a convenient place:

Mars src # tar -zxvf ./DI-524_E1_GPL.tgz 

This will create a folder in the directory called "di524". Now on to seeing what we can find out.

First impressions

First good news is that it seems the wifi chip the router uses is atheros, I found this out because I found the madwifi modules in the folder. This means that we are using a well supported chipset and many programs exist to work with it (they could have coded their own drivers for a proprietery wifi chipset instead, so kudos).

Also found out common tools like "iwconfig" and "hostap". This means we should already have all the bits and pieces to make this system function like a client. Now the only question is how to access them from the firmware. It's not like the D-link firmware provides a bash console for us. This means we have to find a way to enable a text console from the interface we have.

Well, afther further browsing around, we find out that there is a tftp server (tftpd). This stands for "trivial ftp", a small subset of the modern FT Protocol, that's well suited to devices with limited memory. This is good news as it means we could (in theory) transfer files to/from the router. Things like programs to add functionality (e.g. kismet, if resources allow) or configuration files.

The system seems to use the kernel httpd service to serve webpages. It also supports php via a external program (atp).

TFTP access attempt

Well, the next thing to do is to find out what port the ftp server lives on. We connect the router up to a network and tell nmap to scan the ports.

Things you need to do:

  1. Reset the router to factory defaults before proceeding. That way you are sure that this guide and you are dealing with the same situation
  2. Make sure your firmware matches the source (v2.06). If it doesn't than upgrade it.

Well, I don't seem to be able to find the tftp port. Nmap only gives me two ports, 80 and 515, neither are tftp. As such this idea looks like a dead end.

Any php loopholes

Next option is to see if I can find any holes in the web code. As we found out, the webserver is configured for php support, and we found php files in the /var/www directory. As such it is safe to assume that the web server has php support enabled. Next thing to find out where the files are held. As the AP uses javascript navigation we have to capture the http headers between the browser and AP. Once captured URL is as follows:
 
http://192.168.0.1/prim.htm?rc=_&rf=&ZT=1220196151002
 
Next thing to do is find "prim.htm" in the sources, something which I have not managed to do. I assume the actual html files are not provided, as they are probably under a proprietery license, so this idea will not work.
 

CGI Holes

Next thing I had a look at was the cgi-bin system. I noticed that when you made a change to the wlan settings, it would call the following cgi program:
 
http://192.168.0.1/cgi-bin/wlap?RC=%40wlap&rf=&rd=x&Xf=1&prev=&CS=0&WD=o&ZN=dlinkie&ZC=6&_Security=0&ZS=0
 
ZN = Zone name (Essid), I named it "dlinkie" for testing
_Security = Encryption (0 = None)
 
The others I don't know about (at the moment, still looking). Any ideas appreaciated of course.
 
The situation is the same here as with the php, we don't seem to have the program as part of the sources, so I have no idea about what it supports.

Building custom firmware

Well, I decided to stop faffing about with the above. I decided to build the firmware with my modifications that will give me the access I want.

Building the toolchain

Well, you have extraced the files already, enter the "di524" directory. There you will find a script called "toolchain.sh", you will need to run this in order to be able to build firmware.

Execute it, it will ask you some questions, it gave me the following options:

Target Processor Architecture
> 1. Generic (MIPS I) (CONFIG_MIPS_ISA_1) (NEW)
  2. MIPS II (CONFIG_MIPS_ISA_2) (NEW)
  3. MIPS III (CONFIG_MIPS_ISA_3) (NEW)
  4. MIPS IV (CONFIG_MIPS_ISA_4) (NEW)
  5. MIPS32 (CONFIG_MIPS_ISA_MIPS32) (NEW)
  6. MIPS64 (CONFIG_MIPS_ISA_MIPS64) (NEW)

I didn't know what architecture is used (As I have yet to find any specs about the router, I will probably have to  take it apart if the defaults fail). I left it as the default (1). I also left the processor Endianness as "Little Endian", because when nmap was scanning, it said "IP ID Sequence Generation: Broken little-endian incremental", so I'm going to assume the whole thing is little endian. I also assume that there isn't a MMU.

Once it is done, run "source ./toolchain_path" in the terminal you will be building from as they tell you to.

Once it is done, go into "/usr/src/di524/buildroot", and type make. In my case this did nothing (as everything was compiled already). For the time being we will not be making any changes to the code, first we want to see if we can make a valid image that can be flashed to the router.


April 24, 2009

Wow, almost a whole year since I last looked at this article.  During this time I had not really done anything with this project. The wifi link still uses the old laptop, which is soon to be replaced with a Mini-ITX based system and the DLink 524 just sat in the back of my cupboard... till now.

I got an email from someone called "Rubber Ducky", asking about what I managed to do with this project. To be honest, I'd forgotten all about it, but now that I've been reminded about it (specifically that I  didn't succeed) it's bugging me, so I set out to try again.

Building the image

This was a pain last time, because my system was just not set up for compiling the source, and altering my computer was causing way too many problems for me (plus it was taking so long). The solution this time was  to give it it's own machine, specifically, a Virtual machine. I set up a VM running Gentoo Linux (really, nothing comes close to it as a development platform), got the sources (from ftp.dlink.com/GPL this time) and compiled it as per instructions above.

After lots of compiling (and some hacking of  hostap code that refused to compile) I got my first home built image! Next thing I did was write it to the 524, which it did successfully! I now have the AP running my own compiled firmware, an excellent first step!*

(*)This also means that the defaults specified above work fine! No need to change them.

Update: April 25, 2009

I found out that my image wasn't being written to the D-link. I mean, I update the firmware, the checksum is good, and it says it succeded, but after rebooting theold firmware is still there. I have no idea why, so I shall have to dig into this.

Other interesting bits and bobs

I found out that there is an automated way of logging into the D-link.If you type:

http://<path to DLINK>/cgi-bin/logi?rc=@&PSW=<ADMINPASSWORD>&rd=menu

(replacing the "path to DLINK" and "Adminpassword" parts) it will try to log in for you. If the log in is correct, you will get a blank page (totally blank, no HTML source at all).

If you get the password wrong, you get a blank page, but the source reads something like this:

<SCRIPT LANGUAGE=JAVASCRIPT><!-- 
sa("Password is incorrect!
");

//--></SCRIPT>

 

As this is much faster (and easier) than screen scraping and crafting your own responses, it will be a useful thing for automating logins for administration (or it could be a good way of automating dictionary attacks).

 Oh, and I also found out that the router runs the mathopd (http://www.mathopd.org/) web server.