Hobbyproject: wek je IP-cam weer tot leven

Enige tijd geleden heb ik eens een kleine ip-camera gekocht. Bij aankomst bleek het apparaat helaas niet te werken en kreeg ik een nieuwe opgestuurd. Uiteraard had ik de niet-werkende niet weggegooid en het bleef kriebelen om deze alsnog aan de praat te krijgen. Het lampje bij de UTP-plug knipperde namelijk wel…

Allereerst ging ik eens op zoek naar meer informatie over de chip die gebruikt wordt. Op de artikelpagina werd gesproken over Hi3518E, wat me al snel bij een datasheet van HiSilicon bracht. Leuke informatie over de chip, maar bracht me nog niet veel verder. Een veel interessanter topic op een forum over een soortgelijke camera gaf veel nuttiger informatie. De camera bleek namelijk een open poort te hebben (poort 9527), waar je naar kunt telnetten en vervolgens root toegang kunt krijgen. Zie onderstaande stappen:

telnet 192.168.1.10 9527
login as admin
hit enter for password
shell (na een enter kom je op een lege regel)
telnetd -f

Maak nu een nieuwe telnetverbinding naar poort 23

telnet 192.168.1.10 23 login: root
password: xmhdipc

Op de werkende IP-camera was het mogelijk om dit te doen. Ik kon vervolgens ook bijvoorbeeld dhcp aanzetten, aangezien het vast ingestelde ip mij niet handig uitkwam, en bij meerdere dezelfde camera’s is het helemaal niet handig als ze ook nog eens hetzelfde ip hebben.

DHCP aanzetten kan op de volgende manier:

echo 1 > /mnt/mtd/Config/dhcp.cfg

Uiteraard raak je dan je verbinding kwijt, omdat de camera een nieuw ip gaat opvragen via dhcp.

Terug naar de defecte camera

Op hetzelfde forum kwam ik er ook achter dat er een seriele poort op de camera zit. 3 pinnetjes op de printplaat zijn de RX, TX and GND, die je weer kunt aansluiten op een USB->serieel converter. Na het gokken dat de aansluiting van de pinnen hetzelfde was als de afbeelding op het forum, had ik opeens een bootproces op mijn scherm zodra ik de (defecte) camera aanzette. Na het bootproces was het ook afgelopen met de interactie, maar het bericht “Press Ctrl+C to stop autoboot” gaf hoop.

Nog een keer opstarten en snel genoeg op Ctrl+C drukken gaf toegang tot de U-boot omgeving. Deze omgeving was nieuw voor mij, maar het blijkt een bootloader te zijn die je de mogelijkheid geeft om het flashgeheugen te lezen en te schrijven. Vanuit U-boot heb je ook wat simpele netwerkmogelijkheden.

In de U-boot omgeving van de defecte camera bleek dat ik wel gewoon in staat was om te pingen. De netwerkaansluiting was dus prima. Met U-boot zou ik dus verder moeten komen, wellicht was de camera nog te redden.

Backup van de werkende camera

Mijn aanname was nu dat de software op de defecte camera wellicht niet goed geflashed was. Aangezien beide camera’s hetzelfde zijn en er eentje werkt, kan daar natuurlijk de software afgehaald worden en op de andere gezet worden. De werkende camera had ik al ingebouwd in een behuizing, dus via U-boot kon ik hier niet handig de software afhalen. Dan maar via telnet.

In een ander blog vond ik informatie over het kopiëren van de partities via NFS. Er vanuit gaande dat je een NFS share hebt op /hicam op 192.168.1.100, maken de volgende commando’s het mogelijk om alle mtd partities te kopiëren:

mkdir /mnt/nfs
mount -t nfs -o nolock 192.168.1.100:/hicam /mnt/nfs

Even je root re-mounten, maar dan read-only:

mount -o remount,ro /

En vervolgens kun je de partities kopieren:

dd if=/dev/mtdblock0 of=/mnt/nfs/mtdblock0 bs=65536<br> dd if=/dev/mtdblock1 of=/mnt/nfs/mtdblock1 bs=65536<br> dd if=/dev/mtdblock2 of=/mnt/nfs/mtdblock2 bs=65536
dd if=/dev/mtdblock3 of=/mnt/nfs/mtdblock3 bs=65536<br> dd if=/dev/mtdblock4 of=/mnt/nfs/mtdblock4 bs=65536<br> dd if=/dev/mtdblock5 of=/mnt/nfs/mtdblock5 bs=65536

Van deze partities is mtdblock0 de bootloader partitie (dus waar U-boot op staat). Deze is dus behoorlijk kritisch en hoeven we eigenlijk niet aan te komen.

Via cat /proc/mtd weten we meer over de grootte van de partities, dat hebben we straks nodig bij het flashen:

# cat mtd
dev: size erasesize name <br> mtd0: 00040000 00010000 "boot"
mtd1: 00370000 00010000 "romfs"
mtd2: 00280000 00010000 "user"
mtd3: 00140000 00010000 "web"
mtd4: 00040000 00010000 "custom"
mtd5: 00050000 00010000 "mtd"

Hieruit volgt dat de partities de volgende adressen gebruiken:

0x000000000000-0x000000040000 : "boot" mtd0
0x000000040000-0x0000003b0000 : "romfs" mtd1
0x0000003b0000-0x000000630000 : "user" mtd2
0x000000630000-0x000000770000 : "web" mtd3
0x000000770000-0x0000007b0000 : "custom" mtd4
0x0000007b0000-0x000000800000 : "mtd" mtd5

Herstellen van de software van de defecte camera

We hebben nu de werkende software en toegang tot de camera, nu die twee nog combineren.

Een manier om binnen U-boot bestanden over het netwerk te halen is via TFTP. Een simpel bestandsoverdrachtprotocol zonder authenticatie of encryptie wat op omgevingen waar de bronnen schaars zijn vaak geimplementeerd is. Zo ook op deze ip-camera. Door nu zelf een TFTP server te installeren kunnen de partities naar de defecte camera worden gekopieerd.

Zoals genoemd blijven we van mtdblock0 af, want de bootloader werkt (we kunnen immers in U-boot komen).

In de U-boot omgeving moet eerst de TFTP server ingesteld worden

set serverip [TFTP_SERVER_IP_ADDRESS]

zodat U-boot weet waar het bestand vandaan moet komen.

Met het commando tftp [bestandsnaam] kunnen nu de bestanden die we eerder hebben gekopieerd in het geheugen van de defecte camera geladen worden, dat is in dit geval RAM adres 0x80008000.

Een nu belangrijk commando is sf, het commando om flash geheugen te programmeren. De volgende sf commando’s gaan we nu gebruiken. De bijbehorende betekenis staat er achter:

sf probe [[bus:]cs] [hz] [mode] - init flash device on given SPI bus and chip select

sf erase offset [+]len - erase 'len' bytes from 'offset'; '+len' round up 'len' to block size

sf write addr offset len - write 'len' bytes from memory at 'addr' to flash at 'offset'

Het eerste commando is

sf probe 0

om de juiste chip te selecteren.

Dan halen we via TFTP de eerste partitie binnen die we willen schrijven (niet de bootloader, maar mtdblock1)

tftp mtdblock1

De partitie worden nu in het RAM geladen (positie 0x80008000)

Vervolgens gaan we eerst het flashgeheugen erasen. Bij het flashen wordt er maar 1 soort bitflip gedaan. Dus van bijvoorbeeld een 1 kan wel een 0 worden gemaakt, maar van een 0 geen 1. Bij het erasen worden dan bijvoorbeeld alleen maar 1’en geschreven, zodat het flashen de 0’en op de juiste plek kan schrijven. Belangrijk is wel om hier de juiste offset en length te geven, dat zijn de gegevens die we uit de eerdere cat /proc/mtd kunnen halen

sf erase 0x40000 0x370000

Vervolgens kunnen we de mtdblock1 partitie vanuit RAM schrijven naar flash:

sf write 0x80008000 0x40000 0x370000

Voor de overige partities de commando’s:

tftp mtdblock2

sf erase 0x3b0000 0x280000

sf write 0x80008000 0x3b0000 0x280000

tftp mtdblock3

sf erase 0x630000 0x140000

sf write 0x80008000 0x630000 0x140000

tftp mtdblock4

sf erase 0x770000 0x40000

sf write 0x80008000 0x770000 0x40000

tftp mtdblock5

sf erase 0x7b0000 0x50000

sf write 0x80008000 0x7b0000 0x50000

Als alles goed gegaan is is het nu camera opnieuw opstarten en hij werkt! In mijn geval had ik direct na het opnieuw opstarten van de eerder defecte camera hetzelfde (DHCP) IP als de werkende camera. Ik kon netjes verbinden, maar opeens was de verbinding weg. Logisch: de camera heeft wel een ander MAC-adres en kreeg dus al vrij snel een ander IP-adres.

Ook voor andere apparaten kan een dergelijke aanpak via de seriële poort wellicht werken. Bijvoorbeeld routers die ge-bricked zijn door verkeerde firmware kunnen zo weer tot leven gewekt worden.

Ook bij deze camera geldt weer: let bij het installeren van een IP-camera wel op dat je je beveiliging op orde hebt. Het zou jammer zijn als je op Insecam terecht komt en met de mogelijke lekken in camera’s weet je bij deze Chinese firmware natuurlijk ook niet wat je binnenhaalt.