hacking-gemtek is a reverse engineering project for a Gemtek home router (model WVRTM-127ACN) distributed in Italy by Linkem (a Wireless ISP) with the scope to modify the firmware to add useful software, as an sshd daemon, and to understand how the default WiFi router password is generated. It includes an emulation environment based on Qemu and Docker, a firmware modification kit and a default WiFi password generator. The project follows the reverse engineering process described by the author in a talk at Hack In Paris 2019 Cybersecurity Conference and in the Hardware Hacking Tutorial series on the Make Me Hack YouTube channel.
- Description
- Table of Contents
- Quick Start
- The Reverse Engineering Process
- Information gathering
- How the device works: file system analysis
- Building the emulation environment
- How the device works: Reverse Engineering Router's Binaries
- Firmware modification kit
- Author
Clone the following Github repository on your Linux machine (only Linux is supported)
valerio@ubuntu-hp:~$ mkdir gemtek # configuration script will create folders here
valerio@ubuntu-hp:~$ cd gemtek
valerio@ubuntu-hp:~/gemtek$ git clone https://github.com/digiampietro/hacking-gemtek.git hacking-gemtek
If we know the router's serial number, we can generate the router's default password with the gemtek-pass.c program. For example for the router with serial number "GMK170210005623" and ESSID "Linkem2.4GHz_A8D9A6" we can generate the default password in the following way:
$ # compile the program, if not done yet
$ gcc gemtek-pass.c -lcrypto -o gemtek-pass
$ # execute the compiled program
$ ./gemtek-pass GMK170210005623 A8D9A6
Serial number : GMK170210005623
Last 3 MAC digits: A8D9A6
wifi password is : wsagj2zz
$
This router's serial number has the format GMKyymmddnnnnnn. If the serial number is unknown and only the ESSID, as Linkem2.4GHz_A8D9A6, is known, we can capture the WPA/WPA2 handshake following some tutorial as cracking WPA/WPA2 passwords capturing an handshake and using a dictionary attack and then cracking the password using the dictionary generated by gemtek-gen-dict.c that generates possible passwords, for the specific ESSID, for millions of possible serial numbers. For example:
$ # ---- compile gemtek-gen-dict.c, if not done yet
$ gcc gemtek-gen-dict.c -lcrypto -o gemtek-gen-dict
$ # ---- generate a wordlist for possible serial numbers of routers manufactured in 2016 and 2017
$ ./gemtek-gen-dict -s 160101 -e 171231 -a 0 -z 20000 -m A8D9A6 > gemtek-wordlist.txt
sdate - start date: 160101
edate - end date: 171231
sserial - start serial: 0
eserial - end serial: 20000
halfmac - last 3 mac digits: A8D9A6
---> tot number of days: 731
---> GMK160101000500
...
To access a root shell the router must be in "factory mode" and root access is available only when it is in this mode:
- open the router, connect a USB TTL serial cable to the PC and to the main board UART, the pinout is available below
- start a terminal emulator with serial parameters 115200N8 (115200 bps, No parity, No Flow Control, 1 stop bit, 8 bit)
- connect the PC to the router with an ethernet cable attached to one of the router's LAN interfaces
- assign to the PC ethernet interface the IP address 192.168.15.100
$ sudo ifconfig eth0 192.168.15.100 - power up the router and look at the terminal emulator
- immediately after "Please choose the operation" press the key "4" to enter the U-Boot CLI ("4" must be pressed within 1 second)
Please choose the operation: 1: Load system code to SDRAM via TFTP. 2: Load system code then write to Flash via TFTP. 3: Boot system code via Flash (default). 4: Entr boot command line interface. 9: Load Boot Loader code then write to Flash via TFTP. . You choosed 4 - at the U-Boot CLI set the variable factory at value 2 with the command "setenv factory 2" and then permanently save the U-Uboot environment with the command "saveenv"
MT7621 # setenv factory 2 MT7621 # saveenv Saving Environment to NAND Flash... Writing new Env to NAND Flash... ranand_erase: start:580000, len:20000 ..Done! MT7621 # - power down the router, then power up again and wait until the boot is completed
- from the PC connect to the router using telnet, the router has the "factory mode" IP (139.128.15.1), you will have a root shell prompt. It is not possible to modify the read only squashfs root file system, but it is possible to explore the system and to modify the content of the UBIFS file system mounted under /mnt/jffs2, for example you can modify the password for the user Lnk_Administrator
valerio@ubuntu-hp:~/linkem/hacking-gemtek$ telnet 192.168.15.1 Trying 192.168.15.1... Connected to 192.168.15.1. Escape character is '^]'. . ~ #
- open the router, connect a USB TTL serial cable to the PC and to the main board UART, the pinout is available below and dump the entire EEPROM to the text file eeprom.txt with the expect program serial-flash-dump.expect
$ # dump the entire EEPROM in ASCII, the following program will run for about 11 hours $ # power down the device, start the following program, then power up the device $ ./serial-flash-dump.expect /dev/ttyUSB0 | tee eeprom.txt # ---> modem device: /dev/ttyUSB0 #---> connecting to /dev/ttyUSB0 spawn [open ...] #---> waiting for U-Boot command prompt ... - convert the ASCII file eeprom.txt back to binary with the perl program hexdump2bin.pl
$ cat eeprom.txt | ./hexdump2bin.pl > eeprom.bin SUCCESS 65536 pages dumped, 134217728 bytes - split the eeprom.bin in partiton image files and extract the squashfs root file system
the above command, among other things, creates the following files and folders in the ../firmware folder:
$ ./hg-config.sh eeprom.bin- 01-bootloader.bin, first EEPROM partition image
- 02-bootloader2.bin second EEPROM partition image
- 03-config.bin third EEPROM partition image
- 04-env1.bin forth EEPROM partition image
- 05-env2.bin fifth EEPROM partition image
- 06-kernel.bin sixth EEPROM partition image
- 07-kernel2.bin seventh EEPROM partition image
- 08-storage.bin eighth EEPROM partition image
- 09-storages.bin ninth EEPROM partition image
- u04-sqfs.dat suqashfs root file system image
- root folder containing the extracted root file system
There is no quick start guide, you have to follow the full Firmware modification kit paragraph
There is no quick start guide, you have to follow the full Building the emulation environment paragraph
The Reverse Engineering Process is based on
- Information gathering to identify hardware and software components of the device and get the firmware and the root file system;
- Build an emulation environment using QEMU, Buildroot and Docker to have a debugging friendly environment where to run interesting device binaries;
- Analyze how the device works doing file system analysis and reverse engineering of interesting binaries in the emulated environment;
- Build a firmware modification kit to simplify the process to create an alternative firmware to load into the device.
This process, with an example on another router, is described in a talk at Hack In Paris 2019 Cybersecurity Conference:
- Slides of the talk in pdf format
- Slides of the talk with the transcript of the presentation
- Video of the presentation on youtube
The information gathering process is usually based on three steps:
- Searching information on Internet, using the device name and manufacturer as search string;
- Opening the case and inspecting the device, identifying main device components, UART and JTAG interface;
- Finding a way to get the firmware and the root file system from the vendor web site or from the EEPROM.
Using the device manufacturer name Gemtek, the device model WVRTM-127ACN and the ISP provider name Linkem it is possible to find a lot of information on Internet:
- device information at wikidevi that gives very useful info:
- CPU: MediaTek MT7621AT, it has a 32bit MIPS 100K4c architecture, running at 880Mhz with a dual core/quad thread processor;
- RAM: 128Mb, device: ESMT M14D1G1664A-2.5B;
- EEPROM: 128Mb, Nand Flash device: ESMT F59L1G81LA-25T;
- FCC documentation that includes external and internal pictures of the device and a "Quick start Manual".
Anyway no information was found about UART and JTAG location and pinout.
It is quite easy to open the case and extract the main board:
Reading the text printed on top of every integrated circuit is not easy, but with a small trick, using alcohol and a white chalk, it is not difficult either. In the photo, of the main board top and of the main board bottom, the main integrated circuits are clearly readable and it is possible to identify:
- the System On a Chip is a Mediatek MT7621AT, this confirms what was found on wikidevi;
- the RAM is a 128Mb Winbond W971GG6SB 8M x 8 BANKS x 16 BIT DDR2 SDRAM, this is different from what was found on wikidevi;
- the 74HC164, it is discrete logic IC, quite unusual to find one on a modern main board, but it can be useful because his GND and VCC pins can be used as voltage reference;
- the NAND Flash Memory, on the main board bottom, is a F59L1G81LA a 1 Gbit (128M x 8) 3.3V NAND Flash Memory, this confirms what was found on wikidevi.
On the main board top there is a white 4 pin connector, the pin 1 is at the top, the pin 4 is at the bottom, it is the perfect candidate for the UART interface; with a multi-meter we can take the following measurements:
main board switched off, resistance measurements
- pin 1 the resistance between this pin and VCC is 0 Ohm (VCC is pin 14 of 74HC164D)
- pin 2 the resistance between this pin and VCC is infinite and between this pin and GND is 4.7 KOhm (GND is pin 7 of 74HC164D)
- pin 3 the resistance between this pin and VCC is infinite and between this pin and GND is infinite
- pin 4 the resistance between this pin and GND is 0 Ohm
main board switched on, voltage measurements
- pin 1 is at 3.35V (VCC)
- pin 2 is at 3.31V, but it oscillates randomly between 1.66V to 3.31V when booting
- pin 3 is at 3.25V, it remains constant when booting
- pin 4 is at 0V (GND)
The multi-meter gives a voltage measurement that is the average of the actual voltage over a period of few hundred milliseconds; when booting, a lot of text is written to the UART interface (it is the serial console), this means that the TX pin will oscillate between 0 and 1 (between 0V and 3.3V), for this reason measuring the voltage with a multi-meter on the TX pin will give an oscillating measurement. If nothing is written to the UART, the TX pin will remain at logic 1 (3.3V).
Based on the above measurements we can assume that that this 4 pin connector is the UART interface and that the pinout is:
- pin 1 is VCC
- pin 2 is TX
- pin 3 is RX (by exclusion)
- pin 4 is GND
To confirm that it is the UART interface we connect this interface to a PC with a TTL Serial Adapter, we select a 3.3V TTL serial adapter (or select the 3.3V mode in a double mode serial adapter), we connect:
- UART pin 4 - GND to the GND pin of the TTL serial adapter
- UART pin 2 - TX to the RX pin of the TTL serial adapter
- UART pin 3 - RX to the TX pin of the TTL serial adapter
- we leave the UART pin 1 - VCC unconnected
We can now fire up a serial emulator on our PC, like PuTTY, setup serial parameters to 115200 bps, No Parity, No Flow Control, 8 bit, switch on the device and log and watch what is printed on the serial console during boot.
On the main board there aren't other pin headers arranged in a single or a double row, there are some test points (see main board top picture) labeled TP1, TP2, TP3, TP4, TP5, TP6, TP7, TP8, TP11, TP12; they are not regularly arranged and, probably, they are used to test the board after manufacture using a bed of nails tester. TP usually stands for "Test Point", so, probably, these points, or some of them, can belong to the JTAG interface but they are quite difficult to use because, not having a bed of nails tester, it is needed to solder a wire to each point to discover if they belong to the JTAG interface. For this reason we don't investigate further and move forward without locating the JTAG interface.
Looking at what is printed on the serial console when booting we can get a lot of useful information:
- the boot loader is U-Boot version 1.1.3
U-Boot 1.1.3 (Oct 23 2015 - 16:03:05) - parameters of the NAND device, can be useful to know in the emulation environment and to re-write the firmware
mtd->writesize=2048 mtd->oobsize=64, mtd->erasesize=131072 devinfo.iowidth=8 - the WiFi chip, that was hidden in the main board top, probably below the gray rectangular area, is a Ralink chip; it is confirmed that the SoC is a Mediatek MT7621A with a dual core CPU running at 880 Mhz and that the RAM has 128 Mbytes
Ralink UBoot Version: 4.3.2.0 -------------------------------------------- ASIC MT7621A DualCore (MAC to MT7530 Mode) ... ##### The CPU freq = 880 MHZ #### estimate memory size =128 Mbytes - U-Boot presents a menu and allows the boot to be interrupted and to enter a U-Boot command line interface, this can be very interesting
Please choose the operation: 1: Load system code to SDRAM via TFTP. 2: Load system code then write to Flash via TFTP. 3: Boot system code via Flash (default). 4: Entr boot command line interface. 9: Load Boot Loader code then write to Flash via TFTP. ``` - Details of the booting kernel, this can be useful when trying to modify the firmware and boot an alternate firmware. Later we will discover that Image 0 is the Linux kernel and that Image 1 is the squashfs read only root file system
3: System Boot system code via Flash. ## Booting image at 81000000 ... Image Name: =01.01.02.090 Image Type: MIPS Linux Multi-File Image (lzma compressed) Data Size: 19062732 Bytes = 18.2 MB Load Address: 80001000 Entry Point: 8000f540 Contents: Image 0: 1966004 Bytes = 1.9 MB Image 1: 17096704 Bytes = 16.3 MB Verifying Checksum ... OK Uncompressing Multi-File Image ... OK ## Transferring control to Linux (at address 8000f540) ... ## Giving linux memsize in MB, 128 Starting kernel ... - Kernel version 2.6.36 and kernel command line; the firmware has been built with Buildroot version 2015-02. Buildroot is the same build system we will use in our emulation environment. Confirmation that the CPU instruction set is MIPS 1004Kc and that we have a squashfs root file system
[ 0.000000] Linux version 2.6.36 (snapshot@Michelle) (gcc version 4.5.4 (Buildroot 2015.02-svn12502) ) #1 SMP PREEMPT Fri Jan 22 15:01:55 CST 2016 ... [ 0.000000] Kernel command line: console=ttyS0,115200n8 console=ttyS0,115200n8 ... [ 0.204000] CPU revision is: 0001992f (MIPS 1004Kc) ... [ 2.416000] squashfs: version 4.0 (2009/01/31) Phillip Lougher ... [ 3.448000] RAMDISK: squashfs filesystem found at block 0 [ 3.452000] RAMDISK: Loading 16696KiB [1 disk] into ram disk... done. [ 4.052000] VFS: Mounted root (squashfs filesystem) readonly on device 1:0. - How the NAND device is partitioned
[ 2.760000] Creating 9 MTD partitions on "MT7621-NAND": [ 2.764000] 0x000000000000-0x000000100000 : "Bootloader" [ 2.772000] 0x000000100000-0x000000200000 : "Bootloader2" [ 2.776000] 0x000000200000-0x000000300000 : "Config" [ 2.784000] 0x000000300000-0x000000580000 : "Env1" [ 2.788000] 0x000000580000-0x000000800000 : "Env2" [ 2.792000] 0x000000800000-0x000002800000 : "Kernel" [ 2.800000] 0x000002800000-0x000004800000 : "Kernel2" [ 2.804000] 0x000004800000-0x000006400000 : "Storage1" [ 2.808000] 0x000006400000-0x000007f80000 : "Storage2" - It can be useful to rewrite the partition table in number of blocks of 1024 bytes, to be used, later, in dd commands
Nr Device Start Length Name -- ------ ------- ------- ------------ 1 mtd0 0 1,024 Bootloader 2 mtd1 1,024 1,024 Bootloader2 3 mtd2 2,048 1,024 Config 4 mtd3 3,072 2,560 Env1 5 mtd4 5,632 2,560 Env2 6 mtd5 8,192 32,768 Kernel 7 mtd6 40,960 32,768 Kernel2 8 mtd7 73,728 28,672 Storage1 9 mtd8 102,400 28,160 Storage2 - It is a system based on Busybox version 1.23.1. Busybox is very popular in embedded devices because a small binary implements a lot of functionalities (init, shell, many linux commands)
init started: BusyBox v1.23.1 (2016-01-22 15:02:56 CST) - The partition 8 (mtd8) is a UBI file system using lzo compression
[ 5.052000] UBI: attached mtd8 to ubi8 [ 5.056000] UBI: MTD device name: "Storage2" ... [ 5.352000] UBIFS: mounted UBI device 8, volume 0, name "mtd8" [ 5.356000] UBIFS: file system size: 23744512 bytes (23188 KiB, 22 MiB, 187 LEBs) [ 5.364000] UBIFS: journal size: 1142784 bytes (1116 KiB, 1 MiB, 9 LEBs) [ 5.372000] UBIFS: media format: w4/r0 (latest is w4/r0) [ 5.376000] UBIFS: default compressor: lzo [ 5.380000] UBIFS: reserved for root: 1121511 bytes (1095 KiB) - Some keys are, perhaps, generated during boot
## Error: "clientkey" not defined ## Error: "clientcert" not defined ## Error: "private_key_header" not defined [ AES_Key_Gen] 202 MAC=[1C:49:7B:A8:D9:A6] [ AES_Key_Gen] 203 Customer=[Linkem] [ AES_Key_Gen] 208 key=[1C:49:7B:A8:D9:A6Linkem] len[23] - Firmware version
[ 21.212000] FW Version:0.0.00 Build:1 - The router has some process implementing the CWMP (CPE WAN Management Protocol) to be remotely controlled and try to contact, multiple times, the provider server acs.linkem.com; because I didn't connect the router to Internet, it cannot resolve the hostname and cannot contact his master
[TR069_A4] ACS Connect Failed: Could not resolve host acs.linkem.com[TR069_A4] [startInformRetryTimer] @ [553] retry = 1 waitTime = 5 sec [TR069_A4] ACS Connect Failed: Could not resolve host acs.linkem.com[TR069_A4] [startInformRetryTimer] @ [553] retry = 2 waitTime = 16 sec [TR069_A4] ACS Connect Failed: Could not resolve host acs.linkem.com[TR069_A4] [startInformRetryTimer] @ [553] retry = 3 waitTime = - At the end of the booting process a login prompt is shown, but trying to login with a username ("admin" in this case) the system responds with a "Challenge code", this means that it is not the Linux standard /bin/login process
buildroot login: admin Challenge code: mZkq7ohJax+YwmOgTHSTRwdKotmQkVqX4tOZQt0ypomSRQz6RkKsj/TAOD32iXjy focWSRrrIUFEeqQaShH3+xZHFe8znuCYBfZrdXdyzTShql0OpT+i62XRwLbwGaBw ptcOpWX6dANtb612WXLEFaLfL4yEBDbChVSKVrre9RsrKFL4YblAPKGDQEdlt05i lC2ZDX0TNQOgWKkarAAVgHO5LnOdgyPT4SakKzZfH2JmYEbRhbCBRTVhYkqcZ3J8 NqT0lI5QKcWwYURE0foJc7+YCm7NU+MPzyt/3tEl5l8JjjZLxgg8p2xBX9/42372 pcE3rtIoUWGT6/2l5hN6eA Authentication code: admin Fail!
As seen in the previous paragraph it is possible to press "4", within a second, when the U-Boot menu appears on the serial console to enter the U-Boot command line interface. Typing "help" it is possible to discover the U-Boot commands available:
MT7621 # help
? - alias for 'help'
bootm - boot application image from memory
go - start application at address 'addr'
help - print online help
md - memory display
mdio - Ralink PHY register R/W command !!
mm - memory modify (auto-incrementing)
nand - nand command
nm - memory modify (constant address)
printenv- print environment variables
reset - Perform RESET of the CPU
saveenv - save environment variables to persistent storage
setenv - set environment variables
tftpboot- boot image via network using TFTP protocol
version - print monitor version
MT7621 # help nand
nand nand usage:
nand id
nand read <flash_offset> <len> [dst_addr]
nand write <flash_offset> <src_addr> <len>
nand erase_write <flash_offset> <src_addr> <len>
nand page <number>
nand erase <addr> <len>
nand erase_ignore_bad_block <flash_offset> <len>
nand list_bad_block
nand oob <number>
nand dump
nand init
MT7621 # help md
md [.b, .w, .l] address [# of objects]
- memory display
The U-Boot environment variables are:
U-Boot 1.1.3 (Oct 23 2015 - 16:03:05)
MT7621 # printenv
bootdelay=1
baudrate=115200
ethaddr="00:AA:BB:CC:DD:10"
filesize=c5900c
fileaddr=81000000
ipaddr=10.10.10.123
serverip=10.10.10.3
Mmid=WVRTM-127ACN
version_uboot=U-Boot 1.1.3 (Oct 23 2015 - 16:03:05)
lanaddr=1C:49:7B:A8:D9:A6
mid=WVRTM-127ACN
cid=Linkem
pid=LTE CPE
hid=V02
dmid=WVRTM-127ACN
serial=GMK170210005623
LTE_SupportBand_Mask=0000060000000000
dsp_port_number=0
wmxaddr=1C:49:7B:A8:D9:A6
wifiaddr=1C:49:7B:A8:D9:A7
11acaddr=1C:49:7B:A8:D9:A8
mtddevnum=6
root_chain_cert=QlpoOTFBWSZTWYDk05wABNX/lOiQAEDAC//iP///+H////AEAAAAgAhgBx75ASgA AABpoHIGlRo9IDagA9TEBiADQADIAGIMqQAGgaAA0B6gehAGgyAAA4yZNGIYmmAg YE0wRgmJppoAMIcZMmjEMTTAQMCaYIwTE000AGEElRDTJqeQ1T21DSbUwT0p6nkn tUbKY9Ih7UZIPTQJShMjJhNMjTTQGgNDQAGpphNUBHojij33kKslxWHEOJuuISrE fyYweUAis4NELcbY2hkQroKCEIIsiI+kZmv+dBiMEx/JuFz/MjaZjhGaD1fLvSwc z/K5xGcEglxD+0FUNhcLhsFlvSRdiOFtGUpi9V0h57/GGYEDx+Ro7PcaULPFlRX4 cB18S8pK/M0NnDgDpiJ92camBGIaARYp9MerOCK6NQ+ckwvhtLZopyBmL5Of0wPl 1clA59lQSKJqNDbcSjxFEA7VqrSdAjUc1sWAxmj2nKvGAeIn4k2JolOdjW7KMuL+ ciGQymu0v8p3h9RYYUwIw+uzwWS8Z+5Oqj02kysG71U1oy6bGY2sWQudShO+UuFp 4qmUs8086Dy5+ZJMvvQsq2/NdxGi6/AtcmBaWS0SmTE9jqHap5csK6B1aNg2jGvx krSGiwEhu1zUkePRrHWRQtjDFZKAkS/+kuwpfbN5lT4XO5FuD8m+tSfoGOraG4z1 fsolHkiTwdmhlUppEnpOkc8ge2ETMxAXjX4Ba4ijGjqaUJuBxduqgwzKy1+04ayo UB7Kp2GXOALOjgvoSqKlQzFgFjmKBIKAsbk4bIeNMdLbJyyX/jBuItRrKQ6WRVsO CKnWW5gHymMDBGC5fJVz+E8ncovEwyZCIeKdYplVzC0uajcUFt0aLOq4eyEVz5Uo JfZOn/L4ODpuMQfgTy3GFC6NWAbruQX0ZNJ+1dgWl5IykZGi6x7CmlUWOR18cKhU CE6fQnhN8Yl4cNnm2a8TpXRQJID2u8VAXKApqHGkNIUh9OCX7BmBchNI+qMFIVxF 3aKloWCoYB0XOVEesLTJgxgqF0bMiWhnr2aKhhehJUxWLx5GTCZS+Tpo5UwvkJVJ +FVOZAl8GD0CgSq+vRJClsfBQe3OF/bNQ6LPEmsiMZtzHxMd0wEFUer4MLBmIbG1 8Z1lqoXwdRVHaRMahkHyYMiiYRo4DpQRJsNmcsDfvEVO59cAeLJIaC95IiUukQXL pCYtR5Op5XGFJj0QExtdKpOedovZYR8b8iplMvhG85Y4J8SXfaTowtcLmfoRZRqE JlahlV1cAs4D18a3k5MdUwEIsSjSVBYV4qG4aMwwbShgZJC4kIoaS2bwpjDB8NQ4 MuQxaUkMIWbyPPiphR3kfhYpJqkyC4fCUDGkTffk3Mk0+AZT0j9dI0grW+xY/I2u 40eDCLd1I0qMGgkrxczQzaFbbh0PvdxspMjekgSSUdBgoKRZxqjNUVNkTGcRkVGx QlGxp08OHGi4di8VkowlV+c0OhAKlf0w84SkZYCubxhwdhOJcPeyUsJ0pnT7KnQ2 i8JdB44t+D65rc7oVncM/2sNGc3u7DIJysmMtGcZIhcFBUMR1tH5yHB/uV8/iAh6 kR24lobErmDbMbBcPGLLnDKnseXH7hhM5GYcJ1ITomovdMAyEfoVIhYiGBLDVsuG zgwkBro7m+2jJTyzHk8lNqtmHPHZIAsouX7cxEX7PAHEvbSDePGCBYYLA34mTUzg SnUNCwTF4N5gDcTCpwIzVDw9H3YrdMSbLiY0n/Midzki0Dw8MFQ+hYkO5UPXUeLr 7Ls+3SJAEMZ37o4flc7lVO+a4s74fQnTdgNpwCPlAMJuytihvphdOhGMJWGoY205 9059hkuhXbJI/1/Kf+aN8JzL5pMROnZOrJ1CbENlAZBmDZbRwpkwRz2lzFeHMLjt UDhciRuzq8VoXUwktuIJBnKwlseTlaNoVUr+Q9DFIduXLyh5veISsNJtHBQoeA4o oqaRcqlYMxlFx323KmdMNQWgOyazM+czSSZgxEhWLxSW1TokN55Ec9dUWy9c+i3J 9MfPLrIjMcOlXecVW+dz311paOkBsBlgwivmJV1QIExPaR8p8WV8LWPPQbVjDVtS uz2uCKXU3Fz4NE4z5Sr0zDO6oZB0asGg7kXvsSVZvu6GqoKpqOkt8gHG5DKfDinb GvUL424OlI/a0k9DlqBHkwjZinkxb0WN9l9HyBINmYQn7iEKQBly0O6zyTl9ThxH vgf6Zk88ch19JqMIN+tKh0ZKT/pKyHHFaNisU4ZWHE/dD/UFgK13KcxTASJ0yZXa B8xlNPsh3FgUPsTIE21QQkMsANKCrWglJWb3uClhL44HQ46Q40scZXKUodPII0Cj iMy8OAnmSp+IvtrobKgFxgKyFxdOkXhsYQzGMKUq1Y9YjSSj5ObxUVRUiUPRoxmY sguVxe7OUj74F4LbQqNh599N9Fp7rofKxTExJ9JsYRwdNfNLJwC517lcKafJDF8n jclZvYwiLR+JdJTm7ZlO6bi75EP/i7kinChIQHJpzgA=
stdin=serial
stdout=serial
stderr=serial
Environment size: 3108/131067 bytes
- fileaddr=81000000 it is the memory address where to load the boot image
- ipaddr=10.10.10.123 it is the IP address of the router assigned to it by U-Boot and used only for the tftp boot image loading
- serverip=10.10.10.3 it is the IP address of the TFTP server, this is the address to assign to the PC with the tftpd daemon for tftp boot image loading
- mtddevnum=6 probably it is the partition to load the boot image from (first partition is "0", partition 6 is "kernel" partition)
- root_chain_cert it looks like a base64 encoded file (chars in the set 'a' .. 'z','A' .. 'Z', '0' .. '9','+','/' and padding char '=' at the end); we can copy the string on a file "cert.txt" and decode:
$ # ----- copy the root_chain_cert string to a file $ cat > cert.txt QlpoOTFBWSZTWYDk05wABNX/lOiQAEDAC//iP///+H////AEAAAAgAhgBx75ASgA ... jclZvYwiLR+JdJTm7ZlO6bi75EP/i7kinChIQHJpzgA= ^D $ # ----- replace spaces with carriage returns and decode with base64 $ cat cert.txt | sed 's/ /\n/g' | base64 -d > cert.bin $ file cert.bin cert.bin: bzip2 compressed data, block size = 900k $ # ----- it is a bzip2 file, uncompress it to cert2.bin $ bzcat cert.bin > cert2.bin $ file cert2.bin cert2.bin: POSIX tar archive (GNU) $ # ----- it is a tar archive $ tar -xvf cert2.bin cert/ cert/CA/ cert/CRL/ cert/server.pem cert/servercert.pem
the file servercert.pem is a public certificate, server.pem includes both the private key and the public certificate (the same included in servercert.pem). Anyway the purpose of these key and certificate are unknown, at the moment.
- nand page prints the hex value of a NAND page: 2048 bytes plus 64 bytes of OOB (Out Of Band data, used for a sort of "error correction"). This command will be used to dump the entire NAND Flash EEPROM
- tftpboot allows to boot from a tftp server, this will be used during the development of a modified kernel+squashfs
- nand read to move kernel+squashfs from EEPROM to RAM
- bootm to boot from memory
We know the memory address where to load the boot image (U-Boot variable fileaddr=81000000) and the Flash EEPROM partitions, so we know the U-Boot command do boot from different sources:
- boot from "kernel" partition (at EEPROM address 0x800000, length 0x2000000)
MT7621 # nand read 800000 2000000 81000000 read len: 33554432 0x00800000 copy to 0x81000000 MT7621 # bootm ## Booting image at 81000000 ... Image Name: =01.01.02.090 Image Type: MIPS Linux Multi-File Image (lzma compressed) Data Size: 19062732 Bytes = 18.2 MB Load Address: 80001000 Entry Point: 8000f540 Contents: Image 0: 1966004 Bytes = 1.9 MB Image 1: 17096704 Bytes = 16.3 MB Verifying Checksum ... OK Uncompressing Multi-File Image ... OK ## Transferring control to Linux (at address 8000f540) ... ## Giving linux memsize in MB, 128 # Starting kernel ... ``` - boot from "kernel2" partition (at EEPROM address 0x2800000, length 0x2000000)
MT7621 # nand read 2800000 2000000 81000000 read len: 33554432 0x02800000 copy to 0x81000000 MT7621 # bootm ## Booting image at 81000000 ... Image Name: =01.01.02.090 Image Type: MIPS Linux Multi-File Image (lzma compressed) Data Size: 21528524 Bytes = 20.5 MB Load Address: 80001000 Entry Point: 8000f540 Contents: Image 0: 1966004 Bytes = 1.9 MB Image 1: 19562496 Bytes = 18.7 MB Verifying Checksum ... OK Uncompressing Multi-File Image ... OK ## Transferring control to Linux (at address 8000f540) ... ## Giving linux memsize in MB, 128 # Starting kernel ... ``` - boot from tftp server, the server must have ip=10.10.10.3
MT7621 # tftpboot 81000000 kernel.bin netboot_common, argc= 3 NetTxPacket = 0x87FE4480 KSEG1ADDR(NetTxPacket) = 0xA7FE4480 NetLoop,call eth_halt ! NetLoop,call eth_init ! Trying Eth0 (10/100-M) Waitting for RX_DMA_BUSY status Start... done # ETH_STATE_ACTIVE!! TFTP from server 10.10.10.3; our IP address is 10.10.10.123 Filename 'kernel'. TIMEOUT_COUNT=10,Load address: 0x81000000 Loading: Got ARP REQUEST, return our IP Got ARP REQUEST, return our IP Got ARP REQUEST, return our IP Got ARP REPLY, set server/gtwy eth addr (40:b0:34:09:1b:b4) Got it ################################################################# ################################################################# ... ###################################################### 32 MB reveived # done Bytes transferred = 33554432 (2000000 hex) NetBootFileXferSize= 02000000 MT7621 # bootm ## Booting image at 81000000 ... Image Name: =01.01.02.090 Image Type: MIPS Linux Multi-File Image (lzma compressed) Data Size: 21528524 Bytes = 20.5 MB Load Address: 80001000 Entry Point: 8000f540 Contents: Image 0: 1966004 Bytes = 1.9 MB Image 1: 19562496 Bytes = 18.7 MB Verifying Checksum ... OK Uncompressing Multi-File Image ... OK ## Transferring control to Linux (at address 8000f540) ... ## Giving linux memsize in MB, 128 . Starting kernel ...
Firmware upgrades are not available on the ISP website Linkem and on the manufacturer website Gemtek, probably the upgrade happens only through the CWMP, remote management protocol, when the ISP provider decides that the router have to be upgraded.
This means that to get the firmware we have to download it from the NAND Flash EEPROM. Because we have access to the U-Boot command line and we have available the command "nand page n" we can dump all the EEPROM pages on standard output in ASCII format and then we can use a small program to convert back to a binary EEPROM image file. For example:
MT7621 # nand page 0
page 0x0:
27 05 19 56 42 ee ee b3 56 29 e9 b9 00 02 25 fc a0 20 00 00 a0 20 00 00 c6 70 7e b0 05 05 01 00
4e 41 4e 44 20 46 6c 61 73 68 20 49 00 00 00 00 00 00 00 40 00 00 60 00 00 00 00 00 a2 0e b4 a1
...
00 00 5b af 21 d8 e0 03 21 f8 c0 03 08 00 60 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 08 00 c1 28 2e 00 20 14 21 10 80 00 26 50 a4 00 03 00 4a 31 33 00 40 15
#
oob:
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
db 15 b2 47 1b fc f3 ff 7e dd 57 a5 d2 3d fb ff 5e 31 c4 f8 26 0d f7 ff ac d8 61 5a 0a 85 fd ff
it prints the entire content of the page 0 of the EEPROM (2 Kbytes), including the 64 bytes of the OOB (Out Of Band) area. To dump the entire EPROM content we have to print each one of the 65536 pages (from page 0 to page 65535), to do so we can use a small expect script "serial-flash-dump.expect", available here; with no other program opening the serial interface, this script:
- opens the serial interface, passed as argument
- wait for the U-Boot menu prompt
- send the char "4" to select the U-Boot CLI
- send the "nand page 0" command, wait for the prompt, send the "nand page 1" command and so on
- each page is 2 Kbtyes, but the ASCII dump, including spaces, carriage returns and oob data, uses about 6450 bytes, this means that the dump of the entire ROM will be an ASCII file of about 400 Mb, to write this file on serial console, running at 115200 bps, it will require about 11 hours or more!
The entire EEPROM can be dumped to the ASCII file eeprom.txt with the following command:
$ # ----- dump the entire EEPROM in ASCII, the following program will run for about 11 hours
$ # ----- power down the device, start the following program, then power up the device
$ ./serial-flash-dump.expect /dev/ttyUSB0 | tee eeprom.txt
# ---> modem device: /dev/ttyUSB0
#---> connecting to /dev/ttyUSB0
spawn [open ...]
#---> waiting for U-Boot command prompt
...
Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
9: Load Boot Loader code then write to Flash via TFTP.
#---> got command prompt
You choosed 4
0
4: System Enter Boot Command Line Interface.
U-Boot 1.1.3 (Oct 23 2015 - 16:03:05)
MT7621 # nand page 0
page 0x0:
27 05 19 56 42 ee ee b3 56 29 e9 b9 00 02 25 fc a0 20 00 00 a0 20 00 00 c6 70 7e b0 05 05 01 00
4e 41 4e 44 20 46 6c 61 73 68 20 49 00 00 00 00 00 00 00 40 00 00 60 00 00 00 00 00 a2 0e b4 a1
...
After about 11 hours the ./serial-flash-dump.expect script will terminate and the full EEPROM has been hex dumped to the file eeprom.txt, now with another script available here, hexdump2bin.pl, this hex dump can be converted back to binary format:
$ cat eeprom.txt | ./hexdump2bin.pl > eeprom.bin
SUCCESS 65536 pages dumped, 134217728 bytes
Now the eeprom.bin file contains the full image of the device EEPROM, because we know (see above), how the EEPROM is partitioned we can extract a file image for each partition with the following commands, included in the script hg-config.sh, so we can run this script instead of the following commands:
dd if=eeprom.bin of=01-bootloader.bin bs=1024 skip=0 count=1024
dd if=eeprom.bin of=02-bootloader2.bin bs=1024 skip=1024 count=1024
dd if=eeprom.bin of=03-config.bin bs=1024 skip=2048 count=1024
dd if=eeprom.bin of=04-env1.bin bs=1024 skip=3072 count=2560
dd if=eeprom.bin of=05-env2.bin bs=1024 skip=5632 count=2560
dd if=eeprom.bin of=06-kernel.bin bs=1024 skip=8192 count=32768
dd if=eeprom.bin of=07-kernel2.bin bs=1024 skip=40960 count=32768
dd if=eeprom.bin of=08-storage1.bin bs=1024 skip=73728 count=28672
dd if=eeprom.bin of=09-storage2.bin bs=1024 skip=102400 count=28160
Using binwalk on each image and hexdump -C, when needed, we can understand that:
- 01-bootloader.bin is the U-Boot bootloader for OS Linux and CPU MIPS
- 02-bootloader2.bin is unused, it has all bytes at default value (0xff)
- 03-config.bin unrecognized by binwalk, probably contains some router configuration
- 04-env1.bin contains U-Boot environment variables
- 05-env2.bin contains U-Boot environment variables, only one byte is different from the previous file, probably it is the active environment partition flag
- 06-kernel.bin contains an U-Boot header, a Linux kernel and a Squashfs file system. It is the boot image, and it is the starting point to modify the squashfs root file system
- 07-kernel2.bin is exactly, bit by bit, the same content as the one above
- 08-storage1.bin is an UBIFS file system, this is a writable, NAND Flash optimized, file system
- 09-storage2.bin is another UBIFS file system, the one that contains data
The router, probably, has duplicated partitions for bootloader, U-Boot environment, boot image, and storage to have a robust firmware upgrade system, the upgrade will go on the partition not active and then, if everything goes ok, the upgraded partition will become the active one.
The most interesting partition is the boot image partition (06-kernel.bin) because it includes the kernel and the root file system, to modify the firmware we are interested in modifying the root file system. It has a U-Boot header so we can understand exactly his content.
The U-Boot header format is:
#define IH_MAGIC 0x27051956 /* Image Magic Number */
#define IH_NMLEN 32 /* Image Name Length */
typedef struct image_header {
uint32_t ih_magic; /* Image Header Magic Number */
uint32_t ih_hcrc; /* Image Header CRC Checksum */
uint32_t ih_time; /* Image Creation Timestamp */
uint32_t ih_size; /* Image Data Size */
uint32_t ih_load; /* Data Load Address */
uint32_t ih_ep; /* Entry Point Address */
uint32_t ih_dcrc; /* Image Data CRC Checksum */
uint8_t ih_os; /* Operating System */
uint8_t ih_arch; /* CPU architecture */
uint8_t ih_type; /* Image Type */
uint8_t ih_comp; /* Compression Type */
uint8_t ih_name[IH_NMLEN]; /* Image Name */
} image_header_t;
“Multi-File Images” start with a list of image sizes, each
image size (in bytes) specified by an “uint32_t” in network
byte order. This list is terminated by an “(uint32_t)0″.
Immediately after the terminating 0 follow the images, one by
one, all aligned on “uint32_t” boundaries (size rounded up to
a multiple of 4 bytes).
In our case, analyzing the actual U-Boot header, using hexdump -C command, we can understand that the 06-kernel.bin can be divided in 4 parts:
- U-Boot header (64 bytes)
- Images lengths (24 bytes, 8 bytes for first image, 8 bytes for second image and 8 bytes, all "0", as terminator)
- Kernel image, lzma compressed
- Squashfs image
The 06-kernel.bin can be splitted in these 4 components using the following commands, included in the hg-config.sh script:
# ----- get length of the two images
IMG1LEN=`(echo -n "ibase=16;obase=A;"; hexdump -s 64 -n 4 -ve '/1 "%02X"' 06-kernel.bin ;echo) | bc`
IMG2LEN=`(echo -n "ibase=16;obase=A;"; hexdump -s 72 -n 4 -ve '/1 "%02X"' 06-kernel.bin ;echo) | bc`
# ----- extract the U-Boot header, first 64 bytes
dd if=06-kernel.bin bs=1 skip=0 count=64 of=u01-hdr.dat
# ----- extract the image lengths data segment, 24 bytes
dd if=06-kernel.bin bs=1 skip=64 count=24 of=u02-len.dat
# ----- extract the compressed kernel
dd if=06-kernel.bin bs=1 skip=88 count=$IMG1LEN of=u03-kern.dat
# ----- extract the squashfs file system image
dd if=06-kernel.bin bs=1 skip=`echo "88 + $IMG1LEN"|bc` count=$IMG2LEN of=u04-sqfs.dat
To extract the squashfs root file system from the squashfs image we can use the following command:
$ fakeroot -s fakeroot.dat unsquashfs -d squashfs-root u04-sqfs.dat
The fakeroot command is used to run the unsquashfs command as normal user and to prevent errors when extracting files owned by root and when extracting device special files. The -s option is useful to run again the fakeroot command resuming the same environment (regarding special device files and files ownership).
We know that the firmware has been built using Buildroot (see above, serial console output analysis during boot) so we are interested to see if some buildroot related stuff is available on the root file system:
# ----- at the root of the extracted squashfs file system
$ find . -print|grep -i buildroot
./etc/buildroot_config
we have the buildroot_config file, it is really interesting to understand how the firmware was built and it is very useful in building the emulation environment using Buildroot. Some interesting Buildroot configurations:
- Target architecture
BR2_mipsel=y BR2_ARCH="mipsel" BR2_ENDIAN="LITTLE" BR2_GCC_TARGET_ARCH="mips32r2" BR2_GCC_TARGET_ABI="32" BR2_ARCH_HAS_ATOMICS=y BR2_BINFMT_SUPPORTS_SHARED=y BR2_BINFMT_ELF=y BR2_mips_32r2=y BR2_MIPS_OABI32=y - The Buildroot generated toolchain has been used
- The following components have been selected:
- uClibc version 0.9.33.2
- Kernel version 2.6.36.x
- Binutils version 2.25
- Gcc version 4.5.4
- Use shadow passwords with sha-512 encryption
- Use Busybox as init processes and default shell
- Use U-Boot, target architecture MT7621A_DDR2
- Install host U-Boot tools
- Install some Gemtek packages (custom packages)
- Install a package named fwupgrade (interesting to upgrade the router with our own modified firmware)
- Install libcrypt and openssl packages
- Install some Linkem customer related stuff
We know that the login process is unusual (see above, serial console output analysis during boot) because it asks for a username (as the standard /bin/login), but then present a "Challenge code" instead of asking for a password. Looking at the Busybox Init configuration file, /etc/inittab, we can see that the usual /sbin/getty process manages the login on the serial console:
# Put a getty on the serial port
ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100 # GENERIC_SERIAL
/sbin/getty usually executes /bin/login but, in this case, /bin/login is a soft link to /bin/shell_auth, shell_auth probably is a custom developed replacement of the standard /bin/login. In the emulation environment we will try to reverse engineer this script to understand if we can successfully do a login on the console using the unmodified firmware.
The startup scripts are the Busybox standard startup scripts, in the /etc/inittab configuration file there is the following line:
::sysinit:/etc/init.d/rcS
this means the the script /etc/init.d/rcS is executed during boot and it runs every script in /etc/init.d directory starting with 'S', these scripts are:
- S10mountstorage mounts the UBI file system over /mnt/jffs2
- S11mountexternalusb in our case it doesn't mount the USB key, it does nothing
- S13portmap starts the portmap daemon, it is usually needed to mount NFS file systems
- S15create_account.sh during first boot it copies /etc/passwd.default, /etc/group.default, /etc/shadow.default to /mnt/jffs2/etc/passwd, /mnt/jffs2/etc/group, /mnt/jffs2/etc/shadow. /etc/passwd is a link to /mnt/jffs2/etc/passwd and also the other files in /etc are links to corresponding files in /mnt/jffs2/etc/
- S20urandom it saves the random seed between reboots in the permanent UBIFS storage /mnt/jffs2/random-seed
- S40network starts network interfaces
- S49ntp starts the NTP (Network Time Protocol) daemon
- S59snmpd starts the SNMP (Simple Network Management Protocol) daemon
- S90crond starts the cron daemon
- S99gemtek.sh the above scripts are, more or less, pretty Linux standard stuff, this script, instead, initialize and starts the most router specific configuration and services; it configures specific router hardware, inserts Gemtek specific modules into the kernel, modifies some kernel parameters, and executes some interesting programs:
- cert_gen probably some certificate generator program, but it gives error during boot
- if the boot happens in "factory mode" (with the U-Boot variable factory set to value 2), the router starts a telnet daemon with the shell /bin/sh listening (so without authentication) and broadcasts a UDP packet to the local LAN with the content "Gemtek Hello" from his factory IP address 192.168.15.1; on reboot the U-Boot variable factory is removed so the router restarts in normal mode. This fact is really interesting because to get a root shell prompt is really easy:
- connect the TTL USB serial cable to the PC and start a terminal emulator with serial parameters 115200N8 (115200 bps, No parity, No Flow Control, 1 stop bit, 8 bit)
- connect the PC to the router with an ethernet cable attached to one of the router's LAN interfaces
- assign to the PC ethernet interface the IP address 192.168.15.100
- power up the router and look at the terminal emulator
- when appears the prompt "Please choose the operation" press the key "4" to enter the U-Boot CLI (key must be pressed within 1 second)
- at the U-Boot CLI set the variable factory at value 2 with the command "setenv factory 2"
- at the U-Boot CLI permanently save the U-Uboot environment with the command "saveenv"
- power down the router, then power up again and wait until the boot is completed
- from the PC connect to the router using telnet and you will have a root shell prompt. It is not possible to modify the read only squashfs root file system, but it is possible to explore the system and to modify the content of the UBIFS file system mounted under /mnt/jffs2
- two other important custom daemon are started: proc_mon and msg_center. Using the strings command, to have an idea of what these two executables do, it seems that proc_mon monitors some processes and restarts them if needed; msg_center seems to be the core of the router doing a lot of stuff and executing a lot of external commands to do practically anything. It is really really interesting to analyze the embedded strings in msg_center
/etc/passwd and /etc/shadow are soft links to corresponding files in /mnt/jffs2/etc/, the permanent read/write ubifs file system. The files on /mnt/jffs2/etc/ are copied, on first boot, from /etc/passwd.default and /etc/shadow.default.
The main users in these files are:
- root with /bin/sh shell, password is "5/4jp6", discovered searching on Internet the password hash in the shadow file
- Lnk_Administrator with no shell (/bin/false)
- operator, disabled by default ('!' in password field) with no shell
- guest with no shell, it is the initial user that interacts with the web interface and the password is written on the user's manual
The purpose of the emulation environment is to run, as much as possible, router executables in a debugging friendly Qemu virtual machine where executable and library files are compiled with debugging information. This means not only that the machine must have a 32 bit, MIPS 1004Kc processor, but that kernel and libraries should be same version, or compatible version, as the one used in the router.
The emulated environment should have:
- a 32 bit MIPS 1004Kc processor
- an emulated 128Mb NAND flash memory, emulated with the nandsim kernel flash emulator
- a Linux Kernel version 2.6.36
- a root file system using uClibc, version 0.9.33.2, as standard C library
- other libraries with compatible versions with the router's binaries
The root file system can be built with a cross compilation toolchain able to generate binaries for the MIPS architecture on an Intel based Linux PC; but building the kernel, the libraries and the needed packages can be very challenging and time consuming because of the various version dependency that each package can have with other packages and standard libraries (the so called dependency hell). For this reason it is better to select a build tool able to manage this dependency hell, the most popular building tools for embedded devices are:
- The Yocto Project is very powerful, not only builds a root file system, but is able to create a custom Linux distribution for the embedded device. It's main drawback is that it has a steep learning curve
- Buildroot has a more limited scope: it builds the root file system and the kernel, it is quite easy and fast to learn and has a very good user manual, not too big, neither too small
- Openwrt/LEDE Build System is tailored mainly to build a replacement router firmware, his documentation is much more scattered in the web site and so requires more time to learn.
Buildroot has been the tool chosen for this reverse engineering project. It has been easy to learn ed effective in building the required root file system. In this project buildroot is the same software used to build the router's firmware and we know the exact buildroot version used to create the original firmware, so we will use the same version (buildroot-2015.02)
We want to use the same buildroot version used tho build the original firmware (buildroot-2015.02) that should have same library versions as the embedded firmware. The problem is that this buildroot version, on Ubuntu 18.04, gives multiple compilation errors, almost impossible to fix; changing gcc version doesn't help to solve all the issues.
The solution has been to use a Docker image, based on Debian Wheezy released in 2013, to run buildroot-2015-02; this docker image is able to run this version of buildroot without big issues.
During the setup of this environment many other issues have arisen, described below in the description of various configurations.
The main purpose of the Docker image is to have a Linux environment able to run buildroot-2015.02 without issues, for this reason the image is based on Debian Wheezy (released in 2013) with additional packages needed to run buildroot-2015.02, including packages and QT libraries to do a make xconfig with a GUI. The Docekerfile is quite simple and doesn't include Buildroot.
The Docker image can be created with the very simple script dockbuild.sh:
#!/bin/sh
docker build -t="digiampietro/buildroot-mips4kc" .
The image name is digiampietro/buildroot-mips4kc, later I will put this image on Docker HUB, in the meantime it is possible to change his name both on this script and on dockrun.sh.
Buildroot is installed in the user's home directory using the script hg-config.sh. This script, shown below, does also many other stuffs (see above)
$ ./hg-config.sh eeprom.bin
Both the user and his home directory are mapped inside the Docker image using the following shell script, docker/dockrun.sh, to run the Docker image:
#!/bin/sh
export GDISPLAY=unix/$DISPLAY # forward X11 display to the host machine
export GUSERNAME=`id -u -n` # current user's username
export GUID=`id -u` # current user's user id
export GGROUP=`id -g -n` # current user's primary group name
export GGID=`id -g` # current user's primary group id
export GHOME=$HOME # current user's home directory
export GSHELL=$SHELL # current user's shell
export GRUNXTERM=0 # flag start lxterminal, useful in windows
export GPWD=`pwd` # current working directory
docker run -h BRHOST \
--rm \
-v /tmp/.X11-unix:/tmp/.X11-unix \
-v $HOME:$HOME \
-e DISPLAY=$GDISPLAY \
-e GUSERNAME=$GUSERNAME \
-e GUID=$GUID \
-e GGROUP=$GGROUP \
-e GGID=$GGID \
-e GHOME=$GHOME \
-e GSHELL=$SHELL \
-e GRUNXTERM=$GRUNXTERM \
-e GPWD=$GPWD \
-it digiampietro/buildroot-mips4kcIn this script:
-
the user's home directory ($HOME) is mapped, with option
-v, inside the running image at exactly the same path -
the
-v /tmp/.X11-unix:/tmp/.X11-unixoption has the purpose do display, on the host, X11 applications running inside the Docker image -
the
--rmoptions terminate the Docker image process after exiting from the interactive shell; This is needed to prevent having a lot of unused stopped images -
some environment variables (options
-v) are passed from the host to the docker image with the purpose to create, on the fly, inside the image, the same user existing on the host with exact same attributes (username, uid, primary group, shell, home dir). This job is accomplished by the following entrypoint scriptdocekr/startup.sh:#!/bin/sh # # add current user and user's primary group # groupadd -g $GGID $GGROUP useradd -u $GUID -s $GSHELL -c $GUSERNAME -g $GGID -M -d $GHOME $GUSERNAME usermod -a -G sudo $GUSERNAME echo $GUSERNAME:docker | chpasswd if [ "$GRUNXTERM" = "1" ] then # become the current user and start a shell su -l -c lxterminal $GUSERNAME # another root shel lxterminal else # become the current user and start a shell su -l $GUSERNAME # another root shell /bin/bash fi
This Docker usage pattern allows to transparently share the user's home directory between the host and the Docker image and can be used every time there is a need to use a Docker image to transparently run software that cannot be run on the host and that will use and/or modify files in user's home directory.
In this case the Buildroot folder is not installed inside the Docker image, but will be installed in user's home directory and, in this way, the Buildroot folder will remain persistent across Docker image invocations.
The Buildroot configuration is stored in an external tree in the folder ext-tree, Buildroot itself can be launched with the shell script brmake that, basically, changes directory in the Buildroot directory and execute a make BR2_EXTERNAL=<path to ext-tree>.
The ext-tree folder has the following content:
ext-tree/
├── board
│ └── mips4kc
│ ├── kernel-defconfig
│ ├── overlay
│ │ └── etc
│ │ └── profile.d
│ │ └── set-prompt.sh
│ └── post-build.sh
├── Config.in
├── configs
│ ├── mips4kc-qemu_mipsel_malta_defconfig
│ └── uClibc-0.9.33.config
├── external.desc
├── external.mk
├── package
└── patches
-
ext-tree/board/mips4kc contains files for the fictitious board called mips4kc (for our router emulation)
-
ext-tree/board/mips4kc/kernel-defconfig contains the kernel configuration, saved in a defconfig file; main differences, compared with the default kernel configuration, have been introduced to be more similar to the router's kernel and to run it in QEMU, the most important configurations are:
- Preemption Model: Preemptible Kernel (low latency Desktop)
- Device Drivers
- NAND Device Support and Support for NAND Flash Simulator, this is very important to simulate the UBIFS file system on the flash memory
- OneNAND Device Support
- Enable UBI
- File Systems
- Miscellaneous filesystems: JFFS2 support, UBIFS, Squashfs
-
ext-tree/board/mips4kc/overlay in this path's subfolder there is the
set-prompt.shscript used to setup the prompt inside the QEMU emulated machine -
ext-tree/board/mips4kc/post-build.sh this is the Buildroot post-build script, used mainly to copy router's root file system and firmware to the root image of the emulated machine
-
ext-tree/Config.in, external.desc, external.mk are files needed by Buildroot to use the external tree
-
ext-tree/configs/mips4kc-qemu_mipsel_malta_defconfig contains the buildroot configuration, it is based on the qemu_mipsel_malta_defconfig, included in buildroot, to emulate a MIPS Malta Core LV with a MIPS 32 processor. The most important modified options are:
- Build Options, the selected options are needed to make easier the reverse engineering job:
- Build packages with debugging symbols
- gcc debug level 2
- strip binaries: no
- gcc optimization level 0
- global patch directories, to point to the external tree patch directory
- Toolchain, the selected options are needed to enable and facilitate debugging and to compile the 2.6.36 Kernel
- Kernel Headers: 2.6.x
- Enable large file support
- Enable WCHAR support
- Thread library debugging
- Enable C++ support
- Build cross GDB for the host
- Linux Kernel, the selected options are needed to select the 2.6.36 kernel and to run it under QEMU:
- Kernel configuration: using a custom config file
- Compressor and Decompressor, useful for the purpose of emulating the router environment
- bzip2
- xz-utils
- Debugging profiling and benchmark, the selected options are useful for reverse engineering
- gdb (gdbserver and full debugger)
- strace
- Development tools
- binutils, flex, libtools, make, pkgconf
- mtd, jffs2 and ubi/ubifs tools; these are very important because are related to flash eeprom Emulation
- Libraries, the selected options are needed to emulate binaries requiring the selected libraries
- libsha1, libssh2, openssl, expat, json-c
- Network Applications are included to exchange files between the emulated machine and the external world
- rsync, ncftp
- Shell and utilities
- file
- Host utilities
- host mtd, jffs2 and ubi/ubifs tools
- Build Options, the selected options are needed to make easier the reverse engineering job:
-
ext-tree/configs/uClibc-0.9.33.config this is the uClibc configuration, differences, compared with the default, have been introduced to be compatible with the router's binaries and to include debugging symbols in the library files. The inclusion of debugging symbols has been problematic: uClibc don't obey to the general option included in the Buildroot configuration, has his own flag for this purpose; the problem is that enabling his own flag the compilation gives impossible to fix errors, for this reason a workaround, described below, has been used:
- Target Architecture Features and Options
- Enable full C99 math library support
- General Library Settings
- Link LD Config statically, not selected
- Thread support, older (stable) version of linuxthreads
- Build pthreads debugging support
- Malloc returns live pointer for malloc(0)
- Provide libutil library and functions
- String and Stdio support
- Wide character support
- Support hexadecimal float notation
- Support glibc's register_printf_function()
- Some other glibc compatible settings
- Development/debugging options
- in Compiler Warnings add the string "-ggdb -g3", this is the work around to compile the uClibc with debugging symbols
- Target Architecture Features and Options
-
Having already downloaded the EEPROM image in the file eeprom.bin (see Getting the firmware file) we have to run the script hg-config.sh passing as parameter the filename of the eeprom image:
$ ./hg-config.sh /path/to/eeprom.binthis script:
- download buildroot-2015-02 in ../download
- copy eeprom.bin in ../download
- extract the buildroot tar file in ../buildroot-2015-02
- patches Buildroot because there are some packages that need the '-fPIC' compilation flag to compile successfully
- extract the eeprom partition images (01-bootloader.bin, 02-bootloader2.bin, 03-config.bin, 04-env1.bin, 05-env2.bin, 06-kernel.bin, 07-kernel2.bin, 08-storage.bin, 09-storages.bin) from eeprom.bin into ../firmware
- extract components from the boot image file 06-kernel.bin (u01-hdr.dat, u02-len.dat, u03-kern.dat, u04-sqfs.dat) into ../firmware
- extract the root file system from the squashfs root file system image u04-sqfs.dat into ../firmware/root
-
Build the docker machine
$ cd docker $ ./dockbuild.sh -
run the docker machine
$ ./dockrun.sh valerio@BRHOST:~$ -
do the initial Buildroot configuration
valerio@BRHOST:~$ cd linkem/hacking-gemtek/ valerio@BRHOST:~/linkem/hacking-gemtek$ ./brmake mips4kc-qemu_mipsel_malta_defconfig -
optionally do additional Buildroot configurations, the previous step has already configured Buildroot for this project, so you can skip this step or you can do this step without changing the current configuration
valerio@BRHOST:~/linkem/hacking-gemtek$ ./brmake xconfig -
optionally configure the uClibc library, it is already configured for this project, so you can skip this step or you can do this step without changing the current configuration
valerio@BRHOST:~/linkem/hacking-gemtek$ ./brmake uclibc-menuconfig -
optionally configure the kernel, it is already configured for this project, so you can skip this step or you can do this step without changing the current configuration
valerio@BRHOST:~/linkem/hacking-gemtek$ ./brmake linux-menuconfig -
you can now start Buildroot that will cross-complile everyting and will create the linux kernel vmlinux and the root file system rootfs.ext2 in the buildroot-2015.02/output/images folder
valerio@BRHOST:~/linkem/hacking-gemtek$ ./brmake -
the script to start the QEMU emulated machine, qemu-run/qr will automatically pickup the linux kernel and root file system generated in the previous step
The Buildroot User's Manual is a very good guide on how to configure and run Buildroot; in this environment Buildroot make commands should be executed using the brmake script, the most useful commands are:
./brmake xconfig(or./brmake menu-config) to configure Buildroot options;./brmake linux-menuconfigto configure the Linux Kernel. It is not possible to use./brmake linux-xconfigbecause the kernel is so old that requires the QT3 software, unavailable on Debian Wheezy, and doesn't like the compatibility layer that, usually, allows to run QT3 binaries in a QT4/QT5 environment./brmake uclibc-menuconfig(the xconfig version is not available for uClibc) to configure the uClibc library./brmake savedefconfigto save the Buildroot configuration in the external tree, on the fileext-tree/configs/mips4kc-qemu_mipsel_malta_defconfig./brmake linux-update-defconfigto save the Linux Kernel configuration in the external tree, on the fileext-tree/board/mips4kc/kernel-defconfig./brmake uclibc-update-defconfigto save the uClibc configuration in the external tree, on the fileext-tree/configs/uClibc-0.9.33.config./brmake cleanto delete all build products (including build directories, host, staging and target trees, the images and the toolchain); it can be useful to remove also the compilation cache with the commandrm -rf ~/.buildroot-ccache/./brmake distcleanto delete everything, including configuration files; needed to build for a new target, should not be used in this environment;./brmake linux-dircleanremoves the whole kernel build directory, to be used when kernel configuration changes are made;./brmake -s printvarsto dump all the variables known to make;./brmaketo build the kernel and the root file system.
To run QEMU there is the qr script inside the qemu-run folder, this script runs QEMU using the root file system built by Buildroot. The script is the following:
#!/bin/bash
MYDIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
. $MYDIR/../set-env.sh > /dev/null
cd $MYDIR
export QEMU_AUDIO_DRV="none"
echo "kernel: $BRIMAGES/vmlinux"
echo "rootfs: $BRIMAGES/rootfs.ext2"
qemu-system-mipsel -M malta \
-m 256 \
-kernel $BRIMAGES/vmlinux \
-nographic \
-hda $BRIMAGES/rootfs.ext2 \
-net nic,model=e1000 \
-net user,hostfwd=tcp::2222-:22,hostfwd=tcp::9000-:9000 \
-append "root=/dev/hda console=uart0"
The first three lines set environment variables and change directory to that of the script, the fourth line disables the audio driver (the emulated board doesn't emulate audio hardware), the qemu-system-mipsel options select:
- board malta with processor MIPS 24Kc and 256Mb of RAM (maximum amount of RAM available on this emulated board)
- the -nographic option prevents the opening of another window: the console input/output go to the current terminal
- the -kernel option selects the kernel generated by Buildroot
- the -hda option selects the root file system image generated by Buildroot emulated as an Hard Disk
- the -net options associate an ethernet card to the emulated board and does port forwarding from the host to the qemu machine, the forwarded ports are host port 2222 to qemu machine port 22 (to do ssh from the host to the qemu machine) and port 9000 from the host to same port on the qemu machine (it will be used by gdb/gdbserver).
To stop the emulated machine there is the command halt and to exit from the emulator there is the key command sequence: Ctrl-A X.
The QEMU emulated machine can be started with the qr script:
$ cd qemu-run/
$ ./qr
kernel: /home/valerio/linkem/buildroot-2015.02/output/images/vmlinux
rootfs: /home/valerio/linkem/buildroot-2015.02/output/images/rootfs.ext2
...
Welcome to Buildroot
buildroot login: root
root@buildroot:~#
Inside the root file system, thanks to the ext-tree/board/mips4kc/post-build.sh script, there are two folders:
- /mips-root contains the original squashfs root file system extracted in this folder
- /mips-firm contains the binary files of each router's partition and the script
set-nandsim.shthat loads the nandsim, NAND simulator, kernel module simulating the original router's NAND Flash partitons, loads the partition images into the emulated NAND partitions and mount the UBIFS file sistem in /mnt/jffs2, as in the original router.
The main purpose of this reverse engineering project is to modify the router firmware to be able to modify configurations, add additional software and to be able to login and become root on the router.
During file system analysis we have already found a way to login, as root, into the router, setting "factory mode", as explained above, but we are interested to understand if we can logon, through the UART iterface, as root. We know that the /bin/login is a link to /bin/shell_auth that prints a "Challenge code" waiting for a response to this challenge code, so we start reverse engineering this binary.
The MIPS executable shell_auth has no debugging information but, as almost all executables, it makes a lot of library calls. The emulated environment has been set up with debugging information on all executable and library files, this means that to reverse engineer the shell_auth executable we can follow the library calls it does.
Using readelf we can get some interesting information
$ $TOOLBIN/mipsel-linux-readelf -a squashfs-root/bin/shell_auth
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x400a60
Start of program headers: 52 (bytes into file)
Start of section headers: 8952 (bytes into file)
Flags: 0x70001007, noreorder, pic, cpic, o32, mips32r2
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 9
Size of section headers: 40 (bytes)
Number of section headers: 27
Section header string table index: 26
...
[Requesting program interpreter: /lib/ld-uClibc.so.0]
...
Dynamic section at offset 0x198 contains 21 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libssl.so.1.0.0]
0x00000001 (NEEDED) Shared library: [libcrypto.so.1.0.0]
0x00000001 (NEEDED) Shared library: [libc.so.0]
This command shows that it uses libssl, libcrypto, and libc (the last one provided by uClibc).
The following readelf command (display symbols in the dynamic section) lists the library function calls and external symbols used by the executable:
$ $TOOLBIN/mipsel-linux-readelf --sym -D squashfs-root/bin/shell_auth
Symbol table for image:
Num Buc: Value Size Type Bind Vis Ndx Name
36 0: 00401ba0 0 FUNC GLOBAL DEFAULT UND OPENSSL_add_all_algorithm
26 1: 00401c30 0 FUNC GLOBAL DEFAULT UND RSA_public_encrypt
39 1: 00401b70 0 FUNC GLOBAL DEFAULT UND BIO_set_flags
44 1: 00000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
48 1: 00401af0 0 FUNC GLOBAL DEFAULT UND strcmp
14 2: 00401ce0 0 FUNC GLOBAL DEFAULT UND memcpy
9 3: 00412040 0 OBJECT GLOBAL DEFAULT 19 __RLD_MAP
29 4: 00000000 0 FUNC WEAK DEFAULT UND __register_frame_info
42 4: 00401b40 0 FUNC GLOBAL DEFAULT UND strrchr
43 4: 00401b30 0 FUNC GLOBAL DEFAULT UND RSA_private_decrypt
1 4: 004018cc 356 FUNC GLOBAL DEFAULT 9 main
33 9: 00401bd0 0 FUNC GLOBAL DEFAULT UND BN_bin2bn
5 9: 00000001 0 SECTION GLOBAL DEFAULT ABS _DYNAMIC_LINKING
27 10: 00401c20 0 FUNC GLOBAL DEFAULT UND fgets
55 11: 00401a90 0 FUNC GLOBAL DEFAULT UND RSA_size
25 14: 00401c40 0 FUNC GLOBAL DEFAULT UND ERR_load_crypto_strings
41 14: 00401b50 0 FUNC GLOBAL DEFAULT UND sleep
24 15: 00401c50 0 FUNC GLOBAL DEFAULT UND BIO_s_mem
32 15: 00401be0 0 FUNC GLOBAL DEFAULT UND printf
35 15: 00401bb0 0 FUNC GLOBAL DEFAULT UND perror
49 16: 00401ae0 0 FUNC GLOBAL DEFAULT UND signal
17 18: 00401cc0 0 FUNC GLOBAL DEFAULT UND puts
10 18: 00412128 0 NOTYPE GLOBAL DEFAULT 21 _edata
4 19: 004009f4 28 FUNC GLOBAL DEFAULT 8 _init
56 19: 00401a80 0 FUNC GLOBAL DEFAULT UND memcmp
18 20: 00401cb0 0 FUNC GLOBAL DEFAULT UND BN_set_word
23 21: 00401c60 0 FUNC GLOBAL DEFAULT UND BN_new
30 23: 00401c00 0 FUNC GLOBAL DEFAULT UND BIO_write
37 23: 00401b90 0 FUNC GLOBAL DEFAULT UND BIO_free_all
45 23: 00401b20 0 FUNC GLOBAL DEFAULT UND malloc
19 24: 00401ca0 0 FUNC GLOBAL DEFAULT UND BIO_ctrl
21 24: 00401c80 0 FUNC GLOBAL DEFAULT UND __xpg_basename
34 24: 00401bc0 0 FUNC GLOBAL DEFAULT UND BIO_read
15 25: 00401cd0 0 FUNC GLOBAL DEFAULT UND BIO_push
6 25: 00412128 0 NOTYPE GLOBAL DEFAULT 22 _fbss
3 25: 00401d20 28 FUNC GLOBAL DEFAULT 11 _fini
20 26: 00401c90 0 FUNC GLOBAL DEFAULT UND execv
7 27: 00412030 0 NOTYPE GLOBAL DEFAULT 18 _fdata
46 27: 00401b10 0 FUNC GLOBAL DEFAULT UND RSA_generate_key_ex
16 28: 00000000 0 OBJECT GLOBAL DEFAULT UND stdin
53 28: 00401ab0 0 FUNC GLOBAL DEFAULT UND RSA_free
13 29: 00401cf0 0 FUNC GLOBAL DEFAULT UND strlen
28 29: 00401c10 0 FUNC GLOBAL DEFAULT UND exit
52 29: 00401ac0 0 FUNC GLOBAL DEFAULT UND BN_free
40 30: 00401b60 0 FUNC GLOBAL DEFAULT UND RSA_new
11 31: 00412150 0 NOTYPE GLOBAL DEFAULT 22 _end
12 32: 00401d00 0 FUNC GLOBAL DEFAULT UND BIO_new
31 32: 00401bf0 0 FUNC GLOBAL DEFAULT UND alarm
38 32: 00401b80 0 FUNC GLOBAL DEFAULT UND BIO_f_base64
47 32: 00401b00 0 FUNC GLOBAL DEFAULT UND memset
2 33: 00400a60 0 NOTYPE GLOBAL DEFAULT 9 _ftext
8 35: 00412128 0 NOTYPE GLOBAL DEFAULT 22 __bss_start
54 35: 00401aa0 0 FUNC GLOBAL DEFAULT UND __uClibc_main
22 36: 00401c70 0 FUNC GLOBAL DEFAULT UND BN_bn2bin
50 36: 00000000 0 FUNC WEAK DEFAULT UND __deregister_frame_info
51 36: 00401ad0 0 FUNC GLOBAL DEFAULT UND BIO_new_mem_buf
To generate an initial gdb (Gnu Debugger) script that puts a breakpoint on each library call it is possible to use the script qemu-run/gen-breakpoints.sh; this script get information from the previous command.
The generated gdb script has been heavily modified with some macros and commands to run when certain breakpoints are hit and is available in ./qemu-run/shell_auth.gdb; this script will be used in the debugging session.
The guest emulated machine is started with the script qr in the qemu-run folder, this script launches qemu-system-mipsel with:
- the emulated board malta
- the cpu MIPS 24Kc
- 256Mb of RAM
- the file system generated by buildroot in an emulated hard disk
- port forwarding from host to the guest on port 22 (to be used by
ssh) and on port 9000 (to be used bygdbon the host andgdbserveron the guest)$ ./qr Linux version 2.6.36 (valerio@BRHOST) (gcc version 4.5.4 (Buildroot 2015.02) ) #1 SMP PREEMPT Wed Aug 14 06:56:35 UTC 2019 bootconsole [early0] enabled CPU revision is: 00019300 (MIPS 24Kc) FPU revision is: 00739300 Determined physical RAM map: memory: 00001000 @ 00000000 (reserved) memory: 000ef000 @ 00001000 (ROM data) memory: 003f5000 @ 000f0000 (reserved) memory: 0fb1b000 @ 004e5000 (usable) Wasting 40096 bytes for tracking 1253 unused pages Welcome to Buildroot buildroot login: root # uname -a Linux buildroot 2.6.36 #1 SMP PREEMPT Wed Aug 14 06:56:35 UTC 2019 mips GNU/Linux # # cat /proc/cpuinfo system type : MIPS Malta processor : 0 cpu model : MIPS 24Kc V0.0 FPU V0.0 BogoMIPS : 1189.47 wait instruction : yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : yes, count: 1, address/irw mask: [0x0ff8] ASEs implemented : mips16 shadow register sets : 1 core : 0 VCED exceptions : not available VCEI exceptions : not available #
The post-build.sh script has copied:
-
the router root file system in the folder
/mips-rootin the emulated machine -
the firmware partition images and the squashfs file system image in the folder
/mips-firm -
the
shell_authexecutable is located in/mips-root/bin/shell_auth. Thegdbserveris launched with the following commands in the qemu virtual machine:root@buildroot:~# cd /mips-root/bin/ root@buildroot:/mips-root/bin# gdbserver :9000 ./shell_auth Process ./shell_auth created; pid = 840 Listening on port 9000
The gdb in the host machine is started with the script gdbrun.sh
in the qemu-run folder, this script:
-
sets some environment variables
-
sets the gdb SYSROOT directory to locate unstripped binaries generated by buildroot
-
add the current directory (
qemu-run) and the host tools directory (wheremipsel-linux-gdbis located) to the list of directories where to search sources and gdb scripts -
set the remote target address/port and starts
gdbwith the arguments given to the script.$ ./gdbrun.sh -x shell_auth.gdb GNU gdb (GDB) 7.8.2 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=mipsel-buildroot-linux-uclibc". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". Remote debugging using :9000 0x2b1d4a00 in ?? () Reading symbols from /home/valerio/linkem/buildroot-2015.02/output/target/lib/ld-uClibc.so.0...done. Loaded symbols for /home/valerio/linkem/buildroot-2015.02/output/target/lib/ld-uClibc.so.0 Source directories searched: /home/valerio/linkem/buildroot-mips4kc/qemu-run:$cdir:$cwd Source directories searched: /home/valerio/linkem/buildroot-2015.02/output/host/usr/bin:/home/valerio/linkem/buildroot-mips4kc/qemu-run:$cdir:$cwd Function "BIO_ctrl" not defined. Breakpoint 1 (BIO_ctrl) pending. ... Function "_stdio_fopen" not defined. Breakpoint 24 (_stdio_fopen) pending. (gdb) cont
Usually Linux does virtual address space randomization this means that each time you run a program, the memory address of variables and pointers changes and this is reflected in gdb output. This is good for security reason, but it is not desirable in reverse engineering, luckily this address space randomization can be disabled:
root@buildroot:/mips-root/bin# # ----- disable address space randomization
root@buildroot:/mips-root/bin# echo 0 > /proc/sys/kernel/randomize_va_space
The RSA public key is formed by two MPI (Multi Precision Integer),
the modulus and the exponent, in the case of shell_out the
exponent is allways 0xFFFF, for this reason we usually see only the
modulus during the gdb session. In gdb, looking at breakpoints and
function parameters we can understand what shell_auth does. The
following gdb screenshots have been edited to improve readability, in
short what shell_out does is:
-
it calls
RSA_newto allocate memory for a newRSApublic/private key at memory address 0x41ea58, we call this key generated-rsaBreakpoint 16, RSA_new () at rsa_lib.c:80 # returned value --- r: $1 = (RSA *) 0x41ea58 {... n = 0x420580, # modulus e = 0x4205b0, # exponent d = 0x420598, p = 0x4205c8, q = 0x4205e0, dmp1 = 0x4205f8, dmq1 = 0x420610, iqmp = 0x420628 ... } -
it calls again
RSA_newto allocate memory for a newRSApublic/private key at memory address 0x4202c8, we call this key eprom-rsaBreakpoint 16, RSA_new () at rsa_lib.c:80 --- r: $3 = (RSA *) 0x4202c8 {... n = 0x41ea18, # modulus e = 0x4208f8, # exponent ... } -
it calls
RSA_generate_key_exto generate a newRSApublic/private key and to store it at memory address 0x41ea58, (generated-rsa)Breakpoint 15, RSA_generate_key_ex --- arguments rsa = 0x41ea58 bits = 1024 e_value = 0x41ea18 cb = 0x0 -
the modulus of the generated-rsa is serialized with the function
BN_bn2bin(Big Number to Binary string) and stored at address 0x7FFF6B70, we call this address generated-rsa.modulusBreakpoint 12, BN_bn2bin a=0x420580, to=0x7fff6b70 at bn_lib.c:649 649 n = i = BN_num_bytes(a); -
a modulus, stored inside the
shell_authbinary, is copied into the eprom-rsa, initializing only the public keyTemporary breakpoint 28, BN_bin2bn s = 0x401fb0 len = 256 ret = 0x41ea18 $7 = (BIGNUM *) 0x41ea18 $8 = {d = 0x420650, top = 64, dmax = 64, neg = 0, flags = 1} # modulus content follows ---------- eprom-rsa modulus 00000000: bb31 3a22 dc7a f2da dd72 77ae 8a49 92db .1:".z...rw..I.. 00000010: 1612 de35 2a80 ebd9 b208 199b e991 2ee9 ...5*........... 00000020: 060e f760 0d63 4f99 4e88 0839 dea5 25b7 ...`.cO.N..9..%. 00000030: 0827 5b7b c4f1 dc2d a622 4a47 a4b4 e022 .'[{...-."JG..." 00000040: 3f1b 6169 4b0d 6c20 182f b4e3 f89d a3a7 ?.aiK.l ./...... 00000050: 67ee df55 0fd5 6743 758d 90d7 ba1a 20c5 g..U..gCu..... . 00000060: 357a dd0b 5897 e699 fe43 2901 1631 e6c4 5z..X....C)..1.. 00000070: 86f7 14cf f9a3 fc0e d7ea 6034 1c34 484b ..........`4.4HK 00000080: e7b3 c265 ed5d 1d91 785b f840 cc60 2894 ...e.]..x[.@.`(. 00000090: 7b4d 01bb 875d 6f10 14a8 4ca3 8e09 1d5a {M...]o...L....Z 000000a0: 8b79 6ea4 708f 5dd1 abe0 a425 11bf 91e8 .yn.p.]....%.... 000000b0: 6841 a8ee 3faf 0d00 d61b e026 014a 6da9 hA..?......&.Jm. 000000c0: 0d43 35ed b4bd dbc4 2a71 6e3f 734a fc15 .C5.....*qn?sJ.. 000000d0: 8851 3cee 672f 8efa b036 e0a1 61ec b962 .Q<.g/...6..a..b 000000e0: e8e8 043a e803 0586 e471 a2d4 dc9a e988 ...:.....q...... 000000f0: 8f32 b13f 496c 796f 4073 c71e 6474 8485 [email protected].. -
RSA_public_encrypt is called to encrypt the generated-rsa.modulus with the public key eprom-rsa
Breakpoint 18, RSA_public_encrypt --- info args flen = 128 from = 0x7fff6b70 # generated-rsa.modulus see above step 4 to = 0x7fff6a68 rsa = 0x4202c8 # eeprom-rsa se above step 2 padding = 1 -
after some intermediate steps the generated-rsa.modulus encrypted with eprom-rsa in the previous step is base64 encoded and printed as the challenge string
-
the login prompt, after the challenge, does expect a base64 string, not padded with "=" chars, corresponding to 128 original bytes. If the string length is shorter than expected the login process is immediately aborted writing the string "Fail!" on the console
-
if the input string in the previous step has the correct length, it is base64 decoded and then decrypted with the function RSA_private_decrypt using the private key generated-rsa
-
this means that:
- the challenge code is the public key to use (probably) to encrypt the login user's password
- the challenge code is encrypted with the Gemtek public key
stored inside the
shell_authbinary and base64 encoded - in order to decrypt the public key of the challenge code we need the Gemtek private key
- because we don't know the Gemtek private key, this means that
there is no way to successfully login with
shell_auth - we can defeat the above protection modifying the firmware as explained below.
During file system analysis we have found a very interesting binary, msg_center, with a lot of interesting strings inside, found with the use of the strings command. Some of this interesting string are related to the assist binary, probably a binary to do (un)secure related stuff:
$ strings msg_center | grep assist
/bin/assistant -p hO2PHGNmaX0Ww!v0eqD8 -w xvoip_password_1 -t xvoip_plaintext_pw_1
/bin/assistant -p hO2PHGNmaX0Ww!v0eqD8 -w xvoip_password_2 -t xvoip_plaintext_pw_2
/bin/assistant -p hO2PHGNmaX0Ww!v0eqD8 -w iad_xvoip_password_1 -t iad_xvoip_plaintext_pw_1
/bin/assistant -p hO2PHGNmaX0Ww!v0eqD8 -w iad_xvoip_password_2 -t iad_xvoip_plaintext_pw_2
/bin/assistant -p hO2PHGNmaX0Ww!v0eqD8 -g
assistant -p hO2PHGNmaX0Ww!v0eqD8 -w wifi -h "$serial" -s %s 2> dev/null | cut -c1-8 | tr 'A-Z' 'a-z'
The latest string seems to be a command used to generate the WiFi
default password, "$serial" could be the serial number "-s %s"
could be the seed, probably the 3 bytes hex string that is formed by
the last 6 chars of the ESSID. Looking at my router label: 
we can try to execute this program
in the emulated environment:
root@buildroot:/mips-root/bin# ./assistant -p hO2PHGNmaX0Ww!v0eqD8 -w wifi -h "GMK170210005623" -s A8D9A6
./assistant: can't load library 'libcmc.so'
#
# # ----- the libcmc.so is a proprietary library, we can set LD_LIBRARY_PATH to load it
root@buildroot:/mips-root/bin# export LD_LIBRARY_PATH=/lib:/usr/lib:/mips-root/lib:/mips-root/usr/lib
root@buildroot:/mips-root/bin# ./assistant -p hO2PHGNmaX0Ww!v0eqD8 -w wifi -h "GMK170210005623" -s A8D9A6
WSAgj2ZZ
#
# # ----- giving exactly the same command as in the string inside msg_center
root@buildroot:/mips-root/bin# ./assistant -p hO2PHGNmaX0Ww!v0eqD8 -w wifi -h "GMK170210005623" -s A8D9A6 2> /dev/null | cut -c1-8 | tr 'A-Z' 'a-z'
wsagj2zz
Bingo! we have, included in the router firmware, a fantastic hacking tool: we are able to generate the default password of each router with similar firmware, but we need to know the serial number. Next step is to reverse engineer this binary, to create a program that can do the same thing on a Linux or Windows or Mac PC and that can, eventually, generate a dictionary of possible passwords to be used with tools like aircrack-ng.
As above we start the gdbserver in the emulated machine
root@buildroot:~# cd /mips-root/bin/
root@buildroot:/mips-root/bin# #------- disable randomization of virtual address space
root@buildroot:/mips-root/bin# echo 0 > /proc/sys/kernel/randomize_va_space
root@buildroot:/mips-root/bin# #------- add proprietary router's library to LD_LIBRARY_PATH
root@buildroot:/mips-root/bin# export LD_LIBRARY_PATH=/lib:/usr/lib:/mips-root/lib:/mips-root/usr/lib
root@buildroot:/mips-root/bin# gdbserver :9000 ./assistant -p hO2PHGNmaX0Ww!v0eqD8 -w wifi -h "GMK170210005623" -s A8D9A6
Process ./shell_auth created; pid = 840
Listening on port 9000
and gdb in the Linux host machine:
$ ./gdbrun.sh -x assistant.gdb
GNU gdb (GDB) 7.8.2
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
...
Function "BN_bn2bin" not defined.
Breakpoint 38 (BN_bn2bin) pending.
(gdb) cont
Analyzing /bin/assistant in gdb we can understand:
-
it calculates the SHA1 digest for the router's serial number, storing the digest at address 0x7FFF618C
Breakpoint 36, SHA1 (d=0x7fff63ec "GMK170210005623", n=15, md=0x7fff618c "") at sha1_one.c:70 -
the content of the SHA1 digest, after the SHA1 function returns, is:
gdb) xxd 0x7fff618c 20 00000000: c40d e496 1620 cfbc c6c9 0566 544a 8f8f ..... .....fTJ.. 00000010: 2a59 25d8 *Y%. -
it makes some calculations to calculate a binary version of the WiFi password
-
it calls the BIO_s_mem, BIO_new, BIO_f_base64, BIO_push, BIO_ctrl functions to setup a base64 encoder
-
it calls BIO_write to convert a binary representation of the password to a base64 string that, converted to lower case, will be the actual password
Breakpoint 19, BIO_write (b=0x4132a8, in=0x7fff612c, inl=6) at bio_lib.c:225 225 if (b == NULL) (gdb) xxd 0x7fff612c 6 00000000: 5920 208f 6659 Y .fYAt the address
0x7fff612cthere is the binary representation of the password, excluding case, that is5920 208f 6659, in fact:$ # ---- "xxd -r -p" converts hex string back to binary $ echo "5920 208f 6659" | xxd -r -p | base64 WSAgj2ZZ $ # WSAgj2ZZ is the mixed case version of the actual password "wsagj2zz" -
we can see that the binary representation of the password is a permutation of some bytes that were present in SHA1 digest of the serial number. May be it is not so easy to spot, it took me some debugging sessions and iterations, changing the seed from the original A8D9A6 to 000000, 000001, 000100, 010000 and also changing, in memory, the SAH1 binary string to all zero;
-
after these debugging sessions and seed permutations I found the algorithm to generate the binary representation of the mixed case password; explaining with the same example used above, the algorithm is:
- A8D9A6 is splitted in each ASCII char code and subtracted the
value for the char '0':
i1 = 'A' - '0' = 17i2 = '8' - '0' = 8i3 = 'D' - '0' = 20i4 = '9' - '0' = 9i5 = 'A' - '0' = 17i6 = '6' - '0' = 6
- count i1 (17) bytes, starting from zero, in the SHA1 of the serial number (c40d e496 1620 cfbc c6c9 0566 544a 8f8f 2a 59 25d8), this gives 59, the first byte of the binary representation of the password
- continue to count i2 (8) bytes after the byte 59, restarting from the beginning when hitting the end (c40d e496 16 20 cfbc c6c9 0566 544a 8f8f 2a59 25d8), this gives 20, the second byte of the binary representation of the password
- continue to count i3 (20) bytes after the byte 20, restarting from the beginning when hitting the end (c40d e496 16 20 cfbc c6c9 0566 544a 8f8f 2a59 25d8), this gives 20, the third byte of the binary representation of the password
- repeat for remaining bytes and you get the binary representation of the password
- base64 encode this binary representation of the password, convert to lowercase and you get the WiFi router's defautl password "wsagj2zz"
- A8D9A6 is splitted in each ASCII char code and subtracted the
value for the char '0':
The reverse engineering of the WiFi router's default password generator has been completed and can be implemented, see below, in a program to run on a PC.
The above algorithm has been implemented in the simple C program
gemtek-pass.c it can be compiled, in a Linux
system, with the command:
$ gcc gemtek-pass.c -lcrypto -o gemtek-pass
it requires the libssl-dev package that provides the libcrypto
library. It should be easy to port this program to Windows and/or to
Mac OS X, but I haven't done it. For example, to generate the default
router's password with GMK170210005623 serial number and
Linkem2.4GHz_A8D9A6 ESSID, the command is:
$ ./gemtek-pass GMK170210005623 A8D9A6
Serial number : GMK170210005623
Last 3 MAC digits: A8D9A6
wifi password is : wsagj2zz
This router's serial number has the format GMKyymmddnnnnnn where:
- yy is the last 2 digits of the year of production
- mm is the month of production
- dd is the day of production
- nnnnnn is a serial number, increased by one for each manufactured router
If the serial number is unknown and only the ESSID, as
Linkem2.4GHz_A8D9A6, is known, one possible approach to WiFi default
password recovery is to capture the WPA/WPA2 handshake using
airmon-ng, airodump-ng, aireplay-ng and then crack the password
with aircrack-ng using a password dictionary generated with the C
program gemtek-gen-dict.c that generates
possible passwords for millions of possible serial numbers. There are
many tutorials on cracking WPA/WPA2 passwords capturing an handshake
and using a dictionary
attack.
gemtek-gen-dict.c can be compiled, in a Linux system, with the
command:
$ gcc gemtek-gen-dict.c -lcrypto -o gemtek-gen-dict
it requires the libssl-dev package that provides the libcrypto
library. It should be easy to port this program to other platforms.
This program generates possible passwords for serial numbers
manufactured between a start and an end date, the usage is:
./gemtek-gen-dict -s start_date -e end_date -a start_serial -z end_serial -m half_mac [ -n ]
where:
-
start_date is the start date of production in the format yymmdd, for example 160101. The start of production of this type of router seems to be in 2015 or in 2016, but similar products with similar firmware could be manufactured before this years;
-
end_date is the end date of production in the format yymmdd, it seems still in production, so the end date could be today's date
-
start_serial is the starting number, usually '0' (the
nnnnnnpart of the entire serial number); -
end_serial it is the last number generated for each day in the production period. Based on some known serial numbers and related mac addresses and knowing that each router needs 3 mac addresses, it seems that daily productions is in the range 4,000-8,000 units per day, so putting 20,000 as last number generated seems to be a safe assumption. The serial numbers are generated from number 0 for the start date, then number 0 for the second date and so on until the end date and then restart with number 1 for the start date and so on, in this way increasing the end_serial number will not increase the time needed by aricrack-ng to find the default password, because higher, less probable, numbers are at the end of the file and are reached only if the password hasn't be cracked yet;
-
half_mac is the last 6 chars of the ESSID (A8D9A6 in the case of Linkem2.4GHz_A8D9A6)
-
-n must not be used for cracking the password with aircrack-ng, but can be used after the password has been cracked to recover the related serial number, with this option the program will generate, on each line, the serial number and the related password.
In the following example it needs few seconds to generate about 15 millions of possible passwords related to two years of router's production, it prints something every few thousands password generated:
$ ./gemtek-gen-dict -s 160101 -e 171231 -a 0 -z 20000 -m A8D9A6 > gemtek-wordlist.txt
sdate - start date: 160101
edate - end date: 171231
sserial - start serial: 0
eserial - end serial: 20000
halfmac - last 3 mac digits: A8D9A6
---> tot number of days: 731
---> GMK160101000500
...
This kit, located in the folder mod-kit in this repository, allows to extract the suqashfs root file system from the boot partition image file, modify and/or add new files to this root file system and generate a new boot image file, ready to be used to boot the router using the U-Boot CLI and the tftboot or to replace the original boot image in the NAND Flash EEPROM.
This firmware modification kit runs only on Linux and I don't think can be easily ported to other Operating Systems. It has been tested with firmware version "=01.01.02.090", in some scripts it is hardcoded the EEPROM partition size, this limitation will be removed in future versions. It should function on different firmware versions, but only if the EEPROM partitioning has not changed.
The kit requires some software to be available, the most important software needed is fakeroot, unsquashfs and mksquashfs.
The folder mod-kit contains the following files/directories:
-
mod-kit-configure.sh this script prepares and creates the directory tree (mod-kit-dir) that will contain the original boot image file, the original extracted root file system, the patch directory, the overlay directory, the new modified root file system, the new modified boot image. This is the first script to run.
-
mod-kit-run.sh this is the main script that extracts the root file system from the original boot image, apply patches to it, apply overlay files, remove files listed in
root-rm-files.txt, executes thepre-image-script.shand generates the new boot image file. -
root-patch this is a directory with same folder structure as the root file system and a corresponding file for each file that needs to be patched on the original root file system. The patch file name is the same as the file to be patched with the suffix
.patch. This directory is copied to the mod-kit-dir and can be customized, if needed. Currently only the following files will be patched:- /etc/securetty to allow root login when the telnetd daemon is active; it is not needed because the telnetd daemon is not normally running. Was used during initial development
-
root-overlay this is a directory with same folder structure as the root file system, files present in this directory will be written to the new root file system, after the above patches have been applied. This directory is copied to the mod-kit-dir and can be customized. Currently the main folder and files located in this directory are the followings:
/optdirectory, it is currently not used, but could be the mount point for an ext2, ext3 or ext4 first partition on a USB key where to install additional software;/etc/sshis a link to the permanent UBIFS file system/mnt/jffs2/etc/sshwhere to store sshd configuration (sshd was not present on the original boot image)/etc/init.d/S99sshdthe startup script for the sshd daemon to add sshd to the router's boot image- some additional programs, missing from the original boot image,
compiled and stripped in the emulation environment:
/usr/bin/gdb/usr/bin/sftp/usr/bin/rsync/usr/bin/gdbserver/usr/bin/scp/usr/bin/ssh-keygen/usr/bin/strace/usr/libexec/sftp-server/usr/sbin/sshd
-
root-rm-files.txt this file lists, one per line, files and/or directories to be removed from the new root file system. '#' as first char in a line is a comment and it is ignored, a trailing '/' indicates a directory. This file is copied to the mod-kit-dir and can be customized.
-
pre-image-script.sh this script will be executed just before the creation of the new root file system image and can be used to further customize the new root file system. By default it removes the /bin/login link to /bin/shell_auth and replace it with a link to /bin/busybox, the standard login; it also creates the /etc/motd file containing the string hacking-gemtek and the date, this is used to identify a modified boot image.
This script creates the directory tree where the firmware modification kit will store original boot image file, original root file system, modified root file system, modified boot image file and other support files.
Script usage is the following:
usage: ./mod-kit-configure.sh [ -d basedir ] <boot image file>
-d basedir (defautl $HOME/mod-kit)
-h this help
example:
./mod-kit-configure.sh /path/to/06-kernel.bin
This script will create the following directories, and partially
populate them, under the basedir provided with the -d option
(default is $HOME/mod-kit)
-
input the original firmware file is copied to this directory, the original root file system image and other original intermediate images are stored in this directory
-
input/root the original root file system, extracted with unsquashfs by the
mod-kit-run.shscript is stored in this directory -
output the modified boot image file is generated, by
mod-kit-run.sh, in this directory, intermediate modified file system images are stored in this directory -
output/root the modified root file system is stored in this directory. The original file system in
input/rootis copied here, then patches fromroot-patchdirectories are applied, then files in theroot-overlaydirectory are copied here. -
root-patch this is a directory with same folder structure as the root file system and a corresponding file for each file that needs to be patched on the original root file system. The patch file name is the same as the file to be patched with the suffix
.patch. This directory is initially populated by themod-kit-configure.shscript from the similar directory in this repository. The user can customize this directory adding more patch files. -
root-overlay this is a directory with same folder structure as the root file system, files present on this directory will be written to the new root file system, after the above patches have been applied by the
mod-kit-run.shscript. This directory is initially populated by themod-kit-configure.shscript from the similar directory in this repository. The user can customize this directory adding more files and or directories. -
root-rm-files.txt this file lists, one per line, files and/or directories to be removed from the new root file system. '#' as first char in a line is a comment and it is ignored, a trailing '/' indicate a directory. This file can be customized.
-
pre-image-script.sh this script will be executed just before the creation of the new root file system image and can be used to further customize the new root file system. By default it removes the /bin/login link to /bin/shell_auth and replace it with a link to /bin/busybox, the standard login.
This script does the main job to generate the modified boot image file (file names are relative to basedir, ~/mod-kit/ by default):
- it extracts the root file system image from the original squashfs
image file and write it into
input/root - it copies
input/roottooutput/root - it applies patches from
root-patchestooutput/root - it copies additional files/directory from
root-overlaytooutput/root - it generate the new root squashfs file system image
- it insert the new root squashfs file system image into the new boot image file recalculating image lengths and checksums
Usage of this script is the following:
usage: ./mod-kit-run.sh [ -c ] [ -h ]
-c clean all generated files from a previous run
-h print this help
example: ./mod-kit-run.sh
The new generated boot image partition is output/06-kernel-mod.bin, path relative to basedir, by default it is ~/mod-kit/output/06-kernel-mod.bin
-
install a tftpd server on your Linux Machine and a tftp client for testing, for example in Ubuntu
$ sudo apt install tftp-hpa tftpd-hpa -
copy the new boot image to the tftpd directory, default is /var/lib/tftpboot
$ sudo cp ~/mod-kit/output/06-kernel-mod.bin /var/lib/tftpboot/kernel.bin -
assign to your Linux PC ethernet interface the IP address 10.10.10.3, replace eth0 with your ethernet device name
sudo ifconfig eth0 10.10.10.3 -
connect an ethernet cable to your PC and to one of LAN ports on the router
-
connect the USB TTL serial adapter to your PC and to the router and fire up a terminal emulator with parameter 115200N8
-
power-up the router
-
when the string "Please choose the operation:" appears press "4" to enter U-Boot Command Line interface
-
load the modified kernel in memory with the "tftp 81000000 kernel.bin" command:
MT7621 # tftp 81000000 kernel.bin netboot_common, argc= 3 NetTxPacket = 0x87FE4480 ... ###################################################### 32 MB reveived # done Bytes transferred = 33554432 (2000000 hex) NetBootFileXferSize= 02000000 MT7621 # -
boot with the "bootm" command:
MT7621 # bootm ## Booting image at 81000000 ... Image Name: =01.01.02.090 Image Type: MIPS Linux Multi-File Image (lzma compressed) Data Size: 21528524 Bytes = 20.5 MB Load Address: 80001000 Entry Point: 8000f540 Contents: Image 0: 1966004 Bytes = 1.9 MB Image 1: 19562496 Bytes = 18.7 MB Verifying Checksum ... OK Uncompressing Multi-File Image ... OK ## Transferring control to Linux (at address 8000f540) ... ## Giving linux memsize in MB, 128 Starting kernel ... -
you can check that you have the new boot image logging, on the serial interface, as user root with password 5/4jp6 you will successfully login without the infamous Challenge Code
-
to login from the Linux PC, with ssh, you have to change the IP address on the PC, for example:
$ sudo ifconfig eth0 192.168.1.100 $ ssh [email protected] [email protected]'s password: hacking-gemtek modified boot image dom 18 ago 2019, 16.42.24, CEST -sh: export: 11acaddr: bad variable name #
The string "hacking-gemtek modified boot image dom 18 ago 2019, 16.42.24, CEST" has been generated by the firmware modification kit that has created (pre-image-script.sh) the /etc/motd file, that is displayed by default during login and can be used to identify the modified kernel.
The error "-sh: export: 11acaddr: bad variable name" is because the /etc/profile default script includes a call to fw_printenv, that prints U-Boot environment variables, and these variables are converted to shell variables, but the 11acaddr U-Boot variable has an illegal name (starts with a digit) in the shell /bin/sh
We could write the new boot image in the NAND Flash EPPROM using the U-Boot CLI, but it would be safer to use router's command to do this kind of "firmware upgrade", we can try to find if the router includes some firmware upgrade command:
$ find squashfs-root/ -type f -print | grep -i upgrade
squashfs-root/etc/conf/user/http_upgrade.conf
squashfs-root/etc/conf/user/upgrade.conf
squashfs-root/usr/factory/test_upgrade
squashfs-root/bin/fwupgrade
squashfs-root/www/asp/management_rm_ftp_upgrade.asp
The upgrade binary command seems to be /bin/fwupgrade*, but we don't know how to use it, we can search if and how it is used in the router:
$ find squashfs-root/ -type f -print | xargs grep fwupgrade
squashfs-root/usr/factory/test_upgrade:# fwupgrade mtd5 /tmp/$FILE
squashfs-root/usr/factory/test_upgrade:# fwupgrade mtd6 /tmp/$FILE
Binary file squashfs-root/bin/ipkg matches
Binary file squashfs-root/bin/msg_center matches
$
$ strings squashfs-root/bin/ipkg | grep fwupgrade
/bin/fwupgrade mtd%d %s %ld %ld
$
$ strings squashfs-root/bin/msg_center | grep fwupgrade
check_fwupgrade
check_fwupgrade
$
We can also see strings embedded in the fwupgrade binary to understand what it does, some output modified to increase clarity:
$ strings -n10 squashfs-root/bin/fwupgrade
...
'echo FWupgStart > /dev/led_gpio
#
if grep -q rootfs /proc/mtd;
then
(find / -type f -name busybox -o -name 'nand*' -o -name 'fw*' | xargs cat) &> /dev/null;
(find / -type f -name 'cms*' -o -name curl -o -name reboot | xargs cat) &> /dev/null;
(find /etc/init.d -type f | xargs cat) &> /dev/null;
(find / -type f -name libcmc.so -o -name .so. -o -name libmc.so -o -name libxIpc.so | xargs cat) &> /dev/null;
(find / -type f -name 'libpthread.so*' -o -name 'libc.so*' -o -name 'libgcc_s.so*' | xargs cat) &> /dev/null;
fi;
#
flash_eraseall /dev/%s
nandwrite -m -p /dev/%s %s
echo FWupgEnd > /dev/led_gpio
#
infile=%s;
skip=%s;
len=%s;
bs=131072;
( dd bs=1 skip=$skip count=0;
dd bs=$bs count=$(($len / $bs));
dd bs=$(($len %% $bs)) count=1
) < $infile | nandwrite -m -p /dev/%s
#
/dev/mtd%d
/tmp/firmware.out
It seems that the usage is: fwupgrade mtdn boot-image-file [startaddress] [endaddress] where:
- mtdn is the mtd device number n (for example /dev/mtd6)
- boot-image-file is our boot image file
- startaddress seems optional and probably is used to skip initial content of the boot image file
- endaddress seems optional and probably is used to limit the amount of bytes used of the boot image file
There is an U-Boot variable, available as shell variable, mtddevnum (currently equal to 6) that probably indicates the current flash EEPROM boot partition, so to upgrade the router, after tftp booting, we can execute the following commands:
$ # my current IP address is 192.168.1.100 on ethernet interface
$ ssh [email protected]
[email protected]'s password:
hacking-gemtek modified boot image dom 18 ago 2019, 16.42.24, CEST
-sh: export: 11acaddr: bad variable name
# cd /tmp
# tftp -r kernel.bin -l kernel.bin -g 192.168.1.100
kernel.bin 100% |***************************************************************************************************************| 32768k 0:00:00 ETA
# echo $mtddevnum
6
# fwupgrade mtd6 kernel.bin
Erasing 128 Kibyte @ 2000000 - 100% complete.
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
...
Writing data to block 254 at offset 0x1fc0000
Writing data to block 255 at offset 0x1fe0000
# reboot
We do a normal reboot, without entering U-Boot command line and then try to logon with ssh:
$ ssh [email protected]
[email protected]'s password:
hacking-gemtek modified boot image dom 18 ago 2019, 16.42.24, CEST
-sh: export: 11acaddr: bad variable name
#
We can confirm that we successfully replaced the boot image with our own modified version as shown by the "hacking-gemtek modified boot image dom 18 ago 2019, 16.42.24, CEST" login message. (Sorry for the date format, my Ubuntu sometimes speaks Italian!)
I am happy to be contacted about this project, my contact details are:
| Item | Content |
|---|---|
| Author's name | Valerio Di Giampietro |
| [email protected] (yes it's a valid email address!) | |
| Personal web site | http://va.ler.io (aka http://digiampietro.com) |
| http://it.linkedin.com/in/digiampietro | |
| http://twitter.com/valerio | |
| http://facebook.com/digiampietro |
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent