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.
KDPV smoker (for those who have expensive traffic)

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.
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)


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.


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 opened the result of the script log.asp, and 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.


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.


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:



Boot log
U-Boot 1.1.4 (November 6, 2008)
Flash: 4 MB
In: serial
Out: serial
Err: serial
## Booting image at 1c040000 ...
   Image Name: Kernel-Ramdisk-Image
   Image Type: ARM Linux Multi-File Image (uncompressed)
   Data Size: 3338960 Bytes = 3.2 MB
   Load Address: 00008000
   Entry Point: 00008000
   Image 0: 1609588 Bytes = 1.5 MB
   Image 1: 1729360 Bytes = 1.6 MB
   Verifying Checksum ... OK
   Relocate RAMDISK from 0x1c1c8fc0 to 0xc00000 by 0x1a6350 bytes
Starting kernel ...
Uncompressing Linux ................................................ .................................................. ........ done, booting the kernel.
Linux version (gcc version 4.2.1)
CPU: ARM922T [41029220] revision 0 (ARMv4T), cr = c0007177
Machine: Micrel Pegasus
Memory policy: ECC disabled, Data cache writeback
Pegasus ID = 8692 SubID = 00 Revision = 02
Clocks: System 166 MHz, CPU 166 MHz, DDR 166 MHz, PCI 33 MHz, IPsec 50 MHz
CPU0: D VIVT write-back cache
CPU0: I cache: 8192 bytes, associativity 64, 32 byte lines, 4 sets
CPU0: D cache: 8192 bytes, associativity 64, 32 byte lines, 4 sets
Built 1 zonelists in Zone order. Total pages: 16256
Kernel command line: console = ttyAM0,115200
PID hash table entries: 256 (order: 8, 1024 bytes)
console [ttyAM0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 59756KB available (3028K code, 259K data, 128K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
PCI: bus0: Fast back to back transfers disabled
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
Time: pegasus clocksource has been installed.
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
Freeing initrd memory: 1688K
reset button handler is loaded
NetWinder Floating Point Emulator V0.97 (double precision)
NTFS driver 2.1.28 [Flags: R / O].
JFFS2 version 2.2. (NAND)    2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler deadline registered (default)
LED device driver is installed
Serial: Micrel Pegasus UART driver version:
ttyAM0 at MMIO 0x1fffe000 (irq = 45) is a Pegasus
ttyAM1 at MMIO 0x1fffe080 (irq = 49) is a Pegasus
ttyAM2 at MMIO 0x1fffe100 (irq = 52) is a Pegasus
ttyAM3 at MMIO 0x1fffe180 (irq = 55) is a Pegasus
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
IMQ starting with 2 devices ...
IMQ driver loaded successfully.
        Hooking IMQ after NAT on PREROUTING.
        Hooking IMQ before NAT on POSTROUTING.
30 = ffff ffff
Micrel Pegasus 1.0.0 (Oct 7, 2008)
physmap platform flash device: 00400000 at 1c000000
physmap-flash. 0: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd / Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
Redboot partition parsing not available
Using physmap partition information
Creating 4 MTD partitions on "physmap-flash.0":
0x00000000-0x00030000: "Boot Loader"
0x00030000-0x00040000: "Loader Config"
0x00040000-0x003e0000: "Linux RootFS"
0x003e0000-0x00400000: "System Config"
pegasus-ehci pegasus-ehci: Pegasus-EHCI
pegasus-ehci pegasus-ehci: new USB bus registered, assigned bus number 1
pegasus-ehci pegasus-ehci: irq 8, io mem 0x1fffc000
pegasus-ehci pegasus-ehci: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: Product: Pegasus-EHCI
usb usb1: Manufacturer: Linux ehci_hcd
usb usb1: SerialNumber: KS8692
usb usb1: configuration # 1 chosen from 1 choice
hub 1-0: 1.0: USB hub found
hub 1-0: 1.0: 2 ports detected
pegasus-ohci pegasus-ohci: new USB bus registered, assigned bus number 2
pegasus-ohci pegasus-ohci: irq 9, io mem 0x1fffd000
usb usb2: Product: Pegasus-OHCI
usb usb2: Manufacturer: Linux ohci_hcd
usb usb2: SerialNumber: ks8692
usb usb2: configuration # 1 chosen from 1 choice
hub 2-0: 1.0: USB hub found
hub 2-0: 1.0: 2 ports detected
usbcore: registered new interface driver cdc_acm
cdc_acm: v0.26: USB Abstract Control Model driver for USB modems and ISDN adapters
usbcore: registered new interface driver usbserial
drivers / usb / serial / usb-serial.c: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
drivers / usb / serial / usb-serial.c: USB Serial Driver core
Using Pegasus for AES algorithm.
Using Pegasus for DES algorithm.
u32 classifier
    Performance counters on
nf_conntrack version 0.5.0 (1024 buckets, 4096 max)
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Bridge firewalling registered
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 128K
Setting hostname ...
Mounting root fs rw ...
Mounting other filesystems ...
checksum f0d68bc4, tmp_checksum f0d68bc4
flash: Read from flash memory ...
sysconf read 0x40070000
Checksum is f0d68bc4
flash: Wrote to flash memory ...
br0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
device eth1 entered promiscuous mode
time: 9628 ms
usb 2-1: new full speed USB device using pegasus-ohci and address 2
usb 2-1: device descriptor read / 64, error -62
usb 2-1: Product: Qualcomm CDMA Technologies MSM
usb 2-1: Manufacturer: Qualcomm, Incorporated
usb 2-1: configuration # 1 chosen from 1 choice
cdc_acm 2-1: 1.0: ttyACM0: USB ACM device
br0: port 1 (eth1) entering learning state
udhcpd (v0.9.9) started
Unable to open /etc/config/udhcpd.leases for reading
Unable to open /etc/config/udhcpd.assigned for reading
br0: topology change detected, propagating
br0: port 1 (eth1) entering forwarding state
=> ATcommand Start 3
command count 0
>>> Send: AT $ TIME
>>> Read: AT $ TIME = 19800106000024
>>> Send: AT $ PINSTAT
>>> Send: AT $ TIME
Sun Jan 6 00:00:24 UTC 1980
command count 0
>>> Read: AT $ DRC = 0
cdmainfo.r_drc Null Rate
>>> Read: AT $ RF = 007d, 007d
cdmainfo.r_rf = Rx1 007d
cdmainfo.r_rf = Rx2 007d
>>> Read: AT $ CALLSTAT = 0,0
cdmainfo.r_callstat = 1x Offline
cdmainfo.r_callstat = EVDO Inactive
pinstat 3
command count 0
>>> Read: AT $ TIME = 19800106000024
command count 0
>>> Read: AT $ EVDOINFO = 0,0,0,0,0,0, -31,0,0,0
>>> Read: AT $ CDMAINFO = 0,0,0,0,0,0,0,0, -31,0,0,9,9,9
rmmod: nf_nat_dnsproxy: Unknown error -1074267480
>>> Send: AT $ DRC = OK
>>> Send: AT $ RF = OK
>>> Send: AT $ CALLSTAT = OK
>>> Send: AT $ EVDOINFO = OK
Sysinit done
>>> Send: AT $ CDMAINFO = OK
login: >>> Read: AT $ BOOTDONE
>>> Send: AT $ BOOTDONE = OK
pinstat 3

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”.


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.




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 ) 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)
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

Well, we got the location from the intractable bootloader.


Let's see what this veteran can do:

ks8692pb> help
? - alias for 'help'
autoscr - run script from memory
base - print or set address offset
bdinfo - print Board Info structure
boot - boot default, ie, run 'bootcmd'
bootd - boot default, ie, run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BootP / TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
cp - memory copy
crc32 - checksum calculation
dhcp - invoke DHCP client to obtain IP / boot params
echo - echo args to console
erase - erase FLASH memory
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
flinfo - print FLASH memory information
go - start application at address 'addr'
help - print online help
icrc32 - checksum calculation
iloop - infinite loop on address range
imd - i2c memory display
iminfo - print header information for application image
imls - list all images found in flash
imm - i2c memory modify (auto-incrementing)
imw - memory write (fill)
inm - memory modify (constant address)
iprobe - probe to discover valid I2C chip addresses
isf - i2s transmit waveform data file from memory address
isr - i2s receive waveform data to the memory address
isw - i2s transmit waveform data from memory address
itest - return true / false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mdior register - read mdio register
mdiow register data - write mdio register
mii - MII utility commands
mm - memory modify (auto-incrementing)
mmcinit - init mmc card
mnand - copy to nand boot
mr - memory read and compare
mtest - simple RAM test
mw - memory write (fill)
nettest - network port load test
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP / TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
sleep - delay execution for some time
sspi - SPI utility commands
tftpboot- boot image via network using TFTP protocol
usb - USB sub-system
usbboot - boot from USB device
version - print monitor version
wait - wait for memory

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:

ks8692pb> flinfo
Bank # 1: CFI conformant FLASH (16 x 16) Size: 4 MB in 78 Sectors
 Erase timeout 8192 ms, write timeout 1 ms, buffer write timeout 1 ms, buffer size 1
  Sector Start Addresses:
    1C000000 (RO) 1C002000 (RO) 1C004000 (RO) 1C006000 (RO) 1C008000 (RO)
    1C00A000 (RO) 1C00C000 (RO) 1C00E000 (RO) 1C010000 (RO) 1C020000 (RO)
    1C030000 (RO) 1C040000 1C050000 1C060000 1C070000     
    1C080000 1C090000 1C0A0000 1C0B0000 1C0C0000     
    1C0D0000 1C0E0000 1C0F0000 1C100000 1C110000     
    1C120000 1C130000 1C140000 1C150000 1C160000     
    1C170000 1C180000 1C190000 1C1A0000 1C1B0000     
    1C1C0000 1C1D0000 1C1E0000 1C1F0000 1C200000     
    1C210000 1C220000 1C230000 1C240000 1C250000     
    1C260000 1C270000 1C280000 1C290000 1C2A0000     
    1C2B0000 1C2C0000 1C2D0000 1C2E0000 1C2F0000     
    1C300000 1C310000 1C320000 1C330000 1C340000     
    1C350000 1C360000 1C370000 1C380000 1C390000     
    1C3A0000 1C3B0000 1C3C0000 1C3D0000 1C3E0000     
    1C3F0000 1C3F2000 1C3F4000 1C3F6000 1C3F8000     
    1C3FA000 1C3FC000 1C3FE000

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:

ks8692pb> md 0x1c040000
1c040000: 56190527 8e2b9359 cd32444b d0f23200 '..VY. +. KD2..2 ..
1c040010: 00800000 00800000 6a1878c2 00040205 ......... xj ...
1c040020: 6e72654b 522d6c65 69646d61 492d6b73 Kernel-Ramdisk-I
1c040030: 6567616d 00000000 00000000 00000000 mage ............
1c040040: 748f1800 50631a0000000000 e1a00000 ... t..cP ........
1c040050: e1a00000 e1a00000 e1a00000 e1a00000 ................
1c040060: e1a00000 e1a00000 e1a00000 ea000002 ................
1c040070: 016f2818 00000000 00188f74 e1a07001. (O ..... t .... p ..
1c040080: e1a08002 e10f2000 e3120003 1a000001 ..... ..........
1c040090: e3a00017 ef123456 e10f2000 e38220c0 .... V4 ... ... ..
1c0400a0: e121f002 00000000 00000000 e28f00d0 ..! .............
1c0400b0: e890307e e0500001 0a00000a e0855000 ~ 0 .... P ...... P ..
1c0400c0: e0866000 e08cc000 e0822000 e0833000 .` ....... ... 0 ..
1c0400d0: e08dd000 e5961000 e0811000 e4861004 ................
1c0400e0: e156000c 3afffffa e3a00000 e4820004 ..V ....: ........
1c0400f0: e4820004 e4820004 e4820004 e1520003 .............. R.

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


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:


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


Let's see what we have inside the dump:

$ binwalk dump.bin
-------------------------------------------------- ------------------------------
0 0x0 uImage header, header size: 64 bytes, header CRC: 0x59932B8E, created: 2010-01-06 06:50:53, image size: 3338960 bytes, Data Address: 0x8000, Entry Point: 0x8000, data CRC: 0xC278186A, OS: Linux, CPU: ARM, image type: Multi-File Image, compression type: none, image name: "Kernel-Ramdisk-Image"
14476 0x388C gzip compressed data, maximum compression, from Unix, last modified: 2010-01-05 04:49:24
1609664 0x188FC0 gzip compressed data, has original file name: "ramdisk.img", from Unix, last modified: 2010-01-06 06:50:44

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:

$ 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

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

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

$ sudo strings rootfs / bin / lgc_login
GCC: (GNU) 3.3.2 20031005 (Debian prerelease)
GCC: (GNU) 2.95.4 20010319 (prerelease)
GCC: (GNU) 2.95.4 20010319 (prerelease)
GCC: (GNU) 2.95.4 20010319 (prerelease)
GCC: (GNU) 3.3.2 20031005 (Debian prerelease)

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" ""

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.

Also popular now: