Fanvil X6 VoIP-Telefon zerflasht, suche Recovery-Möglichkeit

[Fan[vil]boy (Gast)]

Moin zusammen,

ich habe mir vor Kurzem eines meiner Fanvil X6 VoIP-Phones zerschossen, 
als ich mir das aktuellste Firmware-Upgrade vom Hersteller gezogen habe, 
das aber wohl mit falschen Hardware IDs bestückt war und eigentlich für 
ein anderes Modell ist. Das Telefon hat die Firmware-Datei aber 
gefressen und brav ins NAND geflasht (beinhaltet 2 Firmware-Stände, das 
aktuell aktive und das Update überschreibt den inaktiven Firmware-Stand 
und markiert anschließend diesen als aktiv ab dem nächsten Reboot), nach 
dem Neustart war dann tote Hose am Telefon.

Nachdem ich auf das Mainboard die UART-Schnittstelle mit Pins bestückt 
habe, konnte ich zumindest sehen, dass der Bootprozess (BOOT1, BOOT2) 
noch tut und bis zum Entpacken des (leider falschen) Kernels passt.

Interessant ist hier die kurze Pause beim Output "Press any key to enter 
download mode ...", hier springt er beim Senden eines Chars über die 
UART mit folgender Ausgabe in den download-Modus:

Entered UART loader mode
Please disconnect terminal and run download.sh

Hier bleibt der dann auch stehen und wartet wohl auf irgendwelche 
Kommandos, Kernel über die UART oder irgendwelche Firmware-Bestandteile.

Leider ist Fanvil nicht Willens (oder deren Support nicht fähig), die 
download.sh herauszurücken. Bleibt also nur noch das Reverse Engineering 
des Bootloader-Codes um zu verstehen, welchen Input er im download-Modus 
erwartet.

Die Boot-Partitionen (BOOT1, BOOT2) konnte ich von meinem zweiten 
Telefon ziehen, über die UART landet man hier netterweise in einer 
Terminal-Session im Linux ohne Passwort und mit uid 0 :)

Leider hört bei mir das Wissen auf, mit Ghidra konnte ich das 
ARMv7-Firmware-File analysieren und auch feststellen, dass das an 
Adresse 0x4000 geladen wird (damit passen auch die Referenzen auf die 
ganzen Strings), die Funktion mit den ensprechenden Strings zur 
download.sh habe ich auch gefunden. Ebenfalls konnte ich mutmaßen, über 
welche Funktion Chars/Strings über die UART ein- und ausgegeben werden.
Allerdings hört hier dann mein Wissen auf und auch stundenlanges 
Mnemonic- und C-Code-Lesen brachte mir hier keine Erleuchtung, was der 
nun im download-Modus an Eingabeparameter erwarten könnte.

Eventuell findet sich hier jemand, der ARM-Erfahrung hat und mir hier 
aus der Patsche helfen kann. Den NAND-Flash will ich erst mal nicht vom 
Mainboard holen, weil TSOP48 mit 0.5mm Pitch - und dann müsste ich auch 
erst mal überlegen, was ich wo (und wie) im NAND reinschreiben will.

Den Dump der relevanten Partition habe ich angehängt.

Hier noch das Bootlog bis zum CPU-Crash wegen des falschen Kernels:

BRCM boot1.UNKNOWN
STICKYBITS=0x00000080
STRAPS=0x2c000040
NAND: ID: 0xef 0xf1
(B)

Found valid partition table at 0x00000000
(C)
(D)
magic 0x0000babe
size  0x00009b24
Checksum PASSED: 0x003ec067
imageType   0x00000080
encryptType 0x00000000
 OTP14:0x00000000
OTP key length 0x00000000
(E)
(I)
(M)
No DSA Key.  No authentication required.
(N)
Image not encrypted
(S)
disPerh 0x00000028
(b)
Erasing ARAM

Broadcom Linux NAND boot2.UNKNOWN
NAND: (DMA) ID: 0xef 0xf1
CFG_GLOBAL_FLASH_SIZE_MB: 128
  Strap Extra Addr Cycle: 0
  Strap   Page Size Bits: 11 (2K)
  Strap  Block Size Bits: 17 (128K)

Press any key to enter download mode or bring up the menu[................]
Skipping download mode

FLASH (MB): 0x00000080

Found valid partition table at 0x00000000

Reading OTA Control block...
Control Block Contents
ActiveImage=0
Hdr0 <============================================== Active Image (Next Reboot)
kcrc   = 0x970ec400
ksize  = 0x00261018
fcrc   = 0x2f92d83a
fsize  = 0x02580000
date    = Mon Sep 28 15:04:44 2020
name    = ota_BCM911188SV_x6_v6_5_.bin
hdr crc  = 0x7058a441 (from side header field)
         = 0x7058a441 (by crc'ing side header data)
Hdr1
kcrc   = 0xca78f9f8
ksize  = 0x00223864
fcrc   = 0xa1d4c10c
fsize  = 0x02240000
date    = Mon Aug 17 16:44:14 2020
name    = ota_BCM911198SV_x6_v6_3_3.bin
hdr crc  = 0xf88fec33 (from side header field)
         = 0xf88fec33 (by crc'ing side header data)

ota ctrl block hdr crc = 0xb5ad32d7 (from block hdr field)
                       = 0xb5ad32d7 (by crc'ing block hdr data)
Booting side 0

Booting Linux...
Kernel magic OK
kernelPartition 0x07
kstart 0x0d000000
kend 0x0d261018
kcopysize 0x00261018
kernelStart 0x0d000000
Copying kernel to SDRAM ...................
completed
Branch to kernel at 0x0d000000
memstart 0x00200000
memrsvd 0x00200000
memsize 0x03e00000
Constructed command line 'console=ttyAMA0,115200n8 vmalloc=256m mtdparts=bcm_umi-nand:0x000a0000(boot1),0x000a0000(boot2),0x000a0000(ctrl),0x00220000(nvdata),0x00080000(logo1),0x00080000(logo2),0x00f00000(userdata),0x00300000(k0),0x00300000(k1),0x03000000(root0),0x03000000(root1) ubi.mtd=9,2048 root=ubi0:rootfs rootfstype=ubifs rw bootmemheap'
 MM_IO_BASE_GPIO0 = 80004000
0x80015000 = 70007
0x80015004 = 20002
0x80015008 = 0
0x8001500c = 30003
0x80015010 = c000c
0x80015014 = 20002
0x80015018 = 80008
0x8001501c = 0
0x80015020 = 0
0x80015024 = 0
Testing LOGO ~~~~~~
calculatedCheck sum = 8776; read checksum=ffffffff;
LOGO found
logoHdr->areaSize = 1024
logoHdr->startX = 0
logoHdr->startY = 0
logoHdr->width = 128
logoHdr->height = 64
logoHdr->selected = 0
Machine ID is 0x00000a2c
Uncompressing Linux... done, booting the kernel.