Discussion :

[homeostasie]

Bonjour,

Je suis entrain d'analyser un shellcode et je constate à la fin de celui-ci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
"\x50\xff\x55\xf4\x39\xd8\x0f\x84\x14\xff\xff\xff\x83\xc7\x07\x57\xff\xd0\xc9\xc3"
"\xe8\xc2\xff\xff\xff"
"msvcrt.dll\n"

En débuggant le shellcode, je constate que cette chaîne de caractère est récupérée au travers un "pop edi".

Je voudrais tester cela en faisant un petit code asm sous visual C++ de la manière suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
__asm
{
	push    ebp		
	mov     ebp,esp
	mov     esp,ebp		
	sub     esp,0x30
       ...	
       pop edi        ; <- je pointe sur ma chaine de caractères
       ...
}

Mais je ne vois pas comment je dois m'y prendre pour passer ainsi une chaîne de caractère afin de la récupérer via un "pop edi". Quelqu'un pourrait il me faire part de la méthode ou m'expliquer le principe?

Merci

[Rémi Coquet]

Pour ma part je ne comprend pas bien la question:
Tu veux utiliser la MFC donc (en assembleur inline cela paraît un peu contradictoire mais tu as certainement de bonnes raisons).
L'appel est de forme cCall dans ces cas là et c'est à toi de restaurer la pile.

Il semblerait que le Lp demandé par cette api soit passé en entrée (via un push edi donc) et normalement récupéré en sortie par pop edi.

mov edi Lp

*push...
*push edi
*...

Call MFC

*pop...
*pop edi
*...

*selon le nombre d'arguments utilisés par l'api de la MFC

[homeostasie]

Pour ma part je ne comprend pas bien la question

Oui je ne suis surement pas très clair dans ma requête.

Tu veux utiliser la MFC donc (en assembleur inline cela paraît un peu contradictoire mais tu as certainement de bonnes raisons).

Euh tu as déduis cela à partir de quoi car ce n'est pas du tout le cas...

Il semblerait que le Lp demandé par cette api soit passé en entrée (via un push edi donc) et normalement récupéré en sortie par pop edi.

mov edi Lp

Justement ici ce n'est pas cela qui est mis en place et l'objet de ma question est justement de quelle manière cela a été réalisé?

J'ai fourni la fin du shellcode que j'étudie où on aperçoit la chaine de caractères.
En désassemblant, il n'y a pas au préalable de "mov edi Lp" suivi de "push edi" mais uniquement un "pop edi" pour pointer directement sur cette chaîne passée en fin de shellcode.

Je me dis qu'il y a surement une directive assembleur à spécifier et si c'est bien le cas, c'est celle-ci que j'aimerais trouver.

[Rémi Coquet]

msvcrt est est le nom de module de la dll de la MFC (ce n'est pas une supposition, c'est une affirmation).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
__asm
{
        ...
}

est une directive d'un HLL bien connu, utilisant les { et les ; à tour de bras, pour inclure de l'assembleur inline.

de quelle manière cela a été réalisé ?

Il faut que tu regardes dans la MFC et (re)trouves l'API du module utilisée. Regardes dans les arguments et tu (re)trouveras ton push Lp string.

Maintenant, si tu expliquais ce que tu veux faire avec le contenu d'edi: Le copier, mesurer le nombre de caratère avec ou sans EOS... il serait nettement plus aisé de te faire une réponse ciblée et pertinente...

[homeostasie]

msvcrt est est le nom de module de la dll de la MFC (ce n'est pas une supposition, c'est une affirmation).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
__asm
{
        ...
}

est une directive d'un HLL bien connu, utilisant les { et les ; à tour de bras, pour inclure de l'assembleur inline.

Je suis d'accord mais en aucun cas cela à un rapport avec l'utilisation d'API . J'aurais dû mettre une autre chaîne de caractères. En tout cas peu importe celle-ci.

J'analyse un shellcode comme j'ai déjà dit, celui-ci n'est en aucun cas précédé d'un appel d'une autre fonction. On le charge en mémoire et on l'exécute. Ce shellcode harcode l'API LoadLibrary(), effectue un "pop edi", récupères ainsi un pointeur sur la chaîne de caractères en question (à la fin du shellcode), fait ensuite un "push edi" et enfin le call de LoadLibrary().

Je voudrais connaître le principe de fonctionnement, le principe théorique? Pour essayer de mettre cela en pratique, j'utilise l'assembleur inline.

[Rémi Coquet]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
push eax         un argument sur la pile
call D$esp-0C    call sur Lp passé en argument (2)
cmp eax ebx      comparaison entre le retour de ton call et le contenu (?) d'ebx
je xxx           si egalité saut au label xxx
add edi 7        saute les 7 premiers ascii contenu dans edi (j'imagine..)
push edi         Passe le famaux Lp a ton famaux call trumuche
call eax         Call à une adresse contenue dans eax et différente de celle ebx
leave            typiquement du code visual (Masm en fin de chaîne :mouarf:)
ret              ret pas propre comme Masm les aime avec un leave bien pourri
call ...         Je pense que c'est un call appelé en cas d'égalité eax ebx

Cela semble correspondre à ta description

[Neitsa]

Bonjour homeostasie,

aurais-tu l'intégralité du shellcode ? (ou plus précisément, pourrais-tu en poster l'intégralité si possible), parce qu'avec juste la fin il est plutôt difficile de répondre pourquoi le pop fait pointer sur la chaîne (si j'ai bien compris ta question).

[homeostasie]

Bonjour à vous,

Après debug, je constate que c'est évidemment basé sur une subtilité bien maligne.

Pour ne pas trop rentrer dans les détails, celle-ci consiste à faire pointer "esp" sur une adresse de retour correspondant à la chaîne de caractères. ;')

Merci quand même.

[Rémi Coquet]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
push edi     Passe le fameux Lp a ton famaux call trucmuche
call eax     Call à une adresse contenue dans eax et différente de celle ebx
leave        Bien pourri !!! (pas d'enter comme masm les aime)

pour pop edi ...

Tu confirmes que c'est du code visual !?

[homeostasie]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
push edi     Passe le fameux Lp a ton famaux call trucmuche
call eax     Call à une adresse contenue dans eax et différente de celle ebx
leave        Bien pourri !!! (pas d'enter comme masm les aime)

pour pop edi ...

Tu confirmes que c'est du code visual !?

Je ne comprends pas trop. En tout cas oui, de l'asm inline sous Visual C++. Mais je ne sais pas quel est le nom de l'assembleur utilisé.

Concernant ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
push eax         un argument sur la pile
call D$esp-0C    call sur Lp passé en argument (2)
cmp eax ebx      comparaison entre le retour de ton call et le contenu (?) d'ebx

Je n'ai pas vraiment compris la démarche, pourquoi faire un appel sur la chaine de caractères.
Puis en fait la chaîne ne doit pas être considéré comme un argument, elle est directement codée dans le shellcode.

[Rémi Coquet]

Les produits visual utilisent des compilateurs qui intègrent tous un module "Masm" qui est utilisé par certains à la manière d'un assembleur (ce n'est pas du tout sa fonction première mais c'est hélas possible). L'assembleur utilisé est celui de ton µp cible, le seul que Microsoft connaisse à ce jour. Si tu utilises visual avec les outils fournis avec le SDK tu obtiendras un code de meilleure qualité (sans égaler évidement celle des compilateurs Intel, certes, mais cela sera déjà mieux). Je te renvoie à au SDK pour la configuration de visual.

Masm à de nombreuses particularités liées à un compilateur:

- Ce n'est pas un simple transcodeur qui "rassemble" simplement tes commandes, le code généré n'est donc pas celui écrit pas le codeur mais subit plusieurs encapsulations successives notamment au niveau des apis et génère un code de type compilateur: Qui n'est pas fait pour être lu, mais seulement pour être exécuté.

- Ses Macros ne sont pas accessibles et de type obfsucantes.

- Le rajout de facto de leave en fin de proc (sans son pendant enter) est une de ses nombreuses facéties.

- Dans le cas que tu cites, le compilateur est utilisé de manière "sioux" pour tenter de gagner en vitesse (alors que la charge de travail lié à l'appel de l'Api est proportionnellement énorme par rapport au soi-disant gain millimétré).

C'est ce que j'appelle de la stratégie de compilateur: Nawak, et, code dé-assemblé toujours totalement ridicule dans sons architecture comme dans ces performances.
Les intrinsec sont une bien meilleur réponse aux pertes de performances actuelles des HLL, même si c'est encore plus obsfusant pour le codeur, le code généré est nettement plus propre et plus proche de l'intention initiale.

[homeostasie]

Les produits visual utilisent des compilateurs qui intègrent tous un module "Masm" qui est utilisé par certains à la manière d'un assembleur (ce n'est pas du tout sa fonction première mais c'est hélas possible). L'assembleur utilisé est celui de ton µp cible, le seul que Microsoft connaisse à ce jour.
...

Ok merci pour les informations.

Les intrinsec sont une bien meilleur réponse aux pertes de performances actuelles des HLL, même si c'est encore plus obsfusant pour le codeur, le code généré est nettement plus propre et plus proche de l'intention initiale.

Les intrinsecs, je ne vois pas trop ce que c'est ici mais je pourrais toujours jeter un coup d'oeil sur google.

[Rémi Coquet]

Pour faire simple, ce sont de bouts de code (génériques donc) écrit en assembleur nativement. Ils sont substitués au code original au moment de la compilation.

Le but étant de réduire les nombreuses erreurs d'interprétations contextuelles du compilateur en le bypassant purement et simplement sur des blocs complets de script.

[homeostasie]

Hum hum, d'accord! Ca joue donc le rôle de patch. Peut être en attendant des améliorations au niveau du compilateur... Je dis ça mais je n'y connais pas grand chose et je ne doute pas que les compilateurs font déjà du bon travail.

[Rémi Coquet]

Les compilateurs font un excellent travail, dans le sens où ils rendent le développement accessible à un plus grand nombre de personnes moins formées, donc moins coûteuses, tout en étant "contenues" à l'intérieur d'un système limitant les bugs et permettant de générer du code exploitable sur plusieurs plate-formes différentes (au prix de performances toujours plus dégradées)..

Les compilateurs ne feront pas de grands progrès et les intrinsec en sont l'aveu clair et cuisant.

Borland avait poussé le bouchon jusqu'au développement par glisser/déposer, ce qui était le summum de l'incompétence et du développement à très courts termes.
Pour de nombreuses autres raisons: Le fait que les applications soit de plus en plus volumineuses, appuyées sur toujours plus de couches, que tout codeur moyen s'appuie ouvertement sur les performances de la plate-forme cible avec la bénédiction des divers éditeurs...

Je pense personnellement que ta démarche de "regard" est précieuse pour te guider vers une meilleure exploitation de ton compilateur.

Pour la forme: Fait un bout de code très imbriqué (appels d'api imbriqués etc. cast divers et variés...). Le même complètement déroulé, te fournira un code plus lisible et plus rapide (toutes proportions gardées quand ont parle d'api évidement).