Reverse Engineering a Router – part 2

Hello everyone! Welcome to the thrilling conclusion of the last post!

Let’s kick start this where we left off last time. The USB to UART connector was hooked up to the pins we had soldered onto the router PCB, and it was starting to spit out information.

At this point, as we can see in the above screenshot, it asks us this:

Please choose operation:
3: Boot system code via Flash (default).
4: Entr boot command line interface.
0

Obviously we want to go to a command line interface, so we hit 4. Nothing happens for a second and then the system starts booting the system code via Flash.

Wait what?

OK let’s try rebooting and pressing 4 *repeatedly*

Still no dice. It keeps on ignoring the input.

After about an hour of trouble shooting and checking connectors, re-reading the wiring diagrams I made on a Post-it Note, I still could not figure out what was going on. I even went so far as to Tweet Juan Carlos Jimenez to ask him if he knew what might be going wrong.

He told me to check all the stuff I had already been investigating, so no luck there, but many thanks to him for replying.

I started to wonder if that tiny resistor that came off when soldering actually was important? Well let’s try to drill the holes for the other board, solder some more connectors and see if it is the same result. This is exactly why we bought two boards, redundancy!

This is what it looks like when you have pretty much no idea what you are doing.

Checking that I didn’t somehow manage to screw up the reverse side of the board.

Fortunately the holes are exactly the same spacing as the pins I have.

One measure of not-so-great soldering later, and…

All the pins that are required to be soldered, are.

So now let’s hook this up to our USB to UART bridge and see what happens.

It loads into a shell! At this point I was ready to call it a day, as this is far further than I ever thought I would be able to get. Obviously we can’t stop there though.

U-Boot is a default loader, that is used by several board vendors. I learnt this after some extensive Googling. It also doesn’t seem to have that many commands available that could be of use to us. There is lot’s of stuff to do with memory, and that probably means directly manipulating it, which is for sure the easiest way for us to turn this router into a paperweight.

I rebooted it and got myself a coffee. When I came back I realised that I had missed the prompt for the command login but hit enter anyway.

It dropped me into a login prompt!

This is something called ATP Command Line Interface. After several failed attempts to login, I correctly guessed the credentials as admin:admin. After some further exploration, and a lot of frustration, it turns out that this is not a bash shell.

Once inside, we can see a list of commands using the ‘?’ and we can also make a “debug display cwmp” command and that should display all the information this device uses in order to connect back to the ISP to upgrade itself. This is an application layer protocol called TR-069, but let’s not get into that, I googled around about it for an hour, and realised I couldn’t understand half of what I was reading.

I wasn’t really able to learn much more about the ATP shell, but did at some point get myself into a real shell by typing in the word “shell”. We are dropped into a BusyBox shell. This is super awesome, as it is exactly what I was hoping to find myself in.

Busybox is essentially a really tiny version of Linux, and you find it on almost every different kind of embedded device. It’s really stripped down, but comes with most of the functionality of Linux, allowing you to poke around the file system.

So let’s see what there is to see around here! My usual first stop when investigating a new linux is the /etc folder. There might be a passwd or shadow file around that we want to check out.

Oh dear.

Those two on the left, including one above the root.pem that I forgot to draw around, are pem files. They are TLS certificates to verify the authenticity of this machine and perhaps the authenticity of others. It is pretty normal for all embedded devices of this kind to have the exact same one, meaning finding out one can lead to compromise of all devices of this type.

The root.pem is likely for communicating with a server from the ISP. I would bet non-real money that it is for when the box needs firmware updates.

Also there is obviously a passwd file.

I figured we could check everything at our leisure if we had the entire file system, and as it is probably only a few megabytes (BusyBox is perhaps 2MB in my experience). There is a USB port on the board, and it is apparently running a Samba service of some kind based on one of the boot messages.

I added a USB and managed to get a good few files off.

Using “grep -i -r password” we find several passwords on the device’s file system.

At this point, I am not really too sure where to go with this project. We have come pretty far though, from just receiving a couple of clunky bits of plastic in the mail, to drilling the PCB’s, soldering pins and communicating with the embedded linux systems.

I am for sure going to try to attempt this exact same process with many other things that I have collected over the years, that have found their way into my “To be hacked/taken apart” box.

If I have any more success with them, then I will absolutely post the results here.

I hope you have an awesome week and you enjoyed this mini embedded systems hacking tutorial!

Leave a Reply

Your email address will not be published. Required fields are marked *