Vertex Wireless VW210: a rare router and its inner world

Lyrical digression: everything described in this article was carried out exclusively for educational purposes, the goal of extracting material profit was not pursued, not a single cat was injured in the process (I hope). Everything that is described here you repeat at your own peril and risk.

KAPV smoker (for those who have expensive traffic)

For several years in a remote village working hard, this elusive Joe network industry. The choice fell on him, thanks to the support of the only working solution for the area, namely CDMA 450 from the local operator Sotel (ala SkyLink). Unlike other routers / modems for this standard of that time, it was the only one that made it possible to achieve stable communication using some kind of mother and a directional antenna. But the trouble is: the manufacturer’s website (and possibly himself) has disappeared from the horizon of these of our Internet back in 2011. There was only a pathetic video on YouTube and references to their products from a variety of sellers and operators.


KDPV for readers who do not limit themselves to anything, although what is there to get attention if you are already here.

All subsequent images are clickable (except for a fairy-tale character)

Motivation

Together with the site and the manufacturer, they left this mortal world and any hope of receiving firmware files and even more so opening its source codes, despite the requirements of the GPL. The idea to get more complete access to the system than the web interface allows, appeared in my head for a long time and did not give rest to playful hands. And, thanks to the question on the toaster from uv. Nomad1 and contrary to his advice to throw out this misunderstanding of the network industry, was immediately executed. In fact, thanks to this habruiser for both the first and second, because it was a direct challenge, after which I shouted “Dementia and courage!” went into an unequal battle with the Korean technological machine of the 2009 model.

Soft

First of all, I began to study the web interface, or rather, its inner world. Thanks to the hole in the used version of the GoAhead embedded web server, it turned out to download the source code of the pages, adding a "/" to the main link. For example, the link http://192.168.200.1/html/log.asp opened the result of the script log.asp, and http://192.168.200.1/html/log.asp/ the source file of the script log.asp. With a small script on the bash, everything that was somehow mentioned in the scripts was pulled out, but after analyzing the mine it became clear that this information was clearly not enough for hacking.

Due to another vulnerabilityin the same GoAhead, it was possible to execute the code when the buffer overflowed, but for this it was necessary to obtain information about the address where to transfer control, and in the absence of access to the system, the call stack should not be received in the crash.

In addition to 2 vulnerabilities, vulnerabilities in the implementation of the uPnP server were found in the web server, which led to buffer overflows and code execution, but their operation also required access to the router system.

Iron

Having said goodbye to the hopes of a software hack, I went on to study the iron part.
The iron part of the router is a sandwich of two boards: a modem and interfaces (top in the photo) and a processor unit (bottom in the photo): On the back of the processor part there is a mini-PCI connector in which the Wi-Fi card rests peacefully: Initial examination of the patient showed that the main nodes of this device are:

• Qualcomm MSM6801A - modem processor
• Micrel KSZ8692PB - a system on a chip (SoC) with a network, PCI and other payload

Since we have identified the largest SoC chip, we need to think which way to get to it. Unfortunately, by some ridiculous coincidence, Micrel went into the sunset just like Vertex Wireless. The search for at least some documentation on this chip led to deadlocks in forums where engineers were outraged by the closed specifications and generally the lack of documentation in the public domain, which lovely managers invited them to discuss this face-to-face. But The Wayback Machine came to the rescue , thanks to which I still managed to get hold of the documentation and other goodies for this chip.

UART

After studying the extracted documentation, it became clear that our new friend has 4 pieces of UART-interfaces, as well as JTAG. One of the UARTs is most likely used as a debug console. By launching the terminal,

$ minicom -D /dev/ttyUSB0 -b 115200

I started poking a needle connected to the TTL-USB converter to the debugging points on the board, periodically sending a router to reboot. And at the next point, the cherished letters ran in the console ... and on the next letter answers. It turned out to be UART to communicate SoC with the modem. Theoretically, the exchange log with the modem is also of some interest, especially given the lack of clear documentation on the creation of Qualcomm in the public domain, but we still have a slightly different goal.

The points of the UART debugging console turned out to be on the back side of the board and were closed by the second “sandwich” board, so it took them a bit more time to detect. We solder to the treasured contacts:








And so we got to the console, but the system after loading asks to log in and refuses to accept any standard attendance passwords there, and the u-boot bootloader was assembled without the ability to stop the boot and manage it. The path of the serial console was closed for me and I went further ... well, this is not counting the stupid attempts to guess the password with the minicom script, which were doomed to get the result a little later than that super-computer would say “42”.

Jtag

My luck is that all the contacts of the JTAG interface of the chip turned out to be extreme and could be dialed using a needle: JTAG contacts on the board: However, the adapter assembled on the knee from the DB25 dad for the LPT port, resistances and snot showed that JTAG either disabled, or someone has crooked hands. For the second option, a factory JTAG adapter was ordered on the notorious trading platform of the Middle Kingdom, but this is a long time. And in the first case, you should try to enter SoC into some kind of test mode with the help of needles, wires and test points going to the legs of TESTEN and TESTEN1.

Inspiration

But at that moment an old hack surfaced in my memory, which is used to force firmware of any hardware: drive the hardware into the “broken firmware” mode by shorting the address legs on the USB flash drive. The firmware on our board is located in the microcircuit (Samsung K8P3215UQB www.bdtic.com/DataSheet/SAMSUNG/K8P3215UQB.pdf ) under the screen next to the processor. The first legs of this microcircuit are the address lines, and by shorting them we can violate the firmware reading: Since we would like to get into the u-boot menu, we will be naughty right after loading it at the moment of reading the rest of the firmware. We turn on the router and after a significant blinking of the LEDs and displaying the text on the console:

U-Boot 1.1.4 (November 6, 2008)
DRAM: 64 MB
Flash: 4 MB
In: serial
Out: serial
Err: serial

we begin to affectionately shorten 1-2-3-4 feet of the flash drive with a screwdriver, achieving the cherished:

Bad header checksum
ks8692pb>

Well, we got the location from the intractable bootloader.

Loader

Let's see what this veteran can do:


It looks promising, but in fact it turns out that some of the commands do not work, despite the mention in the help. First of all, I would like to know how the addressing of the flash drive is arranged:


The areas marked with "(RO)" are the bootloader itself. Touch it until it pulls at all, so we run past it and stop our eyes on the remaining ranges.

Long and painful attempts to dump the contents of the flash drive in normal form ended with a SUDDENLY rewritten flash after restarting the process. It turned out that under some unknown conditions, the bootloader after downloading via tftp file sent the processor to a rezet, after which the flash drive automatically started deleting the range where the kernel and ramdisk images lie, and the loaded one starts to be written in their place. In my case, it was a hastily assembled Micrel OpenWRT image for this platform, which has the same relation to combat firmware as a plumber and choreographer. I tried to load it into memory, but the above feature of the bootloader led to the recording of this nonsense in a flash. It saved that in the first place the bootloader was not jammed, and in the second I had the same battle piece next to me.

Because the bootloader didn’t go anywhere, but at the place of the firmware it wasn’t understood that, interrupted halfway during the recording, the procedure was “a bit easier”: now there was no need to caress the USB stick with a screwdriver to get to the “Bad Header Checksum”.
On the barely breathing half-corpse, the only way to dump a USB flash drive was found - this is the md (memory display) command, which displays the indicated section of memory directly to the console in the form of hexadecimal text:



“It will be a little!”
It turns out that in addition to the starting address, you must also specify the second parameter - size.

Dump

In order to ensure that everything acquired by overwork is not hidden together with the minicom console, we start writing the output to the file: press "Ctrl + al" and confirm the file name, for example, the standard "minicom.cap".

We need a dump of the area from 0x1c040000 to 0x1c3fffff (see the output of flinfo). It turns out a block of size 0x3c0000, but the size of the md (memory display) command is not in bytes, but in 32-bit (4-byte) words, so the value we need is obtained by dividing 0x3c0000 by 4 and is equal to 0xf0000. Here is the result:

ks8692pb> md 1c040000 f0000

We are leaving to drink tea / coffee / out of boredom, since the procedure for outputting 3932160 bytes in text hexadecimal form to the serial console is sad. After completing the drain procedure, close minicom (Ctrl + ax).

Copy the minidump exhaust to a file with a more meaningful name

$ cp ~/minicom.cap ./dump.hex

We'll have to look into it and remove the extra lines that were entered / displayed in minicom. In my case, this is one line at the beginning:

ks8692pb> md 1c040000 f0000

and one at the end of the file:

ks8692pb>

Convert from text to binary data:

$ xxd -r -s-0x1c040000 dump.hex > dump.raw.bin

An offset of -0x1c040000 is necessary so that data from the range 0x00000000-0x1c03ffff are not written to the final file, which xxd otherwise considers missing and politely writes to the file.

It turned out that the byte order in the resulting binary was not the same, and I had to look for a solution to expand every four bytes (32-bit word). On the Internet, a solution was quickly found:

cat dump.raw.bin | perl -e 'while (sysread(STDIN,$d,4)){print pack("N",unpack("V",$d));}' > dump.bin

Autopsy

Let's see what we have inside the dump:


It is interesting that, despite the marking on the board "2009-10-15", the factory firmware is labeled January 2010. Apparently something “went wrong” and the finished party was finished on the go. It’s good that the software, and not the hardware ... mounted installation.

Divide the acquired into separate parts:
title

$ dd if=dump.bin of=uImageHeader ibs=1 count=14476

core (size 1595188 = 1609664-14476)

$ dd if=dump.bin of=zImage ibs=1 skip=14476 count=1595188

ramdisk image:

$ dd if=dump.bin of=initrd.gz ibs=1 skip=1609664 & gunzip initrd.gz

Later, after editing ramdisk, it will be possible to assemble everything back into one whole with the commands:

$ cat uImageHeader > out.bin
$ cat zImage >> out.bin
$ gzip initrd & cat initrd.gz >> out.bin

Now you need to find out what kind of file system is used:

$ sudo blkid -o value -s TYPE ./initrd
ext2

And mount it somewhere for cruel experiments:

$ mkdir rootfs
$ sudo mount -o loop -t ext2 ./initrd ./rootfs/

After a short study of FS, we find:

$ sudo cat rootfs/etc/inittab
::sysinit:/etc/rc
::respawn:/bin/lgc_login

The first thing that comes to mind is “what is hardcodes here?”:


Well, here it’s enough to have eyes to discern the username / password pair “admin / .admin.” Tightly wired in the code. I will not torment - authorization in the serial console with this data was successful.

After a more detailed study of the FS, it turned out that you can run the command without authorizing at all, for example telnetd:

$ wget --post-data "cmd_key=%24telnetd%3b" "http://192.168.200.1/goform/ping_showpopup"

It will start, start accepting connections ... but, unfortunately, it will not be able to authorize us. But this is a completely different story.

Thanks uv. Nomad1 for a kick under my lazy ass, to kind people who provided a half-dead model for inhuman experiments, to my wife and daughters for patience, and to my five-year-old son for help in rebooting the router and running commands on the computer when my dad was running out of limbs.