🥇Rhinoceros inde i en kat - start firmwaren i Kopycat-emulatoren

Som en del af mødet 0x0A DC7831 DEF CON Nizhny Novgorod Den 16. februar præsenterede vi en rapport om de grundlæggende principper for binær kodeemulering og vores egen udvikling - en hardware platform emulator Copycat.

I denne artikel vil vi beskrive, hvordan du kører enhedens firmware i emulatoren, demonstrerer interaktion med debuggeren og udfører en lille dynamisk analyse af firmwaren.

forhistorie

For lang tid siden i en galakse langt langt væk

For et par år siden var der i vores laboratorium behov for at undersøge en enheds firmware. Firmwaren blev komprimeret og pakket ud med en bootloader. Han gjorde dette på en meget kompliceret måde og flyttede dataene i hukommelsen flere gange. Og selve firmwaren interagerede derefter aktivt med de eksterne enheder. Og alt dette på MIPS-kernen.

Af objektive grunde passede de tilgængelige emulatorer ikke os, men vi ville stadig køre koden. Så besluttede vi at lave vores egen emulator, som ville gøre det mindste og give os mulighed for at pakke hovedfirmwaren ud. Vi prøvede det, og det virkede. Vi tænkte, hvad nu hvis vi tilføjer periferiudstyr til også at udføre hovedfirmwaren. Det gjorde ikke særlig ondt - og det lykkedes også. Vi tænkte igen og besluttede at lave en fuldgyldig emulator.

Resultatet var en computersystememulator Copycat.

Hvorfor Kopycat?

Der er en leg med ord.

copycat (engelsk, substantiv [ˈkɒpɪkæt]) - imitator, imitator
hvordan (engelsk, navneord [ˈkæt]) - kat, kat - yndlingsdyret for en af skaberne af projektet
Bogstavet "K" er fra programmeringssproget Kotlin

Copycat

Da emulatoren blev oprettet, blev der sat meget specifikke mål:

evnen til hurtigt at skabe nye perifere enheder, moduler, processorkerner;
evnen til at samle en virtuel enhed fra forskellige moduler;
evnen til at indlæse alle binære data (firmware) i hukommelsen på en virtuel enhed;
evne til at arbejde med snapshots (snapshots af systemtilstanden);
evnen til at interagere med emulatoren gennem den indbyggede debugger;
dejligt moderne sprog til udvikling.

Som et resultat blev Kotlin valgt til implementering, busarkitekturen (det er når moduler kommunikerer med hinanden via virtuelle databusser), JSON som enhedsbeskrivelsesformat og GDB RSP som protokol for interaktion med debuggeren.

Udviklingen har stået på i lidt over to år og er aktivt i gang. I løbet af denne tid blev MIPS-, x86-, V850ES-, ARM- og PowerPC-processorkerner implementeret.

Projektet vokser, og det er tid til at præsentere det for den bredere offentlighed. Vi vil lave en detaljeret beskrivelse af projektet senere, men indtil videre fokuserer vi på at bruge Kopycat.

For de mest utålmodige kan en promo-version af emulatoren downloades fra link.

Rhino i emulatoren

Lad os huske på, at der tidligere til SMARTRHINO-2018-konferencen blev oprettet en testanordning "Rhinoceros" til undervisning i reverse engineering-færdigheder. Processen med statisk firmwareanalyse blev beskrevet i denne artikel.

Lad os nu prøve at tilføje "højttalere" og køre firmwaren i emulatoren.

Vi har brug for:
1) Java 1.8
2) Python og modul jep at bruge Python inde i emulatoren. Du kan bygge WHL-modulet Jep til Windows download her.

Til Windows:
1) com0com
2) PuTTY

For Linux:
1) socat

Du kan bruge Eclipse, IDA Pro eller radare2 som en GDB-klient.

Hvordan fungerer det?

For at udføre firmware i emulatoren er det nødvendigt at "samle" en virtuel enhed, som er en analog af en rigtig enhed.

Den rigtige enhed ("næsehorn") kan vises i blokdiagrammet:

Emulatoren har en modulær struktur, og den endelige virtuelle enhed kan beskrives i en JSON-fil.

JSON 105 linjer

{
  "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"]
  ]
}

Vær opmærksom på parameteren firmware sektion params er navnet på en fil, der kan indlæses i en virtuel enhed som firmware.

Den virtuelle enhed og dens interaktion med hovedoperativsystemet kan repræsenteres af følgende diagram:

Den aktuelle testinstans af emulatoren involverer interaktion med COM-portene på hovedoperativsystemet (fejlretning af UART og UART for Bluetooth-modulet). Disse kan være rigtige porte, som enheder er forbundet til, eller virtuelle COM-porte (til dette skal du bare bruge com0com/socat).

Der er i øjeblikket to hovedmåder at interagere med emulatoren udefra:

GDB RSP-protokol (følgelig er de værktøjer, der understøtter denne protokol, Eclipse / IDA / radare2);
intern emulator kommandolinje (Argparse eller Python).

Virtuelle COM-porte

For at kunne interagere med UART af en virtuel enhed på den lokale maskine via en terminal, skal du oprette et par tilknyttede virtuelle COM-porte. I vores tilfælde bruges en port af emulatoren, og den anden af et terminalprogram (PuTTY eller skærm):

Bruger com0com

Virtuelle COM-porte konfigureres ved hjælp af opsætningsværktøjet fra com0com-sættet (konsolversion - C:Program Files (x86)com0comsetupс.exe, eller GUI version - C:Program Files (x86)com0comsetupg.exe):

Sæt kryds i boksene aktivere bufferoverløb for alle oprettede virtuelle porte, ellers venter emulatoren på et svar fra COM-porten.

Bruger socat

På UNIX-systemer oprettes virtuelle COM-porte automatisk af emulatoren ved hjælp af socat-værktøjet; for at gøre dette skal du blot angive præfikset i portnavnet, når emulatoren startes socat:.

Intern kommandolinjegrænseflade (Argparse eller Python)

Da Kopycat er en konsolapplikation, giver emulatoren to kommandolinjegrænseflademuligheder til at interagere med dets objekter og variabler: Argparse og Python.

Argparse er en CLI indbygget i Kopycat og er altid tilgængelig for alle.

En alternativ CLI er Python-fortolkeren. For at bruge det skal du installere Jep Python-modulet og konfigurere emulatoren til at arbejde med Python (Python-fortolkeren installeret på brugerens hovedsystem vil blive brugt).

Installation af Python-modulet Jep

Under Linux kan Jep installeres via pip:

pip install jep

For at installere Jep på Windows skal du først installere Windows SDK og det tilsvarende Microsoft Visual Studio. Vi har gjort det lidt nemmere for dig og WHL bygger JEP til aktuelle versioner af Python til Windows, så modulet kan installeres fra filen:

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

For at kontrollere installationen af Jep skal du køre på kommandolinjen:

python -c "import jep"

Følgende besked skal modtages som svar:

ImportError: Jep is not supported in standalone Python, it must be embedded in Java.

I emulator-batchfilen til dit system (copycat.bat - Til Windows, copycat - for Linux) til listen over parametre DEFAULT_JVM_OPTS tilføje en ekstra parameter Djava.library.path — den skal indeholde stien til det installerede Jep-modul.

Resultatet for Windows skulle være en linje som denne:

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

Lancering af Kopycat

Emulatoren er en konsol JVM-applikation. Starten udføres gennem operativsystemets kommandolinjescript (sh/cmd).

Kommando til at køre under Windows:

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

Kommando til at køre under Linux ved hjælp af socat-værktøjet:

./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, der vil være åben for adgang til GDB-serveren;
-n rhino — navn på hovedsystemmodulet (samlet enhed);
-l user — navnet på biblioteket for at søge efter hovedmodulet;
-y library — sti til at søge efter moduler inkluderet i enheden;
firmwarerhino_pass.bin — stien til firmwarefilen;
COM26 og COM28 er virtuelle COM-porte.

Som et resultat vil der blive vist en prompt Python > (eller Argparse >):

18:07:59 INFO [eFactoryBuilder.create ]: Module top successfully created as top
18:07:59 INFO [ Module.initializeAndRes]: Setup core to top.u1_stm32.cortexm0.arm for top
18:07:59 INFO [ Module.initializeAndRes]: Setup debugger to top.u1_stm32.dbg for top
18:07:59 WARN [ Module.initializeAndRes]: Tracer wasn't found in top...
18:07:59 INFO [ Module.initializeAndRes]: Initializing ports and buses...
18:07:59 WARN [ Module.initializePortsA]: ATTENTION: Some ports has warning use printModulesPortsWarnings to see it...
18:07:59 FINE [ ARMv6CPU.reset ]: Set entry point address to 08006A75
18:07:59 INFO [ Module.initializeAndRes]: Module top is successfully initialized and reset as a top cell!
18:07:59 INFO [ Kopycat.open ]: Starting virtualization of board top[rhino] with arm[ARMv6Core]
18:07:59 INFO [ GDBServer.debuggerModule ]: Set new debugger module top.u1_stm32.dbg for GDB_SERVER(port=23946,alive=true)
Python >

Interaktion med IDA Pro

For at forenkle testning bruger vi Rhino-firmwaren som kildefil til analyse i IDA i formen ELF fil (metainformation gemmes der).

Du kan også bruge hovedfirmwaren uden metainformation.

Efter lancering af Kopycat i IDA Pro skal du i Fejlfindingsmenuen gå til punktet "Skift debugger..." og vælg "Fjern GDB debugger". Konfigurer derefter menuen forbindelse: Debugger - Procesmuligheder...

Indstil værdierne:

Anvendelse - enhver værdi
Værtsnavn: 127.0.0.1 (eller IP-adressen på den eksterne maskine, hvor Kopycat kører)
Port: 23946

Nu bliver fejlfindingsknappen tilgængelig (F9-tast):

Klik på den for at oprette forbindelse til debugger-modulet i emulatoren. IDA går i fejlfindingstilstand, yderligere vinduer bliver tilgængelige: information om registre, om stakken.

Nu kan vi bruge alle debuggerens standardfunktioner:

trin-for-trin udførelse af instruktioner (Træder ind и Træd over — tasterne F7 og F8, henholdsvis);
start og pause af eksekvering;
oprette brudpunkter for både kode og data (F2-tast).

At oprette forbindelse til en debugger betyder ikke at køre firmwarekoden. Den aktuelle udførelsesposition skal være adressen 0x08006A74 — start af funktion Reset_Handler. Hvis du ruller ned i listen, kan du se funktionsopkaldet main. Du kan placere markøren på denne linje (adresse 0x08006ABE) og udfør handlingen Kør indtil markøren (tast F4).

Dernæst kan du trykke på F7 for at gå ind i funktionen main.

Hvis du kører kommandoen Fortsæt processen (F9-tast), så vises vinduet "Vent venligst" med en enkelt knap Suspender:

Når du trykker på Suspender udførelse af firmwarekoden er suspenderet og kan fortsættes fra den samme adresse i koden, hvor den blev afbrudt.

Hvis du fortsætter med at udføre koden, vil du se følgende linjer i terminalerne forbundet til de virtuelle COM-porte:

Tilstedeværelsen af "state bypass"-linjen indikerer, at det virtuelle Bluetooth-modul er skiftet til tilstanden til at modtage data fra brugerens COM-port.

Nu i Bluetooth-terminalen (COM29 på billedet) kan du indtaste kommandoer i overensstemmelse med Rhino-protokollen. For eksempel vil "MEOW"-kommandoen returnere strengen "mur-mur" til Bluetooth-terminalen:

Efterlign mig ikke helt

Når du bygger en emulator, kan du vælge detaljeringsniveauet/emuleringen af en bestemt enhed. For eksempel kan Bluetooth-modulet emuleres på forskellige måder:

enheden er fuldt emuleret med et komplet sæt kommandoer;
AT-kommandoer emuleres, og datastrømmen modtages fra COM-porten på hovedsystemet;
den virtuelle enhed giver fuldstændig dataomdirigering til den rigtige enhed;
som en simpel stub, der altid returnerer "OK".

Den nuværende version af emulatoren bruger den anden tilgang - det virtuelle Bluetooth-modul udfører konfiguration, hvorefter det skifter til tilstanden for "proxying" af data fra COM-porten på hovedsystemet til UART-porten på emulatoren.

Lad os overveje muligheden for simpel instrumentering af koden, hvis en del af periferien ikke er implementeret. For eksempel, hvis der ikke er oprettet en timer, der er ansvarlig for at styre dataoverførslen til DMA (kontrollen udføres i funktionen ws2812b_waitplaceret kl 0x08006840), så vil firmwaren altid vente på, at flaget nulstilles travltplaceret kl 0x200004C4som viser belægningen af DMA-datalinjen:

Vi kan omgå denne situation ved manuelt at nulstille flaget travlt umiddelbart efter installationen. I IDA Pro kan du oprette en Python-funktion og kalde den i et breakpoint, og sætte selve breakpointet i koden efter at have skrevet værdien 1 til flaget travlt.

Breakpoint handler

Lad os først oprette en Python-funktion i IDA. Menu Fil - Script kommando...

Tilføj et nyt uddrag på listen til venstre, giv det et navn (f.eks. BPT),
Indtast funktionskoden i tekstfeltet til højre:

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

Derefter trykker vi Kør og luk scriptvinduet.

Lad os nu gå til koden kl 0x0800688A, indstil et brudpunkt (F2-tast), rediger det (kontekstmenu Rediger pausepunkt...), glem ikke at indstille scripttypen til Python:

Hvis den aktuelle flagværdi travlt er lig med 1, så skal du udføre funktionen skip_dma i scriptlinjen:

Hvis du kører firmwaren til udførelse, kan du se udløsningen af breakpoint handler-koden i IDA-vinduet Produktion efter linje Skipping wait ws2812.... Nu vil firmwaren ikke vente på, at flaget nulstilles travlt.

Interaktion med emulatoren

Det er usandsynligt, at emulering for emuleringens skyld forårsager glæde og glæde. Det er meget mere interessant, hvis emulatoren hjælper forskeren med at se dataene i hukommelsen eller etablere interaktionen mellem tråde.

Vi viser dig, hvordan du dynamisk etablerer interaktion mellem RTOS-opgaver. Du bør først pause udførelsen af koden, hvis den kører. Hvis du går til funktionen bluetooth_task_entry til behandlingsgrenen af "LED"-kommandoen (adresse 0x080057B8), så kan du se, hvad der først oprettes og derefter sendes til systemkøen ledControlQueueHandle en eller anden besked.

Du bør indstille et brudpunkt for at få adgang til variablen ledControlQueueHandleplaceret kl 0x20000624 og fortsæt med at udføre koden:

Som følge heraf vil stoppet først ske på adressen 0x080057CA før du kalder funktionen osMailAlloc, derefter på adressen 0x08005806 før du kalder funktionen osMailPut, så efter et stykke tid - til adressen 0x08005BD4 (før du kalder funktionen osMailGet), som hører til funktionen leds_task_entry (LED-opgave), det vil sige, at opgaverne skiftede, og nu fik LED-opgaven kontrol.

På denne enkle måde kan du etablere, hvordan RTOS-opgaver interagerer med hinanden.

Selvfølgelig kan samspillet mellem opgaver i virkeligheden være mere kompliceret, men ved at bruge en emulator bliver det mindre besværligt at spore denne interaktion.

Her Du kan se en kort video af emulatorens start og interaktion med IDA Pro.

Start med Radare2

Du kan ikke ignorere et så universelt værktøj som Radare2.

For at oprette forbindelse til emulatoren ved hjælp af r2, vil kommandoen se sådan ud:

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

Lancering tilgængelig nu (dc) og pause udførelse (Ctrl+C).

Desværre har r2 i øjeblikket problemer med at arbejde med hardware-gdb-serveren og hukommelseslayoutet; på grund af dette virker breakpoints og Steps ikke (kommando ds). Vi håber, at dette snart bliver rettet.

Kører med Eclipse

En af mulighederne for at bruge emulatoren er at fejlsøge firmwaren på den enhed, der udvikles. For klarhedens skyld vil vi også bruge Rhino-firmwaren. Du kan downloade firmwarekilderne dermed.

Vi vil bruge Eclipse fra sættet som en IDE System Workbench til STM32.

For at emulatoren kan indlæse firmware direkte kompileret i Eclipse, skal du tilføje parameteren firmware=null til emulatorstartkommandoen:

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

Opsætning af fejlfindingskonfiguration

I Eclipse skal du vælge menuen Kør - Debug konfigurationer... I det vindue, der åbnes, i afsnittet GDB Hardware Debugging du skal tilføje en ny konfiguration, og derefter på fanen "Main" specificer det aktuelle projekt og applikation til fejlretning:

På fanen "Debugger" skal du angive GDB-kommandoen:
${openstm32_compiler_path}arm-none-eabi-gdb

Og indtast også parametrene for at oprette forbindelse til GDB-serveren (vært og port):

På fanen "Startup" skal du angive følgende parametre:

aktivere afkrydsningsfeltet Indlæs billede (sådan det samlede firmwarebillede indlæses i emulatoren);
aktivere afkrydsningsfeltet Indlæs symboler;
Tilføj startkommando: set $pc = *0x08000004 (indstil pc-registret til værdien fra hukommelsen på adressen 0x08000004 - adressen er gemt der ResetHandler).

Bemærk venligst, hvis du ikke ønsker at downloade firmwarefilen fra Eclipse, skal du vælge mulighederne Indlæs billede и Kør kommandoer ingen grund til at angive.

Når du har klikket på Debug, kan du arbejde i fejlretningstilstand:

trin for trin kodeudførelse
interagere med brudpunkter

Bemærk. Eclipse har, hmm... nogle særheder... og dem må du leve med. For eksempel, hvis meddelelsen "Ingen kilde tilgængelig for "0x0″" vises, når du starter debuggeren, skal du udføre trin-kommandoen (F5)

I stedet for en konklusion

At emulere native kode er en meget interessant ting. Det bliver muligt for en enhedsudvikler at debugge firmwaren uden en rigtig enhed. For en forsker er det en mulighed for at udføre dynamisk kodeanalyse, hvilket ikke altid er muligt selv med en enhed.

Vi ønsker at give specialister et værktøj, der er praktisk, moderat simpelt og ikke tager en masse kræfter og tid at installere og køre.

Skriv i kommentarerne om din oplevelse med at bruge hardwareemulatorer. Vi inviterer dig til at diskutere og vil med glæde besvare spørgsmål.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Hvad bruger du emulatoren til?

Jeg udvikler (debugger) firmware
Jeg undersøger firmware
Jeg starter spil (Dendi, Sega, PSP)
noget andet (skriv i kommentarerne)

7 brugere stemte. 2 brugere undlod at stemme.

Hvilken software bruger du til at emulere native kode?

QEMU
Unicorn motor
Proteus
noget andet (skriv i kommentarerne)

6 brugere stemte. 2 brugere undlod at stemme.

Hvad vil du gerne forbedre i den emulator, du bruger?

Jeg vil have fart
Jeg vil have nem opsætning/start
Jeg vil have flere muligheder for at interagere med emulatoren (API, kroge)
Jeg er glad for alt
noget andet (skriv i kommentarerne)

8 brugere stemte. 1 bruger undlod at stemme.

Kilde: www.habr.com

Rhinoceros inde i en kat - kør firmwaren i Kopycat-emulatoren