Neushoorn in een kat - voer de firmware uit in de Kopycat-emulator

Als onderdeel van de vergadering 0x0A DC7831 DEF CON Nizjni Novgorod Op 16 februari presenteerden we een rapport over de basisprincipes van binaire code-emulatie en onze eigen ontwikkeling: een hardwareplatformemulator Copycat.

In dit artikel beschrijven we hoe u de apparaatfirmware in de emulator uitvoert, de interactie met de debugger demonstreert en een kleine dynamische analyse van de firmware uitvoert.

prehistorie

Lang geleden in een sterrenstelsel ver ver weg

Een paar jaar geleden was er in ons laboratorium behoefte om de firmware van een apparaat te onderzoeken. De firmware werd gecomprimeerd en uitgepakt met een bootloader. Hij deed dit op een zeer ingewikkelde manier, waarbij hij de gegevens in het geheugen verschillende keren verschoof. En de firmware zelf communiceerde vervolgens actief met de randapparatuur. En dit alles op de MIPS-kern.

Om objectieve redenen waren de beschikbare emulators niet geschikt voor ons, maar we wilden toch de code uitvoeren. Toen besloten we om onze eigen emulator te maken, die het minimum zou doen en ons in staat zou stellen de hoofdfirmware uit te pakken. Wij hebben het geprobeerd en het werkte. We dachten: wat als we randapparatuur toevoegen om ook de hoofdfirmware uit te voeren. Het deed niet veel pijn - en het werkte ook. We dachten er nog eens over na en besloten een volwaardige emulator te maken.

Het resultaat was een emulator voor computersystemen Copycat.

Waarom Kopycat?

Er is sprake van een woordspeling.

1. copycat (Engels, zelfstandig naamwoord [kɒpɪkæt]) - imitator, imitator
2. hoe (Engels, zelfstandig naamwoord [ˈkæt]) - kat, kat - het favoriete dier van een van de makers van het project
3. De letter “K” komt uit de programmeertaal Kotlin

Copycat

Bij het maken van de emulator werden zeer specifieke doelen gesteld:

• de mogelijkheid om snel nieuwe randapparatuur, modules en processorkernen te maken;
• de mogelijkheid om uit verschillende modules een virtueel apparaat samen te stellen;
• de mogelijkheid om binaire gegevens (firmware) in het geheugen van een virtueel apparaat te laden;
• mogelijkheid om met snapshots te werken (snapshots van de systeemstatus);
• de mogelijkheid om met de emulator te communiceren via de ingebouwde debugger;
• mooie moderne taal voor ontwikkeling.

Als gevolg hiervan werd Kotlin gekozen voor de implementatie, de busarchitectuur (dit is wanneer modules met elkaar communiceren via virtuele databussen), JSON als apparaatbeschrijvingsformaat en GDB RSP als het protocol voor interactie met de debugger.

De ontwikkeling is al iets meer dan twee jaar aan de gang en is actief aan de gang. Gedurende deze tijd werden MIPS-, x86-, V850ES-, ARM- en PowerPC-processorkernen geïmplementeerd.

Het project groeit en het is tijd om het aan het bredere publiek te presenteren. We zullen later een gedetailleerde beschrijving van het project geven, maar voor nu zullen we ons concentreren op het gebruik van Kopycat.

Voor de meest ongeduldigen kan een promoversie van de emulator worden gedownload van link.

Neushoorn in de emulator

Laten we niet vergeten dat eerder voor de SMARTRHINO-2018-conferentie een testapparaat “Rhinoceros” werd gemaakt voor het aanleren van reverse engineering-vaardigheden. Het proces van statische firmware-analyse werd beschreven in dit artikel.

Laten we nu proberen “luidsprekers” toe te voegen en de firmware in de emulator uit te voeren.

Wij hebben nodig:
1) Java1.8
2) Python en module jep om Python in de emulator te gebruiken. U kunt de WHL-module Jep voor Windows bouwen download hier.

Для Vensters:
1) com0com
2) PuTTY

Voor Linux:
1) socat

U kunt Eclipse, IDA Pro of radare2 gebruiken als GDB-client.

Hoe werkt het?

Om firmware in de emulator uit te voeren, is het noodzakelijk om een ​​virtueel apparaat te "assembleren", dat analoog is aan een echt apparaat.

Het echte apparaat (“neushoorn”) kan worden weergegeven in het blokdiagram:

De emulator heeft een modulaire structuur en het uiteindelijke virtuele apparaat kan worden beschreven in een JSON-bestand.

JSON 105-regels

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

Let op de parameter firmware sectie params is de naam van een bestand dat als firmware in een virtueel apparaat kan worden geladen.

Het virtuele apparaat en zijn interactie met het hoofdbesturingssysteem kunnen worden weergegeven door het volgende diagram:

Het huidige testexemplaar van de emulator omvat interactie met de COM-poorten van het hoofdbesturingssysteem (debug UART en UART voor de Bluetooth-module). Dit kunnen echte poorten zijn waarop apparaten zijn aangesloten of virtuele COM-poorten (hiervoor heeft u alleen nodig com0com/socat).

Er zijn momenteel twee manieren om van buitenaf met de emulator te communiceren:

• GDB RSP-protocol (dienovereenkomstig zijn de tools die dit protocol ondersteunen Eclipse / IDA / radare2);
• interne emulator-opdrachtregel (Argparse of Python).

Virtuele COM-poorten

Om via een terminal te kunnen communiceren met de UART van een virtueel apparaat op de lokale machine, moet u een paar bijbehorende virtuele COM-poorten creëren. In ons geval wordt één poort gebruikt door de emulator en de tweede door een terminalprogramma (PuTTY of screen):

Com0com gebruiken

Virtuele COM-poorten worden geconfigureerd met behulp van het installatieprogramma van de com0com-kit (consoleversie - C: Programmabestanden (x86) com0comsetupс.exe, of GUI-versie - C: Programmabestanden (x86) com0comsetupg.exe):

Controleer de dozen bufferoverloop inschakelen voor alle aangemaakte virtuele poorten, anders wacht de emulator op een reactie van de COM-poort.

Socat gebruiken

Op UNIX-systemen worden virtuele COM-poorten automatisch aangemaakt door de emulator met behulp van het socat-hulpprogramma; om dit te doen hoeft u alleen maar het voorvoegsel in de poortnaam op te geven bij het starten van de emulator socat:.

Interne opdrachtregelinterface (Argparse of Python)

Omdat Kopycat een consoletoepassing is, biedt de emulator twee opdrachtregelinterface-opties voor interactie met de objecten en variabelen: Argparse en Python.

Argparse is een CLI die in Kopycat is ingebouwd en altijd voor iedereen beschikbaar is.

Een alternatieve CLI is de Python-interpreter. Om het te gebruiken, moet je de Jep Python-module installeren en de emulator configureren om met Python te werken (de Python-interpreter die op het hoofdsysteem van de gebruiker is geïnstalleerd, zal worden gebruikt).

Installeren van de Python-module Jep

Onder Linux kan Jep via pip worden geïnstalleerd:

pip install jep

Om Jep op Windows te installeren, moet u eerst de Windows SDK en de bijbehorende Microsoft Visual Studio installeren. We hebben het iets makkelijker voor je gemaakt en WHL bouwt JEP voor huidige versies van Python voor Windows, zodat de module vanuit het bestand kan worden geïnstalleerd:

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

Om de installatie van Jep te controleren, moet u op de opdrachtregel uitvoeren:

python -c "import jep"

Als antwoord moet het volgende bericht worden ontvangen:

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

In het emulatorbatchbestand voor uw systeem (copycat.bat - voor ramen, copycat - voor Linux) toe aan de lijst met parameters DEFAULT_JVM_OPTS voeg een extra parameter toe Djava.library.path — het moet het pad naar de geïnstalleerde Jep-module bevatten.

Het resultaat voor Windows zou er als volgt uit moeten zien:

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

Kopycat lanceren

De emulator is een console-JVM-applicatie. De lancering wordt uitgevoerd via het opdrachtregelscript van het besturingssysteem (sh/cmd).

Commando om onder Windows uit te voeren:

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

Commando om onder Linux uit te voeren met behulp van het socat-hulpprogramma:

./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-poort die open zal zijn voor toegang tot de GDB-server;
• -n rhino — naam van de hoofdsysteemmodule (geassembleerd apparaat);
• -l user — naam van de bibliotheek waar naar de hoofdmodule wordt gezocht;
• -y library — pad om te zoeken naar modules die in het apparaat zijn opgenomen;
• firmwarerhino_pass.bin — pad naar het firmwarebestand;
• COM26 en COM28 zijn virtuele COM-poorten.

Als gevolg hiervan wordt een prompt weergegeven Python > (Of 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 >

Interactie met IDA Pro

Om het testen te vereenvoudigen, gebruiken we de Rhino-firmware als bronbestand voor analyse in IDA in het formulier ELF-bestand (meta-informatie wordt daar opgeslagen).

U kunt ook de hoofdfirmware gebruiken zonder meta-informatie.

Nadat u Kopycat in IDA Pro hebt gestart, gaat u in het Debugger-menu naar het item “Schakel debugger…" en selecteer "GDB-foutopsporing op afstand". Stel vervolgens de verbinding in: menu Debugger - Procesopties…

Stel de waarden in:

• Toepassing - elke waarde
• Hostnaam: 127.0.0.1 (of het IP-adres van de externe machine waarop Kopycat draait)
• Port: 23946

Nu wordt de foutopsporingsknop beschikbaar (F9-toets):

Klik erop om verbinding te maken met de debuggermodule in de emulator. IDA gaat in de foutopsporingsmodus, er komen extra vensters beschikbaar: informatie over registers, over de stapel.

Nu kunnen we alle standaardfuncties van de debugger gebruiken:

• stapsgewijze uitvoering van instructies (Stap in и Overstappen — respectievelijk de toetsen F7 en F8);
• uitvoering starten en pauzeren;
• het creëren van breekpunten voor zowel code als gegevens (F2-toets).

Verbinding maken met een debugger betekent niet dat de firmwarecode moet worden uitgevoerd. De huidige uitvoeringspositie moet het adres zijn 0x08006A74 — begin van de functie Reset_Handler. Als u door de lijst bladert, ziet u de functieaanroep hoofd-. U kunt de cursor op deze regel plaatsen (adres 0x08006ABE) en voer de bewerking uit Ren tot cursor (toets F4).

Vervolgens kunt u op F7 drukken om de functie te openen hoofd-.

Als u de opdracht uitvoert Ga door met proces (F9-toets), dan verschijnt het venster “Even geduld a.u.b.” met één enkele knop Opschorten:

Wanneer u op drukt Opschorten De uitvoering van de firmwarecode wordt opgeschort en kan worden voortgezet vanaf hetzelfde adres in de code waar deze werd onderbroken.

Als u doorgaat met het uitvoeren van de code, ziet u de volgende regels in de terminals die zijn aangesloten op de virtuele COM-poorten:

De aanwezigheid van de "state bypass" -lijn geeft aan dat de virtuele Bluetooth-module is overgeschakeld naar de modus voor het ontvangen van gegevens van de COM-poort van de gebruiker.

Nu kunt u in de Bluetooth-terminal (COM29 in de afbeelding) opdrachten invoeren volgens het Rhino-protocol. Het commando “MEOW” stuurt bijvoorbeeld de string “mur-mur” terug naar de Bluetooth-terminal:

Emuleer mij niet volledig

Bij het bouwen van een emulator kunt u het detailniveau/emulatie van een bepaald apparaat kiezen. De Bluetooth-module kan bijvoorbeeld op verschillende manieren worden geëmuleerd:

• het apparaat is volledig geëmuleerd met een volledige set opdrachten;
• AT-opdrachten worden geëmuleerd en de datastroom wordt ontvangen van de COM-poort van het hoofdsysteem;
• het virtuele apparaat zorgt voor volledige gegevensomleiding naar het echte apparaat;
• als een eenvoudig stompje dat altijd "OK" retourneert.

De huidige versie van de emulator gebruikt de tweede benadering: de virtuele Bluetooth-module voert de configuratie uit, waarna deze overschakelt naar de modus voor het "proxyen" van gegevens van de COM-poort van het hoofdsysteem naar de UART-poort van de emulator.

Laten we de mogelijkheid van eenvoudige instrumentatie van de code overwegen voor het geval een deel van de periferie niet is geïmplementeerd. Als er bijvoorbeeld geen timer is aangemaakt die verantwoordelijk is voor het controleren van de gegevensoverdracht naar DMA (de controle wordt uitgevoerd in de function ws2812b_wachtgevestigd in 0x08006840), dan wacht de firmware altijd totdat de vlag is gereset drukgevestigd in 0x200004C4die de bezetting van de DMA-datalijn toont:

We kunnen deze situatie omzeilen door de vlag handmatig opnieuw in te stellen druk onmiddellijk nadat u deze hebt geïnstalleerd. In IDA Pro kun je een Python-functie maken en deze in een breekpunt aanroepen, en het breekpunt zelf in de code plaatsen nadat je de waarde 1 naar de vlag hebt geschreven druk.

Breekpuntbehandelaar

Laten we eerst een Python-functie maken in IDA. Menu Bestand - Scriptopdracht...

Voeg een nieuw fragment toe in de lijst aan de linkerkant, geef het een naam (bijvoorbeeld BPT),
Voer in het tekstveld aan de rechterkant de functiecode in:

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

Daarna drukken we op lopen en sluit het scriptvenster.

Laten we nu naar de code gaan op 0x0800688A, stel een breekpunt in (F2-toets), bewerk het (contextmenu Onderbrekingspunt bewerken...), vergeet niet het scripttype in te stellen op Python:

Als de huidige vlagwaarde druk gelijk is aan 1, dan moet u de functie uitvoeren skip_dma in de scriptregel:

Als u de firmware uitvoert voor uitvoering, is het activeren van de breekpunthandlercode te zien in het IDA-venster uitgang per lijn Skipping wait ws2812.... Nu wacht de firmware niet tot de vlag opnieuw is ingesteld druk.

Interactie met de emulator

Het is onwaarschijnlijk dat emulatie omwille van de emulatie vreugde en vreugde zal veroorzaken. Het is veel interessanter als de emulator de onderzoeker helpt de gegevens in het geheugen te zien of de interactie van threads vast te stellen.

We laten u zien hoe u op dynamische wijze interactie tussen RTOS-taken tot stand kunt brengen. U moet eerst de uitvoering van de code pauzeren als deze actief is. Als je naar de functie gaat bluetooth_task_entry naar de verwerkingstak van het “LED”-commando (adres 0x080057B8), dan kunt u zien wat er eerst is gemaakt en vervolgens naar de systeemwachtrij is verzonden ledControlQueueHandle een of andere boodschap.

U moet een breekpunt instellen om toegang te krijgen tot de variabele ledControlQueueHandlegevestigd in 0x20000624 en ga verder met het uitvoeren van de code:

Als gevolg hiervan zal de stop eerst plaatsvinden bij het adresseren 0x080057CA voordat u de functie aanroept osMailAlloc, dan op het adres 0x08005806 voordat u de functie aanroept osMailPut, en na een tijdje - naar het adres 0x08005BD4 (voordat u de functie aanroept osMailGet), dat bij de functie hoort leds_task_entry (LED-taak), dat wil zeggen, de taken wisselden, en nu kreeg de LED-taak controle.

Op deze eenvoudige manier kunt u vaststellen hoe RTOS-taken met elkaar omgaan.

Natuurlijk kan de interactie tussen taken in werkelijkheid ingewikkelder zijn, maar met behulp van een emulator wordt het volgen van deze interactie minder bewerkelijk.

Hier U kunt een korte video bekijken van de lancering van de emulator en de interactie met IDA Pro.

Start met Radare2

Je kunt zo'n universele tool als Radare2 niet negeren.

Om verbinding te maken met de emulator met behulp van r2, zou het commando er als volgt uitzien:

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

Lancering nu beschikbaar (dc) en pauzeer de uitvoering (Ctrl+C).

Helaas heeft r2 op dit moment problemen bij het werken met de hardware gdb-server en geheugenindeling; hierdoor werken breekpunten en stappen niet (opdracht ds). Wij hopen dat dit snel wordt opgelost.

Hardlopen met Eclipse

Een van de opties voor het gebruik van de emulator is het debuggen van de firmware van het apparaat dat wordt ontwikkeld. Voor de duidelijkheid zullen we ook de Rhino-firmware gebruiken. U kunt de firmwarebronnen downloaden vandaar.

We zullen Eclipse van de set gebruiken als IDE Systeemwerkbank voor STM32.

Om de emulator de firmware te laten laden die rechtstreeks in Eclipse is gecompileerd, moet u de parameter toevoegen firmware=null naar het startcommando van de emulator:

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

Debug-configuratie instellen

Selecteer het menu in Eclipse Uitvoeren - Foutopsporing in configuraties... In het geopende venster, in de sectie GDB-hardwarefoutopsporing u moet een nieuwe configuratie toevoegen en vervolgens op het tabblad "Hoofd" het huidige project en de huidige toepassing voor foutopsporing opgeven:

Op het tabblad "Debugger" moet u de GDB-opdracht opgeven:
${openstm32_compiler_path}arm-none-eabi-gdb

En voer ook de parameters in voor verbinding met de GDB-server (host en poort):

Op het tabblad “Opstarten” moet u de volgende parameters opgeven:

• selectievakje inschakelen Afbeelding laden (zodat het samengestelde firmware-image in de emulator wordt geladen);
• selectievakje inschakelen Laad symbolen;
• startopdracht toevoegen: set $pc = *0x08000004 (stel het PC-register in op de waarde uit het geheugen op adres 0x08000004 - het adres wordt daar opgeslagen ResetHandler).

Noot, als u het firmwarebestand niet van Eclipse wilt downloaden, dan zijn de opties Afbeelding laden и Opdrachten uitvoeren hoeft niet aangegeven te worden.

Nadat u op Debug hebt geklikt, kunt u in de debugger-modus werken:

• stap voor stap code-uitvoering
  
• interactie met breekpunten
  

Noot. Eclipse heeft, hmm... een aantal eigenaardigheden... en daar moet je mee leren leven. Als bij het starten van de debugger bijvoorbeeld het bericht “Geen bron beschikbaar voor “0x0″” verschijnt, voer dan de opdracht Step uit (F5)

In plaats Output

Het emuleren van native code is heel interessant. Het wordt voor een apparaatontwikkelaar mogelijk om de firmware te debuggen zonder een echt apparaat. Voor een onderzoeker is het een kans om dynamische codeanalyse uit te voeren, wat zelfs met een apparaat niet altijd mogelijk is.

We willen specialisten een tool bieden die handig en redelijk eenvoudig is en die niet veel moeite en tijd kost om op te zetten en te gebruiken.

Schrijf in de reacties over uw ervaringen met het gebruik van hardware-emulators. Wij nodigen u uit om mee te praten en beantwoorden graag uw vragen.

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Waar gebruik je de emulator voor?

• Ik ontwikkel (debug) firmware

• Ik doe onderzoek naar firmware

• Ik lanceer games (Dendi, Sega, PSP)

• iets anders (schrijf in de reacties)

7 gebruikers hebben gestemd. 2 gebruikers onthielden zich van stemming.

Welke software gebruik je om native code te emuleren?

• QEMU

• Eenhoorn-motor

• Proteus

• iets anders (schrijf in de reacties)

6 gebruikers hebben gestemd. 2 gebruikers onthielden zich van stemming.

Wat zou u willen verbeteren in de emulator die u gebruikt?

• Ik wil snelheid

• Ik wil een gemakkelijke installatie/lancering

• Ik wil meer opties voor interactie met de emulator (API, hooks)

• Ik ben blij met alles

• iets anders (schrijf in de reacties)

8 gebruikers hebben gestemd. 1 gebruiker onthield zich van stemming.

Bron: www.habr.com