Noshörning inuti katten – vi startar firmware i Kopycat-emulatorn

Under mötet 0x0A DC7831 DEF CON Nizhny Novgorod Den 16 februari presenterade vi en föreläsning om grundläggande principer för emulering av binärkod och vår egen utveckling – emulatorn för hårdvaruplattformar Kopycat.

I artikeln kommer vi att ge en beskrivning av hur man kör en enhets firmware i emulatorn, demonstrera interaktion med debuggern och utföra en liten dynamisk analys av firmwaren.

Bakgrund

En gång för länge sedan i en galax långt, långt borta

För några år sedan uppstod det ett behov i vårt laboratorium att undersöka firmware för en enhet. Firmwaren var komprimerad och packades upp av bootloadern. Den gjorde detta på ett ganska komplicerat sätt, genom att flera gånger flytta data i minnet. Och själva firmwaren interagerade aktivt med periferin. Och allt detta på en MIPS-kärna.

Existerande emulatorer passade oss av objektiva skäl inte, och vi ville verkligen starta koden. Vi beslöt då att göra vår egen emulator som skulle göra minimi och låta oss packa upp huvudfirmwaren. Vi provade – det lyckades. Vi tänkte, vad händer om vi lägger till periferin för att även kunna köra huvudfirmwaren. Det var inte särskilt smärtsamt – och det lyckades också. Vi tänkte igen och bestämde oss för att göra en fullfjädrad emulator.

Resultatet blev en emulator för datorsystem Kopycat.

Varför Kopycat?

Det är ett ordspel.

1. copycat (eng., subst. [ˈkɒpɪkæt]) – imitatör, efterapare
2. cat (eng., subst. [ˈkæt]) – katt, katten – det älskade djuret hos en av projektets skapare
3. Bokstaven 'K' kommer från programmeringsspråket Kotlin

Kopycat

Vid skapandet av emulatorn satte vi upp helt bestämda mål:

• möjligheten att ganska snabbt skapa en ny perifer enhet, modul, processor-kärna;
• möjligheten att sammanställa en virtuell enhet av olika moduler;
• möjligheten att ladda vilket binärt data (firmware) som helst i minnet på den virtuella enheten;
• möjligheten att arbeta med snapshots (systemtillståndsbilder);
• möjligheten att interagera med emulatorn via den inbyggda debuggern;
• ett trevligt modernt språk för utveckling.

Resultatet blev att Kotlin valdes för genomförandet, bus-arkitektur (där moduler kopplas samman via virtuella databusser), JSON – som format för beskrivning av enheten, och GDB RSP – som protokoll för interaktion med debuggern.

Utvecklingen har pågått i drygt två år och fortsätter aktivt. Under denna tid har CPU-kärnor för MIPS, x86, V850ES, ARM och PowerPC implementerats.

Projektet växer, och det är dags att presentera det för allmänheten. En detaljbeskrivning av projektet kommer senare, men nu fokuserar vi på att använda Kopycat.

För de mest otåliga — en provversion av emulatorn kan laddas ner via länken.

Noshörning i emulatorn

Kom ihåg att det tidigare skapades en testenhet "Noshörning" för konferensen SMARTRHINO-2018 för att lära sig färdigheter inom reverse engineering. Processen för statisk analys av firmware beskrevs i denna artikel.

Nu ska vi försöka lägga till "dynamik" och köra firmware i emulatorn.

Vi behöver:
1) Java 1.8
2) Python och modulen Jep för att använda Python inom emulatorn. WHL-paketet för Jep-modulen för Windows kan laddas ner här.

För Windows:
1) com0com
2) PuTTY

För Linux:
1) socat

Som GDB-klient kan Eclipse, IDA Pro eller radare2 användas.

Hur fungerar det?

För att kunna utföra firmware i emulatorn måste en "virtuell enhet" byggas, som är en motsvarighet till den verkliga enheten.

Den verkliga enheten ("noshörning") kan visas i en systemöversikt:

Emulatorn har en modulär struktur och den slutgiltiga virtuella enheten kan beskrivas i en JSON-fil.

JSON på 105 rader

{
  "top": true,

  // Plugin name should be the same as file name (or full path from library start)
  "plugin": "rhino",

  // Directory where plugin places
  "library": "user",

  // Plugin parameters (constructor parameters if jar-plugin version)
  "params": [
    { "name": "tty_dbg", "type": "String"},
    { "name": "tty_bt", "type": "String"},
    { "name": "firmware", "type": "String", "default": "NUL"}
  ],

  // Plugin outer ports
  "ports": [  ],

  // Plugin internal buses
  "buses": [
    { "name": "mem", "size": "BUS30" },
    { "name": "nand", "size": "4" },
    { "name": "gpio", "size": "BUS32" }
  ],

  // Plugin internal components
  "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" }
  ],

  // Plugin connection between components
  "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"]
  ]
}

Observera parameter firmware i avsnittet params — detta är namnet på filen som kan laddas upp till den virtuella enheten som firmware.

Den virtuella enheten och dess interaktion med det primära operativsystemet kan representeras av följande schema:

Den nuvarande testinstansen av emulatorn förutsätter interaktion med COM-portarna i det primära operativsystemet (debug UART och UART för Bluetooth-modulen). Det kan vara riktiga portar som är anslutna till enheter eller virtuella COM-portar (för detta behövs just com0com / socat).

För att interagera med emulatorn externt finns det för närvarande två huvudsakliga metoder:

• GDB RSP-protokollet (verktyg som stöder detta protokoll — Eclipse / IDA / radare2);
• den interna kommandoraden för emulatorn (Argparse eller Python).

virtuella COM-portar

För att interagera med UART på den virtuella enheten på den lokala maskinen via en terminal måste du skapa ett par ihopkopplade virtuella COM-portar. I vårt fall används en port av emulatorn och den andra av terminalprogrammet (PuTTY eller screen):

Användning av com0com

De virtuella COM-portarna konfigureras med setup-verktyget från com0com-paketet (kommandoradsversion — C:Program Files (x86)com0comsetupс.exe, eller GUI-version — C:Program Files (x86)com0comsetupg.exe):

Du bör aktivera alternativen enable buffer overrun för alla skapade virtuella portar, annars kommer emulatorn att vänta på svar från COM-porten.

Användning av socat

I UNIX-system skapas virtuella COM-portar automatiskt av emulatorn med hjälp av socat-verktyget, det är tillräckligt att ange prefixet socat:.

Det interna kommandoradsgränssnittet (Argparse eller Python)

Eftersom Kopycat är en konsolapplikation erbjuder emulatorn två alternativ för kommandoradsgränssnitt för att interagera med sina objekt och variabler: Argparse och Python.

Argparse är CLI:n som är inbyggd i Kopycat, och den är alltid tillgänglig för alla.

Alternativt CLI — Python-tolk. För att använda detta måste Python-modulen Jep installeras och emulatorn konfigureras för att arbeta med Python (den Python-tolk som är installerad i användarens primära system kommer att användas).

Installation av Python-modulen Jep

Under Linux kan Jep installeras via pip:

pip install jep

För att installera Jep under Windows måste Windows SDK och motsvarande Microsoft Visual Studio först installeras. Vi har förenklat din uppgift något och gjort WHL-paket JEP för aktuella versioner av Python för Windows, så modulen kan installeras från filen:

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

För att kontrollera installationen av Jep, kör följande kommando i kommandorutan:

python -c "import jep"

Som svar ska följande meddelande returneras:

ImportError: Jep stöds inte i fristående Python, det måste inbäddas i Java.

I kommandofilen för emulatören för ditt system (kopycat.bat — för Windows, kopycat — för Linux) lägg till ett ytterligare parameter till listan DEFAULT_JVM_OPTS till ett extra parameter Djava.library.path — den ska innehålla sökvägen till den installerade Jep-modulen.

För Windows bör resultatet bli en rad av följande typ:

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

Starta Kopycat

Emulatören är en konsol-JVM-applikation. Starten görs via ett kommandoskript i operativsystemet (sh/cmd).

Kommandot för att starta under Windows:

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

Kommandot för att starta under Linux med hjälp av verktyget 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-porten som kommer att öppnas för åtkomst till GDB-servern;
• -n rhino — namnet på huvudmodulen i systemet (enheten i samlingen);
• -l user — namnet på biblioteket för att söka efter huvudmodulen;
• -y library — sökvägen för att hitta moduler som ingår i enheten;
• firmwarerhino_pass.bin — sökvägen till firmwarefilen;
• COM26 och COM28 är virtuella COM-portar.

Som resultat kommer en inbjudan att visas Python > (eller Argparse >):

18:07:59 INFO [eFactoryBuilder.create ]: Modulen top skapades framgångsrikt som top
18:07:59 INFO [ Module.initializeAndRes]: Ställer in kärnan till top.u1_stm32.cortexm0.arm för top
18:07:59 INFO [ Module.initializeAndRes]: Ställer in avkodaren till top.u1_stm32.dbg för top
18:07:59 WARN [ Module.initializeAndRes]: Avkännaren hittades inte i top...
18:07:59 INFO [ Module.initializeAndRes]: Initierar portar och busser...
18:07:59 WARN [ Module.initializePortsA]: ATTENTION: Vissa portar har varningar, använd printModulesPortsWarnings för att se det...
18:07:59 FINE [ ARMv6CPU.reset ]: Ställ in startpunktens adress till 08006A75
18:07:59 INFO [ Module.initializeAndRes]: Modulen top är framgångsrikt initierad och återställd som en toppcell!
18:07:59 INFO [ Kopycat.open ]: Startar virtualisering av kortet top[rhino] med arm[ARMv6Core]
18:07:59 INFO [ GDBServer.debuggerModule ]: Ställer in ny avkodare topp.u1_stm32.dbg för GDB_SERVER(port=23946,alive=true)
Python >

Interagera med IDA Pro

Som indatafil för analys i IDA, för att förenkla testning, använder vi firmware "Rhinoceros" i form av EN ELF-fil (där metainformationen är lagrad).

Du kan också använda den huvudsakliga firmware utan metainformation.

Efter att Kopycat startats i IDA Pro, gå till menyn Debugger och välj "Byt debugger…» och välja «Remote GDB-debugger«. Nästa, konfigurera anslutningen: menyn Debugger — Processalternativ…

Ställ in värden:

• Application — vilket värde som helst
• Hostname: 127.0.0.1 (eller IP-adressen till den avlägsna maskinen där Kopycat körs)
• Port: 23946

Knappen för att starta debuggningsläge (tangent F9) blir nu tillgänglig:

Tryck på den — anslutning till debuggningsmodulen i emulatorn sker. IDA går in i debuggningsläge, ytterligare fönster blir tillgängliga: registerinformation, stackinformation.

Nu kan vi använda alla standardfunktioner i debuggningsverktyget:

• stegvis utförande av instruktioner (Step into och Step over — tangenterna F7 och F8, respektive);
• start och paus i utförande;
• skapa brytpunkter både på kod och data (tangent F2).

Anslutning till debuggningsverktyget innebär inte att firmwarekoden körs. Den aktuella positionen för exekvering måste vara adressen 0x08006A74 — början av funktionen Reset_Handler. Om man scrollar ner i listningen kan man se anropet till funktionen main. Man kan sätta markören på den här raden (adressen 0x08006ABE) och utföra operationen Run until cursor (tangent F4).

Därefter kan man trycka på F7 för att gå in i funktionen main.

Om man utför kommandot Continue process (tangent F9), dyker ett fönster med texten «Please wait» upp med en enda knapp Suspend:

Vid tryckning Suspend pausas utförandet av firmwarekoden och kan återupptas från samma adress i koden där det avbröts.

Om man fortsätter att köra koden kan man se följande rader i terminaler som är anslutna till virtuella COM-portar:

Närvaron av raden «state bypass» indikerar att den virtuella Bluetooth-modulen har övergått till läget för att ta emot data från användarens COM-port.

Nu kan man i Bluetooth-terminalen (i bilden — COM29) skriva kommandon enligt «Noshörnings»-protokollet. Till exempel, som svar på kommandot «MEOW» kommer Bluetooth-terminalen att returnera raden «mur-mur»:

Emulera mig inte helt

Vid konstruktionen av emulatorsystemet kan man välja graden av detaljrikedom/emulering av en viss enhet. Till exempel kan Bluetooth-modulen emuleras på olika sätt:

• hela enheten emuleras med ett komplett kommando-set;
• AT-kommandon emuleras, medan dataflödet tas emot från COM-porten i huvudsystemet;
• den virtuella enheten säkerställer fullständig omdirigering av data till den verkliga enheten;
• i form av en enkel stub som alltid returnerar «OK».

I den aktuella versionen av emulatorn används den andra metoden – en virtuell Bluetooth-modul konfigurerar, varefter den går över till att "proxies" data från COM-porten i det primära systemet till UART-porten i emulatorn.

Låt oss överväga möjligheten till enkel instrumentering av koden i fall där någon del av periferin inte är implementerad. Till exempel, om en timer som ansvarar för att kontrollera datatransmissionen i DMA inte har skapats (kontrollen görs i funktionen ws2812b_wait, som ligger på adressen 0x08006840), kommer firmware alltid att vänta på att flaggan busy, som ligger på adressen 0x200004C4, ska återställas, vilket visar aktiviteten på DMA-databussen:

Vi kan lösa denna situation genom att "manuellt" återställa flaggan busy direkt efter att den har satts. I IDA Pro kan du skapa en Python-funktion och anropa den i en breakpoint, sätta själva breakpointen i koden efter att ha skrivit värdet 1 i flaggan busy.

Breakpoint-behandlare

Först ska vi skapa en Python-funktion i IDA. Menyn File – Script command…

Lägg till ett nytt snipp i vänsterpanelen, ge den ett namn (till exempel, BPT),
och i textfältet till höger skriver vi funktionens kod:

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

Efter detta trycker vi på Run och stänger skriptfönstret.

Nu går vi till koden på adressen 0x0800688A, sätter en breakpoint (tangenten F2), redigerar den (högerklicksmenu Edit breakpoint…), glöm inte att ställa in skripttypen – Python:

Om det aktuella värdet av flaggan busy är 1, bör funktionen skip_dma anropas i skriptet:

Om du kör firmware för att exekvera, kan du se kodens breakpoint-behandlare i IDA i fönstret Output med raderna Skipping wait ws2812.... Nu kommer firmware inte att vänta på att flaggan ska återställas. busy.

Interaktion med emulatorn

Emulering för emuleringens skull kommer knappast att väcka glädje. Mycket intressantare är det om emulatorn hjälper forskaren att se data i minnet eller att sätta upp interaktion mellan trådar.

Vi ska visa hur man i realtid sätter upp interaktionen av RTOS-uppgifter. Först måste du stoppa koden om den körs. Om du går till funktionen bluetooth_task_entry i grenen hantering av kommandot "LED" (adress 0x080057B8), kan du se att en viss meddelande först skapas och sedan skickas till det systematiska kön ledControlQueueHandle .

Du bör sätta en breakpoint vid åtkomsten till variabeln ledControlQueueHandle, som ligger på adressen 0x20000624 och fortsätta körning av koden:

Som följd av detta sker först ett stopp på adressen 0x080057CA före anrop av funktionen osMailAlloc, sedan — på adressen 0x08005806 före anrop av funktionen osMailPut, sedan efter en tid — på adressen 0x08005BD4 (före anrop av funktionen osMailGet), som tillhör funktionen leds_task_entry (LED-task), det vill säga att en växling av uppgifter har ägt rum, och nu har LED-tasken fått kontrollen.

På detta enkla sätt kan man avgöra hur RTOS-uppgifter interagerar med varandra.

Självklart kan interaktionen mellan uppgifter i verkligheten vara mer komplex, men med hjälp av en emulator blir det mindre arbetskrävande att spåra denna interaktion.

Här Man kan se en kort video om att köra emulatormiljön och interagera med IDA Pro.

Körning med Radare2

Man kan inte förbise ett så mångsidigt verktyg som Radare2.

För att ansluta till emulatormiljön med hjälp av r2 kommer kommandot att se ut så här:

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

Just nu är körning (dc) och avbrytande av körning (Ctrl+C) tillgängliga.

Tyvärr finns det för närvarande problem med r2 vid användning av hårdvarugdb-servern och minnesmappning, vilket gör att punkter för stopp och Stepping (kommando ds) inte fungerar. Vi hoppas att detta kommer att åtgärdas inom kort.

Körning med Eclipse

Ett av sätten att använda emulatormiljön är att debugga firmware för den utvecklade enheten. För tydlighetens skull kommer vi även att använda firmware "Rhino". Källkoden för firmen kan laddas ner härifrån.

Som IDE kommer vi att använda Eclipse från uppsättningen System Workbench for STM32.

För att emulatormiljön ska ladda firmwaren som direkt samlas i Eclipse, måste parametern firmware=null läggas till i kommandot för att starta emulatormiljön:

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

Inställning av debug-konfiguration

I Eclipse väljer vi menyn Kör — Debug-konfigurationer… I det öppna fönstret under GDB Hardware Debugging måste en ny konfiguration läggas till, varefter aktuellt projekt och applikation för debugging anges i fliken "Main":

I fliken "Debugger" måste GDB-kommandot anges:
${openstm32_compiler_path}arm-none-eabi-gdb

Och även ange parametrar för att ansluta till GDB-servern (värd och port):

I fliken "Startup" måste följande parametrar anges:

• aktivera kryssrutan Ladda bild (så att den komprimerade firmware-bilden laddas i emulatormiljön);
• aktivera kryssrutan Ladda symboler;
• lägg till startkommando: set $pc = *0x08000004 (sätta PC-registret till värde från minne på adress 0x08000004 — där adressen lagras ResetHandler).

Observera, om du inte vill ladda firmware-filen från Eclipse, så behöver du inte ange parametrar Ladda bild och Kör kommandon behöver inte anges.

Efter att ha tryckt på Debug kan du arbeta i felsökningsläge:

• steg-för-steg körning av kod
  
• interaktion med brytpunkter
  

Anmärkning. I Eclipse finns det, hmm... vissa egenskaper... och man får leva med dem. Till exempel, om ett meddelande "Ingen källa tillgänglig för "0x0"" visas vid start av felsökaren, kör kommandot Steg (F5)

Avslutande

Emulering av nativ kod är en mycket intressant uppgift. För en enhetsutvecklare öppnar det möjlighet att felsöka firmware utan verklig enhet. För en forskare erbjuder det möjlighet att göra dynamisk kodanalys, vilket inte alltid är möjligt ens med en enhet tillgänglig.

Vi vill ge specialister ett verktyg som är bekvämt, relativt enkelt och inte tar mycket tid och kraft för att ställa in och köra.

Skriv i kommentarerna om din erfarenhet av att använda hårdvaru-emulatorer. Vi välkomnar diskussion och svarar gärna på frågor.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Vad använder du emulatören till?

• utvecklar (felsöker) firmware

• undersöker firmware

• kör spel (Dendi, Sega, PSP)

• något annat (skriv i kommentarerna)

7 användare har röstat. 2 användare avstod.

Vilken mjukvara använder du för emulering av nativ kod?

• QEMU

• Unicorn engine

• Proteus

• något annat (skriv i kommentarerna)

6 användare har röstat. 2 användare avstod.

Vad skulle du vilja förbättra i den använda emulatören?

• jag vill ha mer hastighet

• jag vill ha mer bekvämlighet i inställningar/start

• jag vill ha fler interaktionsmöjligheter med emulatören (API, hooks)

• jag är nöjd med allt

• något annat (skriv i kommentarerna)

8 användare har röstat. 1 användare avstod.

Källa: habr.com