Limiter le piratage de son application
AP
Membre
Bonjour,
Mon appli étant systématiquement crakée le lendemain de chaque nouvelle version, je me demandais qu'est ce que je pourrais faire pour diminuer un peu cela (80% des téléchargement de l'appli sur mon site web sont pour la craquer)
- Est ce que certains ont essayé de signer leur appli avec un certificat et si oui avec quel succès (et problème)
- avez-vous d'autres idées?
Merci
Mon appli étant systématiquement crakée le lendemain de chaque nouvelle version, je me demandais qu'est ce que je pourrais faire pour diminuer un peu cela (80% des téléchargement de l'appli sur mon site web sont pour la craquer)
- Est ce que certains ont essayé de signer leur appli avec un certificat et si oui avec quel succès (et problème)
- avez-vous d'autres idées?
Merci
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Si il faut internet, je pense à un système de vérification de licence. En plus en vérifiant que la résolution DNS de ton serveur de vérification ne soit pas le localhost (127.0.0.1).
En clair si verif.mondomaine.com => 127.0.0.1 : tentative de piratage car impossible de vérifier la licence. => renvoie vers l'achat de la licence.
Un utilisateur normal indiquera des identifiants de comptes qui validera l'utilisation du logiciel pour la version. Si la version n'est pas active => renvoie vers l'achat d'une mise à jour.
1) Utilisent-ils des clés valides ?
2) Patchent-il l'application ?
Par rapport à ce que tu dis (les utilisateurs téléchargent essentiellement pour pirater), ce serait plutôt la première possibilité.
Dans ce cas, commence à envoyer la clef à un serveur, non pas pour la valider, mais pour voir quelle clef pirate ils utilisent. Ensuite, tu pourrais utiliser un simple système de liste noire.
Edit : j'ai pas assez cherché... Désolé
Il suffit dans /etc/hosts de rediriger verif.mondomaine.com vers une IP invalide, n'importe laquelle. Pas besoin de mettre 127.0.0.1 pour dérouter la vérification. Du coup quand le soft se lancera ta requête de vérification se lancera sur un mauvais serveur et la requête reviendra en erreur. Certes dans ton soft tu peux dire si erreur refus de se lancer. Mais dans ce cas si ton serveur tombe un jour ça va bloquer tous les utilisateurs officiels qui ont dûement payé la licence !
Et sinon il y a toujours moyen de patcher l'appli pour détourner le système de vérification.
Donc comme l'a mentionné Céroce la protection à mettre en place va dépendre de :
- savoir si les gens utilisent des numéros de série pirates
- savoir si les gens patchent ton appli
- quel niveau de sécurité tu veux, sachant que c'est toujours le jeu du chat et de la souris, tu peux perdre de l'énergie à mettre un système de protection, il sera certainement cracké un jour ou l'autre. S'il suffit d'appuyer sur un bouton ou rentrer un code trouvé sur le net pour l'utilisateur c'est sûr qu'il piratera plus facilement que s'il lui faut faire une manipulation compliquée pour patcher ton app, mais cela demande aussi plus d'efforts de ton côté pour complexifier la tâche des pirates... Il faut trouver un juste milieu, la protection parfaite n'existant pas, le but est plus de complexifier la tâche que de la rendre impossible ce qui est utopique.
La vérif d'intégrité est également très simple à contourner. Même les systèmes de protection matériel sont contournable. Avec le UUID de la machine et un serial en rapport, cela complique les choses sauf si il est possible d'en déduire le UUID (depuis le sérial) et de changer celui de la machine. Même le système se basant sur l'adresse MAC d'une carte réseau est contournable.
Pour pousser l'idée d'Ali, l'envoie du serial a un serveur permet de l'incrémenter et aussi de savoir si c'est un numéro officiel (suite à un achat) qui est parti dans la nature. Voir même de savoir si l'algo de création des sérial est parti dans la nature.
Je n'ai pas d'iBidule, mais j'ai cherché un "serial" juste pour voir. Trouvé en 1mn 30 approximativement. Le temps dépend des mots clefs que l'on indique.
Tout est piratable! Mais il ne faut pas que cela empêche de verrouiller ton logiciel. En général mettre un verrouillage de type un peu personnel marche un peu plus longtemps qu'un standard. Mais il sera cracké de toute façon.
Moi je me suis arrêté à l'envoie des infos de la licence que valide l'utilisateur. C'est enregistré et incrémenté sur mon serveur. J'ai aussi une ban-list par de fait même qui est chargée à chaque démarrage de l'application. Même ça je trouve que c'est dommage pour l'utilisateur honnête, mais après tout ça reste très transparent..
Et puis, avec LittleSnitch, il est facile de bloquer ces 2 connexions à mon serveur.
Enfin tout ça m'a appris que 90% des personnes qui cherchent un crack sont celles qui n'achèteront jamais ton app même si le crack ne fonctionne pas.. Pas la peine de plus se battre ducoup
Et le code signing vous avez testé?
Mais ça n'empêche que la modification de l'application, alors si les gens piratent avec des clefs valides, c'est inefficace.
Je veux dire si une application a son code de signé avec un certificat, si un pirate s'amuse à essayer de modifier le binaire pour la patcher, la signature évidemment sera invalide. Et OSX va alors refuser de lancer l'appli. Mais qu'est ce qui empêcherai le pirate d'indiquer (dans le plist de l'app je suppose ou un truc comme ça ?) que l'appli n'est pas signée par un certificat (ce qui est le cas de la plupart des applis OSX du moins celles non distribuées par le MacAppStore) ?
Du coup le pirate modifie le code pour hacker la protection de licence, et modifie au passage le flag disant que l'appli est signée par certificat, et comme OSX accepte encore les applis non signées (contrairement à iOS ou c'est une condition obligatoire que l'appli soit signée pour qu'elle se lance) ça le dérangera pas, si ?
Après il me semble que c'est aussi au développeur de vérifier dans son app que l'appli est valide et le certificat prouve l'authenticité du code de l'appli (j'avais cru voir passer une session WWDC à ce sujet par curiosité, ainsi que quelques conseils Apple à l'époque, sans jamais fournir d'algorithme tout fait sinon ça enlève tout l'intérêt d'une telle protection si tout le monde utilise la même méthode) mais bon, rien n'empêche le pirate également de faire sauter ce code de vérification (un petit "JMP" remplacé par un "JNZ" dans le code assembleur et hop ça inverse la condition de test et basta -- je sais un peu simpliste mais pas tant que ça), non ?
Dans l'une de mes app, j'ai ajouté pas moins de 5 fonctions de vérif du reçu faisait le même contrôle de façon différente et retournant toujours autre chose qu'un booléen. Le test de validité étant réalisé à plusieurs endroit et constamment dans l'app. ça prend un peux plus de CPU mais les tests fourrés de partout dans l'app rend la modification plus difficile.
D'autre par les noms des fonctions sont anodine et il existe des fonctions trompes l'oe“il qui retourne un boobléan servant au fonctionnement normal de l'app (pas à la vérif de la licence) mais ayant un nom pouvant penser qu'elle réalise le contrôle du reçu. Leur modification vas tout simplement déstabiliser le logiciel et faire perdre du temps au gugus... Après c'est facilement contournable et j'ai perdu du temps à faire ça et non mon app.
Résultat : Je ne peux même pas mesurer l'efficacité du procéder !
C'est exactement ce qu'il ne faut pas faire.. m'enfin, chacun voit midi à sa porte. Qu'Apple préconise de multiplier les vérifications, OK, mais je pense qu'il faut quand même faire attention à ne pas perturber l'expérience utilisateur.
En quoi ce que décrit wisky perturbe l'expérience utilisateur ?!
Ca perture l'expérience du pirate, ça c'est sûr, qui s'il essaye de pirater ton appli risque de s'y perdre dans les noms des méthodes du code (au risque de rendre l'appli foireuse à essayer de la bidouiller, plutôt que réussir à la cracker) mais l'utilisateur lui il s'en fout. L'utilisateur qui a acheté l'appli l'appli marche très bien, il s'en fout royalement des noms des méthodes utilisées dans le code... Donc c'est quoi le rapport ?
Bon si tu rajoutes d'autres systèmes (envoi du numéro de série par le net pour contrôle, etc) c'est autre chose. Mais là on parlait de la signature de code non ?
Avec le reçu de l'AppStore, t'as pas de sérial à envoyer sur Internet