Dans le cadre de la réunion 0x0A DC7831 Le 16 février, nous avons présenté un rapport sur les principes de base de l'émulation de code binaire et notre propre développement - un émulateur de plate-forme matérielle .
Dans cet article, nous décrirons comment exécuter le micrologiciel de l'appareil dans l'émulateur, démontrerons l'interaction avec le débogueur et effectuerons une petite analyse dynamique du micrologiciel.
Préhistoire
Il y a longtemps dans une galaxie très lointaine
Il y a quelques années, dans notre laboratoire, il était nécessaire d'étudier le firmware d'un appareil. Le firmware a été compressé et décompressé avec un bootloader. Il l'a fait d'une manière très compliquée, en déplaçant plusieurs fois les données en mémoire. Et le firmware lui-même a ensuite interagi activement avec les périphériques. Et tout cela sur le noyau MIPS.
Pour des raisons objectives, les émulateurs disponibles ne nous convenaient pas, mais nous souhaitions quand même exécuter le code. Nous avons ensuite décidé de créer notre propre émulateur, qui ferait le minimum et nous permettrait de décompresser le firmware principal. Nous l'avons essayé et cela a fonctionné. Nous avons pensé, et si nous ajoutions des périphériques pour exécuter également le firmware principal. Cela n’a pas fait très mal – et ça a aussi fonctionné. Nous y avons réfléchi à nouveau et avons décidé de créer un émulateur à part entière.
Le résultat était un émulateur de systèmes informatiques .
Pourquoi Kopycat ?
Il y a un jeu de mots.
- copycat (anglais, nom [ˈkɒpɪkæt]) - imitateur, imitateur
- cat (anglais, nom [ˈkæt]) - chat, chat - l'animal préféré de l'un des créateurs du projet
- La lettre « K » provient du langage de programmation Kotlin
Imitateur
Lors de la création de l'émulateur, des objectifs très précis ont été fixés :
- la possibilité de créer rapidement de nouveaux périphériques, modules, cœurs de processeur ;
- la possibilité d'assembler un appareil virtuel à partir de différents modules ;
- la possibilité de charger n'importe quelle donnée binaire (micrologiciel) dans la mémoire d'un appareil virtuel ;
- capacité à travailler avec des instantanés (instantanés de l'état du système) ;
- la possibilité d'interagir avec l'émulateur via le débogueur intégré ;
- joli langage moderne pour le développement.
En conséquence, Kotlin a été choisi pour la mise en œuvre, l'architecture du bus (c'est-à-dire lorsque les modules communiquent entre eux via des bus de données virtuels), JSON comme format de description de périphérique et GDB RSP comme protocole d'interaction avec le débogueur.
Le développement dure depuis un peu plus de deux ans et se poursuit activement. Pendant ce temps, les cœurs de processeur MIPS, x86, V850ES, ARM et PowerPC ont été implémentés.
Le projet prend de l'ampleur et il est temps de le présenter au grand public. Nous ferons une description détaillée du projet plus tard, mais pour l'instant nous nous concentrerons sur l'utilisation de Kopycat.
Pour les plus impatients, une version promo de l'émulateur est téléchargeable sur .
Rhino dans l'émulateur
Rappelons que plus tôt pour la conférence SMARTRHINO-2018, un dispositif de test « Rhinoceros » a été créé pour enseigner les compétences d'ingénierie inverse. Le processus d'analyse statique du micrologiciel a été décrit dans .
Essayons maintenant d'ajouter des « haut-parleurs » et d'exécuter le firmware dans l'émulateur.
Nous avons besoin de:
1) Java 1.8
2) Python et modules pour utiliser Python dans l'émulateur. Vous pouvez créer le module WHL Jep pour Windows .
Fenêtres :
1)
2)
Pour Linux:
1) socat
Vous pouvez utiliser Eclipse, IDA Pro ou radare2 comme client GDB.
Comment ça marche?
Afin d'exécuter un firmware dans l'émulateur, il est nécessaire « d'assembler » un appareil virtuel, qui est un analogue d'un appareil réel.
Le véritable appareil (« rhinocéros ») peut être représenté dans le schéma fonctionnel :
L'émulateur a une structure modulaire et le périphérique virtuel final peut être décrit dans un fichier JSON.
JSON 105 lignes
{
"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"]
]
}Faites attention au paramètre firmware section params est le nom d'un fichier qui peut être chargé dans un périphérique virtuel en tant que micrologiciel.
Le périphérique virtuel et son interaction avec le système d'exploitation principal peuvent être représentés par le schéma suivant :
L'instance de test actuelle de l'émulateur implique une interaction avec les ports COM du système d'exploitation principal (débogage UART et UART pour le module Bluetooth). Il peut s'agir de ports réels auxquels les appareils sont connectés ou de ports COM virtuels (pour cela, il vous suffit com0com/socat).
Il existe actuellement deux manières principales d'interagir avec l'émulateur depuis l'extérieur :
- Protocole GDB RSP (par conséquent, les outils qui prennent en charge ce protocole sont Eclipse / IDA / radare2) ;
- ligne de commande interne de l'émulateur (Argparse ou Python).
Ports COM virtuels
Afin d'interagir avec l'UART d'un périphérique virtuel sur la machine locale via un terminal, vous devez créer une paire de ports COM virtuels associés. Dans notre cas, un port est utilisé par l'émulateur, et le second par un programme de terminal (PuTTY ou screen) :
Utiliser com0com
Les ports COM virtuels sont configurés à l'aide de l'utilitaire de configuration du kit com0com (version console - C:Program Files (x86)com0comsetupс.exe, ou version GUI - C:Fichiers programme (x86)com0comsetupg.exe):
Vérifie les boites activer le dépassement de tampon pour tous les ports virtuels créés, sinon l'émulateur attendra une réponse du port COM.
Utiliser socat
Sur les systèmes UNIX, les ports COM virtuels sont automatiquement créés par l'émulateur à l'aide de l'utilitaire socat ; pour cela, il suffit de préciser le préfixe dans le nom du port au démarrage de l'émulateur socat:.
Interface de ligne de commande interne (Argparse ou Python)
Étant donné que Kopycat est une application console, l'émulateur propose deux options d'interface de ligne de commande pour interagir avec ses objets et variables : Argparse et Python.
Argparse est une CLI intégrée à Kopycat et est toujours disponible pour tout le monde.
Une CLI alternative est l’interpréteur Python. Pour l'utiliser, vous devez installer le module Jep Python et configurer l'émulateur pour qu'il fonctionne 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 jepPour installer Jep sur Windows, vous devez d'abord installer le SDK Windows et le Microsoft Visual Studio correspondant. Nous avons rendu la tâche un peu plus facile pour vous et JEP pour les versions actuelles de Python pour Windows, le module peut donc être installé à partir du fichier :
pip install jep-3.8.2-cp27-cp27m-win_amd64.whlPour vérifier l'installation de Jep, vous devez exécuter sur la ligne de commande :
python -c "import jep"Le message suivant doit être reçu en réponse :
ImportError: Jep is not supported in standalone Python, it must be embedded in Java.Dans le fichier batch de l'émulateur pour votre système (copiercat.bat - Pour les fenêtres, imitateur - pour Linux) à la liste des paramètres DEFAULT_JVM_OPTS ajouter un paramètre supplémentaire Djava.library.path — il doit contenir le chemin d'accès au module Jep installé.
Le résultat pour Windows devrait être une ligne comme celle-ci :
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 console JVM. Le lancement s'effectue via le script de ligne de commande du système d'exploitation (sh/cmd).
Commande à exécuter sous Windows :
binkopycat -g 23946 -n rhino -l user -y library -p firmware=firmwarerhino_pass.bin,tty_dbg=COM26,tty_bt=COM28Commande à exécuter sous Linux à l'aide de l'utilitaire 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— Port TCP qui sera ouvert pour l'accès au serveur GDB ;-n rhino— nom du module principal du système (appareil assemblé) ;-l user— nom de la bibliothèque pour rechercher le module principal ;-y library— chemin de recherche des modules inclus dans l'appareil ;firmwarerhino_pass.bin— chemin d'accès au fichier du micrologiciel ;- COM26 et COM28 sont des ports COM virtuels.
En conséquence, une invite s'affichera Python > (ou 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 >Interaction avec IDA Pro
Pour simplifier les tests, nous utilisons le micrologiciel Rhino comme fichier source pour l'analyse dans IDA sous la forme (les méta-informations y sont stockées).
Vous pouvez également utiliser le firmware principal sans méta-informations.
Après avoir lancé Kopycat dans IDA Pro, dans le menu Débogueur, accédez à l'élément "Changer de débogueur…"Et choisissez"Débogueur GDB distant". Ensuite, configurez la connexion : menu Débogueur - Options de processus…
Définissez les valeurs :
- Application - n'importe quelle valeur
- Nom d'hôte : 127.0.0.1 (ou l'adresse IP de la machine distante sur laquelle Kopycat est exécuté)
- Port: 23946
Le bouton de débogage devient désormais disponible (touche F9) :
Cliquez dessus pour vous connecter au module débogueur dans l'émulateur. IDA passe en mode débogage, des fenêtres supplémentaires deviennent disponibles : informations sur les registres, sur la pile.
Nous pouvons désormais utiliser toutes les fonctionnalités standards du débogueur :
- exécution pas à pas des instructions (Entrer dans и Enjamber — touches F7 et F8, respectivement);
- démarrer et suspendre l'exécution ;
- créer des points d'arrêt pour le code et les données (touche F2).
Se connecter à un débogueur ne signifie pas exécuter le code du firmware. La position d'exécution actuelle doit être l'adresse 0x08006A74 — début de fonction Réinitialiser_Handler. Si vous faites défiler la liste, vous pouvez voir l'appel de fonction principal. Vous pouvez placer le curseur sur cette ligne (adresse 0x08006ABE) et effectuez l'opération Courir jusqu'au curseur (touche F4).
Ensuite, vous pouvez appuyer sur F7 pour accéder à la fonction principal.
Si vous exécutez la commande Continuer le processus (touche F9), puis la fenêtre « Veuillez patienter » apparaîtra avec un seul bouton Suspendre:
Lorsque vous appuyez Suspendre l'exécution du code du firmware est suspendue et peut être poursuivie à partir de la même adresse dans le code où elle a été interrompue.
Si vous continuez à exécuter le code, vous verrez les lignes suivantes dans les terminaux connectés aux ports COM virtuels :
La présence de la ligne « state bypass » indique que le module Bluetooth virtuel est passé en mode de réception des données du port COM de l'utilisateur.
Désormais, dans le terminal Bluetooth (COM29 sur la photo), vous pouvez saisir des commandes conformément au protocole Rhino. Par exemple, la commande « MEOW » renverra la chaîne « mur-mur » au terminal Bluetooth :
Ne m'imite pas complètement
Lors de la création d'un émulateur, vous pouvez choisir le niveau de détail/émulation d'un appareil particulier. 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 émulées et le flux de données est reçu du port COM du système principal ;
- le périphérique virtuel fournit une redirection complète des données vers le périphérique réel ;
- comme un simple stub qui renvoie toujours « OK ».
La version actuelle de l'émulateur utilise la deuxième approche - le module Bluetooth virtuel effectue la configuration, après quoi il passe en mode « proxy » des données du port COM du système principal vers le port UART de l'émulateur.
Considérons la possibilité d'une instrumentation simple du code au cas où une partie de la périphérie ne serait pas implémentée. Par exemple, si un timer chargé de contrôler le transfert des données vers DMA n'a pas été créé (le contrôle est effectué dans la fonction ws2812b_attendresitué à 0x08006840), alors le firmware attendra toujours que le drapeau soit réinitialisé occupésitué à 0x200004C4qui montre l'occupation de la ligne de données DMA :
Nous pouvons contourner cette situation en réinitialisant manuellement le drapeau occupé immédiatement après l'avoir installé. Dans IDA Pro, vous pouvez créer une fonction Python et l'appeler dans un point d'arrêt, et placer le point d'arrêt lui-même dans le code après avoir écrit la valeur 1 dans l'indicateur. occupé.
Gestionnaire de point d'arrêt
Tout d’abord, créons une fonction Python dans IDA. Menu Fichier - Commande de script...
Ajoutez un nouvel extrait dans la liste de gauche, donnez-lui un nom (par exemple, BPT),
Dans le champ de texte à droite, saisissez le code fonction :
def skip_dma():
print "Skipping wait ws2812..."
value = Byte(0x200004C4)
if value == 1:
PatchDbgByte(0x200004C4, 0)
return False
Après cela, nous appuyons Courir et fermez la fenêtre de script.
Passons maintenant au code sur 0x0800688A, définir un point d'arrêt (touche F2), le modifier (menu contextuel Modifier le point d'arrêt...), n'oubliez pas de définir le type de script sur Python :
Si la valeur actuelle du drapeau occupé est égal à 1, alors vous devez exécuter la fonction sauter_dma dans la ligne de script :
Si vous exécutez le firmware pour exécution, le déclenchement du code du gestionnaire de point d'arrêt est visible dans la fenêtre IDA. Sortie par ligne Skipping wait ws2812.... Désormais, le firmware n'attendra pas que le drapeau soit réinitialisé occupé.
Interaction avec l'émulateur
Il est peu probable que l’émulation pour le plaisir de l’émulation provoque du plaisir et de la joie. C'est beaucoup plus intéressant si l'émulateur aide le chercheur à voir les données en mémoire ou à établir l'interaction des threads.
Nous allons vous montrer comment établir dynamiquement une interaction entre les tâches RTOS. Vous devez d'abord suspendre l'exécution du code s'il est en cours d'exécution. Si vous allez à la fonction entrée_tâche_bluetooth à la branche de traitement de la commande « LED » (adresse 0x080057B8), vous pouvez alors voir ce qui est d'abord créé puis envoyé à la file d'attente système ledControlQueueHandle un message.
Vous devez définir un point d'arrêt pour accéder à la variable ledControlQueueHandlesitué à 0x20000624 et continuez à exécuter le code :
En conséquence, l'arrêt aura lieu d'abord à l'adresse 0x080057CA avant d'appeler la fonction osMailAlloc, puis à l'adresse 0x08005806 avant d'appeler la fonction osMailPut, puis après un moment - à l'adresse 0x08005BD4 (avant d'appeler la fonction osMailGet), qui appartient à la fonction leds_task_entry (tâche LED), c'est-à-dire que les tâches ont changé, et maintenant la tâche LED a reçu le contrôle.
De cette manière simple, vous pouvez é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 compliquée, mais en utilisant un émulateur, suivre cette interaction devient moins laborieux.
Vous pouvez regarder une courte vidéo du lancement de l'émulateur et de son interaction avec IDA Pro.
Lancez-vous avec Radare2
Vous ne pouvez pas ignorer un outil aussi universel que Radare2.
Pour se connecter à l'émulateur à l'aide de r2, la commande ressemblerait à ceci :
radare2 -A -a arm -b 16 -d gdb://localhost:23946 rhino_fw42k6.elfLancement disponible maintenant (dc) et suspendez l'exécution (Ctrl+C).
Malheureusement, pour le moment, R2 a des problèmes lors du travail avec le serveur matériel GDB et la disposition de la mémoire ; à cause de cela, les points d'arrêt et les étapes ne fonctionnent pas (commande ds). Nous espérons que cela sera bientôt résolu.
Exécuter avec Eclipse
L'une des options d'utilisation de l'émulateur consiste à déboguer le micrologiciel de l'appareil en cours de développement. Pour plus de clarté, nous utiliserons également le firmware Rhino. Vous pouvez télécharger les sources du firmware .
Nous utiliserons Eclipse de l'ensemble comme IDE .
Pour que l'émulateur charge le firmware directement compilé dans Eclipse, vous devez 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=COM28Configuration de la configuration de débogage
Dans Eclipse, sélectionnez le menu Exécuter - Configurations de débogage... Dans la fenêtre qui s'ouvre, dans la section Débogage matériel GDB vous devez ajouter une nouvelle configuration, puis dans l'onglet « Principal » spécifier le projet et l'application en cours pour le débogage :
Dans l'onglet « Débogueur », vous devez spécifier la commande GDB :
${openstm32_compiler_path}arm-none-eabi-gdb
Et saisissez également les paramètres de connexion au serveur GDB (hôte et port) :
Sur l'onglet « Démarrage », vous devez préciser les paramètres suivants :
- activer la case à cocher Charger l'image (pour que l'image du firmware assemblée soit chargée dans l'émulateur) ;
- activer la case à cocher Charger des symboles;
- ajouter une commande de lancement :
set $pc = *0x08000004(réglez le registre PC sur la valeur de la mémoire à l'adresse0x08000004- l'adresse y est stockée Gestionnaire de réinitialisation).
Noter, si vous ne souhaitez pas télécharger le fichier du firmware depuis Eclipse, les options Charger l'image и Exécuter des commandes pas besoin de l'indiquer.
Après avoir cliqué sur Déboguer, vous pouvez travailler en mode débogueur :
- exécution du code étape par étape
- interagir avec les points d'arrêt
Noter. Eclipse a, hmm... quelques bizarreries... et vous devez vivre avec elles. Par exemple, si au démarrage du débogueur le message « Aucune source disponible pour « 0x0″ » apparaît, alors exécutez la commande Step (F5)
Au lieu d'une conclusion
Émuler du code natif est une chose très intéressante. Il devient possible pour un développeur de périphériques de déboguer le micrologiciel sans véritable périphérique. Pour un chercheur, c’est l’occasion de réaliser une analyse dynamique du code, ce qui n’est pas toujours possible même avec un appareil.
Nous souhaitons fournir aux spécialistes un outil pratique, moyennement simple et qui ne demande pas beaucoup d'efforts et de temps à configurer et à utiliser.
Écrivez dans les commentaires votre expérience d'utilisation des émulateurs matériels. Nous vous invitons à en discuter et nous serons heureux de répondre à vos questions.
Seuls les utilisateurs enregistrés peuvent participer à l'enquête. s'il te plait.
Pourquoi utilisez-vous l'émulateur ?
-
Je développe (débogage) un firmware
-
je recherche un firmware
-
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 émuler le code natif ?
-
QEMU
-
Moteur Licorne
-
Proteus
-
autre chose (écrivez dans les commentaires)
6 utilisateurs ont voté. 2 utilisateurs se sont abstenus.
Que souhaiteriez-vous améliorer dans l’émulateur que vous utilisez ?
-
je veux de la vitesse
-
Je veux une facilité de configuration/lancement
-
Je veux plus d'options pour interagir avec l'émulateur (API, hooks)
-
je suis content de tout
-
autre chose (écrivez dans les commentaires)
8 utilisateurs ont voté. 1 utilisateur s'est abstenu.
Source: habr.com