🥇Nosorožec uvnitř kočky — spouštíme firmware v emulátoru Kopycat

V rámci setkání 0x0A DC7831 DEF CON Nižnij Novgorod 16. února jsme představili přednášku o základních principech emulace binárního kódu a našem vlastním vývoji — emulátoru hardwarových platforem Kopycat.

V článku představíme popis spuštění firmwaru zařízení v emulátoru, předvedeme interakci s ladicím nástrojem a provedeme malou dynamickou analýzu firmwaru.

Pozadí

Dávno, v galaxii daleko, daleko odsud

Před pár lety v naší laboratoři vznikla potřeba prozkoumat firmware zařízení. Firmware byl zkomprimovaný, rozbaloval se bootloaderem. Dělal to dost složitým způsobem, několikrát přesouval data v paměti. A samotný firmware pak aktivně interagoval s periferií. A to vše na jádru MIPS.

Existující emulátory nás z objektivních důvodů neuspokojily, a my jsme chtěli přece jen spustit kód. Pak jsme se rozhodli vytvořit svůj emulátor, který udělá minimum a umožní rozbalit hlavní firmware. Zkusili jsme to — a povedlo se. Pomysleli jsme si, co kdybychom přidali periferii, aby bylo možné také vykonávat hlavní firmware. Nebylo to příliš bolestivé — a také to vyšlo. Znovu jsme pomysleli a rozhodli se vytvořit plnohodnotný emulátor.

Nakonec vznikl emulátor výpočetních systémů Kopycat.

Proč Kopycat?

Je to slovní hra.

copycat (angl., podst. jméno [ˈkɒpɪkæt]) — napodobitel, imitátor
cat (angl., podst. jméno [ˈkæt]) — kočka, kocour — oblíbené zvíře jednoho z tvůrců projektu
Písmeno „K“ — z programovacího jazyka Kotlin

Kopycat

Při vytváření emulátoru byly stanoveny zcela jasné cíle:

možnost dostatečně rychle vytvořit novou periferii, modul, procesorové jádro;
možnost sestavit virtuální zařízení z různých modulů;
možnost nahrát do paměti virtuálního zařízení jakákoliv binární data (firmware);
možnost práce se snapshoty (snímky stavu systému);
možnost interakce s emulátorem prostřednictvím vestavěného ladicího nástroje;
příjemný moderní jazyk pro vývoj.

Na realizaci byl vybrán Kotlin, sběrnicová architektura (to je, když jsou moduly propojeny prostřednictvím virtuálních datových sběrnic), JSON — jako formát popisu zařízení, a GDB RSP — jako protokol interakce s ladicím nástrojem.

Vývoj probíhá již něco málo přes dva roky a aktivně pokračuje. Během této doby byly realizovány procesorové jádra MIPS, x86, V850ES, ARM, PowerPC.

Projekt roste a přišel čas představit ho široké veřejnosti. Podrobný popis projektu uděláme později, nyní se soustředíme na využití Kopycat.

Pro nejnetrpělivější — promo verzi emulátoru si můžete stáhnout přes odkazu.

Nosorožec v emulátoru

Připomeňme, že dříve pro konferenci SMARTRHINO-2018 bylo vytvořeno testovací zařízení „Nosorožec“ pro výuku dovedností reverzního inženýrství. Proces statické analýzy firmwaru byl popsán v tomto článku.

Nyní se pokusíme přidat „dynamiku“ a spustíme firmware v emulátoru.

Budeme potřebovat:
1) Java 1.8
2) Python a modul Jep k použití Pythonu uvnitř emulátoru. WHL balíček modulu Jep pro Windows si můžete stáhnout zde.

Pro Windows:
1) com0com
2) PuTTY

Pro Linux:
1) socat

Jako GDB klienta lze použít Eclipse, IDA Pro nebo radare2.

Jak to funguje?

Aby bylo možné nahrávat firmware v emulátoru, je nutné „sestavit“ virtuální zařízení, které představuje analog skutečného zařízení.

Skutečné zařízení („nosorožec“) lze zobrazit na strukturální schématu:

Emulátor má modulární strukturu a konečné virtuální zařízení lze popsat v JSON souboru.

JSON o 105 řádcích

{
  "top": true,

  // Název pluginu by měl být stejný jako název souboru (nebo úplná cesta od začátku knihovny)
  "plugin": "rhino",

  // Adresář, kde plugin umísťuje
  "library": "user",

  // Parametry pluginu (parametry konstruktoru, pokud je verze jar-plugin)
  "params": [
    { "name": "tty_dbg", "type": "String"},
    { "name": "tty_bt", "type": "String"},
    { "name": "firmware", "type": "String", "default": "NUL"}
  ],

  // Vnější porty pluginu
  "ports": [  ],

  // Interní sběrnice pluginu
  "buses": [
    { "name": "mem", "size": "BUS30" },
    { "name": "nand", "size": "4" },
    { "name": "gpio", "size": "BUS32" }
  ],

  // Interní komponenty pluginu
  "modules": [
    {
      "name": "u1_stm32",
      "plugin": "STM32F042",
      "library": "mcu",
      "params": {
        "firmware:String": "params.firmware"
      }
    },
    {
      "name": "usart_debug",
      "plugin": "UartSerialTerminal",
      "library": "terminals",
      "params": {
        "tty": "params.tty_dbg"
      }
    },
    {
      "name": "term_bt",
      "plugin": "UartSerialTerminal",
      "library": "terminals",
      "params": {
        "tty": "params.tty_bt"
      }
    },
    {
      "name": "bluetooth",
      "plugin": "BT",
      "library": "mcu"
    },

    { "name": "led_0",  "plugin": "LED", "library": "mcu" },
    { "name": "led_1",  "plugin": "LED", "library": "mcu" },
    { "name": "led_2",  "plugin": "LED", "library": "mcu" },
    { "name": "led_3",  "plugin": "LED", "library": "mcu" },
    { "name": "led_4",  "plugin": "LED", "library": "mcu" },
    { "name": "led_5",  "plugin": "LED", "library": "mcu" },
    { "name": "led_6",  "plugin": "LED", "library": "mcu" },
    { "name": "led_7",  "plugin": "LED", "library": "mcu" },
    { "name": "led_8",  "plugin": "LED", "library": "mcu" },
    { "name": "led_9",  "plugin": "LED", "library": "mcu" },
    { "name": "led_10", "plugin": "LED", "library": "mcu" },
    { "name": "led_11", "plugin": "LED", "library": "mcu" },
    { "name": "led_12", "plugin": "LED", "library": "mcu" },
    { "name": "led_13", "plugin": "LED", "library": "mcu" },
    { "name": "led_14", "plugin": "LED", "library": "mcu" },
    { "name": "led_15", "plugin": "LED", "library": "mcu" }
  ],

  // Připojení pluginu mezi komponenty
  "connections": [
    [ "u1_stm32.ports.usart1_m", "usart_debug.ports.term_s"],
    [ "u1_stm32.ports.usart1_s", "usart_debug.ports.term_m"],

    [ "u1_stm32.ports.usart2_m", "bluetooth.ports.usart_m"],
    [ "u1_stm32.ports.usart2_s", "bluetooth.ports.usart_s"],

    [ "bluetooth.ports.bt_s", "term_bt.ports.term_m"],
    [ "bluetooth.ports.bt_m", "term_bt.ports.term_s"],

    [ "led_0.ports.pin",  "u1_stm32.buses.pin_output_a", "0x00"],
    [ "led_1.ports.pin",  "u1_stm32.buses.pin_output_a", "0x01"],
    [ "led_2.ports.pin",  "u1_stm32.buses.pin_output_a", "0x02"],
    [ "led_3.ports.pin",  "u1_stm32.buses.pin_output_a", "0x03"],
    [ "led_4.ports.pin",  "u1_stm32.buses.pin_output_a", "0x04"],
    [ "led_5.ports.pin",  "u1_stm32.buses.pin_output_a", "0x05"],
    [ "led_6.ports.pin",  "u1_stm32.buses.pin_output_a", "0x06"],
    [ "led_7.ports.pin",  "u1_stm32.buses.pin_output_a", "0x07"],
    [ "led_8.ports.pin",  "u1_stm32.buses.pin_output_a", "0x08"],
    [ "led_9.ports.pin",  "u1_stm32.buses.pin_output_a", "0x09"],
    [ "led_10.ports.pin", "u1_stm32.buses.pin_output_a", "0x0A"],
    [ "led_11.ports.pin", "u1_stm32.buses.pin_output_a", "0x0B"],
    [ "led_12.ports.pin", "u1_stm32.buses.pin_output_a", "0x0C"],
    [ "led_13.ports.pin", "u1_stm32.buses.pin_output_a", "0x0D"],
    [ "led_14.ports.pin", "u1_stm32.buses.pin_output_a", "0x0E"],
    [ "led_15.ports.pin", "u1_stm32.buses.pin_output_a", "0x0F"]
  ]
}

Všimněte si parametru firmware v sekci params — je název souboru, který lze nahrát do virtuálního zařízení jako firmware.

Virtuální zařízení a jeho interakce se základním operačním systémem lze zobrazit tímto schématem:

Aktuální testovací instance emulátoru předpokládá interakci s COM porty základního OS (ladicí UART a UART pro Bluetooth modul). To mohou být reálné porty, ke kterým jsou připojena zařízení, nebo virtuální COM porty (k tomu právě potřebujete com0com / socat).

Pro interakci s emulátorem zvenčí v současné době existují dva hlavní způsoby:

protokol GDB RSP (příslušné nástroje, které tento protokol podporují — Eclipse / IDA / radare2);
interní příkazový řádek emulátoru (Argparse nebo Python).

Virtuální COM porty

Aby bylo možné interagovat s UARTem virtuálního zařízení na lokálním počítači prostřednictvím terminálu, je nutné vytvořit pár propojených virtuálních COM portů. V našem případě jeden port používá emulátor a druhý — program-terminál (PuTTY nebo screen):

Použití com0com

Virtuální COM porty jsou konfigurovány pomocí setup utility z balíku com0com (konzolová verze — C:Program Files (x86)com0comsetupc.exe, nebo GUI verze — C:Program Files (x86)com0comsetupg.exe):

Je třeba zaškrtnout políčka enable buffer overrun pro všechny vytvořené virtuální porty, jinak emulátor bude čekat na odpověď z COM portu.

Použití socat

Na UNIXových systémech jsou virtuální COM porty automaticky vytvářeny emulátorem pomocí utility socat, stačí při spuštění emulátoru v názvu portu uvést prefix socat:.

Interní rozhraní příkazového řádku (Argparse nebo Python)

Jelikož Kopycat je konzolová aplikace, pro interakci se svými objekty a proměnnými emulátor poskytuje dvě varianty příkazového řádku: Argparse a Python.

Argparse je CLI, vestavěné do Kopycat, je vždy dostupné a pro všechny.

Alternativní CLI je interpret Pythonu. Pro jeho použití je nutné nainstalovat Python modul Jep a nastavit emulátor pro práci s Pythonem (bude používán interpret Pythonu nainstalovaný v základním systému uživatele).

Instalace Python modulu Jep

Pod Linuxem lze Jep nainstalovat přes pip:

pip install jep

Pro instalaci Jep pod Windows je nutné nejdříve nainstalovat Windows SDK a odpovídající Microsoft Visual Studio. Trochu jsme vám usnadnili úkol a vytvořili WHL balíčky JEP pro aktuální verze Pythonu pro Windows, takže modul lze nainstalovat z souboru:

pip install jep-3.8.2-cp27-cp27m-win_amd64.whl

Pro ověření instalace Jep je nutné provést v příkazovém řádku:

python -c "import jep"

Odpověď by měla být zpráva:

ImportError: Jep není podporován v samostatném Pythonu, musí být vložen v Javě.

V dávkovém souboru emulátoru pro váš systém (kopycat.bat — pro Windows, kopycat — pro Linux) je potřeba přidat do seznamu parametrů DEFAULT_JVM_OPTS další parametr Djava.library.path — měl by obsahovat cestu k nainstalovanému modulu Jep.

Výsledná syntaxe pro Windows by měla vypadat takto:

set DEFAULT_JVM_OPTS="-XX:MaxMetaspaceSize=256m" "-XX:+UseParallelGC" "-XX:SurvivorRatio=6" "-XX:-UseGCOverheadLimit" "-Djava.library.path=C:/Python27/Lib/site-packages/jep"

Spuštění Kopycat

Emulátor je konzolová JVM aplikace. Spuštění se provádí prostřednictvím skriptu příkazového řádku operačního systému (sh/cmd).

Příkaz pro spuštění na Windows:

binkopycat -g 23946 -n rhino -l user -y library -p firmware=firmwarerhino_pass.bin,tty_dbg=COM26,tty_bt=COM28

Příkaz pro spuštění na Linuxu s použitím nástroje socat:

./bin/kopycat -g 23946 -n rhino -l user -y library -p firmware=./firmware/rhino_pass.bin, tty_dbg=socat:./COM26,tty_bt=socat:./COM28

-g 23646 — TCP port, který bude otevřen pro přístup k GDB serveru;
-n rhino — název hlavního modulu systému (zařízení v sestavení);
-l user — název knihovny pro nalezení hlavního modulu;
-y library — cesta pro hledání modulů souvisejících s zařízením;
firmwarerhino_pass.bin — cesta k souboru firmwaru;
COM26 a COM28 — virtuální COM porty.

Jako výsledek se zobrazí výzva Python > (nebo Argparse >):

18:07:59 INFO [eFactoryBuilder.create ]: Modul top byl úspěšně vytvořen jako top
18:07:59 INFO [ Module.initializeAndRes]: Nastavení jádra na top.u1_stm32.cortexm0.arm pro top
18:07:59 INFO [ Module.initializeAndRes]: Nastavení debuggeru na top.u1_stm32.dbg pro top
18:07:59 WARN [ Module.initializeAndRes]: Tracer nebyl nalezen v top...
18:07:59 INFO [ Module.initializeAndRes]: Inicializace portů a autobusů...
18:07:59 WARN [ Module.initializePortsA]: POZOR: Některé porty mají varování, použijte printModulesPortsWarnings pro zobrazení...
18:07:59 FINE [ ARMv6CPU.reset ]: Nastavte adresu vstupního bodu na 08006A75
18:07:59 INFO [ Module.initializeAndRes]: Modul top byl úspěšně inicializován a resetován jako top buňka!
18:07:59 INFO [ Kopycat.open ]: Spuštění virtualizace desky top[rhino] s arm[ARMv6Core]
18:07:59 INFO [ GDBServer.debuggerModule ]: Nastavit nový debugger modul top.u1_stm32.dbg pro GDB_SERVER(port=23946,alive=true)
Python >

Interakce s IDA Pro

Jako vstupní soubor pro analýzu v IDA pro usnadnění testování používáme firmware 'Nosoroha' ve formátu ELF souboru (obsahuje uložené metainformace).

Můžete také použít hlavní firmware bez metainformací.

Po spuštění Kopycat v IDA Pro v menu Debugger vybereme položku „Switch debugger…“ a vybereme „Vzdálený GDB debugger«. Dále nastavíme připojení: menu Debugger — Možnosti procesu…

Nastavujeme hodnoty:

Aplikace — libovolná hodnota
Hostname: 127.0.0.1 (nebo IP adresa vzdáleného stroje, kde běží Kopycat)
Port: 23946

Nyní je k dispozici tlačítko pro spuštění ladění (klávesa F9):

Stiskneme jej — dojde k připojení k modulu debuggeru v emulátoru. IDA přechází do režimu ladění, stávají se dostupnými další okna: informace o registrech, o zásobníku.

Nyní můžeme využít všechny standardní možnosti práce s debuggerem:

krokové provádění instrukcí (Krok do a Krok přes — klávesy F7 a F8, odpovídajícím způsobem);
spuštění a pozastavení vykonávání;
vytváření bodů přerušení jak na kód, tak na data (klávesa F2).

Připojení k debuggeru neznamená spuštění kódu firmwaru. Aktuální pozicí pro vykonávání musí být adresa 0x08006A74 — začátek funkce Reset_Handler. Pokud posunete výpis níže, můžete vidět volání funkce main. Můžete umístit kurzor na tento řádek (adresa 0x08006ABE) a provést operaci Spustit až k kurzoru (klávesa F4).

Dále můžete stisknout F7, abyste vstoupili do funkce main.

Pokud spustíte příkaz Pokračovat v procesu (klávesa F9), objeví se okno „Prosím čekejte“ s jediným tlačítkem Pozastavit:

Po stisku Pozastavit vykonávání kódu firmwaru se pozastaví a může být pokračováno z té samé adresy v kódu, kde bylo přerušeno.

Pokud pokračujete ve vykonávání kódu, v terminálech připojených k virtuálním COM-portům můžete vidět následující řádky:

Přítomnost řádku „state bypass“ naznačuje, že virtuální Bluetooth modul přešel do režimu příjmu dat od COM-portu uživatele.

Nyní v Bluetooth terminálu (na obrázku — COM29) můžete zadávat příkazy podle protokolu „Nosorožec“. Například na příkaz „MEOW“ se v Bluetooth terminálu vrátí řádek „mur-mur“:

Nesimuluj mě úplně

Při stavbě emulátoru lze vybírat stupeň detailnosti/emulace konkrétního zařízení. Například modul Bluetooth lze emulovat různými způsoby:

emuluje se celé zařízení s úplnou sadou příkazů;
emulují se AT příkazy a datový tok se přijímá z COM-portu hlavního systému;
virtuální zařízení zajišťuje úplné přesměrování dat na skutečné zařízení;
ve formě jednoduché zástěrky, která vždy vrací „OK“.

V aktuální verzi emulátoru se používá druhý přístup — virtuální Bluetooth modul provádí konfiguraci, po které přechází do režimu „proxy“ dat z COM portu hlavního systému do UART portu emulátoru.

Zvážíme možnost jednoduché instrumentace kódu v případě, že není realizována nějaká část periferie. Například, pokud není vytvořen časovač, který je zodpovědný za kontrolu přenosu dat v DMA (kontrola se provádí ve funkci ws2812b_wait, umístěné na adrese 0x08006840), pak firmware vždy bude čekat na resetování příznaku busy, umístěného na adrese 0x200004C4, který ukazuje na zaneprázdněnost datové linky DMA:

Tuto situaci můžeme obejít „ručním“ resetováním příznaku busy hned po jeho nastavení. V IDA Pro lze vytvořit Python funkci a vyvolat ji v breakpointu, přičemž samotný breakpoint umístíme v kódu po zápisu hodnoty 1 do příznaku busy.

Breakpoint-handler

Nejprve vytvoříme Python funkci v IDA. Menu File — Script command…

Přidáme nový snippeta do seznamu vlevo, dáme mu název (například, BPT),
do textového pole vpravo zadáme kód funkce:

def skip_dma():
    print "Skipping wait ws2812..."
    value = Byte(0x200004C4)
    if value == 1:
        PatchDbgByte(0x200004C4, 0)
return False

Poté klikneme na Spustit a zavřeme okno skriptů.

Nyní přejdeme kód na adrese 0x0800688A, nastavíme breakpoint (klávesa F2), upravíme jej (kontextové menu Edit breakpoint…), nezapomeňte nastavit typ skriptu – Python:

Pokud je aktuální hodnota příznaku busy rovna 1, je třeba provést funkci skip_dma v řádku skriptů:

Pokud spustíme firmware do vykonávání, můžeme vidět aktivaci kódu breakpoint-handleru v IDA v okně Výstup pod řádkem Skipping wait ws2812.... Nyní firmware nebude čekat na reset příznaku. busy.

Interakce s emulátorem

Emulace pro emulaci pravděpodobně nevyvolá nadšení a radost. Mnohem zajímavější je, pokud emulátor pomůže výzkumníkovi vidět data v paměti nebo nastavit interakci vláken.

Ukážeme, jak dynamicky nastavit interakci RTOS úloh. Předtím by mělo být pozastaveno provádění kódu, pokud je spuštěno. Pokud přejdeme do funkce bluetooth_task_entry ve větvi zpracování příkazu „LED“ (adresa 0x080057B8), můžeme vidět, že nejprve je vytvořen, a poté odeslán do systémové fronty ledControlQueueHandle nějaká zpráva.

Je třeba nastavit breakpoint na přístup k proměnné ledControlQueueHandle, umístěné na adrese 0x20000624 a pokračovat v provádění kódu:

V důsledku toho nejprve dojde k zastavení na adrese 0x080057CA před voláním funkce osMailAlloc, poté — na adrese 0x08005806 před voláním funkce osMailPut, pak po nějaké době — na adrese 0x08005BD4 (před voláním funkce osMailGet), která patří funkci leds_task_entry (LED úkol), což znamená, že došlo k přepnutí úkolů a nyní kontrolu získal LED úkol.

Tímto jednoduchým způsobem lze zjistit, jak úkoly RTOS vzájemně interagují.

Samozřejmě, ve skutečnosti může být interakce úkolů složitější, ale pomocí emulátoru je sledování této interakce méně pracné.

Tady Můžete se podívat na krátké video o spuštění emulátoru a interakci s IDA Pro.

Spuštění s Radare2

Nelze opomenout tak univerzální nástroj jako Radare2.

Pro připojení k emulátoru pomocí r2 bude příkaz vypadat takto:

radare2 -A -a arm -b 16 -d gdb://localhost:23946 rhino_fw42k6.elf

Nyní jsou k dispozici spuštění (dc) a pozastavení vykonávání (Ctrl+C).

Bohužel, v současnosti má r2 problémy při práci s hardwarovým gdb serverem a mapováním paměti, kvůli čemuž nefungují breakpointy a Stepy (příkaz ds). Doufáme, že to bude brzy opraveno.

Spuštění s Eclipse

Jednou z možností použití emulátoru je ladění firmwaru vyvíjeného zařízení. Pro názornost také použijeme firmware "Nosorožec". Zdrojové kódy firmwaru lze stáhnout odsud.

Jako IDE budeme používat Eclipse z balíčku System Workbench for STM32.

Aby se do emulátoru nahrál firmware přímo sestavený v Eclipse, je nutné přidat parametr firmware=null do příkazu pro spuštění emulátoru:

binkopycat -g 23946 -n rhino -l user -y modules -p firmware=null,tty_dbg=COM26,tty_bt=COM28

Nastavení debug konfigurace

V Eclipse vyberte menu Run — Debug Configurations… V otevřeném okně v sekci GDB Hardware Debugging je nutné přidat novou konfiguraci, po čemž na kartě „Main“ vybrat aktuální projekt a aplikaci pro ladění:

Na kartě „Debugger“ je nutné uvést GDB příkaz:
${openstm32_compiler_path}arm-none-eabi-gdb

A také zadat parametry pro připojení k GDB serveru (host a port):

Na kartě „Startup“ je nutné uvést následující parametry:

zaškrtnout políčko Load image (aby se prováděl přenos do emulátoru sestaveného obrazu firmwaru);
zaškrtnout políčko Load symbols;
přidat příkaz pro spuštění: set $pc = *0x08000004 (nastavit registr PC na hodnotu z paměti na adrese 0x08000004 — tam je uložena adresa ResetHandler’a).

Vezměte prosím na vědomí, pokud nechcete načítat soubor firmware z Eclipse, pak parametry Load image a Spustit příkazy uvádět není třeba.

Po stisknutí Debug můžete pracovat v režimu ladění:

step-by-step provádění kódu
interakce s breakpointy

Poznámka. V Eclipse jsou, hm… některé zvláštnosti… a s těmi se musíme smířit. Například, pokud se při spuštění debuggeru objeví zpráva „No source available for „0x0”“, pak proveďte příkaz Step (F5)

Na závěr

Emulace nativního kódu je velmi zajímavá záležitost. Pro vývojáře zařízení poskytuje možnost ladit firmware bez skutečného zařízení. Pro výzkumníka – možnost provádět dynamickou analýzu kódu, což není vždy možné ani s dostupným zařízením.

Chceme poskytnout specialistům nástroj, který bude pohodlný, dostatečně jednoduchý a nevyžaduje spoustu úsilí a času na svou konfiguraci a spuštění.

Napište v komentářích o svých zkušenostech s hardwarovými emulátory. Zveme vás k diskusi a rádi odpovíme na otázky.

Pouze registrovaní uživatelé se mohou účastnit ankety. Přihlaste se, prosím.