2 Punkte von GN⁺ 2024-05-26 | 1 Kommentare | Auf WhatsApp teilen
  • Die Samsung WB850F ist das erste Modell, das den DRIMeIII-SoC zusammen mit Wi-Fi nutzte; dank der in der Firmware-ZIP enthaltenen partialImage.o.map wurden die Analyse der Haupt-SoC-Firmware und das Umgehen der Hotspot-Erkennung möglich
  • WB850F_FW_210086.zip enthält WB850-FW-SR-210086.bin mit 6 Partitionen sowie einen Linker-Dump mit mehr als 300.000 Zeilen, wodurch bestätigt werden konnte, dass Main_Image die eigentliche ARM-Firmware ist
  • In der Ghidra-Analyse war entscheidend, über Differenzen bei String-Adressen die Basisadresse 0xc0004000 von Main_Image zu finden und die Funktionsnamen aus .text umzuwandeln und als Symbole zu importieren
  • Die Hotspot-Prüffunktion DevHTTPResponseStart entscheidet anhand eines Yahoo-Domain-Cookies bei HTTP 200 oder anhand des Strings yahoo. am Anfang einer Redirect-URL bei 301/302/307, ob ein AP authentifiziert ist
  • Nachdem Yahoo auf HTTPS weiterleitete, lag die Position von yahoo. außerhalb des im Code erlaubten Bereichs; nach dem Patch von samsung-nx-emailservice gelang der Foto-Upload der WB850F

Aufbau der WB850F-Firmware-ZIP

  • Die Samsung WB850F ist eines der wenigen Modelle, für die Samsung auch nach der eingestellten iLauncher-Anwendung weiterhin Firmware und Support-Dateien veröffentlicht
  • WB850F_FW_210086.zip enthält folgende Dateien
    • GPS_FW/BASEBAND_FW_Flash.mbin
    • GPS_FW/BASEBAND_FW_Ram.mbin
    • GPS_FW/Config.BIN
    • GPS_FW/flashBurner.mbin
    • FWUP
    • partialImage.o.map
    • WB850-FW-SR-210086.bin
    • wb850f_adj.txt
  • FWUP enthält nur den String upgrade all und wirkt wie ein Skript für ein Firmware-Test-/Automatisierungsmodul
  • wb850f_adj.txt ist ein komplexeres Skript, das die GPS-Firmware aktualisiert und zugehörige Dateien löscht
  • Die GPS-bezogenen Skripte und der Ordner GPS_FW sind nicht Gegenstand dieser Analyse

partialImage.o.map: ein Linker-Dump als Karte

  • partialImage.o.map ist eine Textdatei mit mehr als 300.000 Zeilen und enthält die Linker-Ausgabe zu partialImage.o sowie die vollständige Speicherkarte der verlinkten Datei
  • Die Sektion .text enthält Funktionsnamen wie sysInit, archPwrDown, DevHTTPResponseStart, DevHTTPResponseData, DevHTTPResponseEnd
  • Die Sektion .data enthält Datensymbole wie sysBus, sysCpu, sysBootLine
  • Diese Datei wird als Symbolkarte genutzt, um Code und Funktionsnamen in der Firmware zuzuordnen

Header und Partitionstabelle von WB850-FW-SR-210086.bin

  • Betrachtet man WB850-FW-SR-210086.bin mit binwalk, erscheinen HTML-, PNG- und JPEG-Header, VxWorks-Header sowie mehrere Unix-Pfade, aber keine klaren Partitionen oder Dateisysteme
  • Ein Hex-Dump der ersten 1 KB zeigt nach der Firmware-Version 210086 die Bytes 0x00 0x06, gefolgt von Dateinamen wie FW_UP/ONBL1.bin
  • Jeder Record scheint eine 60-Byte-Struktur zu sein, bestehend aus einem 32-Byte-String mit Null-Padding, zwei Little-Endian-Integern und einem 20-Byte-Partitionsnamen mit Null-Padding
  • Die beiden Integer werden jeweils als Länge und Offset innerhalb der Datei interpretiert
  • Da es insgesamt 6 Records gibt, wird 0x00 0x06 als Abschluss- oder Padding-Byte des Firmware-Version-Strings plus 1-Byte-Partitionsanzahl interpretiert
  • Rekonstruierte Partitionen

    • FW_UP/ONBL1.bin
      • Größe: 196 Byte, Offset: 0x0000800, Partitionsname: ONBL1
    • FW_UP/ONBL2.bin
      • Größe: 46 KB, Offset: 0x00008c4, Partitionsname: ONBL2
    • [WB850]DSC_5KEY_WB850
      • Größe: 30 MB, Offset: 0x000bef4, Partitionsname: Main_Image
    • RomFS/SPID.Rom
      • Größe: 48 MB, Offset: 0x1d2b32c, Partitionsname: Resource
    • FW_UP/WB850.HEX
      • Größe: 19 KB, Offset: 0x4c75f2c, Partitionsname: OIS
    • FW_UP/skin.bin
      • Größe: 36 MB, Offset: 0x4c7acb2, Partitionsname: SKIN
    • Zum Extrahieren der Partitionen wurde das DRIMeIII-Firmware-Partitionsextraktionstool geschrieben und verwendet

Code- und Datenpartitionen unterscheiden

  • Das Extraktionstool zieht Dateien anhand des Partitionsnamens heraus und hängt .bin an
  • Allein die Ausgabe von file ist nur begrenzt nützlich, etwa weil Main_Image.bin fälschlich als OpenPGP Secret Key erkannt wird
  • ONBL1 und ONBL2 werden anhand des Strings "BootLoader(ONBL1, ONBL2) Update Done" in Main_Image als Bootloader der ersten und zweiten Stufe vermutet
  • Main_Image ist die eigentliche Firmware, und binwalk -A meldet in dieser Datei zahlreiche ARM-Funktionsprologe
  • Resource und SKIN sind große Container und könnten vom SoC-Hersteller bereitgestellte Konfigurationen für den Kamera-UI-Skin sein
  • OIS ist trotz des Dateinamens kein echtes HEX und könnte Firmware für eine dedizierte optische Bildstabilisierungseinheit sein
  • Im Mittelpunkt der Analyse steht Main_Image

Main_Image in Ghidra mappen

  • Die drei Partitionen ONBL1, ONBL2 und Main_Image enthalten echten ARM-Code
  • Übliche ARM-Firmware hat an Adresse 0x0000000 eine Reset-Vektortabelle, doch alle drei Binärdateien beginnen mit linearem Code und müssen daher auf eine noch unbekannte Adresse neu gemappt werden
  • Um die fehlerhafte Hotspot-Erkennung zu analysieren, waren folgende Schritte nötig
    • die korrekte Speicheradresse finden, auf die Main_Image gemappt werden muss
    • die Symbolnamen aus partialImage.o.map in Ghidra laden
    • die Funktion analysieren, die die Hotspot-Login-Erkennung falsch auslöst
  • Eine Suche nach "yahoo" im Tab Defined Strings von Ghidra brachte Einträge hervor, die wie Debug-Strings von DevHTTPResponseStart() aussehen
    • DevHTTPResponseStart: url=%s, handle=%x, status=%d
    • DevHTTPResponseStart: This is YAHOO check !!!
    • DevHTTPResponseStart: THIS IS GOOGLE/YAHOO/SAMSUNG PAGE!!!! 111
    • 301/302/307! cannot find yahoo!
  • In partialImage.o.map liegt DevHTTPResponseStart bei 0x321a84, und Ghidra findet an demselben Offset ebenfalls eine Funktion
  • Die Differenz zwischen den Pointer-Werten der Debug-Strings und den tatsächlichen String-Offsets passte zu 0xc0004000, sodass die Basisadresse von Main_Image als 0xc0004000 bestimmt wurde
  • Da sich die Basisadresse in Ghidra nachträglich nicht ändern lässt, musste die Binärdatei aus dem Projekt entfernt, erneut importiert und dabei die Basisadresse gesetzt werden

Funktionsnamen importieren und DevHTTPResponseStart analysieren

  • Ghidras ImportSymbolScript.py kann Symbole massenhaft aus einer Texttabelle importieren
  • Das Skript erwartet pro Zeile den Symbolnamen, eine Hex-Adresse und ein f für eine Funktion oder ein l für ein Label
  • Da aus partialImage.o.map nur die Funktionen der aktuellen .text-Sektion benötigt wurden, mussten folgende Einträge ausgeschlossen werden
    • leere Zeilen
    • Offsets von Objektdateien
    • Sektionslabels wie .text
    • Labels mit dem Präfix L$_
    • lokale Symbole mit dem Präfix $
  • Zu den Adressen wird 0xc0004000 addiert, um sie an die Ghidra-Basisadresse anzupassen
  • Das konvertierte Ergebnis wird in einem Format wie sysInit c0004000 f, archPwrDown c0004094 f erstellt und über Ghidras Script Manager geladen
  • Nachdem die Funktionsnamen vorhanden sind, lässt sich das dekompilierte Ergebnis von DevHTTPResponseStart lesen, indem mehrere DAT_-Felder als Pointer markiert und die Parameternamen passend zu den Debug-Strings umbenannt werden

Bedingungen der Hotspot-Erkennung

  • DevHTTPResponseStart entscheidet anhand von HTTP-Antwortstatus, URL und Headern, ob ein Wi-Fi-AP authentifiziert wurde
  • Bei einer HTTP-200-OK-Antwort muss im Response-Header ein Yahoo-Domain-Cookie vorhanden sein, damit dies als erfolgreiche Authentifizierung gewertet wird
    • Geprüft werden domain=.yahoo, Domain=.yahoo, domain=kr.yahoo, Domain=kr.yahoo
    • Ist die Bedingung erfüllt, wird p_request_ongoing auf 0 gesetzt und, falls der Browser noch nicht authentifiziert ist, safnotify_auth_ap(0) aufgerufen
  • Bei HTTP-301/302/307-Redirects wird der String yahoo. in der URL geprüft
    • Fehlt yahoo. oder steht er hinter url + 11, wird dies so behandelt, als sei Yahoo nicht gefunden worden
    • Wenn der Browser-Framebuffer nicht eingeschaltet und auch keine Authentifizierung erfolgt ist, wird safnotify_auth_ap(1) aufgerufen
    • Steht yahoo. am Anfang, wird mit safnotify_auth_ap(0) eine erfolgreiche Authentifizierung gemeldet
  • Ein negativer Status gibt wie eine abgebrochene Anfrage false zurück
  • Bei einem positiven Status, der weder 200 noch ein Redirect ist, hängt das Ergebnis vom Zustand des Browser-Framebuffers ab

Durch TLS gebrochene Yahoo-Prüfung und Umgehung

  • Die von der Kamera abgefragte URL ist http://www.yahoo.co.kr/
  • Bei einer direkten Anfrage antwortet der Server mit HTTP/1.1 301 Moved Permanently und leitet per Location: https://www.yahoo.com/ weiter
  • In https://www.yahoo.com/ steht der Teilstring yahoo. an Position 12
  • Der Code verlangt, dass yahoo. unter den ersten 11 Positionen vorkommt; diese Prüfung ist daher nach der Umstellung auf HTTPS defekt
  • Um die Hotspot-Prüfung zu bestehen, muss man DNS-Records auf einen anderen Server zeigen lassen, der per HTTP auf einen Yahoo-ähnlicher aussehenden Namen weiterleitet oder ein Yahoo-Domain-Cookie setzt
  • Nach dem Patch für samsung-nx-emailservice verbindet sich die Kamera tatsächlich und lädt Fotos hoch

Andere Kameras, bei denen dieselbe Umgehung angewendet wurde

  • Diese Analyse hat es geschafft, anhand einer einzigen per Reverse Engineering untersuchten Funktion die Hotspot-Erkennung der Samsung-WB850F-Wi-Fi-Kamera zu verstehen und zu umgehen
  • Der finale Patch war klein, doch wegen der von Samsung-Ingenieuren implementierten Erkennungsmethode war es schwierig, die Umgehung allein aus Paketmitschnitten abzuleiten
  • Nachdem klar war, wonach gesucht werden musste, wurde dieselbe Umgehung auch auf Kameras angewandt, die MSN.com abfragen
  • Dadurch wurden EX2F, ST200F, WB3xF und WB1100F zur Liste unterstützter Kameras hinzugefügt
  • Main_Image enthält mehr als 77.000 Funktionen, sodass noch reichlich Analysepotenzial besteht, um die Funktionsweise der Digitalkamera besser zu verstehen

1 Kommentare

 
GN⁺ 2024-05-26
Meinungen auf Hacker News
  • https://op-co.de/blog/posts/samsung_nx_cryptofail/#index3h3 hat mir besser gefallen
    Ein wirklich erstaunlicher Fall von fehlgeschlagener Firmware-Verschlüsselung

  • Großartige Arbeit. Ich frage mich, ob du darüber nachdenkst, aus der Vorgehensweise beim Reverse Engineering ein Tutorial zu machen

    • Eigentlich hatte ich gehofft, dass dieser Artikel genug Informationen liefert, um als Tutorial zu dienen
      Ich habe nur die Teile weggelassen, die sich leicht googeln lassen
  • Alles, was ich will: Wenn ich mit der Kamerataste ein dSLR-Foto aufnehme, soll dieses Bild kurz darauf in Apple Photos landen

    • Früher gab es SD-Karten mit integriertem WLAN, die Fotos automatisch synchronisieren konnten, aber Eye-Fi, der wichtigste Anbieter in diesem Bereich, ist pleitegegangen, und offenbar hat niemand ein neues Produkt gebaut, das mit modernen Cloud-Diensten funktioniert
      Smartphones haben den Markt für Consumer-Kameras fast ausgelöscht, daher scheint die Nachfrage zu gering zu sein. Als Projektidee: herausfinden, wie man einen ESP32 in eine SD-Karte quetscht
    • Eine Canon-dSLR mit WLAN dürfte FTP können
      Man kann sie auch mit Telefonen, Tablets und Websites verbinden, braucht dafür aber eine App oder einen Dienst. Dokumentation zum direkten Senden per FTP von der Kamera: https://gdlp01.c-wss.com/gds/5/0300024975/01/eos5d-mk4-wff-i... Seite 113. Der Link führt zum EOS 5D Mark IV (WG) Wi-Fi (Wireless Communication) Function Instruction Manual
    • Die unter Linux laufenden Samsung NX1 und NX500 lassen sich ziemlich einfach so skripten, dass sie bei vorhandenem WLAN-Netzwerk JPEGs oder RAWs zu praktisch jedem Online-Dienst hochladen
      Leider sind es 10 Jahre alte Modelle und selbst auf dem Gebrauchtmarkt selten
    • Die Nikon-Z-Serie mit SnapBridge ist in dieser Richtung so ziemlich das Beste
      Sie koppelt sich per WLAN oder Bluetooth, und wenn man möchte, kann man die Kamera vom iPad aus fernsteuern und auch das Livebild sehen
    • Für Google Photos ist das bereits möglich, also sollte das hier auch gehen: https://www.stg-uploader.xyz/