att F Bonroy - PE et cie

AMcD

29/01/2004 à 03:33

AMcD wrote:

Surtout de bien regarder toutes les fonctions de ImageHelp.dll. Pour
ce qui
est du PE, cherche dans Google avec mon nom, j'ai donné 28 millions
sur le
sujet dans le passé.

Heu 28 millions de liens :o).

--
AMcD

http://arnold.mcdonald.free.fr/
http://amcd.diablo.free.fr/

Frederic Bonroy

29/01/2004 à 14:42

Heu, si je ne m'abuse, le seul intérêt de SEC_IMAGE est de prendre
DIRECTEMENT en compte les informations de mappage et de protection depuis le
fichier. Cela a donc pour résultat de charger le fichier exécutable en tant
que tel (et impose que le fichier passé soit un exécutable) et interdit donc
les autres options possibles. Le fait que SEC_IMAGE ne soit pas implémenté
sous 9x/Me provient de la différence entre les loaders de 9x/Me et celui de
NT.

Lorsque je m'amusais à ce genre de choses avec 9x, j'utilisais MapAndLoad()
de ImageHelp.dll. Mais, si j'ai bonne mémoire, la doc n'était pas très
fournie :o).

J'ai trouvé des informations sur MapAndLoad, que je ne connaissais pas,
mais après quelques minutes d'enthousiasme je suis malheureusement tombé
sur la phrase suivante: "[...] it's important to remember that it
creates a linear mapping of the entire file in one contiguous chunk.
This is different from the Win32 loader bringing an executable module
into memory [...]".
http://www.microsoft.com/library/images/msdn/library/periodic/periodic/msj/hood897.htm

Bref, c'est la même chose que CreateFile + CreateFileMapping +
MapViewOfFile sauf en plus rapide. :-(

Heu ça, c'est la technique bourinos quand même. Bon, c'est faisable, mais il
y a, toujours si j'ai bon souvenir, plus simple : MapAndLoad(). Si, si, tu
vas voir, c'est plus simple :-).

Ben non justement...

Alors quand on a une image exécutable prévue pour 40000h à une
autre adresse, les mov par exemple travaillent avec des adresses
complètement fausses.

Parce qu'il te faut les remapper.

C'est justement le problème! :-) Je ne peux tout de même pas
désassembler tout le code et modifier les instructions qui accèdent à la
mémoire en fonction de l'adresse de base réelle.

Faut pas oublier que quand j'ai une instruction

mov [mem], 1

le mem est traduit en une VA, linéaire quoi, pas en une RVA, d'où le
problème!

Et j'ai du mal à croire qu'il existe un tableau qui répertorie toutes
les instructions du code accédant la mémoire. A moins que... si... dans
la section .reloc comme je viens de m'en apercevoir... Quel merdier.
Dingue ça. :-(

Lors de l'émulation on pourrait, à chaque instruction accédant à la
mémoire, déterminer son adresse virtuelle relative et à partir de cela
calculer sa vraie adresse virtuelle mais ce serait compliqué et lent.

Si tu parles de fonctions d'API, à moins que tu ne passes systématiquement
par des GetProcAddress() (bonjour le délire), les fonctions sont importées
depuis des DLLs. Tu as leurs RVA dans les sections appropriées.

Non, en fait cette histoire de relocations est trop compliqué. Vaut
mieux faire ça de façon dynamique. Exemple: admettons que j'analyse un
exécutable prévu pour l'adresse de base 40000h. Je réserve de la mémoire
pour charger ce fichier, et cette zone de mémoire commence à l'adresse,
disons, 80000h.
Je fais mon émulation et je tombe sur une instruction qui accède à
42000h. Bon. Je sais qu'en fait, 42000h doit être 82000h. Alors je
prends 42000h et je lui ajoute la différence entre la base prévue
(40000h) et la base réelle (80000h) pour obtenir
42000h + (80000h - 40000h) = 82000h.

Et voilà.

Pour ce qui est de l'appel des fonction de l'API, j'ose même pas y
penser, surtout avec les virus qui ne se gênent pas pour accéder
directement à kernel32.dll en mémoire. Pour simuler tout ça, tiens...
:-( Mais bon, pas grave, pour émuler des petites boucles de décryptage
au début d'un virus ça devrait suffir. En théorie.

Et ça se trouve d'ici quelques jours je n'aurai plus envie. ;-)

Heu, si je ne m'abuse, le seul intérêt de SEC_IMAGE est de prendre
DIRECTEMENT en compte les informations de mappage et de protection depuis le
fichier. Cela a donc pour résultat de charger le fichier exécutable en tant
que tel (et impose que le fichier passé soit un exécutable) et interdit donc
les autres options possibles. Le fait que SEC_IMAGE ne soit pas implémenté
sous 9x/Me provient de la différence entre les loaders de 9x/Me et celui de
NT.

Lorsque je m'amusais à ce genre de choses avec 9x, j'utilisais MapAndLoad()
de ImageHelp.dll. Mais, si j'ai bonne mémoire, la doc n'était pas très
fournie :o).

J'ai trouvé des informations sur MapAndLoad, que je ne connaissais pas,
mais après quelques minutes d'enthousiasme je suis malheureusement tombé
sur la phrase suivante: "[...] it's important to remember that it
creates a linear mapping of the entire file in one contiguous chunk.
This is different from the Win32 loader bringing an executable module
into memory [...]".
http://www.microsoft.com/library/images/msdn/library/periodic/periodic/msj/hood897.htm

Bref, c'est la même chose que CreateFile + CreateFileMapping +
MapViewOfFile sauf en plus rapide. :-(

Heu ça, c'est la technique bourinos quand même. Bon, c'est faisable, mais il
y a, toujours si j'ai bon souvenir, plus simple : MapAndLoad(). Si, si, tu
vas voir, c'est plus simple :-).

Ben non justement...

Alors quand on a une image exécutable prévue pour 40000h à une
autre adresse, les mov par exemple travaillent avec des adresses
complètement fausses.

Parce qu'il te faut les remapper.

C'est justement le problème! :-) Je ne peux tout de même pas
désassembler tout le code et modifier les instructions qui accèdent à la
mémoire en fonction de l'adresse de base réelle.

Faut pas oublier que quand j'ai une instruction

mov [mem], 1

le mem est traduit en une VA, linéaire quoi, pas en une RVA, d'où le
problème!

Et j'ai du mal à croire qu'il existe un tableau qui répertorie toutes
les instructions du code accédant la mémoire. A moins que... si... dans
la section .reloc comme je viens de m'en apercevoir... Quel merdier.
Dingue ça. :-(

Lors de l'émulation on pourrait, à chaque instruction accédant à la
mémoire, déterminer son adresse virtuelle relative et à partir de cela
calculer sa vraie adresse virtuelle mais ce serait compliqué et lent.

Si tu parles de fonctions d'API, à moins que tu ne passes systématiquement
par des GetProcAddress() (bonjour le délire), les fonctions sont importées
depuis des DLLs. Tu as leurs RVA dans les sections appropriées.

Non, en fait cette histoire de relocations est trop compliqué. Vaut
mieux faire ça de façon dynamique. Exemple: admettons que j'analyse un
exécutable prévu pour l'adresse de base 40000h. Je réserve de la mémoire
pour charger ce fichier, et cette zone de mémoire commence à l'adresse,
disons, 80000h.
Je fais mon émulation et je tombe sur une instruction qui accède à
42000h. Bon. Je sais qu'en fait, 42000h doit être 82000h. Alors je
prends 42000h et je lui ajoute la différence entre la base prévue
(40000h) et la base réelle (80000h) pour obtenir
42000h + (80000h - 40000h) = 82000h.

Et voilà.

Pour ce qui est de l'appel des fonction de l'API, j'ose même pas y
penser, surtout avec les virus qui ne se gênent pas pour accéder
directement à kernel32.dll en mémoire. Pour simuler tout ça, tiens...
:-( Mais bon, pas grave, pour émuler des petites boucles de décryptage
au début d'un virus ça devrait suffir. En théorie.

Et ça se trouve d'ici quelques jours je n'aurai plus envie. ;-)

Vous avez filtré cet utilisateur ! Consultez son message

Heu, si je ne m'abuse, le seul intérêt de SEC_IMAGE est de prendre
DIRECTEMENT en compte les informations de mappage et de protection depuis le
fichier. Cela a donc pour résultat de charger le fichier exécutable en tant
que tel (et impose que le fichier passé soit un exécutable) et interdit donc
les autres options possibles. Le fait que SEC_IMAGE ne soit pas implémenté
sous 9x/Me provient de la différence entre les loaders de 9x/Me et celui de
NT.

Lorsque je m'amusais à ce genre de choses avec 9x, j'utilisais MapAndLoad()
de ImageHelp.dll. Mais, si j'ai bonne mémoire, la doc n'était pas très
fournie :o).

J'ai trouvé des informations sur MapAndLoad, que je ne connaissais pas,
mais après quelques minutes d'enthousiasme je suis malheureusement tombé
sur la phrase suivante: "[...] it's important to remember that it
creates a linear mapping of the entire file in one contiguous chunk.
This is different from the Win32 loader bringing an executable module
into memory [...]".
http://www.microsoft.com/library/images/msdn/library/periodic/periodic/msj/hood897.htm

Bref, c'est la même chose que CreateFile + CreateFileMapping +
MapViewOfFile sauf en plus rapide. :-(

Heu ça, c'est la technique bourinos quand même. Bon, c'est faisable, mais il
y a, toujours si j'ai bon souvenir, plus simple : MapAndLoad(). Si, si, tu
vas voir, c'est plus simple :-).

Ben non justement...

Alors quand on a une image exécutable prévue pour 40000h à une
autre adresse, les mov par exemple travaillent avec des adresses
complètement fausses.

Parce qu'il te faut les remapper.

C'est justement le problème! :-) Je ne peux tout de même pas
désassembler tout le code et modifier les instructions qui accèdent à la
mémoire en fonction de l'adresse de base réelle.

Faut pas oublier que quand j'ai une instruction

mov [mem], 1

le mem est traduit en une VA, linéaire quoi, pas en une RVA, d'où le
problème!

Et j'ai du mal à croire qu'il existe un tableau qui répertorie toutes
les instructions du code accédant la mémoire. A moins que... si... dans
la section .reloc comme je viens de m'en apercevoir... Quel merdier.
Dingue ça. :-(

Lors de l'émulation on pourrait, à chaque instruction accédant à la
mémoire, déterminer son adresse virtuelle relative et à partir de cela
calculer sa vraie adresse virtuelle mais ce serait compliqué et lent.

Si tu parles de fonctions d'API, à moins que tu ne passes systématiquement
par des GetProcAddress() (bonjour le délire), les fonctions sont importées
depuis des DLLs. Tu as leurs RVA dans les sections appropriées.

Non, en fait cette histoire de relocations est trop compliqué. Vaut
mieux faire ça de façon dynamique. Exemple: admettons que j'analyse un
exécutable prévu pour l'adresse de base 40000h. Je réserve de la mémoire
pour charger ce fichier, et cette zone de mémoire commence à l'adresse,
disons, 80000h.
Je fais mon émulation et je tombe sur une instruction qui accède à
42000h. Bon. Je sais qu'en fait, 42000h doit être 82000h. Alors je
prends 42000h et je lui ajoute la différence entre la base prévue
(40000h) et la base réelle (80000h) pour obtenir
42000h + (80000h - 40000h) = 82000h.

Et voilà.

Pour ce qui est de l'appel des fonction de l'API, j'ose même pas y
penser, surtout avec les virus qui ne se gênent pas pour accéder
directement à kernel32.dll en mémoire. Pour simuler tout ça, tiens...
:-( Mais bon, pas grave, pour émuler des petites boucles de décryptage
au début d'un virus ça devrait suffir. En théorie.

Et ça se trouve d'ici quelques jours je n'aurai plus envie. ;-)

Frederic Bonroy

29/01/2004 à 14:54

Exemple: admettons que j'analyse un exécutable prévu pour l'adresse de base 40000h.
[...]

Je viens de m'apercevoir que j'ai oublié un 0 à chaque fois. :-)

AMcD

29/01/2004 à 15:49

Frederic Bonroy wrote:

J'ai trouvé des informations sur MapAndLoad, que je ne connaissais
pas,
mais après quelques minutes d'enthousiasme je suis malheureusement
tombé
sur la phrase suivante: "[...] it's important to remember that it
creates a linear mapping of the entire file in one contiguous chunk.
This is different from the Win32 loader bringing an executable module
into memory [...]".

http://www.microsoft.com/library/images/msdn/library/periodic/periodic/msj/hood897.htm

Bref, c'est la même chose que CreateFile + CreateFileMapping +
MapViewOfFile sauf en plus rapide. :-(

Pas tout à fait quand même. Et puis, faudrait finir de lire le paragraphe :

"To use an RVA in this situation, you'd have to adjust it to account for the
difference between the section's file offset and its in-memory address.
Luckily, IMAGEHLP.DLL provides an API, ImageRVAToVa, that will do this for
you."

Heu ça, c'est la technique bourinos quand même. Bon, c'est faisable,
mais il
y a, toujours si j'ai bon souvenir, plus simple : MapAndLoad(). Si,
si, tu
vas voir, c'est plus simple :-).

Ben non justement...

Ben si :o).

Faut pas oublier que quand j'ai une instruction

mov [mem], 1

le mem est traduit en une VA, linéaire quoi, pas en une RVA, d'où le
problème!

Et j'ai du mal à croire qu'il existe un tableau qui répertorie toutes
les instructions du code accédant la mémoire. A moins que... si...
dans
la section .reloc comme je viens de m'en apercevoir... Quel merdier.
Dingue ça. :-(

Ben il y a les tables de relogements, la section .reloc, etc. Je t'accorde
volontiers que c'est le bazar.

Si tu parles de fonctions d'API, à moins que tu ne passes
systématiquement
par des GetProcAddress() (bonjour le délire), les fonctions sont
importées
depuis des DLLs. Tu as leurs RVA dans les sections appropriées.

Non, en fait cette histoire de relocations est trop compliqué.

Bah cela a été crée pour simplifier la vie du loader et pour pouvoir
remapper n'importe quoi n'importe où. D'ailleurs, à ce sujet, j'ai oublié de
te donner un lien vers un des rares articles sur les loader. Bon, c'est 2K,
mais très instructif :

http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx

Vaut
mieux faire ça de façon dynamique. Exemple: admettons que j'analyse un
exécutable prévu pour l'adresse de base 40000h. Je réserve de la
mémoire
pour charger ce fichier, et cette zone de mémoire commence à
l'adresse,
disons, 80000h.
Je fais mon émulation et je tombe sur une instruction qui accède à
42000h. Bon. Je sais qu'en fait, 42000h doit être 82000h. Alors je
prends 42000h et je lui ajoute la différence entre la base prévue
(40000h) et la base réelle (80000h) pour obtenir
42000h + (80000h - 40000h) = 82000h.

Et voilà.

Ben le loader ne fait rien d'autre :o). Es-tu sûr d'avoir bien assimilé tout
le concept des VA et RVA et des relocations ?

Pour ce qui est de l'appel des fonction de l'API, j'ose même pas y
penser, surtout avec les virus qui ne se gênent pas pour accéder
directement à kernel32.dll en mémoire. Pour simuler tout ça, tiens...
:-( Mais bon, pas grave, pour émuler des petites boucles de
décryptage
au début d'un virus ça devrait suffir. En théorie.

Plus exactement, ils recherchent l'adresse à partirde laquelle telle ou
telle librairie est chargée dans le processus à infecter. Détaillons un peu.

Par exemple, quand tu écris un virus basé sur CreateRemoteThread(), tu vas
chercher à ce que le processus que tu infectes charge ta DLL pirate. Pour
cela tu vas donc utiliser LoadLibrary() avec le nom de ta DLL. C'est assez
simple dans le concept. Bon, il faut supposer que kernel32.dll soit mappée
toujours au même emplacement mémoire. C'est le cas à 99.99%. D'ailleurs, à
ce sujet, il suffit de filer une adresse preferred différente à kernel32.dll
et tu "$@!& cette technqiue :o).

Le problème des relogements d'adresses (au sens large) est pénible, car il
te faut toujours garder à l'esprit que quand tu attaque un processus, tout
ce que tu envoies est calculé par rapport à TON code. Tu ne peux donc jamais
quasiment utiliser des noms de fonctions en paramètre. Il te faut utiliser
des pointeur par rapport à la DLL via des GetProcAddress(). Et encore ! À
supposer que les fonctions que tu injectes :

- Appartiennent à un DLL effectivement chargée par le processus à infecter.
Pour kernel32.dll c'est quasiment toujours le cas.
- Qu'il n'y ait pas de relocation de DLL. Voir l'excellent article que je te
donne dans un autre post.

C'est exactement pareil quand tu vas vouloir passer des paramètres dépendant
d'une adresse virtuelle. Tant que tu restes dans ton processus pas de
problème. Mais quand tu vises l'espace mémoire d'un autre, crash ! Là aussi,
il faut donc "déréférencer". Tu passes par VirtualAllocEx(), fonction
exceptionnelle qui te permet d'allouer de la mémoire à distance (dans un
autre espace). La méthode est là encore simple. Tu alloues dans le procesus
distant (pas le thread, l'espace mémoire appartient au processus) des blocs
mémoire, tu écris tes paramètres dedans et tu passes ces adresses en
paramètres lorsque tu crée le thread distant. Tu vas découvrir les joies de
WriteProcessMemory()...

Il y a aussi bien plus marrant à faire, c'est d'injecter directement du code
et de ne pas mapper de DLL. Où, encore plus technoïde, d'injecter direct ton
code dans kernel32.dll (chaud !).

Mais ma technique préférée c'est quand même le hooking d'API. Ça c'est de
l'art :o). Bon avec les vieux W9x/Me, il y a des limitations. Mais si t'es
un fan du PE, tu peux t'amuser facilement en modifiant tout simplement les
adresses d'import de fonction.

Franchement, tu devrais d'abord t'entraîner sur ce genre de choses avant de
te lancer dans un émulateur PE. Tu trouveras tout pleins de trucs à ce sujet
en lisant les articles de Matt Pietrek, Mark Russinovicth ou Jeffrey
Richter. Il y a des trucs assez fabuleux. Le top c'est quand tu veux
monitorer les APIs système, tu verrais les ruses parfois mises en oeuvre...
des poème :o). Si tu peux lire l'article de Cogswell (le gars patche
directement la table des descripteurs de service !!!), tu apprécieras la
"technique".

Et ça se trouve d'ici quelques jours je n'aurai plus envie. ;-)

Ha c'est sûr, ça vole plus haut que nos cher magazines de hack français,
mais le travail/effort en vaut la peine. Quoique, au sujet des dits
magazines, les rangs se sont éclaircis semble-t-il. Il fut un temps où il y
en avait une bonne dizaine. Si la qualité y gagne, tant mieux.

--
AMcD

http://arnold.mcdonald.free.fr/
http://amcd.diablo.free.fr/

Frederic Bonroy wrote:

J'ai trouvé des informations sur MapAndLoad, que je ne connaissais
pas,
mais après quelques minutes d'enthousiasme je suis malheureusement
tombé
sur la phrase suivante: "[...] it's important to remember that it
creates a linear mapping of the entire file in one contiguous chunk.
This is different from the Win32 loader bringing an executable module
into memory [...]".

http://www.microsoft.com/library/images/msdn/library/periodic/periodic/msj/hood897.htm

Bref, c'est la même chose que CreateFile + CreateFileMapping +
MapViewOfFile sauf en plus rapide. :-(

Pas tout à fait quand même. Et puis, faudrait finir de lire le paragraphe :

"To use an RVA in this situation, you'd have to adjust it to account for the
difference between the section's file offset and its in-memory address.
Luckily, IMAGEHLP.DLL provides an API, ImageRVAToVa, that will do this for
you."

Heu ça, c'est la technique bourinos quand même. Bon, c'est faisable,
mais il
y a, toujours si j'ai bon souvenir, plus simple : MapAndLoad(). Si,
si, tu
vas voir, c'est plus simple :-).

Ben non justement...

Ben si :o).

Faut pas oublier que quand j'ai une instruction

mov [mem], 1

le mem est traduit en une VA, linéaire quoi, pas en une RVA, d'où le
problème!

Et j'ai du mal à croire qu'il existe un tableau qui répertorie toutes
les instructions du code accédant la mémoire. A moins que... si...
dans
la section .reloc comme je viens de m'en apercevoir... Quel merdier.
Dingue ça. :-(

Ben il y a les tables de relogements, la section .reloc, etc. Je t'accorde
volontiers que c'est le bazar.

Si tu parles de fonctions d'API, à moins que tu ne passes
systématiquement
par des GetProcAddress() (bonjour le délire), les fonctions sont
importées
depuis des DLLs. Tu as leurs RVA dans les sections appropriées.

Non, en fait cette histoire de relocations est trop compliqué.

Bah cela a été crée pour simplifier la vie du loader et pour pouvoir
remapper n'importe quoi n'importe où. D'ailleurs, à ce sujet, j'ai oublié de
te donner un lien vers un des rares articles sur les loader. Bon, c'est 2K,
mais très instructif :

http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx

Vaut
mieux faire ça de façon dynamique. Exemple: admettons que j'analyse un
exécutable prévu pour l'adresse de base 40000h. Je réserve de la
mémoire
pour charger ce fichier, et cette zone de mémoire commence à
l'adresse,
disons, 80000h.
Je fais mon émulation et je tombe sur une instruction qui accède à
42000h. Bon. Je sais qu'en fait, 42000h doit être 82000h. Alors je
prends 42000h et je lui ajoute la différence entre la base prévue
(40000h) et la base réelle (80000h) pour obtenir
42000h + (80000h - 40000h) = 82000h.

Et voilà.

Ben le loader ne fait rien d'autre :o). Es-tu sûr d'avoir bien assimilé tout
le concept des VA et RVA et des relocations ?

Pour ce qui est de l'appel des fonction de l'API, j'ose même pas y
penser, surtout avec les virus qui ne se gênent pas pour accéder
directement à kernel32.dll en mémoire. Pour simuler tout ça, tiens...
:-( Mais bon, pas grave, pour émuler des petites boucles de
décryptage
au début d'un virus ça devrait suffir. En théorie.

Plus exactement, ils recherchent l'adresse à partirde laquelle telle ou
telle librairie est chargée dans le processus à infecter. Détaillons un peu.

Par exemple, quand tu écris un virus basé sur CreateRemoteThread(), tu vas
chercher à ce que le processus que tu infectes charge ta DLL pirate. Pour
cela tu vas donc utiliser LoadLibrary() avec le nom de ta DLL. C'est assez
simple dans le concept. Bon, il faut supposer que kernel32.dll soit mappée
toujours au même emplacement mémoire. C'est le cas à 99.99%. D'ailleurs, à
ce sujet, il suffit de filer une adresse preferred différente à kernel32.dll
et tu "$@!& cette technqiue :o).

Le problème des relogements d'adresses (au sens large) est pénible, car il
te faut toujours garder à l'esprit que quand tu attaque un processus, tout
ce que tu envoies est calculé par rapport à TON code. Tu ne peux donc jamais
quasiment utiliser des noms de fonctions en paramètre. Il te faut utiliser
des pointeur par rapport à la DLL via des GetProcAddress(). Et encore ! À
supposer que les fonctions que tu injectes :

- Appartiennent à un DLL effectivement chargée par le processus à infecter.
Pour kernel32.dll c'est quasiment toujours le cas.
- Qu'il n'y ait pas de relocation de DLL. Voir l'excellent article que je te
donne dans un autre post.

C'est exactement pareil quand tu vas vouloir passer des paramètres dépendant
d'une adresse virtuelle. Tant que tu restes dans ton processus pas de
problème. Mais quand tu vises l'espace mémoire d'un autre, crash ! Là aussi,
il faut donc "déréférencer". Tu passes par VirtualAllocEx(), fonction
exceptionnelle qui te permet d'allouer de la mémoire à distance (dans un
autre espace). La méthode est là encore simple. Tu alloues dans le procesus
distant (pas le thread, l'espace mémoire appartient au processus) des blocs
mémoire, tu écris tes paramètres dedans et tu passes ces adresses en
paramètres lorsque tu crée le thread distant. Tu vas découvrir les joies de
WriteProcessMemory()...

Il y a aussi bien plus marrant à faire, c'est d'injecter directement du code
et de ne pas mapper de DLL. Où, encore plus technoïde, d'injecter direct ton
code dans kernel32.dll (chaud !).

Mais ma technique préférée c'est quand même le hooking d'API. Ça c'est de
l'art :o). Bon avec les vieux W9x/Me, il y a des limitations. Mais si t'es
un fan du PE, tu peux t'amuser facilement en modifiant tout simplement les
adresses d'import de fonction.

Franchement, tu devrais d'abord t'entraîner sur ce genre de choses avant de
te lancer dans un émulateur PE. Tu trouveras tout pleins de trucs à ce sujet
en lisant les articles de Matt Pietrek, Mark Russinovicth ou Jeffrey
Richter. Il y a des trucs assez fabuleux. Le top c'est quand tu veux
monitorer les APIs système, tu verrais les ruses parfois mises en oeuvre...
des poème :o). Si tu peux lire l'article de Cogswell (le gars patche
directement la table des descripteurs de service !!!), tu apprécieras la
"technique".

Et ça se trouve d'ici quelques jours je n'aurai plus envie. ;-)

Ha c'est sûr, ça vole plus haut que nos cher magazines de hack français,
mais le travail/effort en vaut la peine. Quoique, au sujet des dits
magazines, les rangs se sont éclaircis semble-t-il. Il fut un temps où il y
en avait une bonne dizaine. Si la qualité y gagne, tant mieux.

--
AMcD

http://arnold.mcdonald.free.fr/
http://amcd.diablo.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

Frederic Bonroy wrote:

J'ai trouvé des informations sur MapAndLoad, que je ne connaissais
pas,
mais après quelques minutes d'enthousiasme je suis malheureusement
tombé
sur la phrase suivante: "[...] it's important to remember that it
creates a linear mapping of the entire file in one contiguous chunk.
This is different from the Win32 loader bringing an executable module
into memory [...]".

http://www.microsoft.com/library/images/msdn/library/periodic/periodic/msj/hood897.htm

Bref, c'est la même chose que CreateFile + CreateFileMapping +
MapViewOfFile sauf en plus rapide. :-(

Pas tout à fait quand même. Et puis, faudrait finir de lire le paragraphe :

"To use an RVA in this situation, you'd have to adjust it to account for the
difference between the section's file offset and its in-memory address.
Luckily, IMAGEHLP.DLL provides an API, ImageRVAToVa, that will do this for
you."

Heu ça, c'est la technique bourinos quand même. Bon, c'est faisable,
mais il
y a, toujours si j'ai bon souvenir, plus simple : MapAndLoad(). Si,
si, tu
vas voir, c'est plus simple :-).

Ben non justement...

Ben si :o).

Faut pas oublier que quand j'ai une instruction

mov [mem], 1

le mem est traduit en une VA, linéaire quoi, pas en une RVA, d'où le
problème!

Et j'ai du mal à croire qu'il existe un tableau qui répertorie toutes
les instructions du code accédant la mémoire. A moins que... si...
dans
la section .reloc comme je viens de m'en apercevoir... Quel merdier.
Dingue ça. :-(

Ben il y a les tables de relogements, la section .reloc, etc. Je t'accorde
volontiers que c'est le bazar.

Si tu parles de fonctions d'API, à moins que tu ne passes
systématiquement
par des GetProcAddress() (bonjour le délire), les fonctions sont
importées
depuis des DLLs. Tu as leurs RVA dans les sections appropriées.

Non, en fait cette histoire de relocations est trop compliqué.

Bah cela a été crée pour simplifier la vie du loader et pour pouvoir
remapper n'importe quoi n'importe où. D'ailleurs, à ce sujet, j'ai oublié de
te donner un lien vers un des rares articles sur les loader. Bon, c'est 2K,
mais très instructif :

http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx

Vaut
mieux faire ça de façon dynamique. Exemple: admettons que j'analyse un
exécutable prévu pour l'adresse de base 40000h. Je réserve de la
mémoire
pour charger ce fichier, et cette zone de mémoire commence à
l'adresse,
disons, 80000h.
Je fais mon émulation et je tombe sur une instruction qui accède à
42000h. Bon. Je sais qu'en fait, 42000h doit être 82000h. Alors je
prends 42000h et je lui ajoute la différence entre la base prévue
(40000h) et la base réelle (80000h) pour obtenir
42000h + (80000h - 40000h) = 82000h.

Et voilà.

Ben le loader ne fait rien d'autre :o). Es-tu sûr d'avoir bien assimilé tout
le concept des VA et RVA et des relocations ?

Pour ce qui est de l'appel des fonction de l'API, j'ose même pas y
penser, surtout avec les virus qui ne se gênent pas pour accéder
directement à kernel32.dll en mémoire. Pour simuler tout ça, tiens...
:-( Mais bon, pas grave, pour émuler des petites boucles de
décryptage
au début d'un virus ça devrait suffir. En théorie.

Plus exactement, ils recherchent l'adresse à partirde laquelle telle ou
telle librairie est chargée dans le processus à infecter. Détaillons un peu.

Par exemple, quand tu écris un virus basé sur CreateRemoteThread(), tu vas
chercher à ce que le processus que tu infectes charge ta DLL pirate. Pour
cela tu vas donc utiliser LoadLibrary() avec le nom de ta DLL. C'est assez
simple dans le concept. Bon, il faut supposer que kernel32.dll soit mappée
toujours au même emplacement mémoire. C'est le cas à 99.99%. D'ailleurs, à
ce sujet, il suffit de filer une adresse preferred différente à kernel32.dll
et tu "$@!& cette technqiue :o).

Le problème des relogements d'adresses (au sens large) est pénible, car il
te faut toujours garder à l'esprit que quand tu attaque un processus, tout
ce que tu envoies est calculé par rapport à TON code. Tu ne peux donc jamais
quasiment utiliser des noms de fonctions en paramètre. Il te faut utiliser
des pointeur par rapport à la DLL via des GetProcAddress(). Et encore ! À
supposer que les fonctions que tu injectes :

- Appartiennent à un DLL effectivement chargée par le processus à infecter.
Pour kernel32.dll c'est quasiment toujours le cas.
- Qu'il n'y ait pas de relocation de DLL. Voir l'excellent article que je te
donne dans un autre post.

C'est exactement pareil quand tu vas vouloir passer des paramètres dépendant
d'une adresse virtuelle. Tant que tu restes dans ton processus pas de
problème. Mais quand tu vises l'espace mémoire d'un autre, crash ! Là aussi,
il faut donc "déréférencer". Tu passes par VirtualAllocEx(), fonction
exceptionnelle qui te permet d'allouer de la mémoire à distance (dans un
autre espace). La méthode est là encore simple. Tu alloues dans le procesus
distant (pas le thread, l'espace mémoire appartient au processus) des blocs
mémoire, tu écris tes paramètres dedans et tu passes ces adresses en
paramètres lorsque tu crée le thread distant. Tu vas découvrir les joies de
WriteProcessMemory()...

Il y a aussi bien plus marrant à faire, c'est d'injecter directement du code
et de ne pas mapper de DLL. Où, encore plus technoïde, d'injecter direct ton
code dans kernel32.dll (chaud !).

Mais ma technique préférée c'est quand même le hooking d'API. Ça c'est de
l'art :o). Bon avec les vieux W9x/Me, il y a des limitations. Mais si t'es
un fan du PE, tu peux t'amuser facilement en modifiant tout simplement les
adresses d'import de fonction.

Franchement, tu devrais d'abord t'entraîner sur ce genre de choses avant de
te lancer dans un émulateur PE. Tu trouveras tout pleins de trucs à ce sujet
en lisant les articles de Matt Pietrek, Mark Russinovicth ou Jeffrey
Richter. Il y a des trucs assez fabuleux. Le top c'est quand tu veux
monitorer les APIs système, tu verrais les ruses parfois mises en oeuvre...
des poème :o). Si tu peux lire l'article de Cogswell (le gars patche
directement la table des descripteurs de service !!!), tu apprécieras la
"technique".

Et ça se trouve d'ici quelques jours je n'aurai plus envie. ;-)

Ha c'est sûr, ça vole plus haut que nos cher magazines de hack français,
mais le travail/effort en vaut la peine. Quoique, au sujet des dits
magazines, les rangs se sont éclaircis semble-t-il. Il fut un temps où il y
en avait une bonne dizaine. Si la qualité y gagne, tant mieux.

--
AMcD

http://arnold.mcdonald.free.fr/
http://amcd.diablo.free.fr/

Frederic Bonroy

29/01/2004 à 19:30

Bah cela a été crée pour simplifier la vie du loader et pour pouvoir
remapper n'importe quoi n'importe où. D'ailleurs, à ce sujet, j'ai oublié de
te donner un lien vers un des rares articles sur les loader. Bon, c'est 2K,
mais très instructif :

http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx

Merci, je vais le lire.

Ben le loader ne fait rien d'autre :o).

Oui. Mais je comptais le faire dynamiquement. Le loader ne le fait qu'au
début.

Es-tu sûr d'avoir bien assimilé tout le concept des VA et RVA et des relocations ?

Pour les VA et les RVA il n'y a pas de problèmes. C'est la manière dont
c'est réalisé *en pratique* qui est un peu obscure, c'est tout.
Honnêtement, je trouve très peu élégante la méthode de relocation si
elle consiste à modifier ici et là l'image en mémoire. Je sais qu'il n'y
a pas 36 solutions, mais cette méthode n'est pas élégante pour autant.

En fait, je la trouvais si peu élégante que je me suis dit "non, ça ne
peut pas être ça quand-même, il doit y avoir un truc". D'où la confusion.

Par exemple, quand tu écris un virus basé sur CreateRemoteThread(), tu vas
chercher à ce que le processus que tu infectes charge ta DLL pirate. Pour
cela tu vas donc utiliser LoadLibrary() avec le nom de ta DLL. C'est assez
simple dans le concept. Bon, il faut supposer que kernel32.dll soit mappée
toujours au même emplacement mémoire. C'est le cas à 99.99%.

Sous un même système d'exploitation.

Franchement, tu devrais d'abord t'entraîner sur ce genre de choses avant de
te lancer dans un émulateur PE.

Houlà, t'inquiète pas pour ça. Je n'ai aucune intention d'élaborer un
véritable émulateur. :-) Non, en fait je me suis dit que l'émulation
serait un moyen de décompacter les exécutables (et donc les vers)
compactés avec UPX par exemple. Une fois décompactés les vers sont
généralement si simples qu'il suffit de rechercher une chaîne d'octets
sans continuer l'émulation - une certaine boucle de décryptage rot-13
par exemple ;-) - et hop on a une détection.

Comme UPX d'après ce que j'ai pu voir n'appelle aucune fonction API (il
est vrai que je ne l'ai pas suivi complètement) alors théoriquement
c'est faisable sans émulation d'API ou de prise en compte des trucs et
astuces des virus plus sophistiqués (qui sont une minorité, rappelons le).

Ha c'est sûr, ça vole plus haut que nos cher magazines de hack français,
mais le travail/effort en vaut la peine. Quoique, au sujet des dits
magazines, les rangs se sont éclaircis semble-t-il. Il fut un temps où il y
en avait une bonne dizaine. Si la qualité y gagne, tant mieux.

Trolleur. ;-)

Bah cela a été crée pour simplifier la vie du loader et pour pouvoir
remapper n'importe quoi n'importe où. D'ailleurs, à ce sujet, j'ai oublié de
te donner un lien vers un des rares articles sur les loader. Bon, c'est 2K,
mais très instructif :

http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx

Merci, je vais le lire.

Ben le loader ne fait rien d'autre :o).

Oui. Mais je comptais le faire dynamiquement. Le loader ne le fait qu'au
début.

Es-tu sûr d'avoir bien assimilé tout le concept des VA et RVA et des relocations ?

Pour les VA et les RVA il n'y a pas de problèmes. C'est la manière dont
c'est réalisé *en pratique* qui est un peu obscure, c'est tout.
Honnêtement, je trouve très peu élégante la méthode de relocation si
elle consiste à modifier ici et là l'image en mémoire. Je sais qu'il n'y
a pas 36 solutions, mais cette méthode n'est pas élégante pour autant.

En fait, je la trouvais si peu élégante que je me suis dit "non, ça ne
peut pas être ça quand-même, il doit y avoir un truc". D'où la confusion.

Par exemple, quand tu écris un virus basé sur CreateRemoteThread(), tu vas
chercher à ce que le processus que tu infectes charge ta DLL pirate. Pour
cela tu vas donc utiliser LoadLibrary() avec le nom de ta DLL. C'est assez
simple dans le concept. Bon, il faut supposer que kernel32.dll soit mappée
toujours au même emplacement mémoire. C'est le cas à 99.99%.

Sous un même système d'exploitation.

Franchement, tu devrais d'abord t'entraîner sur ce genre de choses avant de
te lancer dans un émulateur PE.

Houlà, t'inquiète pas pour ça. Je n'ai aucune intention d'élaborer un
véritable émulateur. :-) Non, en fait je me suis dit que l'émulation
serait un moyen de décompacter les exécutables (et donc les vers)
compactés avec UPX par exemple. Une fois décompactés les vers sont
généralement si simples qu'il suffit de rechercher une chaîne d'octets
sans continuer l'émulation - une certaine boucle de décryptage rot-13
par exemple ;-) - et hop on a une détection.

Comme UPX d'après ce que j'ai pu voir n'appelle aucune fonction API (il
est vrai que je ne l'ai pas suivi complètement) alors théoriquement
c'est faisable sans émulation d'API ou de prise en compte des trucs et
astuces des virus plus sophistiqués (qui sont une minorité, rappelons le).

Ha c'est sûr, ça vole plus haut que nos cher magazines de hack français,
mais le travail/effort en vaut la peine. Quoique, au sujet des dits
magazines, les rangs se sont éclaircis semble-t-il. Il fut un temps où il y
en avait une bonne dizaine. Si la qualité y gagne, tant mieux.

Trolleur. ;-)

Vous avez filtré cet utilisateur ! Consultez son message

Bah cela a été crée pour simplifier la vie du loader et pour pouvoir
remapper n'importe quoi n'importe où. D'ailleurs, à ce sujet, j'ai oublié de
te donner un lien vers un des rares articles sur les loader. Bon, c'est 2K,
mais très instructif :

http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx

Merci, je vais le lire.

Ben le loader ne fait rien d'autre :o).

Oui. Mais je comptais le faire dynamiquement. Le loader ne le fait qu'au
début.

Es-tu sûr d'avoir bien assimilé tout le concept des VA et RVA et des relocations ?

Pour les VA et les RVA il n'y a pas de problèmes. C'est la manière dont
c'est réalisé *en pratique* qui est un peu obscure, c'est tout.
Honnêtement, je trouve très peu élégante la méthode de relocation si
elle consiste à modifier ici et là l'image en mémoire. Je sais qu'il n'y
a pas 36 solutions, mais cette méthode n'est pas élégante pour autant.

En fait, je la trouvais si peu élégante que je me suis dit "non, ça ne
peut pas être ça quand-même, il doit y avoir un truc". D'où la confusion.

Par exemple, quand tu écris un virus basé sur CreateRemoteThread(), tu vas
chercher à ce que le processus que tu infectes charge ta DLL pirate. Pour
cela tu vas donc utiliser LoadLibrary() avec le nom de ta DLL. C'est assez
simple dans le concept. Bon, il faut supposer que kernel32.dll soit mappée
toujours au même emplacement mémoire. C'est le cas à 99.99%.

Sous un même système d'exploitation.

Franchement, tu devrais d'abord t'entraîner sur ce genre de choses avant de
te lancer dans un émulateur PE.

Houlà, t'inquiète pas pour ça. Je n'ai aucune intention d'élaborer un
véritable émulateur. :-) Non, en fait je me suis dit que l'émulation
serait un moyen de décompacter les exécutables (et donc les vers)
compactés avec UPX par exemple. Une fois décompactés les vers sont
généralement si simples qu'il suffit de rechercher une chaîne d'octets
sans continuer l'émulation - une certaine boucle de décryptage rot-13
par exemple ;-) - et hop on a une détection.

Comme UPX d'après ce que j'ai pu voir n'appelle aucune fonction API (il
est vrai que je ne l'ai pas suivi complètement) alors théoriquement
c'est faisable sans émulation d'API ou de prise en compte des trucs et
astuces des virus plus sophistiqués (qui sont une minorité, rappelons le).

Ha c'est sûr, ça vole plus haut que nos cher magazines de hack français,
mais le travail/effort en vaut la peine. Quoique, au sujet des dits
magazines, les rangs se sont éclaircis semble-t-il. Il fut un temps où il y
en avait une bonne dizaine. Si la qualité y gagne, tant mieux.

Trolleur. ;-)

AMcD

29/01/2004 à 20:09

Ce qui me fais "sourire", c'est que si on t'enlèves toi, Guillermito et
Tweakie (ces deux derniers étant rarissimes), je ne sais pas qui ce genre de
thread peut bien intéresser. C'est triste :'o(.

Frederic Bonroy wrote:

Bah cela a été crée pour simplifier la vie du loader et pour pouvoir
remapper n'importe quoi n'importe où. D'ailleurs, à ce sujet, j'ai
oublié de
te donner un lien vers un des rares articles sur les loader. Bon,
c'est 2K,
mais très instructif :

http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx

Merci, je vais le lire.

En regardant dans ma bibliothèque, j vois que j'ai oublié de te mentioner un
livre intéressant. Linkers & Loaders de Levine. Tiens un lien :

http://linker.iecc.com/

Ben le loader ne fait rien d'autre :o).

Oui. Mais je comptais le faire dynamiquement. Le loader ne le fait
qu'au
début.

Pour gagner du temps. Imagine le bazar à l'exécution.

Es-tu sûr d'avoir bien assimilé tout le concept des VA et RVA et des
relocations ?

Pour les VA et les RVA il n'y a pas de problèmes. C'est la manière
dont
c'est réalisé *en pratique* qui est un peu obscure, c'est tout.
Honnêtement, je trouve très peu élégante la méthode de relocation si
elle consiste à modifier ici et là l'image en mémoire. Je sais qu'il
n'y
a pas 36 solutions, mais cette méthode n'est pas élégante pour autant.

C'est pourtant une méthode classique. De COFF à ELF à DOS à PE, etc. Voir le
livre ci-dessus. Celà tant, je ne vois pa strop comment on pourrait faire
plus simple :

- tous les mov [xxx] (simple exemple) sont référencés par rapport à un
segment de base. genre mov [start+xxx]
- lors du load, si tu peux mapper sur cette même origine de segment, rien à
faire. si tu ne peux pas, tu change l'adresse de segment start et voilà !

En fait, je la trouvais si peu élégante que je me suis dit "non, ça ne
peut pas être ça quand-même, il doit y avoir un truc". D'où la
confusion.

Ben moi je trouve ça bien conçu. Élégant, bof, c'est sûr...

Par exemple, quand tu écris un virus basé sur CreateRemoteThread(),
tu vas chercher à ce que le processus que tu infectes charge ta DLL
pirate. Pour
cela tu vas donc utiliser LoadLibrary() avec le nom de ta DLL. C'est
assez
simple dans le concept. Bon, il faut supposer que kernel32.dll soit
mappée toujours au même emplacement mémoire. C'est le cas à 99.99%.

Sous un même système d'exploitation.

Vi. Sinon tu fais bourrin. Tu regardes depusi ton code où c'est chargé et tu
en déduis...

Franchement, tu devrais d'abord t'entraîner sur ce genre de choses
avant de
te lancer dans un émulateur PE.

Houlà, t'inquiète pas pour ça. Je n'ai aucune intention d'élaborer un
véritable émulateur. :-) Non, en fait je me suis dit que l'émulation
serait un moyen de décompacter les exécutables (et donc les vers)
compactés avec UPX par exemple. Une fois décompactés les vers sont
généralement si simples qu'il suffit de rechercher une chaîne d'octets
sans continuer l'émulation - une certaine boucle de décryptage rot-13
par exemple ;-) - et hop on a une détection.

Ben, j'ai du mal à suivre...

1) t'ouvres le fichier
2) tu regardes le champ e_lfanew
3) t'en déduis vite si un packer est utilisé ;o)
4) tu dépacks éventuellement chaque section avec le bon algo. Les 3/4 sont
libres non ?

Pourquoi un émulateur ?

Comme UPX d'après ce que j'ai pu voir n'appelle aucune fonction API
(il
est vrai que je ne l'ai pas suivi complètement) alors théoriquement
c'est faisable sans émulation d'API ou de prise en compte des trucs et
astuces des virus plus sophistiqués (qui sont une minorité, rappelons
le).

Hum. Je me demande quand même s'il n'y a pas une certaine évolution... De
plus en plus, je doute que les derniers vers à la mode soient écris par des
SK...

Ha c'est sûr, ça vole plus haut que nos cher magazines de hack
français,
mais le travail/effort en vaut la peine. Quoique, au sujet des dits
magazines, les rangs se sont éclaircis semble-t-il. Il fut un temps
où il y
en avait une bonne dizaine. Si la qualité y gagne, tant mieux.

Trolleur. ;-)

Pas du tout. Autrefois, je me ruinais mensuellement pour acheter de
véritables tas de boue ! J'aime l'exhaustivité alors, j'achetais tout :o).
Là, ça c'est bien éclairci. Perso, si deux ou trois pouvaient encore
disparaître... nan, je plaisante !

--
AMcD

http://arnold.mcdonald.free.fr/
http://amcd.diablo.free.fr/

Ce qui me fais "sourire", c'est que si on t'enlèves toi, Guillermito et
Tweakie (ces deux derniers étant rarissimes), je ne sais pas qui ce genre de
thread peut bien intéresser. C'est triste :'o(.

Frederic Bonroy wrote:

Bah cela a été crée pour simplifier la vie du loader et pour pouvoir
remapper n'importe quoi n'importe où. D'ailleurs, à ce sujet, j'ai
oublié de
te donner un lien vers un des rares articles sur les loader. Bon,
c'est 2K,
mais très instructif :

http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx

Merci, je vais le lire.

En regardant dans ma bibliothèque, j vois que j'ai oublié de te mentioner un
livre intéressant. Linkers & Loaders de Levine. Tiens un lien :

http://linker.iecc.com/

Ben le loader ne fait rien d'autre :o).

Oui. Mais je comptais le faire dynamiquement. Le loader ne le fait
qu'au
début.

Pour gagner du temps. Imagine le bazar à l'exécution.

Es-tu sûr d'avoir bien assimilé tout le concept des VA et RVA et des
relocations ?

Pour les VA et les RVA il n'y a pas de problèmes. C'est la manière
dont
c'est réalisé *en pratique* qui est un peu obscure, c'est tout.
Honnêtement, je trouve très peu élégante la méthode de relocation si
elle consiste à modifier ici et là l'image en mémoire. Je sais qu'il
n'y
a pas 36 solutions, mais cette méthode n'est pas élégante pour autant.

C'est pourtant une méthode classique. De COFF à ELF à DOS à PE, etc. Voir le
livre ci-dessus. Celà tant, je ne vois pa strop comment on pourrait faire
plus simple :

- tous les mov [xxx] (simple exemple) sont référencés par rapport à un
segment de base. genre mov [start+xxx]
- lors du load, si tu peux mapper sur cette même origine de segment, rien à
faire. si tu ne peux pas, tu change l'adresse de segment start et voilà !

En fait, je la trouvais si peu élégante que je me suis dit "non, ça ne
peut pas être ça quand-même, il doit y avoir un truc". D'où la
confusion.

Ben moi je trouve ça bien conçu. Élégant, bof, c'est sûr...

Par exemple, quand tu écris un virus basé sur CreateRemoteThread(),
tu vas chercher à ce que le processus que tu infectes charge ta DLL
pirate. Pour
cela tu vas donc utiliser LoadLibrary() avec le nom de ta DLL. C'est
assez
simple dans le concept. Bon, il faut supposer que kernel32.dll soit
mappée toujours au même emplacement mémoire. C'est le cas à 99.99%.

Sous un même système d'exploitation.

Vi. Sinon tu fais bourrin. Tu regardes depusi ton code où c'est chargé et tu
en déduis...

Franchement, tu devrais d'abord t'entraîner sur ce genre de choses
avant de
te lancer dans un émulateur PE.

Houlà, t'inquiète pas pour ça. Je n'ai aucune intention d'élaborer un
véritable émulateur. :-) Non, en fait je me suis dit que l'émulation
serait un moyen de décompacter les exécutables (et donc les vers)
compactés avec UPX par exemple. Une fois décompactés les vers sont
généralement si simples qu'il suffit de rechercher une chaîne d'octets
sans continuer l'émulation - une certaine boucle de décryptage rot-13
par exemple ;-) - et hop on a une détection.

Ben, j'ai du mal à suivre...

1) t'ouvres le fichier
2) tu regardes le champ e_lfanew
3) t'en déduis vite si un packer est utilisé ;o)
4) tu dépacks éventuellement chaque section avec le bon algo. Les 3/4 sont
libres non ?

Pourquoi un émulateur ?

Comme UPX d'après ce que j'ai pu voir n'appelle aucune fonction API
(il
est vrai que je ne l'ai pas suivi complètement) alors théoriquement
c'est faisable sans émulation d'API ou de prise en compte des trucs et
astuces des virus plus sophistiqués (qui sont une minorité, rappelons
le).

Hum. Je me demande quand même s'il n'y a pas une certaine évolution... De
plus en plus, je doute que les derniers vers à la mode soient écris par des
SK...

Ha c'est sûr, ça vole plus haut que nos cher magazines de hack
français,
mais le travail/effort en vaut la peine. Quoique, au sujet des dits
magazines, les rangs se sont éclaircis semble-t-il. Il fut un temps
où il y
en avait une bonne dizaine. Si la qualité y gagne, tant mieux.

Trolleur. ;-)

Pas du tout. Autrefois, je me ruinais mensuellement pour acheter de
véritables tas de boue ! J'aime l'exhaustivité alors, j'achetais tout :o).
Là, ça c'est bien éclairci. Perso, si deux ou trois pouvaient encore
disparaître... nan, je plaisante !

--
AMcD

http://arnold.mcdonald.free.fr/
http://amcd.diablo.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

Ce qui me fais "sourire", c'est que si on t'enlèves toi, Guillermito et
Tweakie (ces deux derniers étant rarissimes), je ne sais pas qui ce genre de
thread peut bien intéresser. C'est triste :'o(.

Frederic Bonroy wrote:

Bah cela a été crée pour simplifier la vie du loader et pour pouvoir
remapper n'importe quoi n'importe où. D'ailleurs, à ce sujet, j'ai
oublié de
te donner un lien vers un des rares articles sur les loader. Bon,
c'est 2K,
mais très instructif :

http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx

Merci, je vais le lire.

En regardant dans ma bibliothèque, j vois que j'ai oublié de te mentioner un
livre intéressant. Linkers & Loaders de Levine. Tiens un lien :

http://linker.iecc.com/

Ben le loader ne fait rien d'autre :o).

Oui. Mais je comptais le faire dynamiquement. Le loader ne le fait
qu'au
début.

Pour gagner du temps. Imagine le bazar à l'exécution.

Es-tu sûr d'avoir bien assimilé tout le concept des VA et RVA et des
relocations ?

Pour les VA et les RVA il n'y a pas de problèmes. C'est la manière
dont
c'est réalisé *en pratique* qui est un peu obscure, c'est tout.
Honnêtement, je trouve très peu élégante la méthode de relocation si
elle consiste à modifier ici et là l'image en mémoire. Je sais qu'il
n'y
a pas 36 solutions, mais cette méthode n'est pas élégante pour autant.

C'est pourtant une méthode classique. De COFF à ELF à DOS à PE, etc. Voir le
livre ci-dessus. Celà tant, je ne vois pa strop comment on pourrait faire
plus simple :

- tous les mov [xxx] (simple exemple) sont référencés par rapport à un
segment de base. genre mov [start+xxx]
- lors du load, si tu peux mapper sur cette même origine de segment, rien à
faire. si tu ne peux pas, tu change l'adresse de segment start et voilà !

En fait, je la trouvais si peu élégante que je me suis dit "non, ça ne
peut pas être ça quand-même, il doit y avoir un truc". D'où la
confusion.

Ben moi je trouve ça bien conçu. Élégant, bof, c'est sûr...

Par exemple, quand tu écris un virus basé sur CreateRemoteThread(),
tu vas chercher à ce que le processus que tu infectes charge ta DLL
pirate. Pour
cela tu vas donc utiliser LoadLibrary() avec le nom de ta DLL. C'est
assez
simple dans le concept. Bon, il faut supposer que kernel32.dll soit
mappée toujours au même emplacement mémoire. C'est le cas à 99.99%.

Sous un même système d'exploitation.

Vi. Sinon tu fais bourrin. Tu regardes depusi ton code où c'est chargé et tu
en déduis...

Franchement, tu devrais d'abord t'entraîner sur ce genre de choses
avant de
te lancer dans un émulateur PE.

Houlà, t'inquiète pas pour ça. Je n'ai aucune intention d'élaborer un
véritable émulateur. :-) Non, en fait je me suis dit que l'émulation
serait un moyen de décompacter les exécutables (et donc les vers)
compactés avec UPX par exemple. Une fois décompactés les vers sont
généralement si simples qu'il suffit de rechercher une chaîne d'octets
sans continuer l'émulation - une certaine boucle de décryptage rot-13
par exemple ;-) - et hop on a une détection.

Ben, j'ai du mal à suivre...

1) t'ouvres le fichier
2) tu regardes le champ e_lfanew
3) t'en déduis vite si un packer est utilisé ;o)
4) tu dépacks éventuellement chaque section avec le bon algo. Les 3/4 sont
libres non ?

Pourquoi un émulateur ?

Comme UPX d'après ce que j'ai pu voir n'appelle aucune fonction API
(il
est vrai que je ne l'ai pas suivi complètement) alors théoriquement
c'est faisable sans émulation d'API ou de prise en compte des trucs et
astuces des virus plus sophistiqués (qui sont une minorité, rappelons
le).

Hum. Je me demande quand même s'il n'y a pas une certaine évolution... De
plus en plus, je doute que les derniers vers à la mode soient écris par des
SK...

Ha c'est sûr, ça vole plus haut que nos cher magazines de hack
français,
mais le travail/effort en vaut la peine. Quoique, au sujet des dits
magazines, les rangs se sont éclaircis semble-t-il. Il fut un temps
où il y
en avait une bonne dizaine. Si la qualité y gagne, tant mieux.

Trolleur. ;-)

Pas du tout. Autrefois, je me ruinais mensuellement pour acheter de
véritables tas de boue ! J'aime l'exhaustivité alors, j'achetais tout :o).
Là, ça c'est bien éclairci. Perso, si deux ou trois pouvaient encore
disparaître... nan, je plaisante !

--
AMcD

http://arnold.mcdonald.free.fr/
http://amcd.diablo.free.fr/

Frederic Bonroy

29/01/2004 à 20:32

Pour gagner du temps. Imagine le bazar à l'exécution.

C'est sûr. Irréalisable.

C'est pourtant une méthode classique. De COFF à ELF à DOS à PE, etc. Voir le
livre ci-dessus. Celà tant, je ne vois pa strop comment on pourrait faire
plus simple :

- tous les mov [xxx] (simple exemple) sont référencés par rapport à un
segment de base. genre mov [start+xxx]
- lors du load, si tu peux mapper sur cette même origine de segment, rien à
faire. si tu ne peux pas, tu change l'adresse de segment start et voilà !

On aurait éventuellement pu à une époque solliciter l'aide du processeur
pour réaliser ce genre de choses. Ainsi on aurait utilisé uniquement des
RVA que le processeur aurait transformés en VA lors de l'exécution. Il
aurait fallu lui indiquer l'adresse de base bien sûr, d'une manière ou
d'une autre.

Ben, j'ai du mal à suivre...

1) t'ouvres le fichier
2) tu regardes le champ e_lfanew
3) t'en déduis vite si un packer est utilisé ;o)
4) tu dépacks éventuellement chaque section avec le bon algo. Les 3/4 sont
libres non ?

Pourquoi un émulateur ?

Parce que c'est plus marrant voyons! Ça suffit pas comme raison? :-)

(Et puis, remarque, ça peut être utile pour les virus cryptés où aucune
fonction API n'est appelée avant la fin de la boucle de décryptage. Bon,
je délire un peu, mais je fais ça pour m'amuser, faut pas oublier.)

Hum. Je me demande quand même s'il n'y a pas une certaine évolution... De
plus en plus, je doute que les derniers vers à la mode soient écris par des
SK...

Sans doute des gens de niveau intermédiaire.

Nicolas Brulez

29/01/2004 à 22:22

AMcD wrote:

Ce qui me fais "sourire", c'est que si on t'enlèves toi, Guillermito et
Tweakie (ces deux derniers étant rarissimes), je ne sais pas qui ce genre de
thread peut bien intéresser. C'est triste :'o(.

Je trouve ce thread intéressant.
Il existe un plugin Open source d'un émulateur pour le désassembleur IDA
si ca t'intéresse Frederic. Il émule pas mal de layers simples utilisés
dans les virus simples.

https://sourceforge.net/projects/ida-x86emu/

Amicalement,

--
Nicolas Brulez

Chief of Security
The Armadillo Software Protection System
http://www.siliconrealms.com/armadillo.shtml

AMcD

29/01/2004 à 23:02

Nicolas Brulez wrote:

AMcD wrote:
Ce qui me fais "sourire", c'est que si on t'enlèves toi, Guillermito
et Tweakie (ces deux derniers étant rarissimes), je ne sais pas qui
ce genre de thread peut bien intéresser. C'est triste :'o(.

Je trouve ce thread intéressant.

Note bien que, si ça ne tenait qu'à moi, on causerait plus souvent de
patchage d'IAT ici :o).

--
Nicolas Brulez

Tiens ! Eh bien, puisque je t'ai sous la main, dans ma collection de
documents PE manque "Analyse d'une protection d'exécutables PE : Asprotect"
dont tu es l'auteur. C'est abuser de demander s'il est possible d'obtenir
les éventuels documents que tu as fourni durant tes interventions ?

Bien cordialement,

--
AMcD

http://arnold.mcdonald.free.fr/
http://amcd.diablo.free.fr/

Nicolas Brulez

30/01/2004 à 02:38

Note bien que, si ça ne tenait qu'à moi, on causerait plus souvent de
patchage d'IAT ici :o).

Va falloir changer ca ;-)

--
Nicolas Brulez

Tiens ! Eh bien, puisque je t'ai sous la main, dans ma collection de
documents PE manque "Analyse d'une protection d'exécutables PE : Asprotect"
dont tu es l'auteur. C'est abuser de demander s'il est possible d'obtenir
les éventuels documents que tu as fourni durant tes interventions ?

Non ca doit pouvoir se faire. Donnes moi quelques jours, et je donnerai
la présentation. J'ai écris un cours complet sur toutes les protections
employées à l'époque pour la conférence, et tout est détaillé :)

Cordialement,

--
Nicolas Brulez

Chief of Security
The Armadillo Software Protection System
http://www.siliconrealms.com/armadillo.shtml

att F Bonroy - PE et cie

10 réponses

Veuillez sélectionner un problème