Vraag:
Reverse engineering van Devolo-firmware
Camandros
2015-03-23 00:06:20 UTC
view on stackexchange narkive permalink

Ik probeer wat reverse engineering uit te voeren op een Devolo dlan wifi 500-apparaat (mips-architectuur). Mijn doel is om wat firmware te plaatsen die door mij is gewijzigd.

Dit is waar ik tot nu toe ben gekomen:

  1. Een firmware-update gedownload van http: // update .devolo.com / linux2 / apt / pool / main / d / devolo-firmware-dlan500-wifi /
  2. Geëxtraheerde firmware-image uit debian-pakket
  3. Geanalyseerde afbeelding met binwalk
  4. Geëxtraheerde inhoud met firmwaremod-kit (aanwezig op Google-code).
  5. Gewijzigde afbeelding
  6. Opnieuw opgebouwd met fmk
  7. Gebruikte webinterface van het apparaat om nieuwe firmware te uploaden

Het is mislukt in stap 7. Ik krijg een bericht met de melding "dit bestand bevat geen geldige gegevens". Dus het apparaat voert een soort verificatie uit voordat updates worden geïnstalleerd.

Dus ik bleef het onderzoeken. De devolo-image bevat een devolo-header / footer, een uboot en een uimage. De koptekst / voettekst moet een soort checksum bevatten. Ik heb geprobeerd de geldige (onvervalste) update te kiezen en een bit op de opvulling veranderd, deze naar het apparaat geüpload en kreeg dezelfde foutmelding.

Als ik wist waar de cheksum is of hoe deze wordt verkregen, zou ik dat kunnen verander het na het opnieuw opbouwen van de afbeelding. Ik vond echter geen documentatie over de devolo-formaten. Om de som te vinden vergeleek ik de hexadecimaal van twee devolo-afbeeldingen: wifi en draadloos (de draadloze afbeelding staat op dezelfde site waar ik de wifi-afbeelding heb gedownload; kon deze link en de fmk-link niet plaatsen omdat ik er minder dan 10 reputatie :(). De kopteksten / voetteksten lijken in de meeste velden erg op elkaar, hoewel ik vond dat geen 32byte-veld een som was. Misschien zou iemand die meer ervaring heeft met reverse engineering mij kunnen helpen.

Ik zou kunnen proberen de som forceren. Omdat het een som is, zou ik een botsing kunnen creëren door bits toe te voegen aan de opvulgebieden. Hiervoor heb ik twee ideeën:

  1. Stuur elke mogelijke combinatie door het netwerk;
  2. Gebruik de bibliotheken van de gedownloade afbeelding om de som lokaal te testen;

Optie 1 zou waarschijnlijk een paar jaar duren ...

Voor optie 2 heb ik geprobeerd een virtuele qemu-machine te gebruiken en daar te compileren, en cross-compileren, zonder resultaat, vanwege de devolo-libs die een oude libc-versie ( https://stackoverflow.com/questions/29153924/how-to-solve-c-conflicts-between-system-and-library-dependencies).

Mijn laatste idee is om op de een of andere manier de gedownloade firmware op mijn amd64-machine te emuleren, om daar wat code te compileren die de devolo-libs zou gebruiken, en zo de afhankelijkheidsproblemen te omzeilen.

Dus ik wil alle tips / fouten in mijn vorige stappen en eventuele aanwijzingen over hoe de gedownloade afbeelding op mijn pc moet worden uitgevoerd.

Bij voorbaat dank (al was het maar voor het lezen van mijn vrij lange post).

Zoek het foutbericht in de geëxtraheerde code, de verificatieroutine zou in de buurt moeten zijn.
Ik heb het bericht gevonden. Het bevindt zich in een uitvoerbaar bestand, dus het is nogal moeilijk om daar iets uit te halen. Maar het was een leuk idee
Als je je systeem al hebt ingesteld voor cross-compileren, heb je ergens een mips-objdump. Voer het uit op uw uitvoerbare bestand en inspecteer vervolgens de code; mips assembler is (imho) veel gemakkelijker te leren dan x86 of arm. U kunt ook www.onlinedisassembler.com gebruiken in plaats van objdump, of controleren of de [Retargetable Decompiler] (https://retdec.com/) nu beter werkt met MIPS (dat deed ik niet, de laatste keer dat ik keek, 3 maanden geleden) ).
Een antwoord:
booto
2015-03-23 23:21:41 UTC
view on stackexchange narkive permalink

Elke sectie in het firmwarebestand heeft een crc32 over de inhoud ervan.

Zie dit.

Het zou optie 1 levensvatbaarder moeten maken.

Meer details: in de afbeelding van squashfs zit een hele hoop op busybox gebaseerde tools en een handvol zelfstandige programma's. Er is er een ( / usr / sbin / chunk ) die waarschijnlijk logica heeft met betrekking tot het doorlopen van de firmwarebestanden. Het bevat een aantal van de 32-bits waarden die overeenkomen met de waarden in het firmwarebestand die eruitzien als magische / fourcc-waarden. strings (1) output was ook behoorlijk bemoedigend.

Ik vind dit antwoord leuk, maar een beetje "hoe weet je dat?" zou het nog beter maken.
Gast, wauw. Gewoon wow. Het werkt perfect. Bedankt voor de code. Kunt u me alsjeblieft alsjeblieft vertellen hoe je dit hebt gedaan?
Ik heb IDA gebruikt om het binaire bestand te analyseren dat ik noemde in het gedeelte 'meer details' van het antwoord.
Ja, maar waarom _usr / sbin / chunk_? Van alle binaire bestanden, waarom die in het bijzonder? Of heb je ze allemaal geanalyseerd? (nogmaals bedankt btw)
Ik heb er snel een paar bekeken (het was niet de eerste), en het leek erop dat dit de beste was om in meer detail te bekijken. Meerdere verwijzingen naar het manipuleren van firmware, en de fourcc-waarden (bijv.DVCO, VRNT, enz.) Verschijnen allemaal. Het formaat van het bestand zelf lijkt enige overeenkomsten te hebben met [PNG] (http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html), (?) Van alle dingen (crc is een beetje anders, en het firmwareformaat ondersteunt enige basisversleuteling).
De gelijkenis met PNG is voor mij niet zo verwonderlijk - dit soort viercc-getagde structuur is een populaire manier om allerlei brok-gestructureerde binaire gegevens op te slaan, tenminste sinds de EA [Interchange File Format] (https: // en.wikipedia.org/wiki/Interchange_File_Format) uit de jaren 80.


Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...