Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
Souvent les cryptos les plus complexe tombent à cause du développeur qui code une simple comparaison de numéro de licence après extraction.
Il suffit alors de trouver dans le code la comparaison et la remplacer par son contraire, ou je dirais mieux, sortir le texte qui doit être dans la table au moment de la comparaison et la remplacer par une table non crypter.
Pour parer ces deux méthodes avec l’utilisation d’un assembleur, c’est de mettre dans la table d’autres éléments primordiaux au fonctionnement de l’application, que le simple numéro de série.
Et pour la comparaison, il faut noyer le poisson avec des traitements rapide mais très long en debug, avec plusieurs comparaisons ou la même en plusieurs fois (du coup pas visible).
De même pour la procédure stocker qui retourne toujours oui, surtout si vous laissez trainer l’analyse pour les mise à jour automatiques.
La plus grosse sécurité n’est pas la façon de faire, mais plutôt la façon de le cacher, simple et introuvable, au lieu de complexe et traçable comme le petit poucet, car avec ce dernier, une petite piste permet déjà de réfléchir à une solution.
Mais bien sûr, le niveau de sécurité dépendra du prix du produit, souvent le nom de l’utilisateur avec le nom de la machine suffit (pour l’associer avec la clé privée),
car le débuggeur voit ça comme un traitement réseau classique (surtout si c’est affiché dans l’application),
et compléter l’exécution avec la lecture de plusieurs numéros de série pour focaliser ses recherches là-dessus.
Bonjour à tous,
Trés interressant le sujet, mais juste un point :
- Sur Win 10, je pense qu'il vaut mieux laisser tomber la solution de la BDR, à chaque mise à jour importante, celle ci est complètement réinitialisée.
