PureBasic

T'aurai du poser un brevet sur ta disquette trouée, ...

Dobro>Cool!

Contrairement à ce qu'on pense, je trouvais que les disquettes 5p1/4 étaient largement plus résistantes que les 3p1/2, et bien plus pratiques à ranger!

Et puis c'est vrai que pour le freesbee, c'était top, à part que ça n'allait pas très loin!

à part que ça n'allait pas très loin!

je depassais les 30 Metres !!

Dobro a écrit :

à part que ça n'allait pas très loin!

je depassais les 30 Metres !!

Spa possible! Tu les alourdissais au plomb, ou tu les trempais dans du mercure c'est ça?
Moi je suis plus fort au lancer de PC

julien a écrit :Oui mais tu ne peut plus faire de test d'intégrité sur l'exe

Je sais pas comment tu fais tes tests d'intégrité mais si ton exe est intacte et que tu changes une valeur, tu n'as mettre a jour la "valeur" qui te permet de vérifier l'intégrité, nan ?

Dri

Une petite question :
Quand on compresse plusieurs fichiers en un ZIP, et qu'on le protège par un mot de passe. Que vaut réellement cette protection face aux hacker

je sais qu'il existe un programme "Brute Force pour les zip"
mais c'est vrais que si l'on met un grand mot de pass
la recherche peut durer longtemps !!
Maintenant il faudrai qu'un pirate nous repondes ?

Dobro a écrit : Maintenant il faudrai qu'un pirate nous repondes ?

sans insultes !!!

Dobro a écrit :je sais qu'il existe un programme "Brute Force pour les zip"
mais c'est vrais que si l'on met un grand mot de pass
la recherche peut durer longtemps !!
Maintenant il faudrai qu'un pirate nous repondes ?

Si ton programme recherche le mot de passe en balayant toutes les possibilités, face à une clé de 20 caractères on peut dormir tranquille
Est-ce possible qu'un pirate arrive à décrypter la clé Au lieu de pirater le ZIP, je pense qu'il vaudrait mieux qu'il pirate le programme qui sert à lire le ZIP... Existe-t-il des programmes qui ne demandent jamais le mot de passe ? Là est la question

oui ! c'est vrais ! mais un zip codé par un mot de pass en en realité un
zip encodé avec le mot de pass , chaque characteres du mot de pass va servir pour modifier chaque octets du zip ! donc sans mot de pass
le zip n'est rien qu'un amas d'octet sans signification !
du moins c'est comme ça que je l'ai compris !

maintenant c'est vrai que certaines image cochonne des magazine sont aussi encodé avec un mot de pass, ça na pas empeché de trouver la faille
et qu'il existe des soft capable de les decoder sans mot de pass !
mais bon les image c'est les trois quart du temp du Xor donc "facile" pour un expert a retrouver (la methode a ete donnée dans PirateMag)

pour ce qui est du ZIp , c'est beaucoup plus difficile !
d'ailleurs a ma connaissance il n'existe que des Brute Force , pour decoder un zip ! , mais peut etre que quelqu'un va me contredire ?
..........

Non, je crois savoir que les zips ainsi protégés ne craignent pas grand chose, à moins d'y passer beaucoup de temps (enfin, les machines évoluent vite). Il n'y a aucun moyen de les lire sans avoir la clé qui permet de déchiffrer les données. Tu peux aussi mettre un zip encodé dans un autre zip encodé, alors là, il n'y a même plus moyen de voir les fichiers qui sont encodés. Je crois que le cryptage utilisé dans les RAR est meilleur que celui des ZIP.

Certains algorythmes de cryptage finissent par montrer des lacunes. Le fait d'essayer de trouver celles-ci s'appelle un "challenge". Ainsi, le SHA-0 et le MD5 (je crois) ont dernièrement été "craqués". Mais cela prend quand même des milliers d'heures sur des superordinateurs.

Voilà un lien intéressant sur la crypto : http://www-128.ibm.com/developerworks/p ... nxw01BILP6

La seule maniere que je connais de trouver le mot de passe d'un Zip, c'est en effet le bruteforce. Attaque par dictionnaire ou par generation de mot. Advanced Zip Password Recovery fait ca bien, ainsi que Passware Kit. Donc bien sur si le mot de passe est "#~{&={[{éçéjhé(hjk(875è_", aucune chance de le trouver

Par contre, je ne comprends pas vraiment comment tu comptes te servir de ça. Si c'est pour proteger des fichiers et que ca sera lu par ton programme, alors forcement tu vas stoquer le mot de passe dans ton executable. Meme crypté à la base, tu auras forcement a un moment donné le mot de passe en clair, lors de ta procedure unzip. Donc là oui, c'est très facilement trouvable. (j'ai deja vu cette idée sur un programme en effet, mais juste pour proteger les ressources, pas pour la protection de l'application)

Petite correction, SHA et MD5 sont de algo de hashage et non de cryptage. Ils permettent de generer une signature unique pour des données. Quand il est possible de generer d'autres données ayant la meme signature, alors l'algo est cassé. On n'en est pas encore la pour le SHA et le MD5 (a ma connaissance) mais des études theoriques ont prouvées que c'etait fesable (et y'a meme eu un exemple sur le MD5, 2 fichiers pdf differents avec le meme hash MD5) Par contre pour des trucs genre CRC32 (si vous voulez mettre des protections comme ca sur vos binaires) ça peut se recalculer et se corriger en ajoutant un dword à un fichier. (en imaginant que le crc soit utilisé pour decrypter un autre fichier apres, sinon il aurait meme simplement suffit de squizzer la comparaison, voir de corriger la constante comparée)

J'ai un peu d'expérience dans le domaine (sans être un dieu non plus) et je peux vous donner certains conseils.

1) Cherchez le crack tout simplement.
Le danger n'est pas le mec qui a cracké votre soft et qui l'utilise. Le danger c'est quand le crack est public.
Faites un petit tour sur emule, astalavista.com, google, newsgroup.
Prennez le crack, effectuez le patch et regarder où votre soft est faillible.

2) Mettez souvent vos versions à jour, même pour un tout petit bug.
Cette méthode est assez efficace, le meilleur exemple étant BlindWrite.
L'utilisateur voudra toujours la dernière version (moins de bugs, plus d'options...) et dans la grande majorité des cas il va d'abord aller chercher le soft puis le crack.
On pourrait pousser le vice en préparant des nouvelles options ou corrections de bugs à l'avance et chaque fois qu'il y a un crack dispo vous balancez la nouvelle version de votre soft.

3) N'utilisez pas des trucs lourds genre les dongles ou autre.
Si vous ne le concevez pas vous-même il y a de fortes chances pour que la protection soit déjà obsolète et la seule chose que vous gagnerez c'est un programme plus lent et plus lourd ou avec plus de problèmes.

4) Packers (UPX, ASPack et cie).
Les packers obligent le cracker à faire un dump de votre programme depuis la mémoire et cette méthode est loin d'être maîtrisée par le débuttant.
Le principal défaut c'est que l'application va être plus lente à lancer surtout dans le cas de gros exécutables. La vitesse d'exécution n'est pas modifiée, juste le lancement.
N'oubliez pas non plus de rester à jour avec le packer, vous pouvez même changer de temps en temps.

5) Votre programmation.
Ma grand-mêre disait "Pourquoi faire simple quand on peut faire compliqué ?". Faites la même chose.

- N'hésitez pas mutiplier les appels à votre procédure de vérification de serial. Par exemple à chaque fonction légère vous faite un appel à votre fonction de vérification même si vous n'utilisez pas le résultat.
Qqun de normal va jamais se dire qu'on vérifie le serial dans la menu Impression ou Quitter.

- Dans votre procédure de vérification faites plein de trucs inutiles avec les variable genre Xor, Longueur, boucles etc...

- Si vous utilisez un serial basé sur des infos (nom, email etc...) ne générez pas le serial pour le comparer à ce que l'utilisateur a donné comme valeur !
C'est la base du cracking (le phishing) et accessibles à tout le monde.
Faites plutôt une fonction qui va générer ce que l'utilisateur a donné ensuite vérifiez plusieurs points du résultat.

6) Ne surestimez pas le coût de votre application, c'est de loin la motivation la plus grande du cracking. Si les majors de l'industrie du disque avaient compris ça on aurait des albums 10 fois moins chers mais 10 fois plus vendus.
L'utilisateur ne voit pas que vous avez mis X heures dans un programme; il voit le programme et ce qu'il fait.
Soyez honnête, personne n'est assez stupide pour acheter un "notepad" à 25 euros.

7) Préférez deux versions de votre soft. La démo publique SANS certaines fonctions (pas juste désactiver quoi) mais gardez la procédure d'enregistrement, beaucoup se casseront les dents dessus.
La seconde serait complète et accessible après l'enregistrement/paiement (comme PB) mais cela ne vous empêche pas de garder un système d'enregistrement manuel (serial ou autre)

N'oubliez pas que le cracker est avant tout un programmeur (certainement plus doué que vous pour les bons crackers).


C'est loin d'être une liste exhaustive mais avec ces quelques petits conseils cela vous permettra limiter les dégâts, seul une poingée de bons crackers seront capables de déplomber votre programme et en général ils seront plus concentrés sur les softs grand public (winzip, adobe, microsoft...).

Pas mal LeCyb

LeCyb a écrit : 1) Cherchez le crack tout simplement.
Le danger n'est pas le mec qui a cracké votre soft et qui l'utilise. Le danger c'est quand le crack est public.
Faites un petit tour sur emule, astalavista.com, google, newsgroup.
Prennez le crack, effectuez le patch et regarder où votre soft est faillible.

Très bonne idée, mais il faut avoir des competences en debugging pour voir comment ca a été cracké

LeCyb a écrit : 2) Mettez souvent vos versions à jour, même pour un tout petit bug.
Cette méthode est assez efficace, le meilleur exemple étant BlindWrite.

Pas très valable par contre ça. Deja, si le soft est mis a jour tres souvent, en effet ca emmerdera le crackeur, mais il va soit tenter de le keygenner, ou s'il n'y arrive pas, le passer à un de ces potes keygenneurs pour qu'il le fasse (ca sert à sa une team) Et ce fut le cas de BlindWrite par exemple. Et il n'est pas concevable de changer de routine d'enregistrement à chaque nouvelle sous-build, pour les utilisateurs (ou alors on peut partir dans cet optique, et envoyer un mail avec le nouveau serial a l'utilisateur, automatiquement)

Apres, si ton soft est pas keygennable (RSA-1024 par ex.), il y a toujours une methode pour se debrouiller, meme si tu modifies l'exe. Il suffit de faire un crack generik qui cherche dans l'executable les zones a patcher. (dans le cas du RSA, la clé publique par exemple, ou autrement les routines a patcher), Je connais un crack pour winrar 2.x qui fonctionne jusqu'a la version 3.42, avec cette methode.

Cette methode emmerde plus l'auteur que le crackeur, a mon avis

LeCyb a écrit : 3) N'utilisez pas des trucs lourds genre les dongles ou autre.
Si vous ne le concevez pas vous-même il y a de fortes chances pour que la protection soit déjà obsolète et la seule chose que vous gagnerez c'est un programme plus lent et plus lourd ou avec plus de problèmes.

J'approuve

LeCyb a écrit : 4) Packers (UPX, ASPack et cie).
Les packers obligent le cracker à faire un dump de votre programme depuis la mémoire et cette méthode est loin d'être maîtrisée par le débuttant.
Le principal défaut c'est que l'application va être plus lente à lancer surtout dans le cas de gros exécutables. La vitesse d'exécution n'est pas modifiée, juste le lancement.
N'oubliez pas non plus de rester à jour avec le packer, vous pouvez même changer de temps en temps.

J'approuve moins Bon c'est vrai que ca coute rien de rajouter un packer (quand il est gratuit), mais c'est comme les dongles, un debutant va trouver un programme tout fait pour supprimer le packer, et un expert va faire ca en 2 min à la main. UPX et ASPack par exemple c'est vraiment super facile.
Apres on peut partir dans les protecteurs, style Armadillo ou ASProtect. Mais là, c'est payant, et comme la protection est utilisé sur des centaines de programmes, les crackeurs étudient beaucoup ces protections et au final ça finit toujours par se faire casser.

LeCyb a écrit : - N'hésitez pas mutiplier les appels à votre procédure de vérification de serial. Par exemple à chaque fonction légère vous faite un appel à votre fonction de vérification même si vous n'utilisez pas le résultat.

oui mais non Enfin, si c'est la meme procedure que tu appelles a chaque fois, ca n'a pas d'interet, car si elle est cracké lors de la validation du serial, elle est aussi lors de l'impression. Idem si c'est keygenner. Il faut donc utiliser une seconde routine au moins (mais la le crackeur va vite la trouver si c'est exactement la meme), voir une autre fonction qui rajoutera des conditions sur le serial generé (qui n'etaient pas dans la 1ere fonction) afin d'emmerder un peu les keygenneurs. Mais bon, ca se trouve vite ca aussi, on a des testeurs, et quand un crack ne fonctionne pas, sachez bien que les gens savent nous le dire vite...

LeCyb a écrit : - Dans votre procédure de vérification faites plein de trucs inutiles avec les variable genre Xor, Longueur, boucles etc...

Dans l'optique d'un crack, c'est inutile. Pour un keygen, c'est perturbant tout au plus. Il y a au moins 2 methodes generales pour faire un keygen. Soit on comprend tout l'algo et on le recode dans notre langage preferé (90% des cas), soit on rip la fonction en asm, et on l'injecte dans notre source, si le compilateur supporte l'asm inline, ou alors on code en asm. Il faut refaire les branchements, corriger les valeurs, mais ca permet de faire un keygen sans comprendre l'algo, ou plutot quand on n'arrive pas a reproduire exactement ce que l'on voit dans le debuggeur. Donc la, soit le mec comprend vraiment rien, et rip tout et meme les trucs inutiles, mais ca fonctionne, soit il comprend et vire les trucs inutiles, mais ca marche aussi. Mais pour ripper un algo faut deja s'y connaitre un peu.

LeCyb a écrit : - Si vous utilisez un serial basé sur des infos (nom, email etc...) ne générez pas le serial pour le comparer à ce que l'utilisateur a donné comme valeur !
C'est la base du cracking (le phishing) et accessibles à tout le monde.
Faites plutôt une fonction qui va générer ce que l'utilisateur a donné ensuite vérifiez plusieurs points du résultat.

Fishing

LeCyb a écrit : 6) Ne surestimez pas le coût de votre application, c'est de loin la motivation la plus grande du cracking. Si les majors de l'industrie du disque avaient compris ça on aurait des albums 10 fois moins chers mais 10 fois plus vendus.

Pour les grosses teams, en effet c'est generalement le cout qui interesse. Mais il ne faut surtout pas oublier les cotés "défis" et "competition". En effet, c'est a la team qui sortira le plus de releases (de qualité de preference, ou jamais faites) Il m'est deja arrivé de cracker un programme a 2€ (honte sur moi :/) parce qu'un pote me le demandait. Bon OK c'etait aussi un programme concurrent au sien
Si une application n'a jamais été cracké, elle interesse souvent plus que si elle vallait tres cher. Si en plus on voit sur le forum que l'auteur se vante de ça, ou qu'il est arrogant, alors on passe plus de temps dessus, en general

LeCyb a écrit : 7) Préférez deux versions de votre soft. La démo publique SANS certaines fonctions (pas juste désactiver quoi) mais gardez la procédure d'enregistrement, beaucoup se casseront les dents dessus.
La seconde serait complète et accessible après l'enregistrement/paiement (comme PB) mais cela ne vous empêche pas de garder un système d'enregistrement manuel (serial ou autre)

J'approuve beaucoup. Et je rajouterais que vous devez meme garder un système d'enregistrement sur la version complete. Et meme un baleze :p On trouve tres souvent des versions full de ces softs, alors autant compliquer l'affaire. Meme pour PureBasic 3.93 par exemple, hein LeCyb

LeCyb a écrit : N'oubliez pas que le cracker est avant tout un programmeur (certainement plus doué que vous pour les bons crackers).

Pas dans tous les cas, mais en effet ca aide beaucoup de programmer, vraiment beaucoup.