Programmation assembleur (ASM) - REDS - HEIG-VD

Programmation assembleur (ASM)
Daniel Rossier / Magali Frölich / Rick Wertenbroek
Environnements de développement croisé
jeudi 6 octobre 2016
Echéance: mardi 18 octobre 2016, 23h59
- 1 -
labo cross-env
(v2016.1.7)
Objectif du laboratoire
L’objectif de ce laboratoire est de se familiariser avec les outils de développement croisé et l’utilisation
du moniteur U-Boot .
Le développement croisé se fera depuis un machine hôte (la VM avec une architecture de type x86_64)
et consiste en la génération d’exécutables binaires pour des machines avec une architecture différente
(de type x86 ou ARM). Les machines cibles seront émulées dans la VM grâce à l’environnement virtuel
Qemu.
Consignes de laboratoire
● Le laboratoire est évalué selon les conditions établies dans le document annexe qui vous a été
distribué en début de semestre.
● Il n’y aura pas de code à rendre pour ce laboratoire et l’évaluation se portera sur votre rapport
(journal) que vous pouvez rédiger dans un fichier README.md . Ce fichier est à placer dans le
dossier asm_student/labo2 .
Etape no. 1 - Mise à jour du workspace asm_student_2016
Pour la suite des laboratoires, nous allons renommer le nom du dépôt asm_student_2016 en
asm_student . La procédure pour effectuer cette modification est la suivante :
a)
En premier lieu, sauvez votre travail sur le serveur bitbucket si nécessaire.
b)
Loguez-vous sur votre compte bitbucket .
c) Sélectionnez votre projet asm_student_2016
d) Cliquez sur le menu " Settings "
e) Editez le nom du dépôt et remplacez asm_student_2016 par asm_student .
f) Cliquez sur le bouton " Save repository details "
Ouvrez un terminal et effectuez les commandes suivantes pour récupérer votre dépôt :
$ git clone https://bitbucket.org/<login bitbucket>/asm_student/
$ git remote add asm_student_orig <login heig-vd>@eigit.heig-
vd.ch:/home2/reds/asm/asm_student
$ git fetch asm_student_orig
$ git merge asm_student_orig/master

ASM – Environnements de développement croisé
- 2 -
Etape no. 2 - Premiers pas avec U-boot et déploiement d'applications
Cette étape est dédiée à la prise en main du moniteur U-boot, le but sera de déployer votre première
application depuis U-boot et ceci dans l’environnement émulé.
Le dossier labo2 contient plusieurs projets (ces projets existent dans votre workspace Eclipse). Ils sont
appelés exo1 et exo2. Dans les dossiers correspondant se trouve tout le matériel nécessaire à la cross-
compilation des machines-cibles x86 et arm.
Pour cette étape, le projet à utiliser est exo2.
a) Compilez le projet : ouvrez un terminal, placez-vous dans le répertoire de projet exo2 et lancez la
commande make.
⇒ Quelle est la toolchain utilisée ?
b) A la racine du workspace (asm_student/) se trouvent deux scripts ./st86 et ./stf
Ceux-ci permettent, respectivement, de lancer la machine émulée de type x86 et ARM. Exécutez le
script ./st86. Les traces de démarrage du moniteur apparaissent jusqu'à l'obtention du shell de U-
boot.
 Utilisez la commande help pour vous renseigner sur les commandes suivantes : go, md, mm,
mw, printenv, setenv, tftp.
 Exécutez la commande printenv et observez les résultats.
c) Programme hello_world
Pour lancer un programme dans la machine émulée, il va d’abord falloir copier et charger le binaire
depuis la machine hôte vers la mémoire de la machine cible. Une variable d’environnement a été
créée afin de faciliter ceci. Pour placer le binaire en mémoire, il vous suffit d’exécuter la commande :
$ boot> run tftphello
Ceci placera le binaire à l’adresse 0xef00000.
Pour exécuter le code du binaire, il suffit d’utiliser la commande go avec l’adresse correspondante.
boot > go 0xef00000
⇒ Que fait la commande run et quels sont les paramètres liés à la variable d’environnement
tftphello ?
d) Programme hello_world sur ARM
 Générez les binaires du projet exo1 à l’aide du Makefile.
⇒ Quelle est la toolchain utilisée ?
 Lancez la machine émulée ARM avec le script ./stf

ASM – Environnements de développement croisé
- 3 -
 Etudiez maintenant les variables d’environnement de U-Boot avec printenv et exécutez
l’application hello_world en vous aidant de run, go et des variables d’environnement.
Consignes supplémentaires pour le rendu de votre laboratoire
 Répondez aux questions dans votre fichier README.md et complétez avec deux captures d’écran
sur lesquelles on peut voir l’exécution du programme et les commandes utilisées pour le lancer.
(x86 et ARM)
Etape no. 3 - Debugger une application tournant dans l'émulateur qemu
Le debugger est un outil puissant. Nous allons étudier son utilisation dans le cadre des exercices suivants.
Dans le projet exo1, une petite application vous permet de jouer au jeu "Feuille-Caillou-Ciseaux" contre
l’ordinateur. Mais attention l’ordinateur triche tout le temps et utilisera toujours le choix qui lui permet
de vous battre. Une fois l’application compilée le but sera d’utiliser le debugger et de modifier les valeurs
dans les registres à l’exécution afin de tricher à notre tour et ainsi battre l’ordinateur. (Il est demandé de
gagner sans modifier les fichiers sources).
a) Lancez la commande make dans le projet exo1.
⇒ Quelle est la toolchain utilisée dans ce projet ?
b) Lancez cette fois-ci le script ./stf-debug (Ce script démarre la machine cible comme le script ./stf mais
en plus il démarre un serveur gdb afin de pouvoir débugger la machine cible depuis la machine hôte.)
et utilisez la configuration de debug Eclipse intitulée "labo2 (ARM) Debug".
c) Exécutez l'application feuille_caillou_ciseaux en utilisant le même procédé qu’à l’étape
précédente. Utilisez la commande printenv afin de visualiser les variables d'environnement dans cette
version d'U-boot pour vous aider.
(NB: l’environnement émulé attendra que la configuration de debug soit lancée dans Eclipse avant
de pouvoir continuer.)
d) Observez le déroulement du programme en exécutant les commandes “pas à pas” et modifier la valeur
des registres afin de gagner la partie. Le code source de l’application peut vous aider.
e) Il est aussi possible de modifier directement le programme chargé en mémoire dans U-Boot. Utilisez
les commandes md et mw pour modifier le binaire chargé dans U-Boot et changer le message "You
lost ! " par "You win !".
Aidez-vous du debugger et des applications objdump/readelf pour trouver les adresses.
Indications
- La commande md.l <adresse> <#bytes à afficher> vous permet d’explorer et
d’afficher le contenu de la mémoire dans U-Boot.
- La commande mw.l <adresse> <valeur sur 4 bytes> permet d’écrire 4 octets.
- La commande mw.b <adresse> <valeur sur 1 byte> permet d’écrire 1 octet.
- Pour rappel, le processeur est configuré en little-endian.

ASM – Environnements de développement croisé
- 4 -
- Utilisez le bon préfixe de la toolchain avec les programmes objdump/readelf
(<toolchain>-objdump par exemple)
Consignes supplémentaires pour le rendu de votre laboratoire
 Documentez les réponses aux questions et votre démarche dans votre README.md
 Effectuez une capture d’écran dans U-Boot où les chaînes de caractères "You win" et "You lost"
sont affichées avec la commande md.
Etape no. 4 - Patch d'une application cross-compilée pour x86
Le binaire pour cet exercice “labo2/exo2/you_shall_not_pass.bin” est une application démo, une version
d’évaluation d’un programme, dont la période d’évaluation est expirée. On s’intéresse ici à modifier son
comportement afin de s’affranchir de la date limite d’utilisation. Le code source est donné mais on ne le
modifiera pas. On cherche ici à étudier son comportement avec le debugger et la vue assembleur afin de
s’affranchir du test de date limite.
a) Lancez cette fois-ci le script ./st86-debug et utilisez la configuration de debug intitulée "labo2 exo2
(x86) Debug"
(NB: Démarrez le debugger après avoir lancé le script ./st86-debug)
Ajoutez un breakpoint à l'entrée de la fonction you_shall_not_pass() et lancez l'exécution de votre
programme. Observez le déroulement du programme en exécutant les commandes “pas à pas”.
Suivez le déroulement dans la vue assembleur.
⇒ Repérez les instructions qui vous interdisent l’utilisation du programme.
b) Servez-vous des commandes d’U-Boot afin d’écraser ces instructions dans le binaire chargé en
mémoire. Lancez ensuite le programme; celui-ci affiche le début de la suite de Fibonacci.
Indications
 Le programme est stocké en mémoire à l’adresse 0xef00000.
 Utilisez les instructions md, mw dans U-boot pour modifier le programme.
 Une idée serait de remplacer des instructions de tests ou alors de saut par l’opération NOP (No
Operation). Elle est codée sur 1 octet et son code (opcode) est 0x90.
En bonus (optionnel)
 Modifier les instructions n’est pas la seule manière de passer outre la protection, proposez et
documentez une solution alternative de votre choix.
Consignes supplémentaires pour le rendu de votre laboratoire
 Documentez votre démarche dans votre README.md et répondez aux questions.
 Effectuez une capture d’écran du debugger qui affiche les instructions NOP que vous avez ajouté.