####################################################################### ####################################################################### ## ## ## III)Comment mieux securiser se programme et source code a l'appui ## ## ## ####################################################################### ####################################################################### Bon voila la partie qui interressera surement le plus le programmeur de super client... Comment securiser efficacement son programme pour eviter que les crackers un peu plus experimente que ceux de caramail le crack... (note: aucune protection n'est infaible, ca depends souvent du temps que l'on passe dessus sois pour la programmer , sois pour la deplomber...) Elle sera surement inneficace contre des crackers qui ont des heures de vol dans le cracking ;) Mais calmera surement des tonnes de ptit crackers... Je l'essairais juste pour le fun mais etant donné mon experience dans la matiere ya de grande chance pour que je parvienne a cracker la nouvelle protection sans trop de problemes (c'est pas de la vantardise mais juste pour ne pas donner de fausse iddées aux programmeurs...) C'est partie : ###################################################### 1 - Il faut choisir un meilleur Crypteur d'executable. ###################################################### En effet , comme vous avez surement pu le constater le decryptage de l'executable est un jeu d'enfant... Il faut utiliser un packer qui donne du fil a retordre au cracker , qui ne soit pas decryptable par procdump et qui donne quelques taches a faire sur le PE. c'est a dire realigner les sections , ajuster l'import table... Je conseil meme de crypter plusieurs fois l'executable et meme d'utiliser 2 packers differents... De renommer le nom des sections en autre choses pour ne pas donner d'indices sur le packer. ET de virer la signature du packer. Quand on edite en hexa decimal on voit souvent: UPX X.XX ou ASPACK.... C'est la signature du packer , ici on voit bien que les packers utilises sont UPX ou bien ASPACK... Une idée serait de changer la signateur en un autre packer connu pour embrouiller... UPX et ASPACK 2000 sont trop simples a unpacker.. Quoi que ascpack2000 posent pas mal de problemes aux newbies cracker, il peut etre util car il compresse beaucoup.. L'utilisation d'une des dernieres versions d'armadillo peut etre utiles aussi... J'ai pas regarder les dernieres versions , mais les premieres etaient tres interressantes à decrypter.. Et largement suffisent pour casser les petits reversers... PEshield, PEcrypt sont pas trop mal aussi.. PElocknt est un des packers que je n'ai jamais reussi a unpacker.. Le code est completement chelou ;-) voila l'auteur n'a plus qu'a s'amuser :) un petit coup de Pelocknt peut s'averer tres efficace :) #################################################### 2 - Il faut utiliser des protections anti Soft ice.. #################################################### Comment ?! Il faut programmer une ou plusieurs detections de soft ice afin d'empecher l'utilisation du programme en presence du debuggeur... Il faut saovoir qu'il existe des programmes qui permettent de rendre soft ice indetectable mais il y a toujours moyen de le detecter ;-) Tout d'abord voici 2 methodes tres répendus qui seront efficace contre les crackers wannabes ;) ************* ************* * Melt ice: * ************* ************* La méthode utilisée pour détecter Soft-ice est la suivante: il utilise l'API createfilea "afin de détecter le VXD" ! Désolé, je ne sais pas trop comment expliquer: il peut détecter Soft-ice avec: SICE, SIWVID pour win9x et NTICE pour winNT BOOL IsSoftIce95Loaded() { HANDLE hFile; hFile = CreateFile( "\\\\.\\SICE", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if( hFile != INVALID_HANDLE_VALUE ) { CloseHandle(hFile); return TRUE; } return FALSE; } Sachant que borland c++ ressemble a delphi voici 1 exemple en Delphi de comment programmer ca: ********************************************************************************* procedure DetectICE; var ACiD:Thandle; s,s2:string; begin s:='\' + '\' + '.' + '\' + 'S' + 'I' + 'C' + 'E'; s2:='\\.\SICE'; if s <> s2 then begin ShowMessage('il est interdit de patcher'); ExitProcess(0); end ; ACiD:=CreateFileA(PChar(s2),GENERIC_READ or GENERIC_WRITE,FILE_SHARE_READ or FILE_SHARE_WRITE,nil,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0); if ACiD <> INVALID_HANDLE_VALUE then begin ShowMessage('Veuillez dechargez le debuggeur svp!'); ExitProcess(0); end ; s:='\' + '\' + '.' + '\' + 'N' + 'T' + 'I' + 'C' + 'E'; s2:='\\.\NTICE'; if s <> s2 then begin ShowMessage('il est interdit de patcher'); ExitProcess(0); end ; ACiD:=CreateFileA(PChar(s2),GENERIC_READ or GENERIC_WRITE,FILE_SHARE_READ or FILE_SHARE_WRITE,nil,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0); if( ACiD <> INVALID_HANDLE_VALUE ) then begin ShowMessage('Veuillez dechargez le debuggeur svp!'); ExitProcess(0); end; end; ****************************************************************************** Donc , ici j'ai rajouté un control sur le string '\\.SICE' qui permet de controler si un petit malin n'a pas modifier avec un editeur hexa decimal cette partie et donc ca annulerais la detection... Si quelqu'un patch, le programme envoi un message et se ferme automatiquement... On peut aussi bien planter la machine apres un certain nombre d'essai en ecrivant une valeur dans la base de registre... A chaque fois que le debuggeur est chargé, il controle le nombre, et si il est deja a son maximum, on appel une sous routine qui plante le PC , sinon on incremente la valeur et on quite.. Pour planter le PC on peut utiliser le bug : "C:\con\con" c'est a dire que l'on execute ce fichier la... En visual basic: shell "c:\con\con\",vbHide Sinon quelques ligne en ASM permettent un BSOD (blue screen of death) ou meme le freeze complet de la machine. ************************** ************************** * détection par INT 68h: * ************************** ************************** mov ah,43h int 68h cmp ax,0F386h jz Soft_ice_est_la_:P Voilà à quoi ressemble le monstre ;P Un petit exemple de programmation en Delphi : ***************************************************************************************** procedure INT68; label Ure_Good_Guy; label I_Got_You; Begin asm mov ah,43h int 68h cmp ax,0f386h jz I_Got_You jmp Ure_Good_Guy end; I_Got_You: showmessage('Soft-ice est chargé!!'); Ure_Good_Guy: // Gentil lol pas de Soft-ice (ou je me suis fait cracker *g*) end; end. ****************************************************************************************** Biensur dans ces deux exemples , j'ai mis un texte comme quoi soft ice est chargé, mais c'est pour montré à l'auteur ou se passé le code qui suit la detection de soft ice... Il est plus que recommandé de ne rien mettre comme message car le message facilite le travail du cracker. A la rigeur un message mais Crypté, mais qui n'appel pas les API MessageBoxa car sinon le cryptage n'est d'aucune utilité lol :) Maintenant voici une idée de detection de soft ice: Tout le monde (enfin presque .....) connait la commande MsDos "MEM". elle permet d'afficher des informations sur la memoire. on met /C pour voir toute les infos donc si je tape "MEM /C" a l'heure actuelle on voit: ------------------------------------------------------------------------------ Modules utilisant la mémoire sous 1 Mo: Nom Total Conventionnel Mémoire haute -------- ---------------- ---------------- ---------------- MSDOS 20 320 (20K) 20 320 (20K) 0 (0K) GSCDROM 26 016 (25K) 26 016 (25K) 0 (0K) CDROM 21 648 (21K) 21 648 (21K) 0 (0K) DISPLAY 18 064 (18K) 18 064 (18K) 0 (0K) HIMEM 1 120 (1K) 1 120 (1K) 0 (0K) DBLBUFF 2 976 (3K) 2 976 (3K) 0 (0K) IFSHLP 2 864 (3K) 2 864 (3K) 0 (0K) win 3 936 (4K) 3 936 (4K) 0 (0K) KEYB 6 944 (7K) 6 944 (7K) 0 (0K) WINICE 13 520 (13K) 13 520 (13K) 0 (0K) vmm32 5 504 (5K) 5 504 (5K) 0 (0K) COMMAND 7 536 (7K) 7 536 (7K) 0 (0K) -------- 80 (0K) 80 (0K) 0 (0K) LIBRE 524 592 (512K) 524 592 (512K) 0 (0K) Résumé mémoire : Type de mémoire Totale Utilisée Libre ---------------- ----------- ----------- ----------- Conventionnelle 651 264 126 672 524 592 Supérieure 0 0 0 Réservée 0 0 0 étendue (XMS) 65 994 752 2 002 944 63 991 808 ---------------- ----------- ----------- ----------- Mémoire totale 66 646 016 2 129 616 64 516 400 Total inférieur 651 264 126 672 524 592 Totale Paginée (EMS) 64 700 416 (62M) Mémoire libre paginée (EMS) 16 777 216 (16M) Taille maximale du programme exécutable 524 576 (512K) Taille max. de la mémoire supérieure libre 0 (0K) MS-DOS réside en mémoire haute (HMA). ------------------------------------------------------------------------------ Okie, donc la dans la liste des noms on voit bien le petit: WINICE. Cela veut bien dire que soft ice est chargé en memoire non ?:) La maneuvre pour detecter soft ice c'est d'executer MEM mais d'envoyer le resultat dans un ficher.. Comme tout les utilisateurs de DOS le savent , on peut faire ca de la maniere suivante: fichier.exe ou com >fichier.txt Donc ici cela donne par exemple: MEM /C>c:\windows\system\detect.txt Donc , cette commande ecrira le resultat de la commande "MEM /C" dans le fichier "detect.txt" lui meme placé dans le repertoire windows\system (c'est quand meme moin flague que la racine du disque dur non ? ) si la commande vous donne un erreur 2 ou 4 il faut créer un fichier bat et ensuite l'executer.. Bon ca c'est tres simple... Ensuite vous avez plus qu'a effectuer une recherche dans le fichier "detect.txt" et cherchez le mot "WINICE" dedans.. Si le mot est presant alors soft ice est chargée!!! on ferme le programme. Sinon soft ice est pas la , donc on lance notre application... Vous avez plus qu'a automatiser ces taches et vous avez une detection de soft ice qui n'est pas encore reconnu a ce jour ;) #################################################### 3) Utiliser un algo beaucoup plus puissant! #################################################### Bon comme vous l'avez vu , l'algo de ce programme est vraiment faible... Ce qui peut etre interressant c'est d'ecrire un algorithme qui sois ireversable... Comme le DES, MD5... Je m'explique, pour cracker l'algo je l'ai tout simplement renverser c'est a dire que a la place des additons , j'ai mis des soustractions... Il faut utiliser des operateurs qui ne sois pas renversable, ou sinon une suite d'operateur qui fasse que l'on ne puisse pas retrouver la chaine non cryptée de depart a partir du resultat obtenu (resultat cryptée). Le programme pour verifiez si le code est bon n'a qu'a crypter ce que l'on entre et comparer avec la constante cryptée dans le programme.Si les deux sont identiques le CODE est bon sinon perdu... Ce qui est chiant c'est que celon l'algo different CODE entré peuvent avoir le meme resultat crypté donc on doit rajouter des controles sur la longueur du CODE , la somme des valeurs ascii.. Ca sert a quoi me direz vous ? Ben tout simplement que la seule facon de casser ce code est de coder un brute forcer pour essayer toute les possibilites jusqu'a trouver le bon CODE... C'est Tres long !! Deja, il faut reprogrammer le crypteur dans un language rapide : Assembleur ou c++ ( l'asm est bcp plus rapide que le C++) et de mettre une fonction qui essai tout les chiffres , caracteres ... On n'a plus qu'a laisser tourner lol :=) Bon , si c'est mal implementer on peut cracker ca plus rapidement.. je rappel que les XOR sont renversables: X xor X = 0 A xor B = C A xor C = B B xor C = A L'utilisatisation des puissances et des modulos est tres interressants dans ce type de cryptage. Sinon , on peut faire un algo qui calcul un CODE en fonction de la chaine entrée et verifie si le Code est bon en comparant le CODE obtenu par le calcul avec la CODE du bon mot de passe... Cette fois si, ce n'est pas vraiment du cryptage mais juste des calculs... Je vous conseil de faire un algo long est penible pour le cracker... Plus il y a d'operations dans l'algo et plus le temps qu'il faudra pour deplomber le protection est long. J'ai ecris une protection en Delphi qui a ce jour n'est toujours pas cracker.. ACiD BuRN's Challenge. L'algo est tres complique , fait plus d'une centaine de ligne en Delphi donc enormement plus en Assembleur.. Meme avec les sources , je suis incapable de le cracker :-p hehe, donc voila tout est dis. Voici a quoi ressemble mon algo : (je met juste 2 lignes de l'algo , il en contient 100 du meme style lol) ------------------------------------------------------------------------------------------ b:=b+c*a*345 xor (3423483+(a*242564 mod c)); key6:=copy(inttostr(abs(strtoint(key6) xor z2 shl strtoint(key2))),length(key6)-4,3); .............. ------------------------------------------------------------------------------------------ C'est pas une seule addition donc :) hehehe... Sinon , l'auteur peut obter pour un code qui depend du nom de la personne.. La aussi il faut faire gaffe a l'algo. Deja faire un code qui depends du numero du disque dur est une bonne idée hehe. Faire que le programme vous donne une valeur calculé en fonction du disque dur du mec. Celui qui desire s'enregistrer donne ce numero, et son nom ( ou pseudo). La avec un programme a part , vous generez le code valide pour ces informations et les renvoyes au mec! Il ne poura pas donner son code a ses amis car le numero depend du disque dur hehe ;) L'algo ne doit en aucun cas faire moins de 10 lignes , a part si c'est une sorte de cryptage compliqué.. Pour exemple , la derniere protection que j'ai ecrite en C++ avec assembleur inline fait 1400 lignes d'assembleur... Avec des Matrices.... Il ne faut pas avoir peur de coder :) Il faut aussi eviter que le code valide soit comparer directement avec le code entré par la personne car c'est trop facile a cracker ca :-p Un peu de maths et de cryptage devrait arranger l'affaire :) #################################################### 13 conseils en vrac #################################################### 1) Ne jamais utiliser de fichiers avec des noms qui veulent tout dire comme : CodeEnregistrement.txt ou meme des procedures avec des noms comme : BonCodeOuMauvaisCodeVerif 2) Attendre un peu avant de dire a l'utilisateur qu'une violation de son programme a été faite... 3) Utiliser des checksums ou CRC dans les executables et Dll... ( ou tout autre fichiers sensibles) 4) Faire des pauses d'une ou deux secondes apres que le code est été entré pour eviter le brute forcing directement par le programme lui meme ( modifié par le cracker) 5) Enregistrez les numeros de serie dans des places non communes ( pas dans le fichier INI , ou dans la base de registre) 6) Enregisrez les numeros de serie a plusieurs endroit different. 8) Controlez les numeros de serie a different endroit du programme et aleatoirement dans un des endroits ou il est placé. 9) Utilisez des anti debuggeurs , sans avertir l'utilisateur que vous avez detecté quelque chose et fermez tout au bout de quelques secondes apres le chargement.. (c'est contre les petits crackers ca.) 10) Utilisez des chaines de caracteres qui ne servent a rien mais avec des noms qui sont allechant: "le numero de serie incorrecte" "Merci de votre soutiens" "Vous etes desormais Enregistré" Placez ce genre de phrases dans une variable de type string et n'y touchez plus , ces phrases seront visibles au cracker si il desassemble l'executable et se croira en presence de choses importantes alors que se ne sont que des Leures! lol 11) Flooder le cracker avec des fausses procedures de cryptage qui sont des leures.. 12) faites references a des fichiers manquant qui ne servent a rien : Licence.key. Faites des operations sur ce fichier , mais qui n'amenent a rien dans l'enregistrement de l'application le cracker se croira en presence d'un keyfile. 13) Crypter vos executables avec un bon packer pour eviter le simple patching mais cela n'empeche pas le Loader patcher... Evitez les vielles versions de Aspack , UPX ( toutes versions) , Petite , PEcrypt .. Je pourais vous donnez des centaines de conseils mais ceux la sont assez importants et eviteront que vous vous fassiez cracker par pal mal de crackers debutant ou pas assez "bons".. Voila ce cours arrive a sa fin et j'espere que vous l'avez apprecié autant que moi ... -¤)-[ tHE ANALYST ]-(¤- ^^^^^^^^^^^^^^^^^^^^^^^