> alors, il est concevable de s'échiner à retarder un peu les hackers a deux
sous qui veulent te piquer tes ressources en deux coups de cuillère à pot.
> alors, il est concevable de s'échiner à retarder un peu les hackers a deux
sous qui veulent te piquer tes ressources en deux coups de cuillère à pot.
> alors, il est concevable de s'échiner à retarder un peu les hackers a deux
sous qui veulent te piquer tes ressources en deux coups de cuillère à pot.
>
Quel est votre problème initial que vous voulez résoudre avec de la
génération automatique de code ?
>
Quel est votre problème initial que vous voulez résoudre avec de la
génération automatique de code ?
>
Quel est votre problème initial que vous voulez résoudre avec de la
génération automatique de code ?
Je connais l'auteur de EditHexa et je précise que le but premier n'est
pas de faciliter la vie des hackers.
Je connais l'auteur de EditHexa et je précise que le but premier n'est
pas de faciliter la vie des hackers.
Je connais l'auteur de EditHexa et je précise que le but premier n'est
pas de faciliter la vie des hackers.
Franchement, si votre propriété intellectuelle est dans une chaîne ou une
image, il est clair que l'on ne fait pas le même travail.
Franchement, si votre propriété intellectuelle est dans une chaîne ou une
image, il est clair que l'on ne fait pas le même travail.
Franchement, si votre propriété intellectuelle est dans une chaîne ou une
image, il est clair que l'on ne fait pas le même travail.
UPX ou Aspack non? C'est si simple.
UPX ou Aspack non? C'est si simple.
UPX ou Aspack non? C'est si simple.
Remi THOMAS wrote:UPX ou Aspack non? C'est si simple.
UPX ? Tellement simple que ça se craque très facilement. Je ne vais pas te
dire comment, je vais encore me faire engueuler. Aspack est un peu plus
costaud. D'ailleurs, quelle que soit leur qualité, tous ces packers
souffrent de plusieurs défauts, le premier étant que l'utilisateur doit
bien lire la doc et bien l'utiliser. Si, si, je connais des packers
ultra-balaises qui ont été obligés de... heu non, j'ai promis :-). Enfin,
bon, comment dire, heu, tu connais le scan mémoire ? Moi, j'ai des tools
(persos, cherche pas sur le Web) qui quel que soit ta protec heu...
Il ne faut pas confondre protection de code et protection de ressources !
Si j'écris du code métamorphique ou obfusqué à mort (ce que font les bons
packers), en mémoire t'as toujours du code métamorphique ou obfusqué. Le
hacker doit donc soit reconstruire le code, soit casser le soft de pack
pour comprendre ses layers d'obfuscation (j'ai des potes qui bossent
là-dedans, souhaitons bon courage aux hackers...). par contre, la majorité
des packers laissent les ressources comme telles, ou, tout au moins, une
fois en mémoire... ben je te les extrait comme je veux :-). Donc, pour ce
cas précis, ces softs ne servent à rien.
Prenons un cas que j'utilise parfois. Supposons que je possède un bitmap
de 4096 pixels de long sur 16 de haut qui contient les 256 icônes/bitmaps
16x16 qui ont coûté très cher à dessiner. Si je le laisse comme tel, il
apparaîtra dans le rc/exe comme tel et sera facilement hackable. Supposons
que j'applique un xor mobile sur chaque bloc de 8 pixels avant de le
mettre dans le exe. Là, en ressource, t'as toujours le bitmap, mais
illisible. Il faut lors du load dans le code de-xorer celui-ci. Bref, il y
a des tas de solutions.
Bien sûr, ce n'est pas moi qui vais dire que l'on peut protéger ses
ressources de manière sûre ! Après tout quand un gars voit une icône qui
lui plaît sur une fenêtre, une copie d'écran et il récupère. Mais bon,
s'il doit faire cela pour des centaines d'icônes, curseurs, bitmaps,
etc...
Le but est de retarder le hacker en bois, c'est à dire 99.99 % des
gugusses qui, parce qu'ils savent insérer un NOP dans un éditeur hexa, se
prennent pour des uber-lords. Compresser le code, l'obfusquer, chiffrer
les ressoures... déjà, t'as 99.99 % des H4ck3r5 qui lâchent l'affaire. Si
tu y mets l'argent et le temps nécessaire, tout se craque, certes. Mais on
peut sérieusement complique la vie des ces petits djeuns nopeurs :-).
Allez, quelques liens :
ASpack ? Heu...
http://elooo.fff.free.fr/consult/Unpacking_aspr1.23_elooo/
C'est pour les débutants, mais tu comprendras bien le sbases du crack des
packers. Tu trouves des articles/tutoriels de ce genre pour la amjorité
des packers.
http://www.woodmann.net/forum/index.php
En fouillant bien, tu trouveras du lourd et du crack (sinon des pistes,
des tuyaux) pour quasi tous les packers.
http://www.cs.arizona.edu/~collberg/Research/Publications/CollbergThomborson2000a/A4.pdf
Pour ceux qui veulent débuter dans l'obfuscation. Il y a des tonnes
d'autres papiers/sites. Demandez.
Bonne lecture.
PS : inutile de me contacter pour me demander comment je fais pour craquer
çi ou ça, extraire çi ou ça, bypasser çi ou ça, etc. Mes propos à ce sujet
sont pures vantardises, je ne sais pas comment on fait et je ne répondrai
donc pas !
--
Arnold McDonald (AMcD) - Help #24 /2006
http://arnold.mcdonald.free.fr/
Remi THOMAS wrote:
UPX ou Aspack non? C'est si simple.
UPX ? Tellement simple que ça se craque très facilement. Je ne vais pas te
dire comment, je vais encore me faire engueuler. Aspack est un peu plus
costaud. D'ailleurs, quelle que soit leur qualité, tous ces packers
souffrent de plusieurs défauts, le premier étant que l'utilisateur doit
bien lire la doc et bien l'utiliser. Si, si, je connais des packers
ultra-balaises qui ont été obligés de... heu non, j'ai promis :-). Enfin,
bon, comment dire, heu, tu connais le scan mémoire ? Moi, j'ai des tools
(persos, cherche pas sur le Web) qui quel que soit ta protec heu...
Il ne faut pas confondre protection de code et protection de ressources !
Si j'écris du code métamorphique ou obfusqué à mort (ce que font les bons
packers), en mémoire t'as toujours du code métamorphique ou obfusqué. Le
hacker doit donc soit reconstruire le code, soit casser le soft de pack
pour comprendre ses layers d'obfuscation (j'ai des potes qui bossent
là-dedans, souhaitons bon courage aux hackers...). par contre, la majorité
des packers laissent les ressources comme telles, ou, tout au moins, une
fois en mémoire... ben je te les extrait comme je veux :-). Donc, pour ce
cas précis, ces softs ne servent à rien.
Prenons un cas que j'utilise parfois. Supposons que je possède un bitmap
de 4096 pixels de long sur 16 de haut qui contient les 256 icônes/bitmaps
16x16 qui ont coûté très cher à dessiner. Si je le laisse comme tel, il
apparaîtra dans le rc/exe comme tel et sera facilement hackable. Supposons
que j'applique un xor mobile sur chaque bloc de 8 pixels avant de le
mettre dans le exe. Là, en ressource, t'as toujours le bitmap, mais
illisible. Il faut lors du load dans le code de-xorer celui-ci. Bref, il y
a des tas de solutions.
Bien sûr, ce n'est pas moi qui vais dire que l'on peut protéger ses
ressources de manière sûre ! Après tout quand un gars voit une icône qui
lui plaît sur une fenêtre, une copie d'écran et il récupère. Mais bon,
s'il doit faire cela pour des centaines d'icônes, curseurs, bitmaps,
etc...
Le but est de retarder le hacker en bois, c'est à dire 99.99 % des
gugusses qui, parce qu'ils savent insérer un NOP dans un éditeur hexa, se
prennent pour des uber-lords. Compresser le code, l'obfusquer, chiffrer
les ressoures... déjà, t'as 99.99 % des H4ck3r5 qui lâchent l'affaire. Si
tu y mets l'argent et le temps nécessaire, tout se craque, certes. Mais on
peut sérieusement complique la vie des ces petits djeuns nopeurs :-).
Allez, quelques liens :
ASpack ? Heu...
http://elooo.fff.free.fr/consult/Unpacking_aspr1.23_elooo/
C'est pour les débutants, mais tu comprendras bien le sbases du crack des
packers. Tu trouves des articles/tutoriels de ce genre pour la amjorité
des packers.
http://www.woodmann.net/forum/index.php
En fouillant bien, tu trouveras du lourd et du crack (sinon des pistes,
des tuyaux) pour quasi tous les packers.
http://www.cs.arizona.edu/~collberg/Research/Publications/CollbergThomborson2000a/A4.pdf
Pour ceux qui veulent débuter dans l'obfuscation. Il y a des tonnes
d'autres papiers/sites. Demandez.
Bonne lecture.
PS : inutile de me contacter pour me demander comment je fais pour craquer
çi ou ça, extraire çi ou ça, bypasser çi ou ça, etc. Mes propos à ce sujet
sont pures vantardises, je ne sais pas comment on fait et je ne répondrai
donc pas !
--
Arnold McDonald (AMcD) - Help #24 /2006
http://arnold.mcdonald.free.fr/
Remi THOMAS wrote:UPX ou Aspack non? C'est si simple.
UPX ? Tellement simple que ça se craque très facilement. Je ne vais pas te
dire comment, je vais encore me faire engueuler. Aspack est un peu plus
costaud. D'ailleurs, quelle que soit leur qualité, tous ces packers
souffrent de plusieurs défauts, le premier étant que l'utilisateur doit
bien lire la doc et bien l'utiliser. Si, si, je connais des packers
ultra-balaises qui ont été obligés de... heu non, j'ai promis :-). Enfin,
bon, comment dire, heu, tu connais le scan mémoire ? Moi, j'ai des tools
(persos, cherche pas sur le Web) qui quel que soit ta protec heu...
Il ne faut pas confondre protection de code et protection de ressources !
Si j'écris du code métamorphique ou obfusqué à mort (ce que font les bons
packers), en mémoire t'as toujours du code métamorphique ou obfusqué. Le
hacker doit donc soit reconstruire le code, soit casser le soft de pack
pour comprendre ses layers d'obfuscation (j'ai des potes qui bossent
là-dedans, souhaitons bon courage aux hackers...). par contre, la majorité
des packers laissent les ressources comme telles, ou, tout au moins, une
fois en mémoire... ben je te les extrait comme je veux :-). Donc, pour ce
cas précis, ces softs ne servent à rien.
Prenons un cas que j'utilise parfois. Supposons que je possède un bitmap
de 4096 pixels de long sur 16 de haut qui contient les 256 icônes/bitmaps
16x16 qui ont coûté très cher à dessiner. Si je le laisse comme tel, il
apparaîtra dans le rc/exe comme tel et sera facilement hackable. Supposons
que j'applique un xor mobile sur chaque bloc de 8 pixels avant de le
mettre dans le exe. Là, en ressource, t'as toujours le bitmap, mais
illisible. Il faut lors du load dans le code de-xorer celui-ci. Bref, il y
a des tas de solutions.
Bien sûr, ce n'est pas moi qui vais dire que l'on peut protéger ses
ressources de manière sûre ! Après tout quand un gars voit une icône qui
lui plaît sur une fenêtre, une copie d'écran et il récupère. Mais bon,
s'il doit faire cela pour des centaines d'icônes, curseurs, bitmaps,
etc...
Le but est de retarder le hacker en bois, c'est à dire 99.99 % des
gugusses qui, parce qu'ils savent insérer un NOP dans un éditeur hexa, se
prennent pour des uber-lords. Compresser le code, l'obfusquer, chiffrer
les ressoures... déjà, t'as 99.99 % des H4ck3r5 qui lâchent l'affaire. Si
tu y mets l'argent et le temps nécessaire, tout se craque, certes. Mais on
peut sérieusement complique la vie des ces petits djeuns nopeurs :-).
Allez, quelques liens :
ASpack ? Heu...
http://elooo.fff.free.fr/consult/Unpacking_aspr1.23_elooo/
C'est pour les débutants, mais tu comprendras bien le sbases du crack des
packers. Tu trouves des articles/tutoriels de ce genre pour la amjorité
des packers.
http://www.woodmann.net/forum/index.php
En fouillant bien, tu trouveras du lourd et du crack (sinon des pistes,
des tuyaux) pour quasi tous les packers.
http://www.cs.arizona.edu/~collberg/Research/Publications/CollbergThomborson2000a/A4.pdf
Pour ceux qui veulent débuter dans l'obfuscation. Il y a des tonnes
d'autres papiers/sites. Demandez.
Bonne lecture.
PS : inutile de me contacter pour me demander comment je fais pour craquer
çi ou ça, extraire çi ou ça, bypasser çi ou ça, etc. Mes propos à ce sujet
sont pures vantardises, je ne sais pas comment on fait et je ne répondrai
donc pas !
--
Arnold McDonald (AMcD) - Help #24 /2006
http://arnold.mcdonald.free.fr/
Je ne comprends pas votre démarche.
Les icônes, les menus, les chaînes de caractères sont passer en clair
au système,
à moins d'avoir soi-même développer un moteur d'affichage
de fonte.
Mais de toutes les façons, votre "propriété intellectuelle" sera
visible sans aucune protection dans la mémoire de la carte vidéo
et
accessible avec une simple webcam et un OCR,
si votre hacker en bois
ne sait pas faire un simple driver layer vidéo ou un hook système.
Pour ce genre de "propriété intellectuelle", le plus sûr est le
water-marking et/ou l'enregistrement.
Cela est très loin de la question initial et rien avoir avec les
ressources qui elles aussi peuvent être protégées par la cryptoAPI.
Je ne comprends pas votre démarche.
Les icônes, les menus, les chaînes de caractères sont passer en clair
au système,
à moins d'avoir soi-même développer un moteur d'affichage
de fonte.
Mais de toutes les façons, votre "propriété intellectuelle" sera
visible sans aucune protection dans la mémoire de la carte vidéo
et
accessible avec une simple webcam et un OCR,
si votre hacker en bois
ne sait pas faire un simple driver layer vidéo ou un hook système.
Pour ce genre de "propriété intellectuelle", le plus sûr est le
water-marking et/ou l'enregistrement.
Cela est très loin de la question initial et rien avoir avec les
ressources qui elles aussi peuvent être protégées par la cryptoAPI.
Je ne comprends pas votre démarche.
Les icônes, les menus, les chaînes de caractères sont passer en clair
au système,
à moins d'avoir soi-même développer un moteur d'affichage
de fonte.
Mais de toutes les façons, votre "propriété intellectuelle" sera
visible sans aucune protection dans la mémoire de la carte vidéo
et
accessible avec une simple webcam et un OCR,
si votre hacker en bois
ne sait pas faire un simple driver layer vidéo ou un hook système.
Pour ce genre de "propriété intellectuelle", le plus sûr est le
water-marking et/ou l'enregistrement.
Cela est très loin de la question initial et rien avoir avec les
ressources qui elles aussi peuvent être protégées par la cryptoAPI.
Paul Bacelar :
Franchement, si votre propriété intellectuelle est dans une chaîne ou une
image, il est clair que l'on ne fait pas le même travail.
Vous avez le mépris facile.
Ma propriété intellectuelle est dans mes applis, lesquelles sont composées
de code, mais aussi de quelques ressources et aussi de fichiers d'aide, de
manuels d'utilisation papier, de sites web associés, de traductions, etc.
Y'a pas de morceaux nobles et de bas morceaux pour ce qui me concerne,
même si je préfère de loin coder que dessiner ou écrire (et je fais aussi
accessoirement le support technique, la comptabilité et le secrétariat
même si j'y prends pas mon pied).
De votre côté, si vous faites exclusivement du code brut, eh bien dont
acte, nous ne faisons pas le même travail. Désolé de vous décevoir.
Paul Bacelar :
Franchement, si votre propriété intellectuelle est dans une chaîne ou une
image, il est clair que l'on ne fait pas le même travail.
Vous avez le mépris facile.
Ma propriété intellectuelle est dans mes applis, lesquelles sont composées
de code, mais aussi de quelques ressources et aussi de fichiers d'aide, de
manuels d'utilisation papier, de sites web associés, de traductions, etc.
Y'a pas de morceaux nobles et de bas morceaux pour ce qui me concerne,
même si je préfère de loin coder que dessiner ou écrire (et je fais aussi
accessoirement le support technique, la comptabilité et le secrétariat
même si j'y prends pas mon pied).
De votre côté, si vous faites exclusivement du code brut, eh bien dont
acte, nous ne faisons pas le même travail. Désolé de vous décevoir.
Paul Bacelar :
Franchement, si votre propriété intellectuelle est dans une chaîne ou une
image, il est clair que l'on ne fait pas le même travail.
Vous avez le mépris facile.
Ma propriété intellectuelle est dans mes applis, lesquelles sont composées
de code, mais aussi de quelques ressources et aussi de fichiers d'aide, de
manuels d'utilisation papier, de sites web associés, de traductions, etc.
Y'a pas de morceaux nobles et de bas morceaux pour ce qui me concerne,
même si je préfère de loin coder que dessiner ou écrire (et je fais aussi
accessoirement le support technique, la comptabilité et le secrétariat
même si j'y prends pas mon pied).
De votre côté, si vous faites exclusivement du code brut, eh bien dont
acte, nous ne faisons pas le même travail. Désolé de vous décevoir.
