Un rhinocéros à l'intérieur d'un chat — démarrer un firmware dans l'émulateur Kopycat

Lors de la réunion 0x0A DC7831 DEF CON Nijni Novgorod Le 16 février, nous avons présenté un rapport sur les principes de base de l'émulation de code binaire et notre développement — un émulateur de plateformes matérielles. Kopycat.

Dans cet article, nous décrirons le lancement du firmware d'un dispositif dans l'émulateur, démontrerons l'interaction avec le débogueur et réaliserons une petite analyse dynamique du firmware.

Contexte

Il y a longtemps, dans une galaxie lointaine, très lointaine

Il y a quelques années, notre laboratoire a eu besoin d'étudier le firmware d'un dispositif. Le firmware était compressé et décompressé par le bootloader. Il le faisait de manière assez complexe, réorganisant plusieurs fois les données en mémoire. De plus, le firmware interagissait activement avec le matériel. Et tout cela sur un noyau MIPS.

Les émulateurs existants ne nous convenaient pas pour des raisons évidentes, et nous voulions quand même exécuter le code. Nous avons donc décidé de créer notre propre émulateur qui ferait le minimum et permettrait de décompresser le firmware principal. Nous avons essayé — ça a marché. Nous avons réfléchi, et si nous ajoutions du matériel pour exécuter également le firmware principal. Cela n'a pas été trop douloureux — et ça a aussi marché. Nous avons encore réfléchi et décidé de créer un émulateur complet.

Au final, un émulateur de systèmes de calcul a été créé. Kopycat.

Pourquoi Kopycat ?

Il s'agit d'un jeu de mots.

1. copycat (anglais, nom [ˈkɒpɪkæt]) — imitateur, copieur
2. cat (anglais, nom [ˈkæt]) — chat, le chat — animal de compagnie préféré d'un des créateurs du projet
3. La lettre « K » vient du langage de programmation Kotlin

Kopycat

Lors de la création de l'émulateur, des objectifs bien définis ont été fixés :

• capacité à créer rapidement un nouveau matériel, un module, un cœur de processeur ;
• capacité à assembler un dispositif virtuel à partir de différents modules ;
• capacité à charger dans la mémoire de l'appareil virtuel n'importe quelle donnée binaire (firmware) ;
• capacité à travailler avec des snapshots (captures d'état du système) ;
• capacité d'interaction avec l'émulateur via un débogueur intégré ;
• un langage de développement moderne et agréable.

Au final, Kotlin a été choisi pour les implémentations, une architecture de bus (c'est lorsque les modules sont reliés entre eux via des bus de données virtuels), JSON — comme format de description de l'appareil, et GDB RSP — comme protocole d'interaction avec le débogueur.

Le développement a lieu depuis un peu plus de deux ans et se poursuit activement. Au cours de cette période, des cœurs de processeur MIPS, x86, V850ES, ARM et PowerPC ont été réalisés.

Le projet grandit, et il est temps de le présenter au grand public. Une description détaillée du projet sera faite plus tard, mais concentrons-nous maintenant sur l'utilisation de Kopycat.

Pour les plus impatients – la version promotionnelle de l'émulateur peut être téléchargée à le lien.

Rhinocéros dans l'émulateur

Rappelons qu'un dispositif de test dénommé « Rhinocéros » a été créé pour la conférence SMARTRHINO-2018 afin d'apprendre des compétences en reverse engineering. Le processus d'analyse statique du firmware a été décrit dans cet article.

Nous allons maintenant essayer d'ajouter un peu de « dynamique » et lancer le firmware dans l'émulateur.

Nous aurons besoin de :
1) Java 1.8
2) Python et le module Jep pour utiliser Python à l'intérieur de l'émulateur. L'assemblage WHL du module Jep sous Windows peut être téléchargé ici.

Pour Windows :
1) com0com
2) PuTTY

Pour Linux :
1) socat

Comme client GDB, vous pouvez utiliser Eclipse, IDA Pro ou radare2.

Comment cela fonctionne ?

Pour exécuter le firmware dans l'émulateur, il est nécessaire de « construire » un dispositif virtuel qui représente un équivalent du dispositif réel.

Le dispositif réel (« rhinocéros ») peut être illustré par le schéma structurel :

L'émulateur possède une structure modulaire et le dispositif virtuel final peut être décrit dans un fichier JSON.

JSON de 105 lignes

{
  "top": true,

  // Le nom du plugin doit être le même que le nom du fichier (ou le chemin complet depuis le début de la bibliothèque)
  "plugin": "rhino",

  // Répertoire où le plugin place
  "library": "user",

  // Paramètres du plugin (paramètres du constructeur si version jar-plugin)
  "params": [
    { "name": "tty_dbg", "type": "String"},
    { "name": "tty_bt", "type": "String"},
    { "name": "firmware", "type": "String", "default": "NUL"}
  ],

  // Ports externes du plugin
  "ports": [  ],

  // Bus internes du plugin
  "buses": [
    { "name": "mem", "size": "BUS30" },
    { "name": "nand", "size": "4" },
    { "name": "gpio", "size": "BUS32" }
  ],

  // Composants internes du 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" }
  ],

  // Connexion du plugin entre les composants
  "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"]
  ]
}

Veuillez prêter attention au paramètre firmware dans la section params — c'est le nom du fichier que vous pouvez télécharger sur l'appareil virtuel en tant que firmware.

Un appareil virtuel et son interaction avec le système d'exploitation principal peuvent être représentés par le schéma suivant :

L'instance actuelle de l'émulateur permet l'interaction avec les ports COM du système d'exploitation principal (UART de débogage et UART pour le module Bluetooth). Cela peut être des ports réels auxquels des appareils sont connectés ou des ports COM virtuels (c'est exactement ce dont ont besoin com0com / socat).

Pour interagir avec l'émulateur depuis l'extérieur, il existe actuellement deux principales méthodes :

• le protocole GDB RSP (les outils qui prennent en charge ce protocole — Eclipse / IDA / radare2) ;
• l'interface de ligne de commande interne de l'émulateur (Argparse ou Python).

Ports COM virtuels

Pour interagir avec le UART de l'appareil virtuel sur la machine locale via un terminal, il est nécessaire de créer une paire de ports COM virtuels liés. Dans notre cas, un port est utilisé par l'émulateur, et l'autre — par le programme terminal (PuTTY ou screen) :

Utilisation de com0com

Les ports COM virtuels sont configurés à l'aide de l'utilitaire setup du package com0com (version console — C:Program Files (x86)com0comsetupс.exe, ou version GUI — C:Program Files (x86)com0comsetupg.exe):

Il convient d'activer les options enable buffer overrun pour tous les ports virtuels créés, sinon l'émulateur attendra une réponse du port COM.

Utilisation de socat

Sur les systèmes UNIX, les ports COM virtuels sont automatiquement créés par l'émulateur à l'aide de l'utilitaire socat, il suffit à cet effet, lors du lancement de l'émulateur, de spécifier le préfixe dans le nom du port socat :.

Interface interne de ligne de commande (Argparse ou Python)

Étant donné que Kopycat est une application en ligne de commande, pour interagir avec ses objets et variables, l'émulateur propose deux options d'interface de ligne de commande : Argparse et Python.

Argparse est une interface CLI intégrée à Kopycat, elle est toujours accessible à tous.

L'alternative CLI est l'interpréteur Python. Pour l'utiliser, il est nécessaire d'installer le module Python Jep et de configurer l'émulateur pour travailler avec Python (l'interpréteur Python installé sur le système principal de l'utilisateur sera utilisé).

Installation du module Python Jep

Sous Linux, Jep peut être installé via pip :

pip install jep

Pour installer Jep sous Windows, il est nécessaire de préalablement installer Windows SDK et la version correspondante de Microsoft Visual Studio. Nous avons un peu simplifié votre tâche en fournissant des builds WHL JEP pour les versions actuelles de Python sous Windows, donc le module peut être installé à partir du fichier :

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

Pour vérifier l'installation de Jep, il est nécessaire d'exécuter dans l'invite de commandes :

python -c "import jep"

La réponse doit être le message suivant :

ImportError : Jep n'est pas supporté dans Python autonome, il doit être intégré dans Java.

Dans le fichier de commande de l'émulateur pour votre système (kopycat.bat — pour Windows, kopycat — pour Linux) ajoutez le paramètre supplémentaire à la liste de paramètres DEFAULT_JVM_OPTS ajoutez le paramètre supplémentaire Djava.library.path — il doit contenir le chemin vers le module Jep installé.

Par conséquent, pour Windows, la chaîne devrait ressembler à ceci :

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

Lancement de Kopycat

L'émulateur est une application JVM en ligne de commande. Le lancement se fait via un script de l'invite de commandes du système d'exploitation (sh/cmd).

Commande pour lancer sous Windows :

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

Commande pour lancer sous Linux en utilisant l'outil 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 — le port TCP qui sera ouvert pour accéder au serveur GDB ;
• -n rhino — le nom du module principal du système (dispositif assemblé) ;
• -l user — le nom de la bibliothèque pour rechercher le module principal ;
• -y library — le chemin pour rechercher les modules compris dans le dispositif ;
• firmwarerhino_pass.bin — chemin vers le fichier de firmware ;
• COM26 et COM28 — ports COM virtuels.

En conséquence, une invite sera affichée Python > ou Argparse >):

18:07:59 INFO [eFactoryBuilder.create ]: Le module top a été créé avec succès comme top
18:07:59 INFO [ Module.initializeAndRes]: Configuration du cœur pour top.u1_stm32.cortexm0.arm pour top
18:07:59 INFO [ Module.initializeAndRes]: Configuration du débogueur pour top.u1_stm32.dbg pour top
18:07:59 WARN [ Module.initializeAndRes]: Tracer non trouvé dans top...
18:07:59 INFO [ Module.initializeAndRes]: Initialisation des ports et bus...
18:07:59 WARN [ Module.initializePortsA]: ATTENTION : Certains ports ont un avertissement, utilisez printModulesPortsWarnings pour le voir...
18:07:59 FINE [ ARMv6CPU.reset ]: Définir l'adresse du point d'entrée sur 08006A75
18:07:59 INFO [ Module.initializeAndRes]: Le module top est initialisé et réinitialisé avec succès en tant que cellule toppen !
18:07:59 INFO [ Kopycat.open ]: Démarrage de la virtualisation de la carte top[rhino] avec arm[ARMv6Core]
18:07:59 INFO [ GDBServer.debuggerModule ]: Nouveau module de débogage set top.u1_stm32.dbg pour GDB_SERVER(port=23946,alive=true)
Python >

Interaction avec IDA Pro

Comme fichier source pour l'analyse dans IDA pour faciliter le test, nous utilisons le firmware « Rhino » sous forme de fichier ELF (qui contient des métadonnées).

Vous pouvez également utiliser le firmware principal sans métadonnées.

Après le lancement de Kopycat dans IDA Pro, dans le menu Débogueur, allons à l'élément «Switch debugger…» et choisissons «Débogueur GDB distant«. Ensuite, configurons la connexion : menu Débogueur — Options de processus…

Nous définissons les valeurs :

• Application — n'importe quelle valeur
• Nom d'hôte : 127.0.0.1 (ou l'adresse IP de la machine distante où Kopycat est exécuté)
• Port : 23946

Le bouton de démarrage du débogage (touche F9) devient maintenant disponible :

Nous cliquons dessus — cela connecte au module de débogage sur l'émulateur. IDA passe en mode débogage, et des fenêtres supplémentaires deviennent accessibles : informations sur les registres, sur la pile.

Nous pouvons maintenant utiliser toutes les fonctionnalités standard du débogueur :

• exécution pas à pas des instructions (Entrer dans et Sauter — les touches F7 et F8, respectivement) ;
• lancer et suspendre l'exécution ;
• créer des points d'arrêt à la fois sur le code et sur les données (touche F2).

Se connecter au débogueur ne signifie pas démarrer le code du firmware. La position actuelle pour l'exécution doit être l'adresse 0x08006A74 — début de la fonction Reset_Handler. Si nous faisons défiler le listing en dessous, nous pouvons voir l'appel de la fonction main. Nous pouvons placer le curseur sur cette ligne (adresse 0x08006ABE) et exécuter l'opération Exécuter jusqu'au curseur (touche F4).

Ensuite, nous pouvons appuyer sur F7 pour entrer dans la fonction main.

Si nous exécutons la commande Continuer le processus (touche F9), une fenêtre «Veuillez patienter» apparaîtra avec le seul bouton Suspendre:

En appuyant sur Suspendre l'exécution du code de firmware est suspendue et peut être reprise à la même adresse dans le code où elle a été interrompue.

Si nous continuons l'exécution du code, dans les terminaux connectés aux ports COM virtuels, nous pouvons voir les lignes suivantes :

La présence de la ligne «state bypass» indique que le module Bluetooth virtuel est passé en mode de réception de données depuis le port COM de l'utilisateur.

Nous pouvons maintenant entrer des commandes dans le terminal Bluetooth (sur l'image — COM29) conformément au protocole «Rhinocéros». Par exemple, pour la commande «MEOW», le terminal Bluetooth retournera la ligne «mur-mur» :

Ne m'émule pas complètement

Lors de la construction de l'émulateur, il est possible de choisir le degré de détail/l'émulation de tel ou tel appareil. Par exemple, le module Bluetooth peut être émulé de différentes manières :

• l'appareil est entièrement émulé avec un ensemble complet de commandes;
• les commandes AT sont émoulées, et le flux de données est reçu depuis le port COM du système principal;
• l'appareil virtuel assure un redirectionnement complet des données vers l'appareil réel;
• sous la forme d'une simple prise qui renvoie toujours «OK».

Dans la version actuelle de l'émulateur, une deuxième approche est utilisée : un module Bluetooth virtuel effectue la configuration, puis passe en mode de « proxy » des données du port COM du système principal vers le port UART de l'émulateur.

Considérons la possibilité d'instrumenter facilement le code dans le cas où une partie du matériel n'est pas implémentée. Par exemple, si un minuteur n'est pas créé pour contrôler le transfert de données en DMA (la vérification se fait dans la fonction ws2812b_wait, située à l'adresse 0x08006840), le firmware attendra toujours le réinitialisation du drapeau busy, situé à l'adresse 0x200004C4, qui indique si la ligne de données DMA est occupée :

Nous pouvons contourner cette situation par un réinitialisation « manuelle » du drapeau busy immédiatement après son installation. Dans IDA Pro, vous pouvez créer une fonction Python et l'appeler dans un point d'arrêt, en plaçant le point d'arrêt dans le code après avoir enregistré la valeur 1 dans le drapeau busy.

Gestionnaire de point d'arrêt

Commençons par créer une fonction Python dans IDA. Menu Fichier — Commande de script…

Ajoutons un nouveau snippet dans la liste de gauche, donnons-lui un nom (par exemple, BPT),
dans le champ de texte à droite, saisissons le code de la fonction :

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

Après cela, nous cliquons sur Exécution et fermons la fenêtre des scripts.

Maintenant, allons dans le code à l'adresse 0x0800688A, plaçons un point d'arrêt (touche F2), modifions-le (menu contextuel Modifier le point d'arrêt…), n'oubliez pas de définir le type de script – Python :

Si la valeur actuelle du drapeau busy est égale à 1, alors la fonction skip_dma devrait être exécutée dans la ligne de scripts :

Si nous lançons le firmware pour l'exécution, nous pouvons voir l'exécution du code du gestionnaire de point d'arrêt dans IDA dans la fenêtre Sortie par la ligne Skipping wait ws2812.... Maintenant, le firmware ne devrait pas attendre la réinitialisation du drapeau. busy.

Interaction avec l'émulateur

L'émulation juste pour le plaisir d'émuler ne suscitera probablement pas d'enthousiasme. Il est beaucoup plus intéressant si l'émulateur aide le chercheur à voir des données en mémoire ou à établir l'interaction des flux.

Voyons comment établir dynamiquement l'interaction des tâches RTOS. Au préalable, il faut suspendre l'exécution du code, si elle est en cours. Si vous accédez à la fonction bluetooth_task_entry dans la branche de traitement de la commande « LED » (adresse 0x080057B8), vous pouvez voir qu'un message est d'abord créé, puis envoyé dans la queue système ledControlQueueHandle .

Il convient de placer un point d'arrêt sur l'accès à la variable ledControlQueueHandle, située à l'adresse 0x20000624 et de continuer l'exécution du code :

En conséquence, un arrêt se produira d'abord à l'adresse 0x080057CA avant l'appel de la fonction osMailAlloc, ensuite, à l'adresse 0x08005806 avant l'appel de la fonction osMailPut, puis après un certain temps, à l'adresse 0x08005BD4 (avant l'appel de la fonction osMailGet), qui appartient à la fonction leds_task_entry (tâche LED), c'est-à-dire qu'il y a eu un changement de tâche, et maintenant, la gestion est passée à la tâche LED.

Cette méthode simple permet d'établir comment les tâches RTOS interagissent les unes avec les autres.

Bien sûr, en réalité, l'interaction des tâches peut être plus complexe, mais avec l'utilisation d'un émulateur, le suivi de cette interaction devient moins ardu.

Ici On peut visionner une courte vidéo sur le lancement de l'émulateur et l'interaction avec IDA Pro.

Lancement avec Radare2

On ne peut pas ignorer un outil aussi polyvalent que Radare2.

Pour se connecter à l'émulateur en utilisant r2, la commande sera la suivante :

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

Actuellement, le démarrage (dc) et la pause d'exécution (Ctrl+C) sont disponibles.

Malheureusement, pour le moment, r2 présente des problèmes lors de l'utilisation du serveur gdb matériel et de la mise en page de la mémoire, ce qui empêche les points d'arrêt et les étapes (commande ds). Nous espérons que cela sera corrigé prochainement.

Lancement avec Eclipse

Une des façons d'utiliser l'émulateur est de déboguer le firmware de l'appareil en développement. Pour plus de clarté, nous allons également utiliser le firmware "Rhinocéros". Vous pouvez télécharger le code source du firmware d'ici.

Nous allons utiliser Eclipse comme IDE de l'ensemble System Workbench for STM32.

Pour que le firmware, directement compilé dans Eclipse, soit chargé dans l'émulateur, il est nécessaire d'ajouter le paramètre firmware=null à la commande de lancement de l'émulateur :

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

Configuration de debug

Dans Eclipse, choisissez le menu Exécuter — Configurations de debug… Dans la fenêtre qui s'ouvre, sous la section GDB Hardware Debugging il est nécessaire d'ajouter une nouvelle configuration, après quoi, dans l'onglet « Principal », indiquer le projet actuel et l'application à déboguer :

Dans l'onglet « Débogueur », il est nécessaire d'indiquer la commande GDB :
${openstm32_compiler_path}arm-none-eabi-gdb

Et également d'entrer les paramètres pour se connecter au serveur GDB (hôte et port) :

Dans l'onglet « Démarrage », il est nécessaire d'indiquer les paramètres suivants :

• cocher la case Load image (pour que le chargement de l'image compilée du firmware soit effectué dans l'émulateur) ;
• cocher la case Load symbols;
• ajouter la commande de lancement : set $pc = *0x08000004 (définir la valeur PC à partir de la mémoire à l'adresse 0x08000004 — là où l'adresse est stockée ResetHandler).

Veuillez noter, si vous ne souhaitez pas charger le fichier de firmware depuis Eclipse, alors les paramètres Load image et Exécutez les commandes ne sont pas nécessaires.

Après avoir cliqué sur Debug, vous pouvez travailler en mode débogage :

• exécution pas à pas du code
  
• interactions avec les points d'arrêt
  

Remarque. Dans Eclipse, il y a, euh… certaines spécificités… et il faut vivre avec. Par exemple, si un message « No source available for «0x0″ » apparaît au lancement du débogueur, exécutez la commande Step (F5)

En conclusion

L'émulation du code natif est un sujet particulièrement intéressant. Pour le développeur d'appareils, cela permet de déboguer le firmware sans appareil réel. Pour le chercheur, c'est une opportunité de réaliser une analyse dynamique du code, ce qui n'est pas toujours possible même avec un appareil.

Nous voulons fournir aux spécialistes un outil qui soit pratique, relativement simple et qui ne prenne pas trop de temps et d'efforts pour sa configuration et son lancement.

Écrivez dans les commentaires votre expérience avec les émulateurs matériels. Nous vous invitons à discuter et nous serons ravis de répondre à vos questions.

Seuls les utilisateurs enregistrés peuvent participer au sondage. Connectez-vous, s'il vous plaît.

Pourquoi utilisez-vous l'émulateur ?

• je développe (débogue) des firmwares

• j'analyse des firmwares

• je lance des jeux (Dendi, Sega, PSP)

• autre chose (écrivez dans les commentaires)

7 utilisateurs ont voté. 2 utilisateurs se sont abstenus.

Quel logiciel utilisez-vous pour l'émulation de code natif ?

• QEMU

• Moteur Unicorn

• Proteus

• autre chose (écrivez dans les commentaires)

6 utilisateurs ont voté. 2 utilisateurs se sont abstenus.

Qu'aimeriez-vous améliorer dans l'émulateur utilisé ?

• je souhaite de la rapidité

• je souhaite un réglage/lancement plus facile

• je souhaite plus d'options d'interaction avec l'émulateur (API, hooks)

• tout me convient

• autre chose (écrivez dans les commentaires)

8 utilisateurs ont voté. 1 utilisateur s'est abstenu.

Source : habr.com