Vertex Wireless VW210: a rare router and its inner world

Lyrical digression: everything described in this article was made solely for educational purposes, the goal of material gain was not pursued, not a single cat in the process (hopefully) was damaged. Everything that is described here you repeat at your own peril and risk.

KDPV smoker (for those who have expensive traffic)

For several years in a deaf village, this elusive Joe of the networking industry has been working tirelessly. 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 the time, he was the only one who allowed to achieve a stable connection with the help of some kind of mother and a directional antenna. But here's the problem: the manufacturer's website (and perhaps he himself) disappeared from the horizon of these of our Internet back in 2011. All that remains is the pretentious video on YouTube and the mention of their products from various sellers and operators.


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

All subsequent images are clickable (except for the fairytale character)

Motivation

Together with the site and the manufacturer, they left this mortal world and any hopes of receiving firmware files, let alone opening its source codes, despite the requirements of the GPL. The idea to get a more complete access to the system than the web interface allows, appeared in my head for a long time and didn’t 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 enforced. In fact, thanks to this habraiser both for the first and for the second, because it was a direct challenge, after which I shouted "Dementia and courage!" I went to an unequal battle with the Korean technological machine of the sample of 2009.

Soft

First of all, I began to study the web interface, or rather its inner world. Thanks to a hole in the used version of the GoAhead embedded web server, it was possible to download the source code of the pages by adding the "/" link 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 original file of the script log.asp. With a small script on the bash, everything that was at least somehow mentioned in the scripts was pulled out, but after analyzing the mined, it became clear that this information was clearly not enough for hacking.
')
Due to another vulnerability in the same GoAhead, it was possible to execute code when the buffer overflowed, but for this it was necessary to get information about the address, where to transfer control, and in the absence of access to the system, the call stack could not be received when it was dropped.

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

Iron

Saying goodbye to the hopes of a software hack, I turned to the study of the iron part.
The iron part of the router is a sandwich of two boards: a modem and interfaces (on the top of the photo) and a processor unit (on the bottom of the photo):



On the reverse side of the processor, there is a mini-PCI connector in which the Wi-Fi board is at peace:



The initial examination of the patient showed that the main components of this device are:

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

Since we have identified the largest SoC chip, we need to think from which side to get close to it. Unfortunately, by some ridiculous coincidence, Micrel went into the sunset as well as Vertex Wireless. Searches for at least some documentation on this chip were led to dead ends on forums, where the engineer was outraged by the secrecy of the specifications and the lack of open access documentation, to which the dear managers invited them to discuss this one-on-one. But The Wayback Machine came to the rescue, thanks to which it still managed to seize documentation and other goodies for this chip.

UART

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

$ minicom -D /dev/ttyUSB0 -b 115200 

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

The points of the UART of the debugging console turned out to be on the back of the board and closed with the second “sandwich” board, so it took a little longer to detect them.



Solder to the cherished contacts:




And here we are in the console, but after the download the system asks for authorization and standard attendance passwords everyone there flatly refuses to accept, and the u-boot loader turned out to be assembled without being able to stop the download and manage it. The path of the serial console was closed for me and I went further ... well, this is not counting foolish attempts to select a password as a script for minicom, which were doomed to receive the result a little later than that super computer says its "42".

JTAG

My happiness is that all the contacts of the JTAG-interface of the chip turned out to be extreme and were available for “pinging” using a needle:



JTAG contacts on the board:



However, the adapter assembled on the knee from the DB25-papa for LPT-port, resistances and snot showed that the JTAG is either disconnected or someone has curved arms. For the second option, a factory-made 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 the SoC into some kind of test mode with the help of needles, wires and test points that go to the TESTEN and TESTEN1 legs.

Insight

But at that moment an old hack emerged in my memory, used to force every piece of hardware to be flushed: drive the piece of iron into the “broken firmware” mode, shorting the address legs on the flash drive with the firmware. On our board, the firmware is in the microchip (Samsung K8P3215UQB www.bdtic.com/DataSheet/SAMSUNG/K8P3215UQB.pdf ) under the screen next to the process.



The first legs of this microcircuit are the address lines and, by shorting them, we can break the firmware reading:



Since we would like to get into the menu of the u-boot, we will be naughty right after it is loaded at the moment of reading the rest of the firmware. We turn on the router and after a significant blinking of the LEDs and the text output to the console:

  U-Boot 1.1.4 (November 6, 2008)

 DRAM: 64 MB
 Flash: 4 MB
 In: serial
 Out: serial
 Err: serial 

Start gently short 1-2-3-4 feet with a screwdriver to achieve the coveted one:

  Bad header checksum
 ks8692pb> 

Well, we have achieved the location of the intractable loader.

Loader

Let's see what this veteran can do:


It looks promising, but 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 works:


The areas marked "(RO)" are the bootloader itself. Touching him is not pulling at all, so we run past him and stop his eyes on the other bands.

Long and painful attempts to dump the contents of the flash drive in a normal form ended EXTREMELY with a flush overwritten after the restart. It turned out that under some unknown conditions, after downloading the file via tftp, the loader sent the processor to a rezet, after which the flash drive automatically started erasing the range where the kernel image and ramdisk lie, and the loaded one begins to be written in their place. In my case, it was a hastily assembled image of OpenWRT from Micrel for this platform, which has the same attitude to combat firmware as a plumber to a choreographer. I tried to load it into memory, but the above feature of the bootloader led to the recording of this nonsense in the flash. It was saved by the fact that in the first place the loader did not get stuck, and in the second I had the same combat piece of iron next to me. Subsequently, the dump from the battle was set up on a padded test specimen, but then it was not at all ridiculous and the bricks fell to the floor in a continuous stream, while I tried to pull myself together.

Since the bootloader didn’t go anywhere, and at the firmware site didn’t understand what, interrupted halfway through the recording, the procedure was a bit easier ’: now you didn’t have to caress the stick of the flash drive with a screwdriver to go to the“ Bad Header Checksum ”.
On the barely breathing semi-corpus, the only way to dump the flash drive was found - this is the command md (memory display), which displays the specified section of memory directly to the console in the form of hexadecimal text:



"It will be enough!"
It turns out besides the starting address you need to specify the second parameter - the size.

Dump

In order that everything acquired by overwork will not disappear together with the minicom console, we start recording 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 flinfo output). A block of size 0x3c0000 is obtained, but the size of the md command (memory display) is not taken in bytes, but in 32-bit (4-byte) words, so the value we need is obtained by dividing 0x3c0000 by 4 and equal to 0xf0000. Here is the result:

  ks8692pb> md 1c040000 f0000 

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

Copy 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 the 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 

The offset to -0x1c040000 requires that data from the 0x00000000-0x1c03ffff range, which xxd would otherwise find missing, and politely write to the file, is not recorded in the final file.

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

 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, in spite of the marking on the “2009-10-15” board, the factory firmware is labeled January 2010. Apparently something “went wrong” and finished the party finished on the move. Well, that software, not iron ... mounted installation.

Divide the acquired into separate parts:
headline

 $ 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 

Subsequently, after editing a ramdisk, it will be possible to put everything back together into one command:

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

Now you need to find out what 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 brief study of the 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 it that has been done?”:


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

After a more detailed study of the file system, it turned out that it was possible to run the command without any authorization 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, will not be able to authorize us. But that's another story.

Thank uv. Nomad1 for kicking under my lazy ass, kind people who provided a half-dead sample for inhuman experiments, my wife and daughters for patience, and my five-year-old son for helping to reboot the router and run commands on the computer when my dad ran out of limbs.