Bonjour à tous.
Pour un dossier que j'écris pour un portail scientifique je cherche quelques
exemples d'émulation inoffensive des effets graphiques de certains vers ou
virus. Par exemple le feu d'artifice de Happy99, la spirale de certaines
versions de Hybris etc.
Merci de m'indique des sources sûres si vous en avez ou de m'envoyer les
fichiers par mail.
Bon, avec un bon debuggueur, avec un produit genre Soft Ice et cie, ça simplifie pas mal :-).
Quand la bestiole n'est pas capable de repérer le debugger c'est sûr ;-)
Après, une fois que tu dispose du code en "clair", ce n'est pas bien difficile ! Pour court-circuiter, tu modifies les conditions de déclenchement des payloads. Pour extraire, eh bien tu repères la partie qui t'intéresses et t'exportes.
Oui, mais le code exporté n'est pas viable tel quel non? C'est pour ça que je parlais d'utiliser des JMP bien placés alors que tu ne parlais que d'exportation.
-- joke0
Salut,
AMcD:
Bon, avec un bon debuggueur, avec un produit
genre Soft Ice et cie, ça simplifie pas mal :-).
Quand la bestiole n'est pas capable de repérer le debugger c'est
sûr ;-)
Après, une fois que tu dispose du code en "clair", ce n'est
pas bien difficile ! Pour court-circuiter, tu modifies les
conditions de déclenchement des payloads. Pour extraire, eh
bien tu repères la partie qui t'intéresses et t'exportes.
Oui, mais le code exporté n'est pas viable tel quel non? C'est
pour ça que je parlais d'utiliser des JMP bien placés alors que
tu ne parlais que d'exportation.
Bon, avec un bon debuggueur, avec un produit genre Soft Ice et cie, ça simplifie pas mal :-).
Quand la bestiole n'est pas capable de repérer le debugger c'est sûr ;-)
Après, une fois que tu dispose du code en "clair", ce n'est pas bien difficile ! Pour court-circuiter, tu modifies les conditions de déclenchement des payloads. Pour extraire, eh bien tu repères la partie qui t'intéresses et t'exportes.
Oui, mais le code exporté n'est pas viable tel quel non? C'est pour ça que je parlais d'utiliser des JMP bien placés alors que tu ne parlais que d'exportation.
-- joke0
AMcD
joke0 wrote:
Bon, avec un bon debuggueur, avec un produit genre Soft Ice et cie, ça simplifie pas mal :-).
Quand la bestiole n'est pas capable de repérer le debugger c'est sûr ;-)
Meuh non. Même si elle le repère tu bypasses facile. Un exemple (pas très clair pour un profane, faut avouer) figure dans MISC n° 7. Sinon, si ce genre de trucs d'intéresse, va sur ce genre de site qui suit là plus bas après la phrase. Tu verras que rien ne resiste à des gens sachant programmer. Rien.
http://www.crackmes.de/ ou http://crackmes.host.sk/
Bon si tu connais pas les docs d'Intel par coeur et ne pipe pas un mot à l'asssembleur, c'est même pas la pien :-).
Oui, mais le code exporté n'est pas viable tel quel non? C'est pour ça que je parlais d'utiliser des JMP bien placés alors que tu ne parlais que d'exportation.
Tatata. Il y a toujours une solution. Une fois, je voulais récupérer une routine dont evidemment tous les offsets étaient dépendant du code, je veux dire, de l'instant ou il est exécuté. Eh bien, je me suis pas foulé ! J'ai exporté et j'ai appliqué le fameux delta_offset que tous les programmeurs de virus connaissent :-). Et après on dira que ça sert pas d'analyser les virus. Tsss.
Tiens un petit exemple. Il te faut connaître l'endroit où tu es. Par exemple, tu ne sais pas à quel endroit les variables de ton virus seront localisées une fois exéécuté. Tu fais :
call amcd amcd: pop bp sub bp, offset amcd
et voilà ! Tu a maintenant le moyen de calculer les différences d'offset. Utile pour les variables. Par exemple, tu remplaces tes mov dx,offset x
par
lea dx,[bp+offset x]
Et ainsi de suite. C'est l'enfance de l'art.
D'autres questions ? (nan parce qu'il pleut sévère là...)
Bon, avec un bon debuggueur, avec un produit
genre Soft Ice et cie, ça simplifie pas mal :-).
Quand la bestiole n'est pas capable de repérer le debugger c'est
sûr ;-)
Meuh non. Même si elle le repère tu bypasses facile. Un exemple (pas très
clair pour un profane, faut avouer) figure dans MISC n° 7. Sinon, si ce
genre de trucs d'intéresse, va sur ce genre de site qui suit là plus bas
après la phrase. Tu verras que rien ne resiste à des gens sachant
programmer. Rien.
http://www.crackmes.de/ ou http://crackmes.host.sk/
Bon si tu connais pas les docs d'Intel par coeur et ne pipe pas un mot à
l'asssembleur, c'est même pas la pien :-).
Oui, mais le code exporté n'est pas viable tel quel non? C'est
pour ça que je parlais d'utiliser des JMP bien placés alors que
tu ne parlais que d'exportation.
Tatata. Il y a toujours une solution. Une fois, je voulais récupérer une
routine dont evidemment tous les offsets étaient dépendant du code, je veux
dire, de l'instant ou il est exécuté. Eh bien, je me suis pas foulé ! J'ai
exporté et j'ai appliqué le fameux delta_offset que tous les programmeurs de
virus connaissent :-). Et après on dira que ça sert pas d'analyser les
virus. Tsss.
Tiens un petit exemple. Il te faut connaître l'endroit où tu es. Par
exemple, tu ne sais pas à quel endroit les variables de ton virus seront
localisées une fois exéécuté. Tu fais :
call amcd
amcd:
pop bp
sub bp, offset amcd
et voilà ! Tu a maintenant le moyen de calculer les différences d'offset.
Utile pour les variables. Par exemple, tu remplaces tes mov dx,offset x
par
lea dx,[bp+offset x]
Et ainsi de suite. C'est l'enfance de l'art.
D'autres questions ? (nan parce qu'il pleut sévère là...)
Bon, avec un bon debuggueur, avec un produit genre Soft Ice et cie, ça simplifie pas mal :-).
Quand la bestiole n'est pas capable de repérer le debugger c'est sûr ;-)
Meuh non. Même si elle le repère tu bypasses facile. Un exemple (pas très clair pour un profane, faut avouer) figure dans MISC n° 7. Sinon, si ce genre de trucs d'intéresse, va sur ce genre de site qui suit là plus bas après la phrase. Tu verras que rien ne resiste à des gens sachant programmer. Rien.
http://www.crackmes.de/ ou http://crackmes.host.sk/
Bon si tu connais pas les docs d'Intel par coeur et ne pipe pas un mot à l'asssembleur, c'est même pas la pien :-).
Oui, mais le code exporté n'est pas viable tel quel non? C'est pour ça que je parlais d'utiliser des JMP bien placés alors que tu ne parlais que d'exportation.
Tatata. Il y a toujours une solution. Une fois, je voulais récupérer une routine dont evidemment tous les offsets étaient dépendant du code, je veux dire, de l'instant ou il est exécuté. Eh bien, je me suis pas foulé ! J'ai exporté et j'ai appliqué le fameux delta_offset que tous les programmeurs de virus connaissent :-). Et après on dira que ça sert pas d'analyser les virus. Tsss.
Tiens un petit exemple. Il te faut connaître l'endroit où tu es. Par exemple, tu ne sais pas à quel endroit les variables de ton virus seront localisées une fois exéécuté. Tu fais :
call amcd amcd: pop bp sub bp, offset amcd
et voilà ! Tu a maintenant le moyen de calculer les différences d'offset. Utile pour les variables. Par exemple, tu remplaces tes mov dx,offset x
par
lea dx,[bp+offset x]
Et ainsi de suite. C'est l'enfance de l'art.
D'autres questions ? (nan parce qu'il pleut sévère là...)
Bon si tu connais pas les docs d'Intel par coeur et ne pipe pas un mot à l'asssembleur, c'est même pas la pien :-).
Je n'y connais pas grand chose puisque je me suis arrêté aux bases du 16 bits. Mais ça ne me fait pas peur de regarder le code dans un désassembleur ou un un debugger, je m'en suis un peu servi pour bidouiller il y a qq années.
Tatata. Il y a toujours une solution. Une fois, je voulais récupérer une routine dont evidemment tous les offsets étaient dépendant du code, je veux dire, de l'instant ou il est exécuté. Eh bien, je me suis pas foulé ! J'ai exporté et j'ai appliqué le fameux delta_offset que tous les programmeurs de virus connaissent :-). Et après on dira que ça sert pas d'analyser les virus. Tsss.
C'est quoi cette histoire de delta_offset? C'est juste un décalage de tout le code?
lea dx,[bp+offset x] Et ainsi de suite. C'est l'enfance de l'art.
En effet, j'ai souvent vu ça dans les codes sources de virus DOS. C'est à peu près la même technique pour connaitre l'offset des API windows non? Il suffit juste de connaître l'adresse d'une seule et les offsets relatifs des autres.
D'autres questions ? (nan parce qu'il pleut sévère là...)
Ben non, rien de spécial. Désolé ;D
-- joke0
Salut,
AMcD:
Bon si tu connais pas les docs d'Intel par coeur et ne pipe
pas un mot à l'asssembleur, c'est même pas la pien :-).
Je n'y connais pas grand chose puisque je me suis arrêté aux
bases du 16 bits. Mais ça ne me fait pas peur de regarder le
code dans un désassembleur ou un un debugger, je m'en suis un
peu servi pour bidouiller il y a qq années.
Tatata. Il y a toujours une solution. Une fois, je voulais
récupérer une routine dont evidemment tous les offsets étaient
dépendant du code, je veux dire, de l'instant ou il est
exécuté. Eh bien, je me suis pas foulé ! J'ai exporté et j'ai
appliqué le fameux delta_offset que tous les programmeurs de
virus connaissent :-). Et après on dira que ça sert pas
d'analyser les virus. Tsss.
C'est quoi cette histoire de delta_offset? C'est juste un
décalage de tout le code?
lea dx,[bp+offset x]
Et ainsi de suite. C'est l'enfance de l'art.
En effet, j'ai souvent vu ça dans les codes sources de virus
DOS. C'est à peu près la même technique pour connaitre l'offset
des API windows non? Il suffit juste de connaître l'adresse
d'une seule et les offsets relatifs des autres.
D'autres questions ? (nan parce qu'il pleut sévère là...)
Bon si tu connais pas les docs d'Intel par coeur et ne pipe pas un mot à l'asssembleur, c'est même pas la pien :-).
Je n'y connais pas grand chose puisque je me suis arrêté aux bases du 16 bits. Mais ça ne me fait pas peur de regarder le code dans un désassembleur ou un un debugger, je m'en suis un peu servi pour bidouiller il y a qq années.
Tatata. Il y a toujours une solution. Une fois, je voulais récupérer une routine dont evidemment tous les offsets étaient dépendant du code, je veux dire, de l'instant ou il est exécuté. Eh bien, je me suis pas foulé ! J'ai exporté et j'ai appliqué le fameux delta_offset que tous les programmeurs de virus connaissent :-). Et après on dira que ça sert pas d'analyser les virus. Tsss.
C'est quoi cette histoire de delta_offset? C'est juste un décalage de tout le code?
lea dx,[bp+offset x] Et ainsi de suite. C'est l'enfance de l'art.
En effet, j'ai souvent vu ça dans les codes sources de virus DOS. C'est à peu près la même technique pour connaitre l'offset des API windows non? Il suffit juste de connaître l'adresse d'une seule et les offsets relatifs des autres.
D'autres questions ? (nan parce qu'il pleut sévère là...)
Ben non, rien de spécial. Désolé ;D
-- joke0
Frederic Bonroy
C'est quoi cette histoire de delta_offset? C'est juste un décalage de tout le code?
C'est un truc un petit peu pourri qui d'ailleurs est pris en compte par les antivirus lors de l'analyse heuristique. ;-)
L'instruction call pousse d'abord l'(E)IP de retour sur la pile. L'adresse de retour, c'est l'adresse de l'instruction qui suit le call. Dans ce cas, l'adresse de pop bp donc. Pop bp, appelé par le call, supprime l'adresse de retour (sa propre adresse) de la pile et la met dans bp. Ensuite tu soustrais de bp l'adresse "absolue" si je puis dire de pop bp pour obtenir la différence qui sert à réaliser le décalage. Ce décalage est dû au fait que les virus ne se retrouvent pas toujours au même endroit quand ils infectent un fichier.
Il faut aussi noter que le call est relatif!
Arnold a posté la version simple. Il y a plein de possibilités différentes pour réaliser ça. Encore une fois on voit ici combien les émulateurs sont utiles. :-)
En effet, j'ai souvent vu ça dans les codes sources de virus DOS. C'est à peu près la même technique pour connaitre l'offset des API windows non? Il suffit juste de connaître l'adresse d'une seule et les offsets relatifs des autres.
Ce n'est pas tout à fait pareil quand-même.
C'est quoi cette histoire de delta_offset? C'est juste un
décalage de tout le code?
C'est un truc un petit peu pourri qui d'ailleurs est pris en compte par
les antivirus lors de l'analyse heuristique. ;-)
L'instruction call pousse d'abord l'(E)IP de retour sur la pile.
L'adresse de retour, c'est l'adresse de l'instruction qui suit le call.
Dans ce cas, l'adresse de pop bp donc. Pop bp, appelé par le call,
supprime l'adresse de retour (sa propre adresse) de la pile et la met
dans bp. Ensuite tu soustrais de bp l'adresse "absolue" si je puis dire
de pop bp pour obtenir la différence qui sert à réaliser le décalage. Ce
décalage est dû au fait que les virus ne se retrouvent pas toujours au
même endroit quand ils infectent un fichier.
Il faut aussi noter que le call est relatif!
Arnold a posté la version simple. Il y a plein de possibilités
différentes pour réaliser ça. Encore une fois on voit ici combien les
émulateurs sont utiles. :-)
En effet, j'ai souvent vu ça dans les codes sources de virus
DOS. C'est à peu près la même technique pour connaitre l'offset
des API windows non? Il suffit juste de connaître l'adresse
d'une seule et les offsets relatifs des autres.
C'est quoi cette histoire de delta_offset? C'est juste un décalage de tout le code?
C'est un truc un petit peu pourri qui d'ailleurs est pris en compte par les antivirus lors de l'analyse heuristique. ;-)
L'instruction call pousse d'abord l'(E)IP de retour sur la pile. L'adresse de retour, c'est l'adresse de l'instruction qui suit le call. Dans ce cas, l'adresse de pop bp donc. Pop bp, appelé par le call, supprime l'adresse de retour (sa propre adresse) de la pile et la met dans bp. Ensuite tu soustrais de bp l'adresse "absolue" si je puis dire de pop bp pour obtenir la différence qui sert à réaliser le décalage. Ce décalage est dû au fait que les virus ne se retrouvent pas toujours au même endroit quand ils infectent un fichier.
Il faut aussi noter que le call est relatif!
Arnold a posté la version simple. Il y a plein de possibilités différentes pour réaliser ça. Encore une fois on voit ici combien les émulateurs sont utiles. :-)
En effet, j'ai souvent vu ça dans les codes sources de virus DOS. C'est à peu près la même technique pour connaitre l'offset des API windows non? Il suffit juste de connaître l'adresse d'une seule et les offsets relatifs des autres.
Ce n'est pas tout à fait pareil quand-même.
AMcD
joke0 wrote:
C'est quoi cette histoire de delta_offset? C'est juste un décalage de tout le code?
Ben c'est comme je te l'explique, une astuce permettant de chopper l'adresse où tu te situe lors de l'exécution de ton virus.
En effet, j'ai souvent vu ça dans les codes sources de virus DOS. C'est à peu près la même technique pour connaitre l'offset des API windows non? Il suffit juste de connaître l'adresse d'une seule et les offsets relatifs des autres.
Houla. C'est un peu plus compliqué. En fait, cela va dépendre de ce que tu cherches. Dans un segment "PE" où tu te situes, tu pourras user ce genre de ruse. Mais si tu cherches des adresses de fonctions de DLLS, il te suffira de chercher dans l'IAT une fois loadée. Etc. Cela dépend de ce que tu veux faire. C'est un peu plus technique mais bon.
C'est quoi cette histoire de delta_offset? C'est juste un
décalage de tout le code?
Ben c'est comme je te l'explique, une astuce permettant de chopper l'adresse
où tu te situe lors de l'exécution de ton virus.
En effet, j'ai souvent vu ça dans les codes sources de virus
DOS. C'est à peu près la même technique pour connaitre l'offset
des API windows non? Il suffit juste de connaître l'adresse
d'une seule et les offsets relatifs des autres.
Houla. C'est un peu plus compliqué. En fait, cela va dépendre de ce que tu
cherches. Dans un segment "PE" où tu te situes, tu pourras user ce genre de
ruse. Mais si tu cherches des adresses de fonctions de DLLS, il te suffira
de chercher dans l'IAT une fois loadée. Etc. Cela dépend de ce que tu veux
faire. C'est un peu plus technique mais bon.
C'est quoi cette histoire de delta_offset? C'est juste un décalage de tout le code?
Ben c'est comme je te l'explique, une astuce permettant de chopper l'adresse où tu te situe lors de l'exécution de ton virus.
En effet, j'ai souvent vu ça dans les codes sources de virus DOS. C'est à peu près la même technique pour connaitre l'offset des API windows non? Il suffit juste de connaître l'adresse d'une seule et les offsets relatifs des autres.
Houla. C'est un peu plus compliqué. En fait, cela va dépendre de ce que tu cherches. Dans un segment "PE" où tu te situes, tu pourras user ce genre de ruse. Mais si tu cherches des adresses de fonctions de DLLS, il te suffira de chercher dans l'IAT une fois loadée. Etc. Cela dépend de ce que tu veux faire. C'est un peu plus technique mais bon.
L'instruction call pousse d'abord l'(E)IP de retour sur la pile. L'adresse de retour, c'est l'adresse de l'instruction qui suit le call. Dans ce cas, l'adresse de pop bp donc. Pop bp, appelé par le call, supprime l'adresse de retour (sa propre adresse) de la pile et la met dans bp. Ensuite tu soustrais de bp l'adresse "absolue" si je puis dire de pop bp pour obtenir la différence qui sert à réaliser le décalage. Ce décalage est dû au fait que les virus ne se retrouvent pas toujours au même endroit quand ils infectent un fichier.
Ok, c'est clair, c'était plus compliqué que je pensais :-)
-- joke0
Salut,
Frederic Bonroy:
L'instruction call pousse d'abord l'(E)IP de retour sur la
pile. L'adresse de retour, c'est l'adresse de l'instruction
qui suit le call. Dans ce cas, l'adresse de pop bp donc. Pop
bp, appelé par le call, supprime l'adresse de retour (sa
propre adresse) de la pile et la met dans bp. Ensuite tu
soustrais de bp l'adresse "absolue" si je puis dire de pop bp
pour obtenir la différence qui sert à réaliser le décalage. Ce
décalage est dû au fait que les virus ne se retrouvent pas
toujours au même endroit quand ils infectent un fichier.
Ok, c'est clair, c'était plus compliqué que je pensais :-)
L'instruction call pousse d'abord l'(E)IP de retour sur la pile. L'adresse de retour, c'est l'adresse de l'instruction qui suit le call. Dans ce cas, l'adresse de pop bp donc. Pop bp, appelé par le call, supprime l'adresse de retour (sa propre adresse) de la pile et la met dans bp. Ensuite tu soustrais de bp l'adresse "absolue" si je puis dire de pop bp pour obtenir la différence qui sert à réaliser le décalage. Ce décalage est dû au fait que les virus ne se retrouvent pas toujours au même endroit quand ils infectent un fichier.
Ok, c'est clair, c'était plus compliqué que je pensais :-)
-- joke0
Frederic Bonroy
Quand la bestiole n'est pas capable de repérer le debugger c'est sûr ;-)
Suffit de repérer l'endroit où il est repéré. ;-)
Oui, mais le code exporté n'est pas viable tel quel non?
Généralement non, et ce n'est pas uniquement une question d'adresses et de décalage. Une partie du code qui gère les effets graphiques peut très bien être enfouie quelque part ailleurs. Tout ne se trouve pas forcément au même endroit. Et il peut y avoir des "relations logiques", c'est-à-dire que le code graphique dépend des résultats du code non-graphique.
Quand la bestiole n'est pas capable de repérer le debugger c'est
sûr ;-)
Suffit de repérer l'endroit où il est repéré. ;-)
Oui, mais le code exporté n'est pas viable tel quel non?
Généralement non, et ce n'est pas uniquement une question d'adresses et
de décalage. Une partie du code qui gère les effets graphiques peut très
bien être enfouie quelque part ailleurs. Tout ne se trouve pas forcément
au même endroit. Et il peut y avoir des "relations logiques",
c'est-à-dire que le code graphique dépend des résultats du code
non-graphique.
Quand la bestiole n'est pas capable de repérer le debugger c'est sûr ;-)
Suffit de repérer l'endroit où il est repéré. ;-)
Oui, mais le code exporté n'est pas viable tel quel non?
Généralement non, et ce n'est pas uniquement une question d'adresses et de décalage. Une partie du code qui gère les effets graphiques peut très bien être enfouie quelque part ailleurs. Tout ne se trouve pas forcément au même endroit. Et il peut y avoir des "relations logiques", c'est-à-dire que le code graphique dépend des résultats du code non-graphique.
joke0
Salut,
Frederic Bonroy:
Et il peut y avoir des "relations logiques", c'est-à-dire que le code graphique dépend des résultats du code non-graphique.
C'est surtout à ça que je pensais.
-- joke0
Salut,
Frederic Bonroy:
Et il peut y avoir des "relations logiques", c'est-à-dire que
le code graphique dépend des résultats du code non-graphique.
Et il peut y avoir des "relations logiques", c'est-à-dire que le code graphique dépend des résultats du code non-graphique.
C'est surtout à ça que je pensais.
-- joke0
AMcD
Frederic Bonroy wrote:
Généralement non, et ce n'est pas uniquement une question d'adresses et de décalage. Une partie du code qui gère les effets graphiques peut très bien être enfouie quelque part ailleurs. Tout ne se trouve pas forcément au même endroit. Et il peut y avoir des "relations logiques", c'est-à-dire que le code graphique dépend des résultats du code non-graphique.
Heuuuuu... Bon, je veux bien être un adepte du procédural :-). Quand tu vas coder du graphisme, tu vas certes avoir le code logique d'un côté et le code de dessin quelque part ailleurs. En théorie, mais ce n'est pas forcé. Cela depend de la complexité de ce que tu mets en oeuvre. Pour un truc du genre le feu d'artifice à la Happy99, je suppute un bon bloc monolithique.
Généralement non, et ce n'est pas uniquement une question d'adresses
et de décalage. Une partie du code qui gère les effets graphiques
peut très bien être enfouie quelque part ailleurs. Tout ne se trouve
pas forcément au même endroit. Et il peut y avoir des "relations
logiques", c'est-à-dire que le code graphique dépend des résultats du
code non-graphique.
Heuuuuu... Bon, je veux bien être un adepte du procédural :-). Quand tu vas
coder du graphisme, tu vas certes avoir le code logique d'un côté et le code
de dessin quelque part ailleurs. En théorie, mais ce n'est pas forcé. Cela
depend de la complexité de ce que tu mets en oeuvre. Pour un truc du genre
le feu d'artifice à la Happy99, je suppute un bon bloc monolithique.
Généralement non, et ce n'est pas uniquement une question d'adresses et de décalage. Une partie du code qui gère les effets graphiques peut très bien être enfouie quelque part ailleurs. Tout ne se trouve pas forcément au même endroit. Et il peut y avoir des "relations logiques", c'est-à-dire que le code graphique dépend des résultats du code non-graphique.
Heuuuuu... Bon, je veux bien être un adepte du procédural :-). Quand tu vas coder du graphisme, tu vas certes avoir le code logique d'un côté et le code de dessin quelque part ailleurs. En théorie, mais ce n'est pas forcé. Cela depend de la complexité de ce que tu mets en oeuvre. Pour un truc du genre le feu d'artifice à la Happy99, je suppute un bon bloc monolithique.
