Je reviens au mail de Testor ci-dessous. Je me pose la question suivante :
est-il possible d'avoir un programme compressé qui se décompacte
automatiquement en s'executant sans passer par un programme extérieur, style
winzip ?
Dans la discussion avec Testor, il était question à un moment donné de la
librairie "zlib" : est-ce la solution ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrick 'Zener' Brunet
Bonjour.
Je réponds à Nicolas qui a écrit :
+-- SenoN --+ a écrit :
Bonjour,
Je reviens au mail de Testor ci-dessous. Je me pose la question suivante : est-il possible d'avoir un programme compressé qui se décompacte automatiquement en s'executant sans passer par un programme extérieur, style winzip ?
Dans la discussion avec Testor, il était question à un moment donné de la librairie "zlib" : est-ce la solution ?
Merci.
On peut arriver à cela avec UPX, disponible sur http://upx.sourceforge.net/ . Il compresse le fichier, et ajoute un petit décompresseur. Au lancement, le décompresseur crée l'image du fichier exécutable, et le lance, sans que l'utilisateur ne le remarque. UPX n'a pas l'air d'utiliser zlib.
L'utilisateur ne le remarquera peut-être pas, mais il y a bien création d'un EXE parallèle, et même s'il est prévu de le détruire après, un firewall ordinaire avec surveillance d'applications ne va pas laisser faire.
Il me semble bien que M. +-- SenoN --+ entendait un programme qui se décompresse lui-même. On sait qu'il y a des techniques d'obfuscation en ASM (MISC a fait un article là-dessus il y a un an environ), mais c'est plutôt de la modification intra-code, a priori sur le process en mémoire, et sans possibilité de dilatation (il faudrait réallouer l'espace)
Une problématique connexe avait déjà été évoquée dans une conversation à laquelle j'avais participé, il y a assez longtemps : il s'agissait pour un EXE d'arriver à s'auto-modifier (définitivement et au niveau du fichier EXE) pour s'auto-tatouer avec une clé de licence.
Nous étions parvenus en gros à la conclusion selon laquelle ça n'est pas directement possible du fait que le fichier EXE est verrouillé en accès exclusif lors de son exécution, ce qui conduisait effectivement à lui faire pondre un "oeuf" et le lancer, puis se terminer pour que ledit oeuf le tatoue avant de se terminer à son tour en relançant le programme principal désormais tatoué. Avec donc le même problème de la présence même fugitive d'un second EXE et donc la possibilité d'une interception.
La suite avait porté sur la possibilité pour un EXE de résider en mémoire pure (pas sur un ramdisk) et donc d'être lancé de mémoire à mémoire (pseudo-fichier programme dans une bloc de mémoire à instance de process en mémoire). Et là on était restés dans l'inconnu sur le moyen de faire faire ça au loader.
Si quelqu'un a du nouveau sur ce thème, je suis toujours intéressé ;-) Maître AMcD® svp ?
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
Je réponds à Nicolas <n.favrefelix@eggbaconandspam--free.fr> qui a écrit :
+-- SenoN --+ a écrit :
Bonjour,
Je reviens au mail de Testor ci-dessous. Je me pose la question
suivante : est-il possible d'avoir un programme compressé qui se
décompacte automatiquement en s'executant sans passer par un
programme extérieur, style winzip ?
Dans la discussion avec Testor, il était question à un moment donné
de la librairie "zlib" : est-ce la solution ?
Merci.
On peut arriver à cela avec UPX, disponible sur
http://upx.sourceforge.net/ .
Il compresse le fichier, et ajoute un petit décompresseur.
Au lancement, le décompresseur crée l'image du fichier exécutable, et
le lance, sans que l'utilisateur ne le remarque. UPX n'a pas l'air
d'utiliser zlib.
L'utilisateur ne le remarquera peut-être pas, mais il y a bien création d'un
EXE parallèle, et même s'il est prévu de le détruire après, un firewall
ordinaire avec surveillance d'applications ne va pas laisser faire.
Il me semble bien que M. +-- SenoN --+ entendait un programme qui se
décompresse lui-même. On sait qu'il y a des techniques d'obfuscation en ASM
(MISC a fait un article là-dessus il y a un an environ), mais c'est plutôt
de la modification intra-code, a priori sur le process en mémoire, et sans
possibilité de dilatation (il faudrait réallouer l'espace)
Une problématique connexe avait déjà été évoquée dans une conversation à
laquelle j'avais participé, il y a assez longtemps : il s'agissait pour un
EXE d'arriver à s'auto-modifier (définitivement et au niveau du fichier EXE)
pour s'auto-tatouer avec une clé de licence.
Nous étions parvenus en gros à la conclusion selon laquelle ça n'est pas
directement possible du fait que le fichier EXE est verrouillé en accès
exclusif lors de son exécution, ce qui conduisait effectivement à lui faire
pondre un "oeuf" et le lancer, puis se terminer pour que ledit oeuf le
tatoue avant de se terminer à son tour en relançant le programme principal
désormais tatoué. Avec donc le même problème de la présence même fugitive
d'un second EXE et donc la possibilité d'une interception.
La suite avait porté sur la possibilité pour un EXE de résider en mémoire
pure (pas sur un ramdisk) et donc d'être lancé de mémoire à mémoire
(pseudo-fichier programme dans une bloc de mémoire à instance de process en
mémoire). Et là on était restés dans l'inconnu sur le moyen de faire faire
ça au loader.
Si quelqu'un a du nouveau sur ce thème, je suis toujours intéressé ;-)
Maître AMcD® svp ?
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
Je reviens au mail de Testor ci-dessous. Je me pose la question suivante : est-il possible d'avoir un programme compressé qui se décompacte automatiquement en s'executant sans passer par un programme extérieur, style winzip ?
Dans la discussion avec Testor, il était question à un moment donné de la librairie "zlib" : est-ce la solution ?
Merci.
On peut arriver à cela avec UPX, disponible sur http://upx.sourceforge.net/ . Il compresse le fichier, et ajoute un petit décompresseur. Au lancement, le décompresseur crée l'image du fichier exécutable, et le lance, sans que l'utilisateur ne le remarque. UPX n'a pas l'air d'utiliser zlib.
L'utilisateur ne le remarquera peut-être pas, mais il y a bien création d'un EXE parallèle, et même s'il est prévu de le détruire après, un firewall ordinaire avec surveillance d'applications ne va pas laisser faire.
Il me semble bien que M. +-- SenoN --+ entendait un programme qui se décompresse lui-même. On sait qu'il y a des techniques d'obfuscation en ASM (MISC a fait un article là-dessus il y a un an environ), mais c'est plutôt de la modification intra-code, a priori sur le process en mémoire, et sans possibilité de dilatation (il faudrait réallouer l'espace)
Une problématique connexe avait déjà été évoquée dans une conversation à laquelle j'avais participé, il y a assez longtemps : il s'agissait pour un EXE d'arriver à s'auto-modifier (définitivement et au niveau du fichier EXE) pour s'auto-tatouer avec une clé de licence.
Nous étions parvenus en gros à la conclusion selon laquelle ça n'est pas directement possible du fait que le fichier EXE est verrouillé en accès exclusif lors de son exécution, ce qui conduisait effectivement à lui faire pondre un "oeuf" et le lancer, puis se terminer pour que ledit oeuf le tatoue avant de se terminer à son tour en relançant le programme principal désormais tatoué. Avec donc le même problème de la présence même fugitive d'un second EXE et donc la possibilité d'une interception.
La suite avait porté sur la possibilité pour un EXE de résider en mémoire pure (pas sur un ramdisk) et donc d'être lancé de mémoire à mémoire (pseudo-fichier programme dans une bloc de mémoire à instance de process en mémoire). Et là on était restés dans l'inconnu sur le moyen de faire faire ça au loader.
Si quelqu'un a du nouveau sur ce thème, je suis toujours intéressé ;-) Maître AMcD® svp ?
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Cyrille Szymanski
"+-- SenoN --+" wrote in news:42bd0d80$0$12703$:
suivante : est-il possible d'avoir un programme compressé qui se décompacte automatiquement en s'executant sans passer par un programme extérieur, style winzip ?
Quel est le problème que tu cherches à résoudre en faisant cela ?
-- Cyrille Szymanski
"+-- SenoN --+" <senon@worldonline.fr> wrote in
news:42bd0d80$0$12703$626a14ce@news.free.fr:
suivante : est-il possible d'avoir un programme compressé qui se
décompacte automatiquement en s'executant sans passer par un programme
extérieur, style winzip ?
Quel est le problème que tu cherches à résoudre en faisant cela ?
suivante : est-il possible d'avoir un programme compressé qui se décompacte automatiquement en s'executant sans passer par un programme extérieur, style winzip ?
Quel est le problème que tu cherches à résoudre en faisant cela ?
-- Cyrille Szymanski
+-- SenoN --+
C'est pour ma culture personnel. Je pensai aussi au noyaux Linux, qui me semble-t-il fait se genre de chose au boot....a moins que je me trompe.
"Cyrille Szymanski" a écrit dans le message de news:
"+-- SenoN --+" wrote in news:42bd0d80$0$12703$:
> suivante : est-il possible d'avoir un programme compressé qui se > décompacte automatiquement en s'executant sans passer par un programme > extérieur, style winzip ?
Quel est le problème que tu cherches à résoudre en faisant cela ?
-- Cyrille Szymanski
C'est pour ma culture personnel.
Je pensai aussi au noyaux Linux, qui me semble-t-il fait se genre de chose
au boot....a moins que je me trompe.
"Cyrille Szymanski" <cns@cns2.invalid> a écrit dans le message de
news:Xns9680999BA6B15cns2cnsinvalid@212.27.42.75...
"+-- SenoN --+" <senon@worldonline.fr> wrote in
news:42bd0d80$0$12703$626a14ce@news.free.fr:
> suivante : est-il possible d'avoir un programme compressé qui se
> décompacte automatiquement en s'executant sans passer par un programme
> extérieur, style winzip ?
Quel est le problème que tu cherches à résoudre en faisant cela ?
C'est pour ma culture personnel. Je pensai aussi au noyaux Linux, qui me semble-t-il fait se genre de chose au boot....a moins que je me trompe.
"Cyrille Szymanski" a écrit dans le message de news:
"+-- SenoN --+" wrote in news:42bd0d80$0$12703$:
> suivante : est-il possible d'avoir un programme compressé qui se > décompacte automatiquement en s'executant sans passer par un programme > extérieur, style winzip ?
Quel est le problème que tu cherches à résoudre en faisant cela ?
-- Cyrille Szymanski
Cyrille Szymanski
Nicolas wrote in news:42bebf2a$0$22324$:
When creating a bootable kernel image, the kernel is also compressed using the zlib algorithm, which requires a very small decompression stub to be included in the resulting image.
Il me semble que le problème qu'ils cherchaient à résoudre était d'avoir une petite empreinte disque pour que le programme de boot prenne le moins de disquettes possible.
Aujourd'hui, avec les CD bootables par exemple, je ne pense pas que ce soit encore la priorité.
-- Cyrille Szymanski
Nicolas <n.favrefelix@eggbaconandspam--free.fr> wrote in
news:42bebf2a$0$22324$626a14ce@news.free.fr:
When creating a bootable kernel image, the kernel is also compressed
using the zlib algorithm, which requires a very small decompression
stub to be included in the resulting image.
Il me semble que le problème qu'ils cherchaient à résoudre était d'avoir
une petite empreinte disque pour que le programme de boot prenne le moins
de disquettes possible.
Aujourd'hui, avec les CD bootables par exemple, je ne pense pas que ce soit
encore la priorité.
When creating a bootable kernel image, the kernel is also compressed using the zlib algorithm, which requires a very small decompression stub to be included in the resulting image.
Il me semble que le problème qu'ils cherchaient à résoudre était d'avoir une petite empreinte disque pour que le programme de boot prenne le moins de disquettes possible.
Aujourd'hui, avec les CD bootables par exemple, je ne pense pas que ce soit encore la priorité.
