Cherche éditeur de ressources win32 particulier

Remi THOMAS wrote:

Nan,
C'était une réponse proportionnée a tes propos

Qu'est-il question de proportion ??? Ton collègue débite ânerie sur ânerie !
Solidarité MVP ? Mouarf. Pitoyable.

Pour un hacker à deux sous UPX c'est suffisant.

Oui, un coup de Google, deux tools, 3 clics boutons et ta protection est
cassée. C'est même pas pour les hackers à deux sous, mais pour ceux à 0
centime ! Enfin bon, c'est pas mes softs, ni mon travail, chacun fait comme
il veut après tout. Je ne peut m'empêcher de te dire tout de même que tu
baisses sérieusement dans mon estime. Comme tu vas me répondre que tu t'en
tapes, brisons donc là. Amusez vous bien entre MVPs.

Bien amicalement,

--
Arnold McDonald (AMcD)

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

> Comme tu vas me répondre que tu t'en tapes, brisons donc là. Amusez vous
bien entre MVPs.

Je ne m'en tape pas.
Je suis en train de protéger un soft et il sera très difficile à casser :
compilation de code à la volée et signature electronique clé privé/clé
publique.

Une DLL, cryptée et signé, execute une des fonctions au coeur de
l'application sans laquelle elle peut fonctionner.
Cette fonction n'existe pas en "statique" car son code est compilé à la
volée, avec un cryptage par mot de passe fonction du mail de l'utilisateur
et mot de passe dans l'EXE.

Si la DLL est modifiée je ne la charge pas (hacker niveau zero)
Si l'EXE est modifié le mot de passe n'est plus bon (hacker niveau un)
Le code compilé à la volée est fait en .NET (hacker niveau deux)
Le code est 100% en RAM et .NET génére du MSIL puis de l'assembleur (hacker
niveau trois)
Pour les hackers niveau quatre et bien tant mieux pour eux mais leur crack
ne fonctionne que pour leur version vu que tout ceci est fonction d'un mail.

Notre cours de récré est très grande.
Tu peux venir jouer avec nous (par exemple aux DevDays 2006).

Rémi

Remi THOMAS wrote:

Notre cours de récré est très grande.
Tu peux venir jouer avec nous (par exemple aux DevDays 2006).

- Du code compilé à la volée ? Et alors ? À un moment donné il sera en
mémoire. Jamais un soft ne m'a empêché de lire dans sa mémoire !
- Code compilé à la volée ? Ha mais donc il y a un générateur d'instruction,
un moteur de création d'instruction. Es-t-il protégé lui ? Et comment ?
- Clé privé/secrète ? Et alors ? Comment elles sont sauvegardées ces clés ?
Quel contrôle as-tu des précautions prises par le client ?
- Mot de passe dans l'exe ? Ouarg !!!! Le pire de tout ! Tu signes comment
ton exe ? Un CRC, un Hash ?
- Du code .Net ? C'est 50 fois plus facile à hacker que des opcodes Intel !
- Code 100% en RAM ? Ha, c'est bien, tu veux mon driver
spécial-je-lis-n'importe-qu'elle-zone-de-ram-kernel-ou-user ?
- Clé privé/secrète ? Hum, en dessous de RSA et compagnie, un petit man in
the middle...
- Codé en fonction d'un mail ? Hum, serveur d'authentification ? Sosu quel
OS il tourne ? Le serveur est-il correctement patché ?

Je continue ?

Si je comprends entre les lignes, soit tu me lances une espèce de défi, soit
tu "méprises" les capacités de gusses dans mon genre. Ce qui revient au même
:-). Tu as de la chance, je viens de récemment fixer mes nouvelles règles de
collaboration-hack sur un forum de crypto. Non, c'est vrai, ça fait 10 ans
que je calme tous les
uber-codeurs-ingénieurs-trop-balaises-en-sécu-et-que-nous-les-hackers-on-est-tous-des-cons
pour des prunes, now, c'est payant ! Fixe une prime et envoie ton soft. Vu
le court descriptif que tu me donnes, je suis sûr à 100% du résultat :-).

PS : sur le forum de crypto en question, le gars refuse obstinément de
m'envoyer son soft. C'est sûr qu'en seulement 40' je lui ai déjà mis à mal
son super soft recommandé par l'armée Suisse et que depuis il a du lire les
archives de quelques forums... Ho, je suis pas plus fort qu'un autre moi
hein, je suis même pas MVP, tu vois un peu. Mais depuis 10 ans j'ai appris
une chose, tout ceux qui me répondent dans ton style, je les ai eus, un par
un. Regarde sur certains forums, crypto, virus, etc. La règle est simple,
plus le gars frime avec sa méthode de sécu, sa protection
uber-elite-ingénieur-super-chiffré-signé-nex-tech-hype et plus son arrogance
l'a éloigné de concepts simples. Simple exemple, il y a quelque mois un gars
est venu nous gonfler avec son super-algo de chiffrement, je l'ai eu facile.
Pas en cassant son algo, je n'y ai meêm pas touché. Mais simplement en...
reconstruisant ses clés ! Il y a toujours un truc auquel le gars n'a pas
pensé :-). Moi, jamais je ne dirai qu'on peut protéger définitivement, on
peut seulement retarder plus ou moins longuement l'échéance du crack. J'ai
cassé des centaines de softs depuis l'âge de 15 ans, alors, je me susi afit
une opinion. En ce qui me concerne la règle est simple, l'investissement
pour casser doit coûter - moins - que 10 fois le prix du soft. Enfin, si
t'es du côté de l'éditeur du soft, c'est le terme - plus - qu'il te faut
employer :-).

Passons aux choses sérieuses : combien vaut ton soft et combien offres-tu
si je le casse ? Et ai-je le droit de publier la méthode employée ?

--
Arnold McDonald (AMcD)

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

"Arnold McDonald (AMcD)" <killspammers@free.fr> wrote in message
news:44022f17$0$23818$626a54ce@news.free.fr...

Remi THOMAS wrote:

Notre cours de récré est très grande.
Tu peux venir jouer avec nous (par exemple aux DevDays 2006).

- Du code compilé à la volée ? Et alors ? À un moment donné il sera en
mémoire. Jamais un soft ne m'a empêché de lire dans sa mémoire !
- Code compilé à la volée ? Ha mais donc il y a un générateur
d'instruction, un moteur de création d'instruction. Es-t-il protégé lui ?
Et comment ?
- Clé privé/secrète ? Et alors ? Comment elles sont sauvegardées ces clés
? Quel contrôle as-tu des précautions prises par le client ?
- Mot de passe dans l'exe ? Ouarg !!!! Le pire de tout ! Tu signes comment
ton exe ? Un CRC, un Hash ?
- Du code .Net ? C'est 50 fois plus facile à hacker que des opcodes Intel
!
- Code 100% en RAM ? Ha, c'est bien, tu veux mon driver
spécial-je-lis-n'importe-qu'elle-zone-de-ram-kernel-ou-user ?
- Clé privé/secrète ? Hum, en dessous de RSA et compagnie, un petit man in
the middle...
- Codé en fonction d'un mail ? Hum, serveur d'authentification ? Sosu quel
OS il tourne ? Le serveur est-il correctement patché ?

Je continue ?

Si je comprends entre les lignes, soit tu me lances une espèce de défi,
soit tu "méprises" les capacités de gusses dans mon genre. Ce qui revient
au même :-). Tu as de la chance, je viens de récemment fixer mes nouvelles
règles de collaboration-hack sur un forum de crypto. Non, c'est vrai, ça
fait 10 ans que je calme tous les
uber-codeurs-ingénieurs-trop-balaises-en-sécu-et-que-nous-les-hackers-on-est-tous-des-cons
pour des prunes, now, c'est payant ! Fixe une prime et envoie ton soft. Vu
le court descriptif que tu me donnes, je suis sûr à 100% du résultat :-).

PS : sur le forum de crypto en question, le gars refuse obstinément de
m'envoyer son soft. C'est sûr qu'en seulement 40' je lui ai déjà mis à mal
son super soft recommandé par l'armée Suisse et que depuis il a du lire
les archives de quelques forums... Ho, je suis pas plus fort qu'un autre
moi hein, je suis même pas MVP, tu vois un peu. Mais depuis 10 ans j'ai
appris une chose, tout ceux qui me répondent dans ton style, je les ai
eus, un par un. Regarde sur certains forums, crypto, virus, etc. La règle
est simple, plus le gars frime avec sa méthode de sécu, sa protection
uber-elite-ingénieur-super-chiffré-signé-nex-tech-hype et plus son
arrogance l'a éloigné de concepts simples. Simple exemple, il y a quelque
mois un gars est venu nous gonfler avec son super-algo de chiffrement, je
l'ai eu facile. Pas en cassant son algo, je n'y ai meêm pas touché. Mais
simplement en... reconstruisant ses clés ! Il y a toujours un truc auquel
le gars n'a pas pensé :-). Moi, jamais je ne dirai qu'on peut protéger
définitivement, on peut seulement retarder plus ou moins longuement
l'échéance du crack. J'ai cassé des centaines de softs depuis l'âge de 15
ans, alors, je me susi afit une opinion. En ce qui me concerne la règle
est simple, l'investissement pour casser doit coûter - moins - que 10 fois
le prix du soft. Enfin, si t'es du côté de l'éditeur du soft, c'est le
terme - plus - qu'il te faut employer :-).

Passons aux choses sérieuses : combien vaut ton soft et combien offres-tu
si je le casse ? Et ai-je le droit de publier la méthode employée ?

--
Arnold McDonald (AMcD)

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

Il faut arreter de toujours répondre à coté, j'avais mis la phrase
"Pour les hackers niveau quatre et bien tant mieux pour eux mais leur crack
ne fonctionne que pour leur version vu que tout ceci est fonction d'un
mail."
Cela veut dire que je suis bien conscient que c'est crackable, alors je
n'offre pas de prime pour le casser, ou alors 10 fois le prix du soft, soit
50 Euros (ouais c'est un tout petit shareware perso en préparation). Et puis
je ne sais pas encore si je le protège autant, le simple mail de
l'utilisateur dans une DLL compilé à la volée sur un serveur ASP.NET c'est
déjà pas mal. Je peux controler lors des mise à jour en limitant le nombre
de download pour un email donné. Comme c'est coté serveur c'est imparable
(et oui mon serveur est bien protégé, patché, seul le port 80 est ouvert,
etc...)

Pour les logiciels diffusés en petit nombre dans les entreprises une simple
clé de registry fonction du numéro de série du processeur est largement
suffisante pour bloquer les copieurs du dimanche.

Rémi

ps: les MVP ne sont pas forcement des cadors. Ce sont simplement des
utilisateurs passionés des techno Microsoft qui partagent leur savoir de
façon courtoise dans les forums.

Remi THOMAS :

Une DLL, cryptée et signé, execute une des fonctions au coeur de
l'application sans laquelle elle peut fonctionner.
Cette fonction n'existe pas en "statique" car son code est compilé à la
volée, avec un cryptage par mot de passe fonction du mail de
l'utilisateur et mot de passe dans l'EXE.

Désolé, je suis une truffe en matière de protection, mais je ne vois pas
l'intérêt d'une compilation au vol par rapport à un cryptage. Qu'est-ce
que ça apporte en plus ? Le fait que le hacker ne puisse pas
désassembler et tracer ? Finalement, la compilation est une forme de
cryptage, non ? D'assez bas niveau et possiblement bijectif, qui plus est.


Quelques réflexions sur le sujet... Je vais sans doute faire sourire
Arnold, mais n'ayant jamais eu à travailler pour l'armée - suisse ou
autre - pour protéger un minimum certains de mes softs, je suis parti de
dogmes simples :

1/ Rien n'est incassable a priori.

2/ Si un soft est très connu, il est rentable de toute façon et c'est
pas la peine de se casser la tête à le protéger. "Ils" en viendront à
bout de toute façon et il suffit d'une seule version craquée pour que le
monde entier en ait une copie dans les heures qui suivent.

3/ Si le soft n'est pas connu, alors oui ça peut valoir la peine d'y
passer du temps, au moins pour éviter que ça arrive trop vite.

4/ Une parade simple contre les cracks, c'est un soft qui évolue en
permanence. Je vois mal des hackers revenir au rendez-vous avec une
nouvelle version tous les deux mois. Je les crois pas très ponctuels, et
même pas vraiment méchants : plutôt du genre à casser une fois pour
ajouter un nom à leur tableau de chasse, et ne plus y revenir.

5/ La meilleure protection étant la baisse de motivation du hacker, il
faut allonger le plus possible le temps que celui-ci va passer pour
venir à bout de la protection. Evidemment, sa motivation peut aussi s'en
trouver augmentée du fait qu'il prend ça comme un défi.

6/ L'idéal est de faire en sorte que le hacker ne soit jamais absolument
sûr qu'il a fait le tour de toutes les protections, d'où l'intérêt de
trucs différents, aléatoires et avec vérifications plus ou moins rares.

7/ Inversement, il faut donner un os à ronger au hacker, genre une
fonction de protection bien classique, propre sur elle, avec
vérification du CRC de l'exe ou un truc du genre. L'idée est de
satisfaire l'ego de ceux qui vont vite passer à autre chose sans se
rendre compte qu'ils n'ont fait qu'une partie du boulot.

8/ Quand une protection détecte que le soft a été cassé, ne jamais
réagir immédiatement. Le lien entre la détection et la réaction doit
être le plus distendu possible, à grands renforts d'actions chaînées les
unes aux autres. Et ne pas juste fermer le programme mais faire en sorte
que l'utilisateur perde le travail effectué, avec le bonjour d'Alfred,
par exemple au moment d'enregistrer son fichier.


Pour les points 5, 6 et 8, mon idée a été de créer plusieurs fonctions
de vérifications différentes, on va les appeler F1, F2 ... Fn, avec F1
appelée à chaque fois (hacker niveau 0), F2 appelée de temps en temps et
Fn appelée très rarement (tout ça selon certains états de l'exécution du
soft, par exemple "Edition / Couper" déclenche une vérification, ou le
Nième clic droit, etc.).

Ensuite, si j'ai une fonction de vérification peu fréquente qui prend 10
lignes de code, je me débrouille pour qu'elle en fasse 100 et je
dissémine ces lignes dans le reste du code à l'aide d'un moteur
d'incrémentation et à grands renforts de variables globales ou de
pointeurs. Exemple très simplifié : pour ma fonction de vérification
élargie à 100 lignes L1 à L100, je pose une variable globale qui sert de
compteur C initialisé à 0. Si l'utilisateur fait "Fichier / Ouvrir" et
que C=0, on exécute L1 et on incrémente C. Si l'utilisateur clique vers
le bas à droite et que C=1, on exécute L2 et on incrémente, etc. Ce qui
fait que le soft peut avoir été exécuté sans que la vérification arrive
au bout. Le moteur d'incrémentation peut gérer accessoirement le niveau
de rareté de la vérification en avançant plus ou moins rapidement. Ou ne
déclencher des vérifications que selon la période calendaire, etc.

Evidemment, tout ça est schématique et ne marche que pour un soft riche
en fonctionnalités sur lequel l'utilisateur passe du temps. J'utilise
pas une variable globale C incrémentée poliment, mais un grand nombre de
variables, chaînes ou pointeurs qui se répondent les uns les autres au
hasard du code (d'où les 100 lignes au lieu de 10). L'idée est de
dérouter le hacker et que ça soit extrêmement chiant à tracer.


Voilà, j'avoue que j'aimerais assez avoir des avis éclairés sur ces
quelques réflexions. Ouais, sans insultes, merci. J'insiste encore : je
suis un vrai touriste en la matière ; je n'ai jamais rien lu sur le
sujet ; je sais même pas ce qu'est l'obfuscation (ne t'offusque pas
Arnold) ; je suis pas une bête en cryptage ; et c'est tout ce qui m'est
venu à l'idée quand j'ai été confronté au problème.

Bon, j'espère ne pas avoir lancé encore un troll...

Remi THOMAS :

ps: les MVP ne sont pas forcement des cadors.

Je pense pas que tu sois contesté sur ce point.

Ce sont simplement des utilisateurs passionés des techno Microsoft
qui partagent leur savoir de façon courtoise dans les forums.

Quelques uns semblent plus passionnés que courtois, à mon avis, et ont
même parfois un sens de l'humour à plutôt basse fréquence. Mais il est
vrai que c'est l'intention qui compte... Finalement, tout avis est bon à
prendre, même avec des pincettes. Je préfère un forum où l'on s'engueule
tous les jours à un forum désert.

Remi THOMAS wrote:

Il faut arreter de toujours répondre à coté

À côté ? C'est ton avis.

Cela veut dire que je suis bien conscient que c'est crackable, alors
je n'offre pas de prime pour le casser, ou alors 10 fois le prix du
soft, soit 50 Euros

Ourf, sans moi alors :-).

Et puis je ne sais pas encore si je le protège autant,

Pour 5 euros, cela semble effectivement abusé.

Je peux controler lors des
mise à jour en limitant le nombre de download pour un email donné.

Certes, mais, comme beaucoup d'adeptes de ce type de méthode, tu focalises
sur l'aspect du contrôle des connections. Le hacker s'en moque un peu. une
fois le code en mémoire et dumpé, il se souciera peu de la mise en place
client/serveur...

Comme c'est coté serveur c'est imparable (et oui mon serveur est bien
protégé, patché, seul le port 80 est ouvert, etc...)

- Rien - n'est imparable, surtout pas parce que tu contrôles le serveur.
Patché ? C'est quoi le serveur, il tourne sous Apache ? Bon, là ce sera plus
chaud. Sous un produit Kro ? Aïe, des vulnérabilités sont découvertes tous
les jours ! Et ne comptons pas les 0-days... Des failles pour ASP.Net ? Des
comme celles-ci, quand on en trouve, ça peut faire très mal (sisi, les DoS
c'est très très pénible) :

http://secunia.com/advisories/16005/

Pour les logiciels diffusés en petit nombre dans les entreprises une
simple clé de registry fonction du numéro de série du processeur est
largement suffisante pour bloquer les copieurs du dimanche.

Ben tiens. Tu me rappelles una ncien logiciel perso ou je "hookais" ce type
de protect. Ho, je peux bien te le dire, c'est tellement facile. Double
hook. Un qui spy la base de registres et l'autre les appels au périphérique
dont j'ai trouvé l'origine en désassemblant le soft. Et j'envoie/retourne ce
que j'ai envie à l'un et l'autre...

ps: les MVP ne sont pas forcement des cadors.

Tsss, solidarité MVP mal-venue :-). Comme je l'ai déjà écris plusieurs fois,
je reconnais volontiers tes compétences, là n'est pas le problème. En ce qui
te concerne, amha, sur ce coup-là, t'es juste atteint temporairement du côté
j'ai-jamais-tort du MVP :-). Le problème est, comme d'habitude avec les
MVPs, qu'il est imposible de :
- leur faire admettre qu'ils ont tort ;
- les empêcher de digresser sans fin sur des sujets dont ils ne connaissent
rien. Cette dernière remarque étant d'ailleurs inversement proportionnelle à
leur niveau d'incompétence ;
- qu'une majorité (oui, une majorité) d'entre eux, je me poserai toujours la
question de savoir comment (ou pourquoi) Microsoft a pu les honorer ainsi vu
leur médiocrité et leur incompétence.
- Que leur titre monte sérieusement à la tête de certains. Ils en perdent
humour et notion des choses...

Ce sont simplement des
utilisateurs passionés des techno Microsoft qui partagent leur savoir
de façon courtoise dans les forums

C'est là que le bât blesse ! Un passionné incompétent, ça reste toujours un
incompétent, passionné ou pas. Or, quand tu vois l'applomb de certains MVP,
même lorsqu'ils débitent des âneries, certains profanes pourraient prendre
cela pour argent content et repartir dans l'erreur ! Moi, je préfère des
forums vivants, avec différents caractères, différents avis/opinions et,
surtout, des gens qui connaissent leur partie, à des forums policés,
stéréotypés, entre gens d'une même caste, où on caresse dans le sens du
poil, s'auto-satisfait et n'apprend rien du tout.

Las titres, ça se donne. la compétence, ça se gagne.

Et je ne comprends pas pourquoi vous vous défendez les uns les autres. Il y
a un nombre de truffes élevé dans vos rangs. Leurs réponses stupides, leur
entêtement à montrer qu'ils sont compétents dans des domaines qu'ils ne
maîtrisent pas dévaluent votre titre. Cela me dépasse !

--
Arnold McDonald (AMcD)

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

Bertrand Lenoir-Welter wrote:

mais n'ayant jamais eu à travailler pour l'armée - suisse

S'il est vari que le produit du gars dont je aprlais a effectivement été
recommandé par l'armée, c'est pitoyablement comique. Un one-time-pad sur
9.000 clés...

1/ Rien n'est incassable a priori.

Non, effectivement. C'est uniquement une question de moyens financiers et de
temps.

2/ Si un soft est très connu, il est rentable de toute façon et c'est
pas la peine de se casser la tête à le protéger.

Enfin un qui a compris ! Eh oui, ça ne sert à rien.

"Ils" en viendront à
bout de toute façon et il suffit d'une seule version craquée pour que
le monde entier en ait une copie dans les heures qui suivent.

Tout à fait. C'est pour cela que moi, par exemple, je me contente de rendre
le travail des candidats pénibles. J'utilise de strucs simples à mettre en
place mais pénibles à détourner. La majorité utilisent des trucs très longs
à mettre en place et... faciles à détourner :-).

3/ Si le soft n'est pas connu, alors oui ça peut valoir la peine d'y
passer du temps, au moins pour éviter que ça arrive trop vite.

C'est le seul cas où c'est rentable. Cela étant, tu n'empêchera jamais un
fou qui, par défi personnel, sport, ou je ne sais quoi, a décidé de casser
ton truc.

4/ Une parade simple contre les cracks, c'est un soft qui évolue en
permanence. Je vois mal des hackers revenir au rendez-vous avec une
nouvelle version tous les deux mois. Je les crois pas très ponctuels,
et même pas vraiment méchants : plutôt du genre à casser une fois pour
ajouter un nom à leur tableau de chasse, et ne plus y revenir.

Vrai et faux à la fois. Le hacker pro, il fait ça pour de l'argent. Aucune
méchanceté, aucun problème personnel, soit apr sport, soit pour l'argent.
L'évolution ne sera utile que si tu changes/améliores de protection à chaque
fois.

5/ La meilleure protection étant la baisse de motivation du hacker, il
faut allonger le plus possible le temps que celui-ci va passer pour
venir à bout de la protection. Evidemment, sa motivation peut aussi
s'en trouver augmentée du fait qu'il prend ça comme un défi.

Exactement.

6/ L'idéal est de faire en sorte que le hacker ne soit jamais
absolument sûr qu'il a fait le tour de toutes les protections, d'où
l'intérêt de trucs différents, aléatoires et avec vérifications plus
ou moins rares.

Pas tout à fait vrai. Cela va dépendre de la méthode employée par le hacker.
Par exemple, soit j'attaque la protection du produit, et là ça ne amrceh que
pour ton produit ou, bien plsu dangereux, j'attaque le produit qui t'a servi
à protéger... AMHA la seule solution est d'utiliser des trucs qui prennent
un temps abyssal à détourner et qui coûtent trop cher en temps pour oser s'y
lancer.

7/ Inversement, il faut donner un os à ronger au hacker, genre une
fonction de protection bien classique, propre sur elle, avec
vérification du CRC de l'exe ou un truc du genre. L'idée est de
satisfaire l'ego de ceux qui vont vite passer à autre chose sans se
rendre compte qu'ils n'ont fait qu'une partie du boulot.

Non, ça c'est faire peu de cas des hackers professionnels.

8/ Quand une protection détecte que le soft a été cassé, ne jamais
réagir immédiatement. Le lien entre la détection et la réaction doit
être le plus distendu possible, à grands renforts d'actions chaînées
les unes aux autres. Et ne pas juste fermer le programme mais faire
en sorte que l'utilisateur perde le travail effectué, avec le bonjour
d'Alfred, par exemple au moment d'enregistrer son fichier.

Ou introduire des erreurs de fonctionnement aléatoires et fluctuant avec le
temsp, ça, c'est bien plus pénible :-).

Pour les points 5, 6 et 8, mon idée a été de créer plusieurs fonctions
de vérifications différentes, on va les appeler F1, F2 ... Fn, avec F1
appelée à chaque fois (hacker niveau 0), F2 appelée de temps en temps
et Fn appelée très rarement (tout ça selon certains états de
l'exécution du soft, par exemple "Edition / Couper" déclenche une
vérification, ou le Nième clic droit, etc.).

Pour casser ce genre de protection, je vais commencer par lister l'ensemble
des fonctions de ton soft et faire un audit de leur fréquence d'appel, avec
état de la pile, état des exceptions (vive les SEH...). je vais vite voir
les fonctions du logiciel, celles qui servent à son fonctionnement, et
celles qui sont appelés suivant des conditions : flags, checksums, timers,
etc.

Ensuite, si j'ai une fonction de vérification peu fréquente qui prend
10 lignes de code, je me débrouille pour qu'elle en fasse 100 et je
dissémine ces lignes dans le reste du code à l'aide d'un moteur
d'incrémentation et à grands renforts de variables globales ou de
pointeurs. Exemple très simplifié : pour ma fonction de vérification
élargie à 100 lignes L1 à L100, je pose une variable globale qui sert
de compteur C initialisé à 0. Si l'utilisateur fait "Fichier /
Ouvrir" et que C=0, on exécute L1 et on incrémente C. Si
l'utilisateur clique vers le bas à droite et que C=1, on exécute L2
et on incrémente, etc. Ce qui fait que le soft peut avoir été exécuté
sans que la vérification arrive au bout. Le moteur d'incrémentation
peut gérer accessoirement le niveau de rareté de la vérification en
avançant plus ou moins rapidement. Ou ne déclencher des vérifications
que selon la période calendaire, etc.

Oui, c'est un procédé classique, que l'on complexifie d'ailleurs avec
quelques layers d'obfuscation aléatoire en général. Bien implémenté, c'est
très long et pénible à casser. Souvent, on va plutôt chercher à désactiver
l'appel de la fonction de vérif plutôt que de détourner le code disséminé
d'ailleurs :-).

Evidemment, tout ça est schématique et ne marche que pour un soft
riche en fonctionnalités sur lequel l'utilisateur passe du temps.
J'utilise pas une variable globale C incrémentée poliment, mais un grand
nombre
de variables, chaînes ou pointeurs qui se répondent les uns les
autres au hasard du code (d'où les 100 lignes au lieu de 10). L'idée
est de dérouter le hacker et que ça soit extrêmement chiant à tracer.

Oui, et bien mis en place, ça l'est. mais il faut faire gaffe avec les
variables globales. Tu peux auditer certains comportements qui ne dépendent
que de certaines et tu fais vite avoir. Par exemple, je peux remarquer que
les varaibles a,b et c ont toujours leur contenu modifié avant l'appel
systématique de telle ou telle fonction et là... Disons que ta métode est
très efficace, mais l'implémentation doit être très trsè rigoureuse.

Voilà, j'avoue que j'aimerais assez avoir des avis éclairés sur ces
quelques réflexions.

Je te donne juste quelques avis. On ne malheureusement pas faire du précis
sur un forum public dans ce domaine :-(. La sécu, c'est un secteur très
sensible et où, malheureusement, navigue un taux de tocards très supérieur à
celui d'autre domaines de l'info. Cela dit, la formation, l'enseignement
manque. D'abord, parce qu'en France on préfère la sécurisation par la
dissimulation du savoir. Ensuite, parce que c'est très technique et que ça
s'apprend pas en quelques mois sur un banc d'école. Pour la petite histoire,
ces dernières années j'ai proposé à des éditeurs d'écrire une sorte
d'encyclopédie du hacking sous Windows, non, pas un truc de boutonneux hein,
LE truc, avec algos détaillées, techniques, exemples, code... Le truc
encyclopédique; du buffer overrun au virus métamorphique avec code recompilé
en mémoire. Le pavé exhaustif quoi. Ben personne n'en a voulu. Alors, les
vendeurs d'huile de serpent ont encore de beaux jours devant eux...

Ouais, sans insultes, merci.

Je n'insulte que les comportement imbéciles et encore, étant du Sud, c'est
plsu à prendre avec humour qu'autre chose.

J'insiste encore :
je suis un vrai touriste en la matière ; je n'ai jamais rien lu sur le
sujet ; je sais même pas ce qu'est l'obfuscation (ne t'offusque pas
Arnold) ;

Jeu de mot subtil ! L'obfuscation c'est rendre le
fonctionenment/déroulement/logique de ton code incompréhensible. J'ai donné
un exemple dans une réponse à notre ami Bacelar. Si tu veux, je peux faire
un exemple ou article (ça mettrait mon site un peu à jour...) plus long et
détaillé, mais bon, ça sera en assembleur...

Bon, j'espère ne pas avoir lancé encore un troll...

Mais non, il n'y a que des bons ou des mauvais trolls. Et puis, merde au
zélateurs d'Usenet, un forum doit vivre ! Et du moment qu'on apprend quelque
chose, un troll est toujours utile amha.

--
Arnold McDonald (AMcD)

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

Arnold McDonald (AMcD) :

Vrai et faux à la fois. Le hacker pro, il fait ça pour de l'argent.

Ben oui, raisonnement imparable. Un hacker pro qui ferait pas ça pour de
l'argent, ce serait plus un pro, non ?

Bon, j'avoue que je parle des hackers qui s'attaquent à des softs mis
sur le marché, pas à des trucs spéciaux ou sensibles pour lesquels
quelqu'un va payer. De toute façon ça rejoint mon point n° 1 : rien
n'est incassable.

Par exemple, dans le cas de Rémi, je vois mal quelqu'un payer un pro
pour craquer un soft vendu 5 €. Un soft à ce prix, en un sens c'est même
la protection parfaite.

Pas tout à fait vrai. Cela va dépendre de la méthode employée par le hacker.
Par exemple, soit j'attaque la protection du produit, et là ça ne amrceh que
pour ton produit ou, bien plsu dangereux, j'attaque le produit qui t'a servi
à protéger... AMHA la seule solution est d'utiliser des trucs qui prennent
un temps abyssal à détourner et qui coûtent trop cher en temps pour oser s'y
lancer.

Arnold, tu devrais nettoyer ton clavier de temps en temps, il doit y
traîner des monceaux de rats crevés. Ou alors tape moins vite. Je n'ose
croire que tes inversions sont un dispositif subtil de cryptage.

Il va de soi que je n'utilise aucun produit servant à protéger. Je me
dois de maîtriser la chaîne d'un bout à l'autre. Remarque, je me suis
déjà servi d'un dongle, mais dans mon cas ça n'aurait pas servi à
grand-chose au hacker de bricoler les fonctions d'accès au dongle
fournies par l'API du fabricant. Un dongle, c'est juste un bout de
flash-RAM qu'il faut considérer comme virtuellement accessible au
hacker. Faire confiance à son inviolabilité est une grosse erreur. Mais
on peut tout de même se servir de cette mémoire locale à bon escient.

Non, ça c'est faire peu de cas des hackers professionnels.

Je ne pense pas intéresser ceux-là, de toute façon. Ni la NSA a
fortiori. Donc j'essaie de rester réaliste.

Ou introduire des erreurs de fonctionnement aléatoires et fluctuant avec le
temsp, ça, c'est bien plus pénible :-).

Oui oui, je vais pas détailler, mais la seule limite est l'imagination.
ET on va ajouter la légalité pour la bonne forme.

Pour casser ce genre de protection, je vais commencer par lister l'ensemble
des fonctions de ton soft et faire un audit de leur fréquence d'appel, avec
état de la pile, état des exceptions (vive les SEH...). je vais vite voir
les fonctions du logiciel, celles qui servent à son fonctionnement, et
celles qui sont appelés suivant des conditions : flags, checksums, timers,
etc.

Je me suis mal expliqué. Si j'écris des fonctions de protection F1, F2,
etc., en fait ce ne sont pas des fonctions au sens classique, mais des
algos dont la séquence est éclatée. Le contenu de ces algos est très
largement grossi, puis disséminé. Par exemple, la ligne 1 de l'algo F2
est contenue dans une fonction normale genre "Fichier / Ouvrir" et n'est
exécutée que selon que mon moteur d'incrémentation est dans le bon état.
Ce qui veut dire que le code de l'algo F2 n'est pas écrit en séquence
dans une fonction appelée, mais que ses lignes sont disséminées un peu
partout sans aucune séquence, précédées d'un ou plusieurs tests pour
faire en sorte que la ligne N+1 de l'algo ne puisse pas être exécutée
avant la ligne N. La séquence n'est donc globalement exécutée qu'au
hasard du travail de l'utilisateur ou à la rigueur de paramètres
d'environnement (et le pompage des messages Windows donne assez de grain
à moudre pour créer un moteur).

Pas d'appel de fonction, donc. Seulement des lignes de code disséminées.

Le talon d'Achille de ce truc, c'est que le hacker peut bloquer le
moteur d'incrémentation. Il est donc nécessaire que ce moteur utilise
beaucoup de possibilités parallèles et beaucoup de variables (globales
ou autres) pour en noyer le mécanisme. Quand je dis "beaucoup", ça veut
dire des dizaines. Pour noyer encore un peu, c'est amusant de bricoler
inutilement ces variables ça et là dans le code quand elles ne sont pas
actives, histoire de rendre la jungle encore plus touffue. Par exemple,
j'utilise une variable entière V qui change d'état tout le temps, sauf
qu'elle n'est prise en compte par le moteur d'incrémentation que sa
valeur est impaire, ou un truc du genre. Je peux m'acharner sur V tant
que je fais attention à sa parité. Ou alors, le moteur change de
variables à mesure qu'il avance, de nouvelles variables prenant le
relais des anciennes, mais on continue de bricoler au passage sur les
variables devenues obsolètes, juste pour le fun. Du code inutile, ça
brouille encore la piste.

Oui, c'est un procédé classique, que l'on complexifie d'ailleurs avec
quelques layers d'obfuscation aléatoire en général. Bien implémenté, c'est
très long et pénible à casser. Souvent, on va plutôt chercher à désactiver
l'appel de la fonction de vérif plutôt que de détourner le code disséminé
d'ailleurs :-).

Pas d'appel, donc. Par exemple, si j'ai un numéro de licence à
contrôler, il faut qu'il y ait une vérification classique au lancement
du soft, mais aussi des vérifications dont le code est disséminé. Je
commence par transférér tout ou partie de ma clef dans diverses
variables qui vont se renvoyer ensuite des balles dans tous les sens, et
je lance mes moteurs d'incrémentation pour les divers algos de vérification.

Si le loup a été détecté, idem, ce sont juste des variables globales qui
vont communiquer entre elles à mesure de l'avancement du moteur, jusqu'à
l'action finale et selon la nature de celle-ci.

En résumé, imaginons qu'on ait un algo à 3 lignes L1 L2 et L3, et trois
variables globales int V1, char V2[10] et void* V3. Au lancement, on
initialise V1000, V2="MX4HZAODC1" et V3 à une adresse quelconque, par
exemple celle d'une autre variable globale. Dans la fonction qui traite
EV_WM_MOUSEMOVE, on divise V1 par la position Y de la souris. Dans celle
qui traite EV_WM_LBUTTONDOWN, si V1==0, on exécute L1 et on fait passer
V2[6] à '0' (zéro à la place de O majuscule). Dans la fonction qui
traite EV_WM_MOUSEMOVE, à nouveau, si V2[i]<64 (avec i comme par hasard
arrivé à 6), on exécute L2 et on fait V3=NULL. Enfin, dans la fonction
qui traite EV_WM_KEYDOWN, si on a V3==NULL, on exécute L3. Etc.

Aucun appel de fonction de protection, et si les lignes L1 L2 L3 sont
toutes exécutées, ce sera en séquence. Patience et longueur de temps...

Evidemment, dans la pratique, je fais beaucoup plus compliqué pour
l'incrémentation et pour les tests sur les variables, avec un maximum
d'intrications.

D'abord, parce qu'en France on préfère la sécurisation par la dissimulation
du savoir.

Voir l'affaire Humpich.

Le truc encyclopédique; du buffer overrun au virus métamorphique avec code
recompilé en mémoire.

Je vois toujours pas l'intérêt d'un code recompilé en mémoire par
rapport à un cryptage.

Je n'insulte que les comportement imbéciles et encore, étant du Sud, c'est
plsu à prendre avec humour qu'autre chose.

Oh Toulouse, même les mémés aiment la castagne...

Tiens, dans le sud-ouest, on ponctue les phrases avec "cong" (par
exemple "y fait beau, cong"). Mais dans ma région - qu'est la plus belle
du monde - c'est plutôt "y fait beau, putaing". Ce qui veut dire qu'à
Marseille, on a le cul entre deux chaises et on dit "y fait beau,
putaing-cong".

Jeu de mot subtil ! L'obfuscation c'est rendre le
fonctionenment/déroulement/logique de ton code incompréhensible.

Ah marrant, comme M. Jourdain faisait de la prose sans le savoir, j'ai
donc fait de l'obfuscation sans même savoir que ça existait. Et moi qui
croyais avoir inventé quelque chose...

PS / Au fait, utiliser des fonctions inline, ça aide pas ?