Sunday, December 8, 2013

Building MobileLite Wireless MLW221 from source

If we are going to build the firmware from MobileLite from source, the first requirement is getting the source from the Kingston support pages. This is an self-extracting archive, and can be extracted using RAR, or similar compatible extractions tools. Once we are finished extracting the code, we can have a look at it and try to find out how to attack this project.

The first thing we notice is that it running on a version of uClinux, a simple and well documented embedded Linux version. We know we are going to need a toolchain to be able to cross-compile this, so we have two options. We could do it the hard way, and look at specifications, FCC images etc. to find out the hardware architecture. But instead we will cheat a little bit and just look around in the source. Specifically we look for the definition of CC, the compiler. This tells that they were using the compiler "/opt/buildroot-gcc342/bin/mipsel-linux-uclibc-gcc", which is pretty much all we need to know. Now we know for sure that we are dealing with a MIPS little endian of some sort. And thats all we really need to know. We can also see that the toolchain is quite old buildroot toolchain, since the naming has now changed in buildroot.

Again we are left with two options. We could build a shining new toolchain to use for our mipsel. We also know that gcc342 is a very old version of GCC, and we might bump into quite a lot of annoyances if we try with a toolchain with a 10 year newer GCC version. But mostly because we are lazy, we can be pretty sure this toolchain is available somewhere online. So we do a few quick searches. And quite fast we find a BBS where someone have some issues compiling from source for another kind of device thats using the same toolchain. And a few quick later we have downloaded the source code for that device, and they have been kind enough to include the toolchain together with the source code. All honors to Medion AG.

So now we have everything we need to start working on this. I put the toolchain in the same folder we found earlier, so we don't have to manually change all the Makefiles. You will also need a few build tools, but that should be easy for you to sort out. If we do a quick grep for "/home/" we can see that it refers to quite a lot of absolute paths. It seems like the most of the work is done by a guy named Steven, but it also refers to the homedir of a Winfred. I guess this means we will have to work a little bit to get this up and running. I'm not going to write it all down here, but basically its just fixing include paths.

If you are using dash as default shell for sh (/bin/sh -> /bin/dash) you will got syntax errors when its building some of the packages. I choose to fix this in the makefile of the affected packages, and refer to /bin/bash instead of /bin/sh.

It also complained about missing includes when compiling SSL for the webserver. For now I just changed the Makefile to compile it without SSL. Since we don't really need it right now.

So now we stop at a issue with iconv.

/opt/buildroot-gcc342/bin/mipsel-linux-gcc -c -I. -I. -I.. -I../include -I./../include -I../srclib -I./../srclib -I../lib -g -O2  -DINSTALLDIR=\"/usr/local/bin\" -DLOCALEDIR=\"/usr/local/share/locale\" ./iconv.c
In file included from ./iconv.c:77:
../srclib/gettext.h:26:22: libintl.h: No such file or directory
In file included from ./iconv.c:77:

I guess we have to fix this as well. A quick find shows that missing file is located at "./lib/include/libintl.h", relative to the root dir of the firmware. So I guess we will have to change the Makefiles here. So we just go to the folder "user/libiconv-1.11/src" and edit the Makefile manually, and add " -I$(srcdir)/../../../lib/include" to the include directive.

Next stop:
make[2]: execvp: ./makedevlinks: Permission denied
Strange, lets look a little bit at this one.
If we check the permissions on the file we can see this:
-rw-r-xr-x 1 erik erik 3999 nov.   7  2012 makedevlinks
For some reason the owner (me) doesn't have execute rights on the file, and the same goes for the rcS script. This must be a mistake, so I just add the missing bit. And then it fails again, and the execute bit is unset again. Time to look at the main Makefile. We can see here that it sets the mode to 655 and 675 on all the executable scripts. I really can't understand why, they are not suid or anything. So I just change all of them to be 744. My system, my rules.

Next issue:
cp /home/erik/hack/mobilelite/MLW_SDK_4100/images/erik_uImage /tftpboot
cp: cannot stat ‘/home/erik/hack/mobilelite/MLW_SDK_4100/images/erik_uImage’: No such file or directory
But there is a file called root_uImage, this leads me to think that there is some issue with environment variables. And quite correct, the Makefile at "vendors/Ralink/MT7620" has been changed from "IMAGE = $(IMAGEDIR)/$(USER)_uImage to "IMAGE = $(IMAGEDIR)/root_uImage". I just changed this.

We know its almost finished compiling the firmware and it stops at the image part, so we just issue a "make image". And now it complains that my user doesn't have right to write to the "/tftpboot" folder, and quite correctly so. But then again I don't need the makefile to put the image there anyways, so we just comment this away from the makefile. But I guess this means they have been using some dev kit with ethernet support.

And again, it fails on the root_uImage, I guess this is the reason why they changed the Makefile earler. We just add another line where we copy our $(USER)_uImage to root_uImage. So now the file is like this:
#!/bin/sh
cd CRC_tool
cp '../images/'$USER'_uImage' ../images/root_uImage
cp ../images/root_uImage ./
./CRC_tool root_uImage WMTM-169N
mv ./CRC_root_uImage ../images/
rm -f root_uImage
ver=`grep " VER" ../user/gt_utilities/version.h | cut -d '"' -f 2`
mv ../images/CRC_root_uImage ../images/Kingston_widrive_v$ver.bin
chmod 777 ../images/Kingston_widrive_v$ver.bin
cp ../images/Kingston_widrive_v$ver.bin ../images/mlwfw_v$ver.bin

And finally we have a "working" image. This is where the fun starts. In the next post.

No comments:

Post a Comment