WRT54G (Revival)
Inhaltsverzeichnis
Allgemeines
Wie so oft kann ich mich von alter ausgedienter Hardware nicht trennen und ueberlege was man mit so einem Schaetzchen wie dem WRT54G(L V1.1) noch so tun kann. Die Nutzung als AP ist nicht mehr zeitgemaesz, aber als Client kann ich mir einen Einsatz noch gut vorstellen. Abgesehen von der Tatsache der ein Raspi doch etwas flinker ist, braucht man sich bei einem WRT54G keine Sorgen um sterbende SD-Karten machen. Und um ein paar kleine Routinen und Sensoren im Netzwerk einzubinden reicht die Performance der WRT54G in vielen Faellen.
Durch ein paar kleine Hardwareeingriffe kann man den WRT54G mit einem SD-Kartenleser, mit 2 seriellen Schnittstellen und mit einem USB-Port (V1.1) ausstatten. Ein Variante, die ich im Netz gefunden habe integriert in das Gehäuse noch einen Arduino-MikroPro und eröffnet so ein riesiges Feld an Moeglichkeiten.
HINWEIS: Das hier beschriebene Vorgehen der systematischen Analyse einer (Embedded-)Hardware laesst sich natuerlich vorgangsgleich auf andere Hardware anwenden. Es ist fuer mich oft der einzige (richtige) Weg, um ein tieferes Verstaendnis von Zusammenhaengen zu erkennnen. Das immer wieder erstaunliche an der Sache ist, dass ab einem bestimmten Grad des Eintauchens sich viele Forenfragen in Luft aufloesen. Oder anders ausgedrueckt, macht man sich einmal diese Arbeit weisz man auf einmal was man tut und probiert nicht einfach nur rum.
DD-WRT vs. OpenWRT
Ich bin hin- und hergerissen. Mit OpenWRT waren die Erfahrungen (Kamikaze, White Russian) aber eher schlecht. Danach habe ich lange Zeit DD-WRT (v3.0-r36247 std (06/29/18) KERNEL 2.4.37) benutzt und es ging so. Aber die 6 APs (mittlerweile durch Ubiquiti-APs ersetzt) im Haus haben immer irgendwie gezickt.
Jetzt wo der AP-Modus keine Rolle mehr spielt und MMC, JFFS, CIFS, USB, TTYSXX und das Aufspielen neuer Software eine groeszere Rolle spielen, war ich mit DD-WRT irgendwie in einer gefuehlten Sackgasse. DD-WRT bietet zum Beispiel Untersutzung von ip (a und r aber nicht n) parallel zu ifconfig, route und arp, aber gibt z.B. keine Fehlermeldungen bei Befehlen wie mount, mkdir. Auch eine Hilfe sucht man vergebens. Da hilft oft nur ein Blick in den SourceCode was die Software tut, oder halt nicht wie gewohnt funktioniert.
Der Support (DD-WRT) fuer CIFS, MMC und JFFS sind zwar in der WebGUI angeboten, lassen sich auch konfigurieren, aber CIFS und MMC lieszen sich nicht mounten und die Unterstuetzung von JFFS war auf der Konsole nicht auffindbar.
Bei OpenWRT Backfire war es mir bisher nicht moeglich den WLAN-Treiber fuer den BCM4306 zum Laufen zu bringen. Um da einen Schritt vorwaerts zu machen muss ich erst eine paar zurueck machen.
Um schneller vergleichen zu koennen habe ich einen Router mit Backfire 10.03.1 und den anderen mit DD-WRT v3.0 36247 laufen.
Aber der Reihe nach.
Hardware
Um sich eine bessers Bild von den Zusammenhaengen zu machen hier nochmal die Hardware im Ueberblick.
CPU
Label: Broadcom BCM5352EKPBG
DD-WRT:~# cat /proc/cpuinfo system type : Broadcom BCM5352 chip rev 0 processor : 0 cpu model : BCM3302 V0.8 BogoMIPS : 199.47 wait instruction : no microsecond timers : yes tlb_entries : 32 extra interrupt vector : no hardware watchpoint : no ASEs implemented : VCED exceptions : not available VCEI exceptions : not available
Hinweise:
Die 199.47 BogoMIPS lassen auf 200 MHz und ein Verhältnis von 1 schlieszen.
Der CPU-Kern BCM3302 findet auch in den SoC BCM4712, BCM53xx und BCM5836 Verwendung (siehe dazu http://oleg.wl500g.info/sdram.html)
SDRAM
Label: Winbond W9412G6JH-5
Size: 2M x 4 BANKS * 16 BITS DDR SDRAM => 16 MebiByte
CELL-Array (Bank) Konfiguration: 4096 * 512 * 16 = 33.554.432 Bit mal 4 Baenke = 134.217.728 Bit = 16.777.216 Byte
Adressraum: 0x000000 - 0xFFFFFF
DD_WRT:~# nvram show|grep sdram sdram_config=0x0062 sdram_refresh=0x0000 sdram_ncdl=0xfe0008 sdram_init=0x010b DD-WRT:~# free total used free shared buffers cached Mem: 13004 11808 1196 0 1452 5180 -/+ buffers/cache: 5176 7828 Swap: 0 0 0
Nuetzlicher Link:
Flash
Label: MXIC (Macronix) MX29LV320EBTI-70G
Size: 4 MebiByte of 8 Bits each or 2 MebiBytes of 16
Irgendwo habe ich gelesen, dass der WRT54G den 16 Bit-Zugriff nutzt.
Adressierung: 0x000000 bis 0x3FFFFF
Sector Structure - 8K-Byte x 8 and 64K-Byte x 63• Extra 256-Byte sector for securit
DD-WRT:
Flash device: 0x400000 at 0x1c000000 bootloader size: 262144 Physically mapped flash: Filesystem type: squashfs, size=0x2c8102 partition size = 2930688 Creating 4 MTD partitions on "Physically mapped flash": 0x00000000-0x00040000 : "cfe" 0x00040000-0x003f0000 : "linux" 0x00124800-0x003f0000 : "rootfs" mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-only 0x003f0000-0x00400000 : "nvram" sflash not supported on this router
Label cfe: 256 MebiByte (262.144 Byte) Bootloader Label linux: 3.776 MebiByte (3.866.624) darin enthalten (am Ende) 2.862 MebiByte (2.930.688) rootfs Label nvram: 64 KibiByte (65536) Configvariablen
Was man hier jetzt erkennen kann, dass das eigentliche Image (.bin,.trx) sich im MTD-Device mit dem Label linux (inkl. dem Device rootfs) befindet. Fuer das Image bleiben 4 MebiByte minus 256 MebiByte (CFE Bootloader) minus 64 KibiByte (nvram) uebrig. Die Squashfs-Size (s.o.) 0x2c8102 (2.916.610 Byte) ist vermutlich die belegte Groesze in der linux-Partition.
Mit dem Programm mtd (http://www.linux-mtd.infradead.org/archive/tech/faq.html memory technology device) werden die Partitionen gemountet/administriert/...
DD-WRT:~# ls -l /dev/mtd/ crw-rw-rw- 1 root root 90, 0 Jan 1 01:00 0 cr--r--r-- 1 root root 90, 1 Jan 1 01:00 0ro crw-rw-rw- 1 root root 90, 2 Jan 1 01:00 1 cr--r--r-- 1 root root 90, 3 Jan 1 01:00 1ro crw-rw-rw- 1 root root 90, 4 Jan 1 01:00 2 cr--r--r-- 1 root root 90, 5 Jan 1 01:00 2ro crw-rw-rw- 1 root root 90, 6 Jan 1 01:00 3 cr--r--r-- 1 root root 90, 7 Jan 1 01:00 3ro DD-WRT:~# ls -l /dev/mtdblock/ 0 1 2 3 DD-WRT:~# ls -l /dev/mtdblock/ brw-rw-rw- 1 root root 31, 0 Jan 1 01:00 0 brw-rw-rw- 1 root root 31, 1 Jan 1 01:00 1 brw-rw-rw- 1 root root 31, 2 Jan 1 01:00 2 brw-rw-rw- 1 root root 31, 3 Jan 1 01:00 3 DD-WRT:~# mtd Usage: mtd [<options> ...] <command> [<arguments> ...] <device> The device is in the format of mtdX (eg: mtd4) or its label. mtd recognizes these commands: unlock unlock the device resetbc reset bootcounter for WRT1900AC/WRT1200AC/WRT1900ACv2 erase erase all data on device write <imagefile>|- write <imagefile> (use - for stdin) to device Following options are available: -q quiet mode (once: no [w] on writing, twice: no status messages) -r reboot after successful command -f force write without trx checks -e <device> erase <device> before executing the command Example: To write linux.trx to mtd4 labeled as linux and reboot afterwards mtd -r write linux.trx linux
CFE (Common Firmware Environment) Bootloader
CFE ist nicht nur der Bootloader (fuer Broadcom), sondern auch ein Interface fuer die Hardware.
Auf Github befindet sich der Sourcecode.
Definition [2] Common Firmware Environment (CFE), pronounced as 'cafe', is a firmware interface and bootloader developed by Broadcom for 32-bit and 64-bit system- on-a-chip systems. It is intended to be a flexible toolkit of CPU initialization and bootstrap code for use on embedded processors (typically running on MIPS32/64 instruction set CPUs found in Broadcom SoCs). It is roughly analogous to the BIOS on the IBM PC platform. Its source-code is available on Open source license from Broadcom. Common embedded system alternatives include Das U-Boot.
Da das CFE mit dem BIOS bei einem PC vergleichbar ist, kann man sich vorstellen, dass sollte da ein "Defekt" vorliegen, die einfachen Mechanismen zum wiederherstellen der Embedded Hardware schwieriger werden. Manchmal wird in diesem Zusammenhang auch schon von "bricked" gesprochen. Dies ist aber nicht ganz richtig. Es bleiben in diesem Fall noch mindestens 2 Moeglichkeiten der Rettung: Erstens JTAG und zweitens Flash ausloeten und extern behandeln!
Hinweis: Mit der zweiten Moeglichkeit habe ich mal ein Panasonic-Notebook mit verlorenem BIOS-Passwort wiederbelebt, obwohl selbst Panasonic behauptet hat, dass es da keine Rettung gaebe, da ihre BIOSe sicher seien und keine (SW-)Moeglichkeit des Passwortruecksetzens besteht. Also wer so einen "hoffnungslosen" Fall hat, dem kann ich gerne weiterhelfen.
Interessant ist auch der Hinweis im Wiki, dass CFE auch in SmartTVs von LG und Samsung Einsatz findet. Sogar Amiga (meinen hab ich noch:-))) NG nutzt ihn.
Linux (Image/Squashfs)
Am Beispiel eines (alten) Images sei die Konvertierung von bin nach trx (und ggf. zuerueck) gezeigt.
dd if=lede-17.01.7-brcm47xx-legacy-linksys-wrt54g-squashfs.bin of=lede-17.01.7-brcm47xx-legacy-linksys-wrt54g-squashfs.trx bs=32 skip=1
Mit diesem Befehl werden die ersten 32 Byte des Bin-Images entfernt.
worker:/home/chris/Downloads # ll lede* -rw-r--r-- 1 chris users '''4001824''' Jul 27 21:22 lede-17.01.7-brcm47xx-legacy-linksys-wrt54g-squashfs.bin -rw-r--r-- 1 root root '''4001792''' Jul 29 22:59 lede-17.01.7-brcm47xx-legacy-linksys-wrt54g-squashfs.trx worker:/home/chris/Downloads # hexdump -C lede-17.01.7-brcm47xx-legacy-linksys-wrt54g-squashfs.bin|more 00000000 57 35 34 47 00 00 00 00 13 06 16 04 47 01 55 32 |W54G........G.U2| 00000010 4e 44 00 06 1f 00 00 00 00 00 00 00 00 00 00 00 |ND..............| 00000020 48 44 52 30 00 10 3d 00 3d a6 e1 7b 00 00 01 00 |HDR0..=.=..{....| 00000030 1c 00 00 00 24 09 00 00 00 54 12 00 1f 8b 08 00 |....$....T......| 00000040 00 00 00 00 02 03 8d 57 5d 68 1c d7 15 fe e6 ee |.......W]h......| 00000050 ac b4 fa 4b 47 ab 95 b3 8e 55 32 d7 ba 5a 6d bd |...KG....U2..Zm.| 00000060 2e dd b8 ae ab 87 2d 9d ae 64 23 8a 1f d6 3f 69 |......-..d#...?i| 00000070 4d 29 61 51 44 f1 43 a0 72 d3 80 1f fa 30 28 4a |M)aQD.C.r....0(J| 00000080 11 45 78 36 60 83 1e 4c 59 d6 92 a3 94 45 2b 3b |.Ex6`..LY....E+;| 00000090 4a ea 42 9d 2c c2 6d 5a 68 a1 50 43 fd d2 22 42 |J.B.,.mZh.PC.."B| 000000a0 1e f2 54 f2 d0 36 6e 42 3b fd ce ec 6c ad 3a 36 |..T..6nB;...l.:6| 000000b0 cd c2 72 67 ee cf 39 df fd ce 39 df bd b3 e0 7f |..rg..9...9.....| 000000c0 be f4 87 f0 f6 b8 83 b5 56 06 eb ad 2c ae b7 c6 |........V...,...| 000000d0 f0 5a ab ea f7 97 80 19 0d 3f 59 3a 3f bc 6e e0 |.Z.......?Y:?.n.| 000000e0 f7 94 b2 4f ff da 00 1b 2b c0 72 d3 c6 ba 6b 63 |...O....+.r...kc| 000000f0 c9 3d 94 ba 8e 8f 43 37 03 fe 2c df f1 30 36 6c |.=....C7..,..06l| 00000100 cc 72 51 65 e1 a6 a5 6f f1 27 c3 50 48 19 7b 39 |.rQe...o.'.PH.{9| 00000110 af fc 44 da 98 5a 45 ed bc 9a 86 85 d3 39 ec a6 |..D..ZE......9..| worker:/home/chris/Downloads # hexdump -C lede-17.01.7-brcm47xx-legacy-linksys-wrt54g-squashfs.trx|more 00000000 48 44 52 30 00 10 3d 00 3d a6 e1 7b 00 00 01 00 |HDR0..=.=..{....| 00000010 1c 00 00 00 24 09 00 00 00 54 12 00 1f 8b 08 00 |....$....T......| 00000020 00 00 00 00 02 03 8d 57 5d 68 1c d7 15 fe e6 ee |.......W]h......| 00000030 ac b4 fa 4b 47 ab 95 b3 8e 55 32 d7 ba 5a 6d bd |...KG....U2..Zm.| 00000040 2e dd b8 ae ab 87 2d 9d ae 64 23 8a 1f d6 3f 69 |......-..d#...?i| 00000050 4d 29 61 51 44 f1 43 a0 72 d3 80 1f fa 30 28 4a |M)aQD.C.r....0(J| 00000060 11 45 78 36 60 83 1e 4c 59 d6 92 a3 94 45 2b 3b |.Ex6`..LY....E+;| 00000070 4a ea 42 9d 2c c2 6d 5a 68 a1 50 43 fd d2 22 42 |J.B.,.mZh.PC.."B| 00000080 1e f2 54 f2 d0 36 6e 42 3b fd ce ec 6c ad 3a 36 |..T..6nB;...l.:6| 00000090 cd c2 72 67 ee cf 39 df fd ce 39 df bd b3 e0 7f |..rg..9...9.....| 000000a0 be f4 87 f0 f6 b8 83 b5 56 06 eb ad 2c ae b7 c6 |........V...,...| 000000b0 f0 5a ab ea f7 97 80 19 0d 3f 59 3a 3f bc 6e e0 |.Z.......?Y:?.n.| 000000c0 f7 94 b2 4f ff da 00 1b 2b c0 72 d3 c6 ba 6b 63 |...O....+.r...kc| 000000d0 c9 3d 94 ba 8e 8f 43 37 03 fe 2c df f1 30 36 6c |.=....C7..,..06l| 000000e0 cc 72 51 65 e1 a6 a5 6f f1 27 c3 50 48 19 7b 39 |.rQe...o.'.PH.{9| 000000f0 af fc 44 da 98 5a 45 ed bc 9a 86 85 d3 39 ec a6 |..D..ZE......9..| 00000100 8e 1a cf b1 ca d3 29 78 18 31 f6 ea 88 b5 1f 67 |......)x.1.....g| 00000110 54 da 03 f6 23 af d2 35 1a d8 f5 3d 7c c0 bf 9f |T...#..5...=|...|
Den Header des Bin-Images (57 35 34 47 00 00 00 00 13 06 16 04 47 01 55 32 4e 44 00 06 1f 00 00 00 00 00 00 00 00 00 00 00) muss ich mir bei Gelegenheit mal noch genauer anschauen.
Fuer die kleine Image-Analyse ist das Programm 'binwalk' recht nuetzlich.
worker:/home/chris/Downloads # binwalk dd-wrt.v24_std_generic_36247.bin DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 TRX firmware header, little endian, image size: 3858432 bytes, CRC32: 0xA663F3EF, flags: 0x0, version: 1, header size: 28 bytes, loader offset: 0x1C, linux kernel offset: 0x9D0, rootfs offset: 0xE4800 28 0x1C gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date) 2512 0x9D0 LZMA compressed data, properties: 0x6E, dictionary size: 33554432 bytes, uncompressed size: 2985984 bytes 935936 0xE4800 Squashfs filesystem, little endian, DD-WRT signature, version 3.0, size: 2916610 bytes, 690 inodes, blocksize: 131072 bytes, created: 2018-06-29 09:09:45 worker:/home/chris/Downloads # binwalk dd-wrt.v24_mini_generic_44715.bin DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 TRX firmware header, little endian, image size: 3375104 bytes, CRC32: 0x9886060E, flags: 0x0, version: 1, header size: 28 bytes, loader offset: 0x1C, linux kernel offset: 0xA34, rootfs offset: 0xCF400 28 0x1C gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date) 2612 0xA34 LZMA compressed data, properties: 0x6E, dictionary size: 33554432 bytes, uncompressed size: 2756608 bytes 848896 0xCF400 Squashfs filesystem, little endian, DD-WRT signature, version 3.0, size: 2521285 bytes, 650 inodes, blocksize: 131072 bytes, created: 2020-11-03 04:01:08 worker:/home/chris/Downloads # hexdump -C dd-wrt.v24_mini_generic_44715.bin |more 00000000 48 44 52 30 00 80 33 00 0e 06 86 98 00 00 01 00 |HDR0..3.........| 00000010 1c 00 00 00 34 0a 00 00 00 f4 0c 00 1f 8b 08 00 |....4...........| 00000020 00 00 00 00 02 03 95 58 5d 6c 14 d7 15 3e 33 b3 |.......X]l...>3.| 00000030 eb dd b5 dd 74 d6 ec 3a a6 71 61 27 7b 67 3d b1 |....t..:.qa'{g=.| 00000040 f3 b0 20 8b 6e ab 7d 18 d6 b6 ba a5 a9 e4 90 54 |.. .n.}........T| 00000050 72 db 3c 58 04 28 aa 2a 95 a4 50 f1 40 db 09 01 |r.<X.(.*..P.@...| 00000060 e2 46 0e b3 a8 04 f9 a1 55 b6 36 6b d6 68 61 96 |.F......U.6k.ha.| 00000070 14 42 2b 85 c6 b5 b0 01 a9 aa 48 db a4 95 da 07 |.B+.......H.....|
Also haben wir nach dem BIN-Header (s.o.) auch noch einen TRX-Header (28 Bytes: 48 44 52 30 00 80 33 00 0e 06 86 98 00 00 01 00 1c 00 00 00 34 0a 00 00 00 f4 0c 00)
Ab 0x1C steht der gzip-header beginnend mit der Magic Number (1f 8b). Siehe dazu weiter
Um die Analyse weiter zu treiben habe ich noch ein paar Zusatzpakete unter OpenSuSE (15.3) installiert.
zypper in openocd zypper in sasquatch zypper in bcm43xx-firmware zypper in pullin-bcm43xx-firmware
Um sasquatch zu installieren war bei mir noch ein Repo hinzuzufuegen.
zypper ar "https://download.opensuse.org/repositories/devel:/tools/openSUSE_Leap_15.3/" DEVEL
Mit sasqautch war nun auch binwalk mit dem extrahieren der SquachFS-Partition erfolgreich.
binwalk --extract dd-wrt.v24_std_generic_44715.bin worker:/home/chris/Downloads # ll _dd-wrt.v24_std_generic_44715.bin.extracted/ total 8944 -rw-r--r-- 1 root root 4816 Jul 31 09:19 1C -rw-r--r-- 1 root root 2748416 Jul 31 09:19 A34 -rw-r--r-- 1 root root 3622348 Jul 31 09:19 A34.7z -rw-r--r-- 1 root root 2772622 Jul 31 09:19 CF400.squashfs drwxr-xr-x 15 root root 4096 Nov 3 2020 squashfs-root
Die Namen der extrahierten Dateien ist die hexadezimale Position im bin-File. Zusaetzlich zu sind die Inhalte bei A34 und CF400 noch dekomprimiert angelegt.
worker:/home/chris/Downloads/_dd-wrt.v24_std_generic_44715.bin.extracted # 7z l A34.7z 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=de_DE.UTF-8,Utf16=on,HugeFiles=on,64 bits,16 CPUs Intel(R) Xeon(R) CPU X5570 @ 2.93GHz (106A5),ASM) Scanning the drive for archives: 1 file, 3622348 bytes (3538 KiB) Listing archive: A34.7z -- Path = A34.7z Open WARNING: Can not open the file as [7z] archive Type = lzma Date Time Attr Size Compressed Name ------------------- ----- ------------ ------------ ------------------------ ..... 2748416 A34 ------------------- ----- ------------ ------------ ------------------------ 2748416 3622348 1 files Warnings: 1
unsquashfs fuehrte hier nicht zum Erfolg. Da die Magic Number von 0x73717368 auf 0x74717368 (Grrrr!) geaendert wurde. Siehe hierzu [3]
worker:/home/chris/Downloads/_dd-wrt.v24_std_generic_44715.bin.extracted # sasquatch -i CF400.squashfs SquashFS version [3.0] / inode count [700] suggests a SquashFS image of the same endianess Non-standard SquashFS Magic: hsqt Parallel unsquashfs: Using 1 processor Trying to decompress using default gzip decompressor... Trying to decompress with lzma... Trying to decompress with lzma-adaptive... Detected lzma-adaptive compression 654 inodes (693 blocks) to write squashfs-root dir_scan: failed to make directory squashfs-root, because File exists created 0 files created 0 directories created 0 symlinks created 0 devices created 0 fifos
NVRAM
NonVolatileRAM. Die (Config-)Variablen zur Einstellung der Linux-Umgebung auf der (Embedded-)Hardware werden zur Laufzeit im RAM abgelegt und beim Booten aus der Partition mit dem Label nvram geladen. Das erklaert auch warum man nach einer Aenderung einer Variablen mit 'nvram commit' die Aenderungen in die Flash-Partitiion uebertraegt und somit 'nichtfluechtig' macht. Vergisst man nach einer Variablenaenderung das Committen (sich bekennen, verpflichten: Sinn?) geht die Aenderung bei einem Reboot verloren.
Weiterfuehrende Analysen/Techniken
https://www.heise.de/ct/ausgabe/2013-21-Hinter-den-Kulissen-eines-Router-Botnets-2313886.html