Problème ASM/C - Page 1

Bonjour bonjour !

Voila, j'ai un petit probleme, je m'explique:

j'ai un processus qui tourne, dont l'adresse de début (virtuelle) est 0x00401000
Ensuite, avec un autre programme, je crée dans le premier processus une zone mémoire en 0x00350000 méttons.
Je copie du code asm dedans et j'aimerais l'executer, mais pas à n'importe quel moment !

Voici une partie du code asm du premier processus:

:05AF523 8A8314010000 mov al, byte ptr [ebx+00000114]
:005AF529 84C0 test al, al
:005AF52B 7477 je 005AF5A4

Ce que jveux faire donc, c'est remplacer le mov xxxx par un Call qui pointerais sur l'espace mémoire que j'ai alloué. Ensuite, dans cet espace mémoire, j'execute mon code et je fini par le mov xxxx et un ret.

La question est donc: Comment créer le Call ?
J'ai essayé en mettant l'adresse 0x00350000 mais il veut pas :/ ( a la limite si qqun a la solution avec un jmp, pas de probleme)

ah ben c'est bon, j'ai trouvé tt seul

tu peux donner la solution?
sinon tu pour te faciliter la tache tu peux utiliser les zones de memoires partagées (Unix/Linux)

		//-----------------
		// Création du saut
		signed int saut;
		BYTE DataHook[6] = {0xE8,		// opcode instruction Call
							0x90,		// sera remplacé par l'adresse
							0x90,		// pareil
							0x90,		// pareil
							0x90,		// pareil
							0x90};		// nop obligé dans mon cas !

		saut =  ( ((int)CodeMem - 0x5AF523 ) - 0x5 + 0x18);	// calcul du "saut"
		memcpy( &DataHook[1], &saut, sizeof(int));			// on le recopie dans le processus

		WriteProcessMemory( hProc, (LPVOID)0x5AF523, &DataHook[0], 6 * sizeof(char), 0); // adresse du mov

Avec:
DataHook => les octets qui vont remplacé l'instruction dans le processus cible (chez moi le mov xx faisait 6 octets)
saut => calcul de la "distance"-5 en octet entre l'adresse du Call et la ou tu veux allé ( chez moi y'a + 0x18 mais c'est parce que mon code est différent)

Et pour finir tu recopies ca dans le processus: ca va créer un Call adresse_de_CodeMem.
(Penses bien a mettre dans ton code l'isntruction que t'as zappé hein)

Questions :
- tu as quel processeur ?
et
- tu as SP2 installé ?

tiens, marrant ces bidouillages, ca me rappelle mes fonctions maths qui patchent le code appelant avec l'addresse d'une fonction dans une dll optimisee pour le proc sur lequel tu tourne

Sauf qu'avec le SP2 et un processeur récent ça va planter (protection des données contre l'exécution)

? ca m'etonnerait bcp, je le teste sous SP2, avec un PIV 3GHz relativement recent.
ah oui, petite precision, le code patche se trouve dans un buffer alloue par le process qui contient du code genere a la volee, j'ai pas essaye sur le code de l'executable lui meme, mais je vois pas pourquoi ca marcherait pas?

Processeur trop vieux
Il supporte pas l'extension d'interdiction de pages en exécution ^^

Et ça marcherait pas parce que les données, avec SP2 et un processeur qui le gère, sont interdites en exécution.

c'est quoi ce delire? ils interdisent tout ce qui est JIT compiled du coup? y doit bien y avoir moyen de le desactiver ca nan?

Bon en fait on a un peu continué la discussion sur irc. Voilà en gros les passages essentiels (oué j'ai enlevé pas mal de commentaires autour du sujet pour pas poster un log de 10 pages.

[18:18:32] <sBibi> c'est quoi ce delire la?
[18:18:35] <Spectras> de quoi ?
[18:18:49] <sBibi> de plus pouvoir executer du code genere dans un buffer alloue avec les procs recents?
[18:19:01] <Spectras> oué c'est vrai, si l'os le supporte
[18:19:10] <Spectras> (xp à partir du SP2 notamment)
[18:19:21] <sBibi> supporte quoi? l'interdiction de l'executer?
[18:19:23] <Spectras> oué
[18:19:26] <sBibi> tu parle d'une feature...
[18:19:33] <sBibi> securite, toussa?
[18:19:39] <Spectras> c'est censé rendre les buffers overflow plus dur à exploiter
[18:19:43] <sBibi> c'est desactivable par le prog au moins?
[18:20:01] <Spectras> sous dows je crois qu'il faut passer un flag à VirtualAlloc
[18:20:21] <Spectras> fonction d'allocation de mémoire ^^
[18:20:45] <sBibi> oue, enfin la moi j'utilise malloc/free, me sers pas des fct os-specific
[18:21:02] <Spectras> bah dans ce cas c'est grilled pour exécuter du code généré dynamiquement
[18:21:43] <Spectras> à partir de SP2 ça passera plus. (processeurs K8 et supérieur chez amd, ou itanium et supérieurs chez intel)
[18:22:02] <sBibi> ah, pke par defaut il met tout ce que t'alloue pas executable?
[18:22:06] <Spectras> oui
[18:23:13] <Spectras> "Execution protection (also known as NX, or no execute) prevents code execution from data pages such as the default heap, various stacks, and memory pools. Protection can be applied in both user and kernel-mode."
[18:23:30] <Spectras> (source : msdn => http://msdn.microsoft.com/security/productinfo/XPSP2/memoryprotection/execprotection.aspx )
[18:24:50] <sBibi> enfin bon, ca pourrait etre pire, on pourrait ne pas avoir le choix du tout, et avoir l'execution bloquee pour absolument tout
[18:25:12] <Spectras> ben pour la débloquer t'es obligé de passer par les apis win32
[18:25:22] <Spectras> donc la portabilité en prend un coup
[18:25:42] <Spectras> (déjà que si tu génères du code à la volée la portabilité est limitée à un proc particulier)
[18:26:10] <Spectras> "Applications that attempt to violate execution protection will receive an exception with status code STATUS_ACCESS_VIOLATION (0xC0000005)."

[18:28:15] <sBibi> ca bloque tout ce qui est JIT compiled
[18:28:23] <Spectras> oué
[18:28:43] <Spectras> sauf
[18:28:56] <Spectras> ils font un cas particulier
[18:29:14] <Spectras> apparmment d'après ce que je lis, ils détectent au moins certaines versions de .net
[18:29:19] <Spectras> et désactivent la protection tous seuls
[18:29:41] <Spectras> ça pue la tentative de faire passer .net devant java de manière déloyale à plein nez

[18:35:24] <sBibi> ah sur le stack aussi??
[18:35:29] <sBibi>
[18:35:43] <Spectras> oué la pile aussi est interdite en exécution

mais heu t'as vire mon coup de gueule

Je peux le remettre si tu veux
Ou tu peux aussi uploader le log complet et mettre un lien ici ^^

non mais je deconnais hein

[18:29:41] <Spectras> ça pue la tentative de faire passer .net devant java de manière déloyale à plein nez

Je suis prêt à parier que s'ils ont fait des trucs spéciaux pour que .net marche, ils ont fait la même chose pour java... skoi cette anti-microsoftisme de base

Pollux> tu paries mal, d'après le site de Microsoft lui-même.
(en plus tu vois vraiment microsoft dépenser de l'argent pour faire marcher une technologie concurrente ?)

Google n'a pas l'air d'être loquace sur des conflits entre Java et WinXP SP2 liés au bit NX, donc à moins que tu aies des références précises, je n'y crois pas...

Après MS dit sans doute qu'il ne supporte pas la JVM de Sun, mais c'est encore autre chose ^^

- c'est pas la jvm mais uniquement les progs en jit
- c'est uniquement avec des processeurs K8 (ou supérieur mais comme y'a pas de supérieurs)

Donc c'est pas anormal qu'il y ait pas plus d'infos.

- oui, mais ts les progs sont exécutés par défaut en jit, non ?
- certes, mais on peut pas dire que ça soit rarissime...

et je dois donc en déduire que tu n'as pas la moindre source ?

- Ca dépend : un prog qui est exécuté par la jvm c'est pas un problème suffit de mettre à jour la jvm. Le problème vient des applications utilisant java, intégrant leur jvm ou leur compiler jit (même une copie d'une version un peu plus ancienne) dans leur répertoire. Toutes ces applis là ne pourront pas marcher sans mise à jour.
- Pour l'instant les K8 sont pas super répandus, et faut à la fois le K8 et windows xp pro sp2

Ben j'ai la source de Microsoft qui fait mention que les programmes jit ne fonctionneront pas.
Sauf ceux .net parce qu'ils ont fait une routine pour les détecter et désactiver la protection.

Ca marche niquel sur mon XP2800+ sous winXp pro SP1

Oui, sauf que si t'as lu ce qui précède ça doit foirer à partir de la série K8 (Athlon64 et Opteron) avec winxp pro SP2

yep, j'ai pas encore eu l'occasion de tester, mais bientot