Discussion :

[pierre987321]

bonjour suite a votre aide sur le forum j'avais réalisé un cryptage en MD5 avec + une clé pour réalisé les cryptage d'une donné atribué aux utilisateurs.

aujourd'hui une personne a cracké mon soft et se les approprié.
je v faire un truc béton, pouvez vous m'aider ?


sur la version en se moment il y a un changement de donné style "replace" par
une donné fixe (intrégré au soft) puis un cryptage en MD5.

que pensez vous ?

[Mihalis]

moi ce que je fais généralement c'est dans les codes des données fixes, betement une constante du style l'adresse ip du client ou des choses du genre qui ne sont adaptées uniquement au client

[droggo]

Qia,

moi ce que je fais généralement c'est dans les codes des données fixes, betement une constante du style l'adresse ip du client ou des choses du genre qui ne sont adaptées uniquement au client

C'est typiquement le genre de protection qui se cracke en quelques minutes au plus.

[pierre987321]

la valeur a la base est un id atribué a l'enregistré,
cette idé subi un "replace" sur un élément par un autre qui
est fixe dans l'exe.
puis le tout est crypté en MD5.

Puis je pense que la lamerz a réalisé un saut de string puis une modif pour se faire afficher le passe. car une foi enregistré, le passe de l'enregistré est montré pour évité d'etre perdu.

qu'est il possible de faire pour mon histoire ?
j'ai bien des idées mais bon, je doute ! !


ps : avec un générateur de code aléatoire pour etre une clé ?

[Mihalis]

Qia,

C'est typiquement le genre de protection qui se cracke en quelques minutes au plus.

tout dépend de ce que tu fais...

[Mihalis]

le problème avec le md5 c'est que c'est connu de tout le monde et qu'on connait egalement la commande pr executer l'inverse,a la limite tu cryptes toi meme

[droggo]

Goa,

le problème avec le md5 c'est que c'est connu de tout le monde et qu'on connait egalement la commande pr executer l'inverse

Là, j'ai un sérieux doute.

Que dis-je, une certitude : actuellement on ne sait pas, et on ne pourra jamais faire la fonction inverse d'une fonction de hash, quelle qu'elle soit (sinon, merci la compression. Exemple avec md5 : résultat sur 16 octets, quelle que soit la taille de la source. Donc si taille source = 6 Go par exemple, cela voudrait dire qu'on peut compresser 6 Go dans 16 octets, et retrouver le contenu de ces 6 Go. Bravo, ce serait utile pour stocker nos données ).

Ce que tu as voulu dire est qu'on peut trouver une entrée qui donne la même valeur de hash, mais actuellement on ne sait pas faire non plus.
On sait créer des entrées différentes donnant le même hash, mais pas trouver une entrée donnant un hash imposé.

[defluc]

En ce qui me concerne, je pars du principe qu'on donne beaucoup de chance au cracker en utilisant des algoritme publics.

Un bon nombre "d'amateurs" seront déjà découragés pas des algoritmes de cryptage et de décryptage perso.

[Okaryn]

Tu auras beau faire tous les algorithmes que tu souhaites pour crypter ton mot de passe, il sera toujours facile de le sauter. Soit en retournant toujours un test OK, soit en attribuant un hash connu à la place de celui de l'utilisateur.

Si tu veux vraiment sécuriser tes données, il faut que tu les cryptes par rapport au mot de passe. Cela implique de recrypter TOUTES les données à chaque changement de mot de passe.

Ainsi, même si l'utilisateur retourne un test OK au moment de la vérification du mot de passe, la clef de décryptage des données ne sera pas bonne et les données lues seront n'importe quoi.
S'il injecte un hash MD5 connu à la place du mot de passe actuel, même résultat : la clef sera fausse pour le décryptage.

Bien sur, tu peux utiliser comme clef de cryptage un autre hash au lieu du mot de passe en clair.

Voici un programme que j'ai réalisé utilisant ce principe :
http://okaryn.free.fr/forum/viewtopic.php?id=25

[pierre987321]

oui c claire

a votre avie pour ma nouvelle version ?

[defluc]

Si le cryptage intègre une ou plusieurs variables telle que le nom de la machine et de l'utilisateur, il sera différent à chaque installation.

[Okaryn]

a votre avie pour ma nouvelle version ?

Ca ne te convient pas ce que je t'ai indiqué ?

Si le cryptage intègre une ou plusieurs variables telle que le nom de la machine et de l'utilisateur, il sera différent à chaque installation.

A déconseiller totalement. En cas de changement de machine, de nom d'utilisateur ou quelque autre paramètre non interceptable, toutes les données existantes seront perdues car impossible à convertir à postériori.

[Gaadek]

Dans tous les cas, le premier point à faire est de protéger le soft contre la décompilation.

En gros, vous aurez beau utiliser tous les moyens de cryptage d'un mot de passe, si vous faites de simples tests de comparaison, et bien en décompilant, on trouve les sauts (= les tests), on skip l'opération, et la vérification n'est plus effectuée. C'est entre guillement la base du hacking, à savoir trouver l'endroit où une comparaison est réalisée pour ensuite la désactiver.

Une idée serait de tenter de protéger l'exe de ce type d'opération (décompilation).

Ensuite, pour l'identification, le mieux est encore d'utiliser une identification sur un serveur web.

Sinon, un topic déjà important sur le sujet existe...

[pierre987321]

oui, le lamerz ma confirmé que c'est bien avec juste un saut.
au moment de comparaison.

j'aime bien ton idée de protéger son EXE, mais comment faire ?
ou bien un lien ?

p tu m'expliquer le systeme de saut ?
car pour moi il y a un

if (comparaison)
begin
---non
end
else
begin
---oui
---visualisation de la clé
end

car apres le saut il y a en gros la visualisation de la clé


j'ai entendu parlé aussi de compréssion d'EXE, mais j'ai jamais rien trouvé,
tu as qulque chose sur sa ?

[Okaryn]

Même en protégeant de la décompilation, il suffit de réaliser un résident qui intercepte les données. C'est une méthode qui est déjà utilisée pour cracker certains programmes protégés.

Ce n'est certes pas à la portée de tout le monde, loin de là...

La méthode de cryptage de données en plus du mot de passe ne te convient pas ?

Pour le système de saut, il remplace dans ton programme if (condition) par if true (ou if false selon ton test)

[pierre987321]

si bien sur, mais je vai tester plusieurs systeme et si possible
les associers entre eux.

franchement, il ma gonflé se lamerz :-(


comment faire pour mes questions ci-dessus ?

[Clorish]

J'ai reflechi au probleme a plusieurs reprises pour nos propres softs.
J'ai trouver quelques pistes type bidouille a bibi a adapter, combiner, ameliorer ...

Le tout est de rendre bien casse bonbon le systeme de hacking.

- Si tu code une donnée, genre mot de passe multiplie les algoritmes et la succession. PAr exemple stocke le cryptage MD5 du CRC32 du mot de passe.
Si l'utilisateur comprends que le mot de passe est crypté MD5, et qu'il injecte "MonMotDePasse" crypté MD5 a la place du tiens quand il rentrera son passe, tu calculera le CRC32 codé MD5, qui generera forcement une chaine MD5 differente de celle rentree par l'utilisateur.
Detecter le nombre et le type d'appels est plutot fastidieux a mon avis.

- Ensuite tu peux gerer le decryptage temporellement et sequentielement.
PAr exemple calculer le CRC32, laisser tourner l'application plus au bout d'un certain temps (timer) calculer le MD5 de cette somme et activer definitivement le logiciel. de meme, si tu doit comparer 2 valeurs, compare les dans le temps bout par bout

- E ncombinant les 2 methodes, tu peux par exemple dans un premiertemps coder en CRC32 puis MD5 le mot de passe, comparer les bits 1 4 et 8 puis plus tard calculer le MD5 puis le CRC32 et tester les bits 5 et 6, etc ....

- Ensuite plutot que de bloquer completement l'application, il serait peut etre plus judicieux de la paraliser completement.
Par exemple dasn le constrcuteur de certains objets principaux, faire appel a des methodes d'objets globaux dispatchées un peu partout dans le code dont le but n'est pas de faire du traitement mais de generer une exception (EAccessViolation) car non instancié. L'instanciation de ces objets se faisant au fil de la validation.
Une exception dans un constructeur genere une destruction de l'objet.
Donc l'objet utilse qui etait en cours de creation sera detruit donc plantera l'application. Catch l'exception lors de la creation de l'objet reel pour eviter une remontee de l'erreur .....

Que dire de plus .... Multiplie un max le genre d'idee bien sadique l'utilisation de donnees aleatoires (changeant a chaques executions, et multiplie les fausses pistes ... (calculs de mots de passes qui ne seront jamais testé)

Et ne pert surtout pas de vue que la plupart des super-protecs se resument bien souvent a un simple "IF Super-Protec Then" ......

[darkvadr]

Salut,
bon je confirme: 1) on ne reverse pas un hash MD5 car ce n'est pas du cryptage mais une signature.

2)Par contre on peut trouver une collisison (c'est a dire une autre mdp par exemple qui a le meme MD5)

Mais lorsqu'on carck un logiciel, c'est assez rare qu'on s'attaque a un hash MD5
A priori tu auras du mal a embecher une team de te cracker si vraiment ils veulent pourtant on a bien vu avec starforce que le travail peut etre suffisement enorme pour prendre plusieurs annes.

Alors voici quelques idées en vrac:

Packer le programme est une assez bonne idée (ca enerve toujours), surtout s'il y a cryptage (crypter l'IAT ca enerve aussi) mais bon utiliser un packer connut ne te protegera que 4 secondes. Il te faudra faire preuve d'imagination et coder ton propre packer

Verifier la presence de debuggers en utilisant plusieurs methodes et eviter par exemple d'utiliser l'API IsDebuggerPresent en l'emulant par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
function IsDebuggerPresent: boolean; stdcall;
asm
  MOV     EAX, DWORD PTR FS:[$30]
  TEST    EAX, EAX
  JS      @@W9X
@@WNT:
  MOV     ECX, FS:[$18]
  MOV     ECX, DWORD PTR [ECX+$30]
  XOR     EAX, EAX
  MOV     AL, BYTE PTR [ECX+2]
  RET
@@W9X:
  MOV     EAX, DWORD PTR [$BFFC9CE4]
  MOV     ECX, DWORD PTR  [EAX]
  CMP     DWORD PTR DWORD PTR [ECX+$54], 1
  SBB     EAX, EAX
  INC     EAX
  RET
end;

cette emulation est tres connue mais a toi de faire de l'obscurfaction dessus.

Un truc pour eloigner les amateurs qui ne debug pas en deadline. Bref les utilisateurs de tracers genre ollydebug... Mettre des timeout dans les fonctions critiques (comme ca lorsque on interromp le process pour le tracer, on sort en timeout et on reboot l'ordi par exemple)

Ne jamais utiliser des boites de dialogue genre "Bravo bon mdp" ou encore "mauvais mdp"

Construire un driver (.sys) qui va tourner en ring0 et va se charger de la securité (y a plain de crackers qu'aiment pas le ring0)

faire de l'obscurfaction en ajoutant des milliers de lignes de code inutiles.

Ajouter des CRC

avoir une ou deux "fake dll" par exemple qui peuvent servir a un .sys pour reconstruire l'executable d'origine si il y a eut modification via un XOR par exemple (genre .exe XOR fake dll1 ---> fake dll 2 donc fake dll 1 XOR fake dll 2 = .exe)

faire .exe coquille vide et aller telecharger sur internet le code efficace a l'interieur a chaque lancement (cryptage et tout).

Etc...

Tout faire en meme temps!

Ou liberer ton source!
GPL rulez

J'ai quelques liens si tu veux, mais tu vas passer plus de temps a proteger qu'a developper et y'a des acaharnés de l'autre coté...

[femtosa]

En ce qui me concerne, je pars du principe qu'on donne beaucoup de chance au cracker en utilisant des algoritme publics.

Un bon nombre "d'amateurs" seront déjà découragés pas des algoritmes de cryptage et de décryptage perso.

Au contraire ! Aucun cryptage ne résistera si tu te base uniquement sur le secret ! Quelqu'un trouvera ton secret tôt ou tard (et plutôt tôt aujourd'hui ... ).

C'est prouvé, les algorithmes les plus dur à casser sont les algorithmes publique (AES, RSA, ...) (C'est une des règles de base, on doit pouvoir fournir l'algorithme sans que sa solidité en soit modifier)

[darkvadr]

Au contraire ! Aucun cryptage ne résistera si tu te base uniquement sur le secret ! Quelqu'un trouvera ton secret tôt ou tard (et plutôt tôt aujourd'hui ... ).

C'est prouvé, les algorithmes les plus dur à casser sont les algorithmes publique (AES, RSA, ...) (C'est une des règles de base, on doit pouvoir fournir l'algorithme sans que sa solidité en soit modifier)

+1 c'est evident... Je veux dire que c'est meme la base de la crypto. Un algo n'est fiable que s'il reste fiable une fois publique. La securité ne doit pas tenir sur le fait que l'algo est inconnut car très vite il sera reversé et connut. Sa fibailité doit tenir uniquement sur des principes mathematiques solides. Autemant dit un algo est fiable si est uniquement si en possedant 1) l'algo, 2) le resultat de chiffrement par l'algo, il reste impossible de trouver la clef (autrement que par un brute force) et donc le message clair.

Le brute forcing est vite hors de portée si la clef est grosse.

Reste qu'on peut TOUJOURS avoir de la chance.

P.S faire un petit tour du coté de la factorisation de grands nombres premiers pour comprendre.