Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Som en del av møtet 0x0A DC7831 DEF CON Nizhny Novgorod 16. februar presenterte vi en rapport om de grunnleggende prinsippene for binær kodeemulering og vår egen utvikling - en maskinvareplattformemulator Copycat.

I denne artikkelen vil vi beskrive hvordan du kjører enhetens fastvare i emulatoren, demonstrerer interaksjon med debuggeren og utfører en liten dynamisk analyse av fastvaren.

forhistorie

For lenge siden i en galakse langt langt unna

For et par år siden i vårt laboratorium var det behov for å undersøke fastvaren til en enhet. Fastvaren ble komprimert og pakket ut med en bootloader. Han gjorde dette på en veldig komplisert måte, og flyttet dataene i minnet flere ganger. Og selve fastvaren samhandlet da aktivt med periferiutstyret. Og alt dette på MIPS-kjernen.

Av objektive grunner passet ikke de tilgjengelige emulatorene oss, men vi ønsket fortsatt å kjøre koden. Så bestemte vi oss for å lage vår egen emulator, som ville gjøre det minste og tillate oss å pakke ut hovedfastvaren. Vi prøvde det og det fungerte. Vi tenkte, hva om vi legger til eksterne enheter for også å utføre hovedfastvaren. Det gjorde ikke særlig vondt - og det ordnet seg også. Vi tenkte om igjen og bestemte oss for å lage en fullverdig emulator.

Resultatet var en datasystememulator Copycat.

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren
Hvorfor Kopycat?

Det er et ordspill.

  1. copycat (engelsk, substantiv [ˈkɒpɪkæt]) - imitator, imitator
  2. hvordan (engelsk, substantiv [ˈkæt]) - katt, katt - favorittdyret til en av skaperne av prosjektet
  3. Bokstaven "K" er fra programmeringsspråket Kotlin

Copycat

Når du opprettet emulatoren, ble det satt veldig spesifikke mål:

  • muligheten til å raskt lage nye periferiutstyr, moduler, prosessorkjerner;
  • muligheten til å sette sammen en virtuell enhet fra forskjellige moduler;
  • muligheten til å laste alle binære data (fastvare) inn i minnet til en virtuell enhet;
  • evne til å jobbe med øyeblikksbilder (øyeblikksbilder av systemtilstanden);
  • muligheten til å samhandle med emulatoren gjennom den innebygde debuggeren;
  • fint moderne språk for utvikling.

Som et resultat ble Kotlin valgt for implementering, bussarkitekturen (dette er når moduler kommuniserer med hverandre via virtuelle databusser), JSON som enhetsbeskrivelsesformat og GDB RSP som protokoll for interaksjon med debuggeren.

Utviklingen har pågått i litt over to år og pågår aktivt. I løpet av denne tiden ble MIPS-, x86-, V850ES-, ARM- og PowerPC-prosessorkjerner implementert.

Prosjektet vokser og det er på tide å presentere det for et bredere publikum. Vi vil gjøre en detaljert beskrivelse av prosjektet senere, men foreløpig vil vi fokusere på å bruke Kopycat.

For de mest utålmodige kan en promoversjon av emulatoren lastes ned fra link.

Rhino i emulatoren

La oss huske at tidligere for SMARTRHINO-2018-konferansen ble det opprettet en testenhet "Rhinoceros" for å lære om reverse engineering-ferdigheter. Prosessen med statisk fastvareanalyse ble beskrevet i denne artikkelen.

La oss nå prøve å legge til "høyttalere" og kjøre fastvaren i emulatoren.

Vi trenger:
1) Java 1.8
2) Python og modul Jepp å bruke Python inne i emulatoren. Du kan bygge WHL-modulen Jep for Windows Last ned her.

For Windows:
1) com0com
2) PuTTY

For Linux:
1) socat

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

Hvordan virker det?

For å utføre fastvare i emulatoren, er det nødvendig å "montere" en virtuell enhet, som er en analog av en ekte enhet.

Den virkelige enheten ("neshorn") kan vises i blokkskjemaet:

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Emulatoren har en modulær struktur og den endelige virtuelle enheten 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 oppmerksom på parameteren firmware seksjon params er navnet på en fil som kan lastes inn i en virtuell enhet som fastvare.

Den virtuelle enheten og dens interaksjon med hovedoperativsystemet kan representeres av følgende diagram:

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Den nåværende testforekomsten av emulatoren involverer interaksjon med COM-portene til hovedoperativsystemet (feilsøke UART og UART for Bluetooth-modulen). Dette kan være ekte porter som enheter er koblet til eller virtuelle COM-porter (for dette trenger du bare com0com/socat).

Det er for øyeblikket to hovedmåter å samhandle med emulatoren fra utsiden:

  • GDB RSP-protokoll (følgelig er verktøyene som støtter denne protokollen Eclipse / IDA / radare2);
  • intern emulator-kommandolinje (Argparse eller Python).

Virtuelle COM-porter

For å samhandle med UART til en virtuell enhet på den lokale maskinen via en terminal, må du opprette et par tilknyttede virtuelle COM-porter. I vårt tilfelle brukes en port av emulatoren, og den andre brukes av et terminalprogram (PuTTY eller skjerm):

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Bruker com0com

Virtuelle COM-porter konfigureres ved hjelp av oppsettverktøyet fra com0com-settet (konsollversjon - C:Program Files (x86)com0comsetupс.exe, eller GUI-versjon - C:Program Files (x86)com0comsetupg.exe):

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Kryss av i boksene aktivere bufferoverløp for alle opprettede virtuelle porter, ellers vil emulatoren vente på svar fra COM-porten.

Bruker socat

På UNIX-systemer opprettes virtuelle COM-porter automatisk av emulatoren ved å bruke socat-verktøyet; for å gjøre dette, spesifiser du bare prefikset i portnavnet når du starter emulatoren socat:.

Internt kommandolinjegrensesnitt (Argparse eller Python)

Siden Kopycat er en konsollapplikasjon, gir emulatoren to kommandolinjegrensesnittalternativer for å samhandle med objektene og variablene: Argparse og Python.

Argparse er en CLI innebygd i Kopycat og er alltid tilgjengelig for alle.

En alternativ CLI er Python-tolken. For å bruke den må du installere Jep Python-modulen og konfigurere emulatoren til å fungere med Python (Python-tolken som er installert på brukerens hovedsystem vil bli brukt).

Installere Python-modulen Jep

Under Linux kan Jep installeres via pip:

pip install jep

For å installere Jep på Windows, må du først installere Windows SDK og det tilsvarende Microsoft Visual Studio. Vi har gjort det litt enklere for deg og WHL bygger JEP for gjeldende versjoner av Python for Windows, slik at modulen kan installeres fra filen:

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

For å sjekke installasjonen av Jep, må du kjøre på kommandolinjen:

python -c "import jep"

Følgende melding skal mottas som svar:

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

I emulatorbatchfilen for systemet ditt (copycat.bat - for Windows, copycat - for Linux) til listen over parametere DEFAULT_JVM_OPTS legge til en ekstra parameter Djava.library.path — den må inneholde banen til den installerte Jep-modulen.

Resultatet for Windows skal være en linje som dette:

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

Lanserer Kopycat

Emulatoren er en konsoll JVM-applikasjon. Lanseringen utføres gjennom operativsystemets kommandolinjeskript (sh/cmd).

Kommando for å kjøre under Windows:

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

Kommando for å kjøre under Linux ved å bruke socat-verktøyet:

./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 som vil være åpen for tilgang til GDB-serveren;
  • -n rhino — navn på hovedsystemmodulen (montert enhet);
  • -l user — navnet på biblioteket for å søke etter hovedmodulen;
  • -y library — bane for å søke etter moduler som er inkludert i enheten;
  • firmwarerhino_pass.bin — bane til fastvarefilen;
  • COM26 og COM28 er virtuelle COM-porter.

Som et resultat vil en melding vises 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 >

Interaksjon med IDA Pro

For å forenkle testingen bruker vi Rhino-fastvaren som kildefil for analyse i IDA i skjemaet ELF-fil (metainformasjon lagres der).

Du kan også bruke hovedfastvaren uten metainformasjon.

Etter å ha lansert Kopycat i IDA Pro, i Debugger-menyen går du til elementet "Bytt debugger..." og velg "Ekstern GDB-feilsøker". Deretter setter du opp tilkoblingen:-menyen Debugger – prosessalternativer...

Still inn verdiene:

  • Søknad - hvilken som helst verdi
  • Vertsnavn: 127.0.0.1 (eller IP-adressen til den eksterne maskinen der Kopycat kjører)
  • Port: 23946

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Nå blir feilsøkingsknappen tilgjengelig (F9-tast):

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Klikk på den for å koble til feilsøkingsmodulen i emulatoren. IDA går inn i feilsøkingsmodus, flere vinduer blir tilgjengelige: informasjon om registre, om stabelen.

Nå kan vi bruke alle standardfunksjonene til feilsøkeren:

  • trinnvis utførelse av instruksjoner (Gå inn i и Tråkke over - tastene F7 og F8, henholdsvis);
  • start og pause utførelse;
  • lage bruddpunkter for både kode og data (F2-tast).

Å koble til en debugger betyr ikke å kjøre fastvarekoden. Gjeldende utførelsesposisjon må være adressen 0x08006A74 — start av funksjon Reset_Handler. Hvis du blar nedover listen, kan du se funksjonsanropet main. Du kan plassere markøren på denne linjen (adresse 0x08006ABE) og utfør operasjonen Kjør til markøren (tast F4).

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Deretter kan du trykke F7 for å gå inn i funksjonen main.

Hvis du kjører kommandoen Fortsett prosessen (F9-tast), så vil "Vennligst vent"-vinduet vises med en enkelt knapp suspendere:

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Når du trykker suspendere utførelse av fastvarekoden er suspendert og kan fortsette fra samme adresse i koden der den ble avbrutt.

Hvis du fortsetter å kjøre koden, vil du se følgende linjer i terminalene som er koblet til de virtuelle COM-portene:

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Tilstedeværelsen av "state bypass"-linjen indikerer at den virtuelle Bluetooth-modulen har byttet til modusen for å motta data fra brukerens COM-port.

Nå i Bluetooth-terminalen (COM29 på bildet) kan du legge inn kommandoer i henhold til Rhino-protokollen. For eksempel vil "MEOW"-kommandoen returnere strengen "mur-mur" til Bluetooth-terminalen:

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Etterligne meg ikke helt

Når du bygger en emulator, kan du velge detaljnivå/emulering for en bestemt enhet. For eksempel kan Bluetooth-modulen emuleres på forskjellige måter:

  • enheten er fullstendig emulert med et komplett sett med kommandoer;
  • AT-kommandoer emuleres, og datastrømmen mottas fra COM-porten til hovedsystemet;
  • den virtuelle enheten gir fullstendig dataomdirigering til den virkelige enheten;
  • som en enkel stubb som alltid returnerer "OK".

Den nåværende versjonen av emulatoren bruker den andre tilnærmingen - den virtuelle Bluetooth-modulen utfører konfigurasjon, hvoretter den bytter til modusen for å "proxy" data fra COM-porten til hovedsystemet til UART-porten til emulatoren.

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

La oss vurdere muligheten for enkel instrumentering av koden i tilfelle en del av periferien ikke er implementert. For eksempel, hvis en tidtaker som er ansvarlig for å kontrollere dataoverføringen til DMA ikke er opprettet (kontrollen utføres i funksjonen ws2812b_waitligger ved 0x08006840), vil fastvaren alltid vente på at flagget skal tilbakestilles opptattligger ved 0x200004C4som viser belegget på DMA-datalinjen:

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Vi kan omgå denne situasjonen ved å tilbakestille flagget manuelt opptatt umiddelbart etter installasjon. I IDA Pro kan du lage en Python-funksjon og kalle den i et bruddpunkt, og sette selve bruddpunktet i koden etter å ha skrevet verdien 1 til flagget opptatt.

Knekkpunktbehandler

Først, la oss lage en Python-funksjon i IDA. Meny Fil - Skript-kommando...

Legg til en ny kodebit i listen til venstre, gi den et navn (f.eks. BPT),
I tekstfeltet til høyre skriver du inn funksjonskoden:

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

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Etter det trykker vi Kjør og lukk skriptvinduet.

La oss nå gå til koden på 0x0800688A, angi et bruddpunkt (F2-tast), rediger det (kontekstmeny Rediger bruddpunkt...), ikke glem å sette skripttypen til Python:

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren
Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Hvis gjeldende flaggverdi opptatt lik 1, så bør du utføre funksjonen skip_dma i skriptlinjen:

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Hvis du kjører fastvaren for kjøring, kan utløsningen av bruddpunktbehandlerkoden sees i IDA-vinduet Produksjon etter linje Skipping wait ws2812.... Nå vil ikke fastvaren vente på at flagget skal tilbakestilles opptatt.

Interaksjon med emulatoren

Emulering for emuleringens skyld vil neppe forårsake glede og glede. Det er mye mer interessant hvis emulatoren hjelper forskeren med å se dataene i minnet eller etablere interaksjonen mellom tråder.

Vi vil vise deg hvordan du dynamisk etablerer interaksjon mellom RTOS-oppgaver. Du bør først sette kjøringen av koden på pause hvis den kjører. Hvis du går til funksjonen bluetooth_task_entry til behandlingsgrenen til "LED"-kommandoen (adresse 0x080057B8), så kan du se hva som først er opprettet og deretter sendt til systemkøen ledControlQueueHandle noen melding.

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Du bør angi et bruddpunkt for å få tilgang til variabelen ledControlQueueHandleligger ved 0x20000624 og fortsett å kjøre koden:

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Som et resultat vil stoppet først skje på adressen 0x080057CA før du kaller opp funksjonen osMailAlloc, deretter på adressen 0x08005806 før du kaller opp funksjonen osMailPut, så etter en stund - til adressen 0x08005BD4 (før du ringer opp funksjonen osMailGet), som hører til funksjonen leds_task_entry (LED-oppgave), det vil si at oppgavene byttet, og nå fikk LED-oppgaven kontroll.

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

På denne enkle måten kan du etablere hvordan RTOS-oppgaver samhandler med hverandre.

Selvfølgelig, i virkeligheten, kan samspillet mellom oppgaver være mer komplisert, men ved å bruke en emulator blir det mindre arbeidskrevende å spore denne interaksjonen.

Her Du kan se en kort video av emulatoren som starter og samhandler med IDA Pro.

Start med Radare2

Du kan ikke ignorere et så universelt verktøy som Radare2.

For å koble til emulatoren ved hjelp av r2, vil kommandoen se slik ut:

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

Lansering tilgjengelig nå (dc) og sett kjøringen på pause (Ctrl+C).

Dessverre, for øyeblikket, har r2 problemer når du arbeider med maskinvare-gdb-serveren og minneoppsettet; på grunn av dette fungerer ikke bruddpunkter og trinn (kommando ds). Vi håper dette blir fikset snart.

Kjører med Eclipse

Et av alternativene for å bruke emulatoren er å feilsøke fastvaren til enheten som utvikles. For klarhetens skyld vil vi også bruke Rhino-fastvaren. Du kan laste ned fastvarekildene derav.

Vi vil bruke Eclipse fra settet som en IDE System Workbench for STM32.

For at emulatoren skal laste fastvaren direkte kompilert i Eclipse, må du legge til parameteren firmware=null til emulatorstartkommandoen:

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

Setter opp feilsøkingskonfigurasjon

I Eclipse velger du menyen Kjør - Feilsøkingskonfigurasjoner... I vinduet som åpnes, i seksjonen GDB maskinvarefeilsøking du må legge til en ny konfigurasjon, og deretter på "Hoved"-fanen spesifiser det nåværende prosjektet og programmet for feilsøking:

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

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

Og skriv også inn parameterne for å koble til GDB-serveren (vert og port):

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

På fanen "Oppstart" må du spesifisere følgende parametere:

  • aktiver avkrysningsboksen Last inn bildet (slik at det sammensatte fastvarebildet lastes inn i emulatoren);
  • aktiver avkrysningsboksen Last inn symboler;
  • legg til startkommando: set $pc = *0x08000004 (sett PC-registeret til verdien fra minnet på adressen 0x08000004 - adressen er lagret der ResetHandler).

Vær oppmerksom, hvis du ikke vil laste ned fastvarefilen fra Eclipse, så alternativene Last inn bildet и Kjør kommandoer ikke nødvendig å indikere.

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Etter å ha klikket Feilsøking, kan du jobbe i feilsøkingsmodus:

  • trinn for trinn kodeutførelse
    Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren
  • samhandle med bruddpunkter
    Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

Note. Eclipse har, hmm... noen særheter... og du må leve med dem. For eksempel, hvis meldingen "Ingen kilde tilgjengelig for "0x0" vises når du starter feilsøkeren, utfør trinnkommandoen (F5)

Neshorn inne i en katt - kjør fastvaren i Kopycat-emulatoren

I stedet for en konklusjon

Å emulere innfødt kode er en veldig interessant ting. Det blir mulig for en enhetsutvikler å feilsøke fastvaren uten en ekte enhet. For en forsker er det en mulighet til å utføre dynamisk kodeanalyse, noe som ikke alltid er mulig selv med en enhet.

Vi ønsker å gi spesialister et verktøy som er praktisk, moderat enkelt og som ikke tar mye krefter og tid å sette opp og kjøre.

Skriv i kommentarene om din erfaring med maskinvareemulatorer. Vi inviterer deg til å diskutere og svarer gjerne på spørsmål.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Hva bruker du emulatoren til?

  • Jeg utvikler (feilsøker) fastvare

  • Jeg undersøker fastvare

  • Jeg lanserer spill (Dendi, Sega, PSP)

  • noe annet (skriv i kommentarfeltet)

7 brukere stemte. 2 brukere avsto.

Hvilken programvare bruker du for å emulere innfødt kode?

  • QEMU

  • Unicorn motor

  • Proteus

  • noe annet (skriv i kommentarfeltet)

6 brukere stemte. 2 brukere avsto.

Hva vil du forbedre i emulatoren du bruker?

  • Jeg vil ha fart

  • Jeg vil ha enkel oppsett/lansering

  • Jeg vil ha flere alternativer for å samhandle med emulatoren (API, kroker)

  • Jeg er fornøyd med alt

  • noe annet (skriv i kommentarfeltet)

8 brukere stemte. 1 bruker avsto.

Kilde: www.habr.com

Legg til en kommentar