Tijdens de vergadering 0x0A DC7831 Op 16 februari hebben we een presentatie gegeven over de basisprincipes van binair code-emulatie en onze ontwikkeling — een emulator voor hardwareplatforms. .
In dit artikel zullen we een beschrijving geven van het starten van de firmware van het apparaat in de emulator, de interactie met de debugger demonstreren en een kleine dynamische analyse van de firmware uitvoeren.
Achtergrond
Lang geleden in een sterrenstelsel ver, ver weg
Een paar jaar geleden ontstond in ons laboratorium de noodzaak om de firmware van een apparaat te onderzoeken. De firmware was gecomprimeerd en werd uitgepakt door de bootloader. Dit gebeurde op een nogal complexe manier, met verschillende keren gegevensverplaatsing in het geheugen. Bovendien interageerde de firmware actief met de periferie. En dat allemaal op een MIPS-kern.
De beschikbare emulators voldeden om objectieve redenen niet aan onze verwachtingen, en we wilden toch de code uitvoeren. Dus besloten we om onze eigen emulator te maken die minimaal zou doen en zou toelaten om de belangrijkste firmware uit te pakken. We hebben het geprobeerd — het werkte. We dachten, wat als we ook de periferie toevoegen, zodat we ook de belangrijkste firmware kunnen uitvoeren. Het was niet al te pijnlijk — en het werkte ook. We dachten opnieuw na en besloten een volwaardige emulator te maken.
Uiteindelijk is er een emulator van rekensystemen ontstaan. .
Waarom Kopycat?
Er is sprake van een woordspeling.
- copycat (Engels, subst. [ˈkɒpɪkæt]) — imitatior, navolger
- cat (Engels, subst. [ˈkæt]) — kat, het favoriete huisdier van een van de projectoprichters
- De letter 'K' komt van de programmeertaal Kotlin
Kopycat
Bij de ontwikkeling van de emulator waren er een aantal specifieke doelen gesteld:
- de mogelijkheid om snel nieuwe periferie, modules en processorcores te creëren;
- de mogelijkheid om een virtueel apparaat samen te stellen uit verschillende modules;
- de mogelijkheid om elke binaire data (firmware) in het geheugen van het virtuele apparaat te laden;
- de mogelijkheid om met snapshots (systeemstatusopnames) te werken;
- de mogelijkheid om via de ingebouwde debugger met de emulator te communiceren;
- een aangename moderne taal voor ontwikkeling.
Uiteindelijk is er gekozen voor Kotlin, een busarchitectuur (dat is wanneer modules met elkaar worden verbonden via virtuele databus), JSON — als het beschrijvingsformaat voor het apparaat, en GDB RSP — als het protocol voor interactie met de debugger.
De ontwikkeling duurt al iets meer dan twee jaar en gaat actief verder. In deze tijd zijn de MIPS, x86, V850ES, ARM en PowerPC processorcores gerealiseerd.
Het project groeit, en het is tijd om het aan het grote publiek voor te stellen. Een gedetailleerde beschrijving van het project volgt later; laten we ons nu richten op het gebruik van Kopycat.
Voor de meest ongeduldigen — de promo-versie van de emulator kan gedownload worden via .
Neushoorn in de emulator
Ter herinnering, voor de SMARTRHINO-2018 conferentie werd een testapparaat 'Neushoorn' gecreëerd om vaardigheden in reverse engineering te onderwijzen. Het proces van statische analyse van de firmware werd beschreven in .
Laten we nu proberen wat 'dynamiek' toe te voegen en de firmware in de emulator te starten.
We hebben nodig:
1) Java 1.8
2) Python en de module voor het gebruik van Python binnen de emulator. De WHL-build van de Jep-module voor Windows kan .
Voor Windows:
1)
2)
Voor Linux:
1) socat
Eclipse, IDA Pro of radare2 kunnen als GDB-client worden gebruikt.
How does it work?
Om de firmware in de emulator uit te voeren, moet een virtueel apparaat worden 'samengesteld', dat een analogon van een echt apparaat is.
Het echte apparaat ('neushoorn') kan op een structureel schema worden getoond:
De emulator heeft een modulaire structuur en het uiteindelijke virtuele apparaat kan worden beschreven in een JSON-bestand.
JSON van 105 regels
{
"top": true,
// De naam van de plugin moet hetzelfde zijn als de bestandsnaam (of volledig pad vanaf de bibliotheekstart)
"plugin": "rhino",
// Directory waar de plugin plaatst
"library": "user",
// Pluginparameters (constructorparameters als het jar-plugin versie is)
"params": [
{ "name": "tty_dbg", "type": "String"},
{ "name": "tty_bt", "type": "String"},
{ "name": "firmware", "type": "String", "default": "NUL"}
],
// Externe poorten van de plugin
"ports": [ ],
// Interne buses van de plugin
"buses": [
{ "name": "mem", "size": "BUS30" },
{ "name": "nand", "size": "4" },
{ "name": "gpio", "size": "BUS32" }
],
// Interne componenten van de plugin
"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" }
],
// Verbinding tussen componenten van de plugin
"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 het parameter firmware in de sectie params — dit is de naam van het bestand dat je in het virtuele apparaat kunt laden als firmware.
Een virtueel apparaat en de interactie met het onderliggende besturingssysteem kunnen worden weergegeven als volgt:
De huidige testversie van de emulator gaat uit van interactie met de COM-poorten van het hoofdbesturingssysteem (debug UART en UART voor de Bluetooth-module). Dit kunnen zowel fysieke poorten zijn, waaraan apparaten zijn aangesloten, als virtuele COM-poorten (hiervoor hebben we net com0com / socat).
Voor interactie met de emulator van buitenaf zijn er momenteel twee hoofdmogelijkheden:
- het GDB RSP-protocol (waarbij de tools die dit protocol ondersteunen — Eclipse / IDA / radare2);
- de interne opdrachtregelinterface van de emulator (Argparse of Python).
Virtuele COM-poorten
Om te interageren met de UART van het virtuele apparaat op de lokale machine via een terminal, moet je een paar verbonden virtuele COM-poorten maken. In ons geval gebruikt de emulator één poort, terwijl de andere de terminalprogramma (PuTTY of screen) is:
Gebruik van com0com
Virtuele COM-poorten worden ingesteld met de setup-tool uit het com0com-pakket (de consoleversie — C:Program Files (x86)com0comsetupс.exe, of de GUI-versie — C:Program Files (x86)com0comsetupg.exe):
Zorg ervoor dat je de vinkjes inschakelt voor enable buffer overrun voor alle gemaakte virtuele poorten, anders zal de emulator op een reactie van de COM-poort wachten.
Gebruik van socat
Op UNIX-systemen worden virtuele COM-poorten automatisch door de emulator aangemaakt met de socat-tool; het is voldoende om bij het opstarten van de emulator de naam van de poort het voorvoegsel socat:.
Interne opdrachtregelinterface (Argparse of Python)
Aangezien Kopycat een consoletoepassing is, biedt de emulator twee opties voor de opdrachtregelinterface voor interactie met zijn objecten en variabelen: Argparse en Python.
Argparse is de CLI die in Kopycat is ingebouwd, deze is altijd en voor iedereen beschikbaar.
De alternatieve CLI is de Python-interpreter. Voor het gebruik hiervan moet de Python-module Jep worden geïnstalleerd en moet de emulator worden ingesteld om met Python te werken (de Python-interpreter die op het hoofdsyteem van de gebruiker is geïnstalleerd, zal worden gebruikt).
Installatie van de Python-module Jep
Onder Linux kan Jep worden geïnstalleerd via pip:
pip install jepVoor de installatie van Jep onder Windows is het noodzakelijk om eerst de Windows SDK en de bijbehorende Microsoft Visual Studio te installeren. We hebben je het een beetje gemakkelijker gemaakt en hebben JEP voor de actuele versies van Python voor Windows, dus de module kan vanuit het bestand worden geïnstalleerd:
pip install jep-3.8.2-cp27-cp27m-win_amd64.whlOm de installatie van Jep te controleren, moet je het volgende in de opdrachtprompt uitvoeren:
python -c "import jep"Als reactie moet het volgende bericht verschijnen:
ImportError: Jep wordt niet ondersteund in standalone Python, het moet in Java worden ingebed.In het batchbestand van de emulator voor jouw systeem (kopycat.bat — voor Windows, kopycat — voor Linux) voeg je aan de lijst met parameters DEFAULT_JVM_OPTS een extra parameter toe Djava.library.path — deze moet het pad naar de geïnstalleerde Jep-module bevatten.
Daarom moet voor Windows de regel er als volgt uitzien:
set DEFAULT_JVM_OPTS="-XX:MaxMetaspaceSize=256m" "-XX:+UseParallelGC" "-XX:SurvivorRatio=6" "-XX:-UseGCOverheadLimit" "-Djava.library.path=C:/Python27/Lib/site-packages/jep"Start Kopycat
De emulator is een console JVM-applicatie. De start gebeurt via een opdrachtregel-script van het besturingssysteem (sh/cmd).
De commando voor de uitvoering onder Windows:
binkopycat -g 23946 -n rhino -l user -y library -p firmware=firmwarerhino_pass.bin,tty_dbg=COM26,tty_bt=COM28De commando voor de uitvoering onder Linux met gebruik van de utility 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— de TCP-poort die geopend wordt voor toegang tot de GDB-server;-n rhino— de naam van de hoofdmodule van het systeem (geassembleerd apparaat);-l user— de naam van de bibliotheek voor het zoeken naar de hoofdmodule;-y library— het pad voor het zoeken naar modules die bij het apparaat horen;firmwarerhino_pass.bin— het pad naar het firmwarebestand;- COM26 en COM28 zijn virtuele COM-poorten.
Er verschijnt een prompt Python > (of Argparse >):
18:07:59 INFO [eFactoryBuilder.create]: Module top succesvol aangemaakt als top
18:07:59 INFO [Module.initializeAndRes]: Core ingesteld op top.u1_stm32.cortexm0.arm voor top
18:07:59 INFO [Module.initializeAndRes]: Debugger ingesteld op top.u1_stm32.dbg voor top
18:07:59 WARN [Module.initializeAndRes]: Tracer niet gevonden in top...
18:07:59 INFO [Module.initializeAndRes]: Poorten en bussen aan het initialiseren...
18:07:59 WARN [Module.initializePortsA]: ATTENTIE: Sommige poorten hebben een waarschuwing, gebruik printModulesPortsWarnings om dit te zien...
18:07:59 FINE [ARMv6CPU.reset]: Stel het startadres in op 08006A75
18:07:59 INFO [Module.initializeAndRes]: Module top is succesvol geïnitieerd en opnieuw ingesteld als een topcel!
18:07:59 INFO [Kopycat.open]: Virtualisatie van bord top[rhino] met arm[ARMv6Core] starten
18:07:59 INFO [GDBServer.debuggerModule]: Nieuwe debugger-module top.u1_stm32.dbg ingesteld voor GDB_SERVER(port=23946,alive=true)
Python >Interactie met IDA Pro
We gebruiken de firmware 'Rhino' als bronbestand voor analyse in IDA voor vereenvoudiging van testen in de vorm van (daarin is metadata opgeslagen).
Je kunt ook de hoofdfirmware zonder metadata gebruiken.
Na het starten van Kopycat in IDA Pro ga je in het menu Debugger naar "Switch debugger…" en kies "Externe GDB-debugger«. Vervolgens stellen we de verbinding in: menu Debugger — Procesopties…
Instellen van waarden:
- Applicatie — willekeurige waarde
- Hostname: 127.0.0.1 (of het IP-adres van de externe machine waar Kopycat draait)
- Poort: 23946
Nu wordt de debugstartknop (toets F9) beschikbaar:
We drukken erop - er wordt verbinding gemaakt met de debugmodule in de emulator. IDA gaat over in de debugmodus, extra vensters worden beschikbaar: informatie over de registers, over de stack.
Nu kunnen we alle standaard mogelijkheden van de debugger gebruiken:
- stapsgewijze uitvoering van instructies (Stap in en Stap over — toetsen F7 en F8, respectievelijk);
- het starten en pauzeren van de uitvoering;
- het creëren van breakpoints zowel voor de code als voor de gegevens (toets F2).
Verbinden met de debugger betekent niet dat de firmwarecode wordt uitgevoerd. De huidige positie voor uitvoering moet het adres zijn 0x08006A74 — begin van de functie Reset_Handler. Als we de listing naar beneden scrollen, kunnen we de aanroep van de functie zien. mainJe kunt de cursor op deze regel plaatsen (adres 0x08006ABE) en de operatie Uitvoeren tot cursor (toets F4).
Vervolgens kun je op F7 drukken om de functie binnen te gaan. main.
Als je de opdracht Ga door met proces (toets F9) uitvoert, verschijnt er een venster "Please wait" met één knop Pauze:
Bij het indrukken Pauze wordt de uitvoering van de firmwarecode gepauzeerd en kan deze worden hervat vanaf hetzelfde adres in de code waar het was onderbroken.
Als de uitvoering van de code wordt voortgezet, kunnen in de terminals die zijn aangesloten op de virtuele COM-poorten de volgende regels worden gezien:
De aanwezigheid van de regel "state bypass" geeft aan dat de virtuele Bluetooth-module is overgeschakeld naar de gegevensontvangstmodus van de gebruikers COM-poort.
Nu kan er in de Bluetooth-terminal (in de afbeelding — COM29) opdrachten worden ingevoerd volgens het "Nashorn"-protocol. Bijvoorbeeld, bij de opdracht "MEOW" ontvangt de Bluetooth-terminal de regel "mur-mur":
Emuleer me niet helemaal
Bij het bouwen van de emulator kan de mate van detaillering/emulatie van elk apparaat worden gekozen. Zo kan de Bluetooth-module bijvoorbeeld op verschillende manieren worden geëmuleerd:
- het apparaat wordt volledig geëmuleerd met een volledige set opdrachten;
- AT-opdrachten worden geëmuleerd, terwijl de datastroom van de COM-poort van het hoofdsyteem wordt ontvangen;
- het virtuele apparaat zorgt voor volledige gegevensdoorsturing naar het echte apparaat;
- in de vorm van een simpele troostdie altijd "OK" retourneert.
In de huidige versie van de emulator wordt de tweede benadering gebruikt: een virtuele Bluetooth-module configureert, waarna deze overgaat in de modus van 'proxy-gegevens' van de COM-poort van het hoofd systeem naar de UART-poort van de emulator.
Laten we de mogelijkheid van eenvoudige code-instrumentatie onderzoeken voor het geval dat een deel van de randapparatuur niet is geïmplementeerd. Bijvoorbeeld, als er geen timer is gemaakt die verantwoordelijk is voor het controleren van gegevensoverdracht in DMA (de controle wordt uitgevoerd in de functie ws2812b_wait, gelegen op adres 0x08006840), dan zal de firmware altijd wachten op het resetten van de vlag busy, die op adres 0x200004C4, aangeeft dat de gegevenslijn van de DMA bezet is:
We kunnen deze situatie omzeilen door de vlag handmatig te resetten busy direct nadat deze is ingesteld. In IDA Pro kun je een Python-functie maken en deze aanroepen in de breakpoint, terwijl je de breakpoint zelf in de code plaatst na het instellen van de waarde 1 in de vlag busy.
Breakpoint-handler
Laten we eerst een Python-functie maken in IDA. Menu Bestand — Script commando…
We voegen een nieuwe snippet toe aan de lijst aan de linkerkant, geven deze een naam (bijvoorbeeld, BPT),
in het tekstvak aan de rechterkant voeren we de functiecode in:
def skip_dma():
print "Skipping wait ws2812..."
value = Byte(0x200004C4)
if value == 1:
PatchDbgByte(0x200004C4, 0)
return False 
Daarna klikken we op Run en sluiten we het scriptvenster.
Laten we nu naar de code op adres 0x0800688A, een breakpoint instellen (toets F2), deze bewerken (contextmenu Bewerk breakpoint…), vergeet niet het type script in te stellen – Python:
Als de huidige waarde van de vlag busy gelijk is aan 1, dan moet de functie skip_dma in de regels van de scripts worden uitgevoerd:
Wanneer we de firmware uitvoeren, is de activering van de breakpoint-handler te zien in IDA in het venster Uitvoer via de regel Skipping wait ws2812.... Nu zal de firmware niet wachten op het resetten van de vlag. busy.
Interacties met de emulator
Emulatie om de emulatie zal waarschijnlijk geen vreugde of blijdschap oproepen. Het is veel interessanter als de emulator de onderzoeker helpt om gegevens in het geheugen te zien of interactie tussen threads tot stand te brengen.
We laten zien hoe je in dynamiek de interactie tussen RTOS-taken kunt instellen. Voordat we verder gaan, moet de uitvoering van de code worden gepauzeerd, als deze al draait. Als we naar de functie bluetooth_task_entry in de tak die het commando ‘LED’ verwerkt (adres 0x080057B8), dan is te zien dat eerst een bericht wordt aangemaakt en vervolgens naar de systeemqueue wordt verzonden. ledControlQueueHandle een bepaald bericht.
We moeten een breakpoint instellen op het verzoek om de variabele ledControlQueueHandle, gelegen op adres 0x20000624 en de uitvoering van de code voortzetten:
De eerste stap zal plaatsvinden op het adres 0x080057CA voor de functieaanroep osMailAlloc, daarna — op het adres 0x08005806 voor de functieaanroep osMailPut, daarna na enige tijd — op het adres 0x08005BD4 (voor de functieaanroep osMailGet), die behoort tot de functie leds_task_entry (LED-taak), wat betekent dat er een taakwisseling heeft plaatsgevonden, en nu heeft de LED-taak de controle gekregen.
Op deze eenvoudige manier kan worden vastgesteld hoe de RTOS-taken met elkaar omgaan.
Natuurlijk kan de interactie tussen taken in werkelijkheid complexer zijn, maar met behulp van de emulator wordt het volgen van deze interactie minder arbeidsintensief.
U kunt een korte video bekijken over het starten van de emulator en de interactie met IDA Pro.
Starten met Radare2
Zo'n veelzijdig hulpmiddel als Radare2 kan niet worden genegeerd.
Voor verbinding met de emulator via r2 zal de opdracht er als volgt uitzien:
radare2 -A -a arm -b 16 -d gdb://localhost:23946 rhino_fw42k6.elfMomenteel zijn er uitvoering (dc) en pauzeren (Ctrl+C) beschikbaar.
Helaas zijn er op dit moment problemen in r2 bij het werken met de hardware gdb-server en de geheugenindeling, waardoor breakpoints en Step-commando's (de opdracht ds) niet werken. We hopen dat dit binnenkort zal worden opgelost.
Starten met Eclipse
Een van de mogelijkheden om de emulator te gebruiken, is het debuggen van de firmware van het ontwikkelende apparaat. Voor de duidelijkheid zullen we ook de firmware 'Rhino' gebruiken. De broncode van de firmware kan worden gedownload .
Als IDE zullen we Eclipse uit de set .
gebruiken. Om ervoor te zorgen dat de firmware rechtstreeks vanuit Eclipse in de emulator wordt geladen, moet de parameter worden toegevoegd firmware=null aan de opstartopdracht van de emulator:
binkopycat -g 23946 -n rhino -l user -y modules -p firmware=null,tty_dbg=COM26,tty_bt=COM28Instelling van de debug-configuratie
In Eclipse kiezen we het menu Run — Debug Configurations… In het geopende venster moet in de sectie GDB Hardware Debugging een nieuwe configuratie worden toegevoegd, waarna op het tabblad 'Main' het huidige project en de applicatie voor debugging moeten worden opgegeven:
Op het tabblad 'Debugger' moeten we het GDB-commando opgeven:
${openstm32_compiler_path}arm-none-eabi-gdb
En ook de parameters voor verbinding met de GDB-server (host en poort) invoeren:
Op het tabblad 'Startup' moeten de volgende parameters worden opgegeven:
- de checkbox inschakelen Load image (zodat de geladen firmware-image in de emulator wordt geladen);
- de checkbox inschakelen Load symbols;
- voeg de opstartopdracht toe:
set $pc = *0x08000004(de waarde uit het geheugen op het adres in het register PC zetten0x08000004— daar staat het adres ResetHandler).
Let op, als je het firmwarebestand niet uit Eclipse wilt laden, dan zijn de parameters Load image en Opdrachten uitvoeren hoef je niet op te geven.
Na het drukken op Debug kun je in debugmodus werken:
- stapsgewijs de code uitvoeren
- interactie met breakpoints
Opmerking. In Eclipse zijn er, hmm... bepaalde bijzonderheden... en daar moet je mee leven. Bijvoorbeeld, als er bij het starten van de debugger een bericht verschijnt "No source available for "0x0", voer dan de commando Step (F5) uit
Ter afsluiting
Emulatie van native code is een zeer interessante zaak. Voor de ontwikkelaar van apparaten is er een mogelijkheid om de firmware te debuggen zonder echt apparaat. Voor de onderzoeker — de mogelijkheid om dynamische code-analyse uit te voeren, wat niet altijd mogelijk is, zelfs met een apparaat.
We willen de specialisten een hulpmiddel bieden dat handig, redelijk eenvoudig is en niet veel moeite en tijd kost om in te stellen en te starten.
Schrijf in de opmerkingen over jouw ervaring met hardware-emulators. We nodigen je uit voor discussie en we zijn blij om vragen te beantwoorden.
Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. , alstublieft.
Waar gebruik je de emulator voor?
ik ontwikkel (debug) firmware
ik onderzoek firmware
ik start spellen (Dendi, Sega, PSP)
iets anders (vermeld het in de opmerkingen)
7 gebruikers hebben gestemd. 2 gebruikers hebben zich onthouden.
Welke software gebruik je voor de emulatie van native code?
QEMU
Unicorn engine
Proteus
iets anders (vermeld het in de opmerkingen)
6 gebruikers hebben gestemd. 2 gebruikers hebben zich onthouden.
Wat zou je willen verbeteren aan de gebruikte emulator?
ik wil snelheid
ik wil gemak bij het instellen/starten
ik wil meer mogelijkheden voor interactie met de emulator (API, hooks)
ik ben er tevreden mee
iets anders (vermeld het in de opmerkingen)
8 gebruikers hebben gestemd. 1 gebruiker onthield zich.
Bron: habr.com
