Version imprimable
Bonjour,
je voudrais inscérer l'instruction assembleur suivante : ".ascii \xEB\x01\xE8"
dans mon code en C++ sous gcc et ca me génére une erreur du type: "error: junk at end of line"
Je ne vois pas ou je fais une erreur, merci d'avance de vos lumiéreCode:
2
3
4
5
6
7
8
9
10
11
Il doit manquer une paire de guillemets :
Code:__asm volatile( ".ascii \"\xEB\x01\xE8\"" );
Hello,
Euh ! C'est très tordu ! Que cherches-tu à faire en particulier ?
« .ascii » est une directive indiquant que ce qui suit est une chaîne de caractères qui doit être codée comme telle. Cette chaîne doit être entre guillemets. Or, comme ta directive d'assemblage est déjà elle-même entre guillemets, il faut ajouter les guillemets encadrant la chaîne proprement dite en les « échappant » avec un anti-slash « \ ».
À part ça, les octets qui composent ta chaîne vont être insérés au milieu du code, à l'endroit exact où tu l'as déclarée, et être pris pour des codes opérations. C'est peut-être voulu puisque les codes en hexadécimal y ressemblent. Cela dit, ils semblent ne correspondre à rien. Où plutôt si : un JMP qui saute le dernier opcode. Ça a l'air d'être cohérent puisque le programme s'exécute chez moi sans planter.
Enfin, n'oublie pas de compiler avec « g++ » et pas « gcc ».
Merci, ca fonctionne maintenant, du moins ca compile.
Pour la petite histoire ce bout de code assembleur est censé empécher le désassemblage du code en faisant perdre le fil au désassembleur. J'avoue que je ne comprend pas bien comment ca marche. Je ne sais même pas ce qu'est un « opcode » en fait.
Euh ... Pourquoi ce bout de code bloquerait-il le désassemblage ?
Désolé, je n'ai rien dit (après test).
En effet, un désassemblage statique (via gdb et options par défaut, en tout cas) ne donne rien.
Mais, étant donné qu'un CPU est capable de suivre le code, un désassembleur (ou processeur virtuel à la valgrind) est probablement à même de désassembler.
La preuve par une session GDB :
En lisant main+4, on repère l'embrouille : on saute à une adresse qui n'est pas un opcode repéré par gdb.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
Donc on utilise la syntaxe alternative de disas : on désassemble de main+7 à main+37 (main+36 + 1 ; pour récupérer le retq).
Ce qui nous ramène donc bien au code assembleur de base.
Donc, certes, ça complique l'analyse, mais elle ne reste pas impossible pour autant.
Et il est probable qu'il existe un outil le faisant tout seul, sans intervention de l'utilisateur, simplement en utilisant un processeur virtuel et en stockant les instructions ! (valgrind peut servir de couche de base pour ça)
Ok. C'est ultra-classique, en effet, mais notoirement inefficace.Citation:
Envoyé par uriotcea
Un « code opération », ou « code-op », ou encore « opcode » pour « operation code » en anglais, ce sont les briques du langage machine : chaque octet de ton programme en mémoire va contenir un code qui va correspondre à une opération du micro-processeur. Par exemple :
Code:
2
3
On voit bien dans cet exemple que si ces instructions ont besoin d'opérandes, celles-ci sont placées à la suite du code opération et lues séquentiellement en mémoire. Une fois l'instruction interprétée et exécutée en entier, le micro-processeur passe à l'octet suivant et considère son contenu comme le code d'une nouvelle opération à mener à bien.
Or « EB 01 » signifie « JMP PositionCourante + 1 octet », sachant que la position courante, pointée par EIP, est en fait l'adresse de la prochaine instruction et pas celle en cours d'exécution. Et « E8 » signifie « CALL », qui est en principe suivie de deux octets pour l'adresse de destination.
Code:
2
Donc le JMP sert à passer par dessus le E8 introduit artificiellement. Le désassembleur, par contre, lira le JMP, le traitera comme une instruction tout-à-fait valide et passera à la suivante, « CALL », en prenant comme opérandes des codes qui appartiennent en fait à la suite du programme, désynchronisant ainsi la lecture.
L'ennui, c'est que c'est extrêmement fréquent lors des désassemblages, même lorsque ce n'est pas volontaire. Par exemple, lorsque deux routines sont séparées par de vraies plages de données, ou par du vide. Ensuite, statistiquement, le désassembleur finira quand même par retomber sur ses pieds au bout d'une dizaine d'octets.
Il ne faut donc qu'une minute maximum à un programmeur averti pour contourner le subterfuge.
Ok merci pour vos explication détaillés.
De maniére générale, les techniques anti cracker n'ont jamais pour objectif de l'empécher mais uniquement de le ralentir.
La question est donc si vous n'aviez pas eu le code initial en C++, combien de temps vous aurait-ils fallu pour comprendre le subterfuge, 1 mn, 1 heures, ou plus?
Ça dépend réellement de la personne qui va faire l'exercice. Quiconque a fait de l'assembleur suffisamment sérieusement ne butera pas plus d'une minute dessus. Sinon, l'astuce a effectivement quoi rendre les gens perplexes un moment, mais surtout à cause du fait que l'on va chercher une raison légitime à l'existence de ces codes-opérations. Mais, en désespoir de cause, on va toujours finir pas suivre pas à pas le cheminement du processeur, et s'apercevoir que l'on fait un JMP un octet plus loin, que cela ait du sens où non. Au moment même ou l'utilisateur reprendra le désassemblage à partir de ce point, le programme se dévoilera comme par magie. Il faudrait vraiment en mettre partout (ce qui est possible) pour que cela rende le déssassemblage pénible mais, même à ce moment, il est toujours possible d'écrire un script pour les éliminer d'un coup.Citation:
Envoyé par uriotcea
À noter que l'insertion de codes-opérations apparamment incohérents ne sert pas forcément à empêcher le désassemblage : c'était une technique relativement simple et efficace pour « masquer » une instruction. Par exemple, « 31 C0 » sert à faire un « XOR AX,AX », donc à mettre AX à zéro. Si l'on insère « B8 » juste avant, cela forme « MOV AX,0C031h ». La valeur en elle-même n'a pas beaucoup d'intérêt mais selon l'endroit où l'on saute, ça permet d'affecter à AX une valeur nulle ou non-nulle.
C'était donc un moyen simple et peu coûteux (un seul octet !) d'annuler AX si une procédure avait été prématurément interrompue, par exemple, en faisant un JMP directement vers la sortie, et de lui donner une valeur non nulle si le programme s'est déroulé normalement jusqu'à la fin. C'était également très pratique car, en assembleur, il est difficile de conditionner plusieurs actions à une cause sans recourir aux sauts.
Pour info, sous OllyDbg, l'astuce est éventé directement en déroulant le programme ne mode Trace.