Sécuriser une application
colas_
Membre
Bonjour à tous !
Je suis en train de créer une petite application pour OSX. Je voudrais sécuriser mon application : si quelqu'un la copie depuis son ordi vers un autre ordinateur, ça ne marchera pas. Je ne compte pas diffuser mon appli via le appStore.
Quelqu'un a-t-il déjà fait cela ?
Avez-vous des idées de méthodes faciles ?
Merci !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Ensuite, je ne suis pas sûr que ce soit faisable facilement: l'appli n'a pas les droits Unix pour modifier son propre bundle, on ne peut donc pas y insérer quelque chose pour noter la référence de l'ordi.
Les applis du Mac App Store contiennent un reçu dans lequel on trouve un tas d'infos, notamment l'adresse MAC de la première interface Ethernet de l'ordi, ce qui permet à l'appli de vérifier que l'ordi est bien le bon. Le reçu est signé par un digest pour empêcher toute modification. J'imagine que pour cela, l'application Mac App Store envoie l'adresse MAC au serveur d'Apple, qui ajoute le reçu dans le bundle de l'appli avant de la renvoyer.
- Est-ce vraiment nécessaire de mettre ça en place (rapport complexité / gain)
- Si tu veux mettre ça en place, à quelle hauteur est-ce que tu souhaites mettre la barrière ? Plus tu voudras la mettre haute (rendre le contournement de la protection difficile) moins tu auras de chances que les gens la contourne (il leur faudra un niveau plus élevé, même si ça reste tjs possible), mais plus ça te fait de boulot pour toi pour mettre un système complexe en place (alors qu'il sera peut-être craqué facilement après)
Merci pour vos réponses !
@Ali : je veux mettre la barre bas. Juste une petite protection.
L'idée que j'ai eue hier après la réponse de @Céroce, c'est la suivante :
- mettre une date dans le info.plist (ou qqch du même genre)
- lors du premier lancement de l'appli, s'assurer que la date du lancement correspond à la date de la plist (ou la même semaine, etc.)
- écrire dans le dossier AppicationSupport de l'application
- lors des lancements ultérieurs, si la date n'est pas la bonne, aller vérifier dans le dossier AppicationSupport qu'il y est écrit quelque chose
- pour plus de sécurité, au lieu d'écrire dans le AppSupport un simple BOOL, on peut écrire le UUID de l'ordi (!!! oui de l'ordi pas du iDevice, cf. http://stackoverflow.com/questions/11113735/how-to-identify-a-mac-system-uniquely par exemple)
Comment? Le info.plist fait partie du bundle de l'application. Ou alors, il faut le modifier avant d'envoyer l'appli au client.
Je ne suis pas allé vérifié, mais ce bout de code ressemble à celui donné par Apple pour récupérer l'addresse MAC de l'ordi...
S'il n'y a rien dans /Application Support, qu'en déduire ?
::) Que l'application n'a pas besoin de dossier dans "Application support" !
Céroce et Aligator ont toujours raison: Toute protection peut être contournée, détruite ... etc
Il faut juste y mettre le paquet.
Ils savaient ça déjà au moyen âge: Tous les chateaux forts ont été pris, détruits, envahis ... etc
Si la personne télécharge ton appli et la file à tous ses collègues de boulot le lendemain, c'est cuit aussi ?
Comment les clients se procureront-ils ton application ? D'après ce que tu dis, je suppose pas en téléchargeant l'appli directement depuis un site web, si tu songes à mettre des contrôles et songes à changer la date dans le Info.plist à chaque fois que tu livres à un client. Est-ce à la demande (voire toi qui va installer sur site) ?
Dans ce cas pour plus de sécurité tu peux plutôt :
- Inventer une fonction de hashmaison(X) maison arbitraire mais connue de toi seul (comme une fonction qui fait un XOR entre la chaà®ne X à hasher et un texte interne secret, ou un truc comme ça)
- Au lancement de l'appli, tu récupères l'UUID (ou l'adresse MAC) de la machine, et tu calcules code=hashmaison(UUID)
- S'il n'y a rien dans ApplicationSupport, tu affiches à l'utilisateur une boite de dialogue bloquante affichant l'UUID de la machine et un champ de saisie pour entrer le code. L'utilisateur va alors te communiquer son UUID (par téléphone ou mail), si c'est bien un client à qui tu as vendu ton logiciel, tu vas calculer de ton côté hashmaison(UUID) à l'aide de ta fonction super-secrète et lui fournir en retour pour qu'il le rentre dans le champ. L'appli vérifie alors que le code rentré est bien égal au code qu'elle a calculé de son côté et si oui l'écrit dans ApplicationSupport et permet l'accès à l'application
- Si par contre au lancement il y a déjà un code dans ApplicationSupport, tu vérifies que c'est bien le bon et qu'il correspond au code calculé via hashmaison(UUID), et si oui tu n'affiches pas de boite bloquante mais ouvre directement l'appli. (Si le code de ApplicationSupport est invalide, tu affiche la boite de dialogue comme pour le cas précédent)
Au final le principe est donc que l'utilisateur te fournisse l'UUID de sa machine, tu calcules un code à partir de ce UUID que seuls toi et le code de ton appli connaissent, comme ça tu peux lui générer le code de ton côté et l'appli peut le vérifier du sien.A toi d'imaginer une fonction hashmaison au feeling (XOR du UUID et d'un texte, md5 de {"xyz"+5 premiers caractères de UUID + "kwy" + reste de UUID + "mnop"}, autre, à toi de voir du moment que c'est secret).
Si l'utilisateur copie l'appli sur un autre ordi, même s'il tente de gruger en copiant le fichier de ApplicationSupport, comme l'autre ordi aura un UUID différent le code ne sera pas bon et ça bloquera l'appli sur l'autre ordi.
Après ça veut aussi dire (mais ça quelle que soit la solution que tu choisisses, la tienne ou la mienne), si(ou plutôt quand) l'utilisateur change(ra) de machine, il faudra qu'il te refasse une demande de code. (Et tu n'auras pas moyen de vérifier qu'en vrai c'est pas la machine d'un copain qu'il faut passer pour sa nouvelle machine à lui).
Ca me semble un bon compromis entre facilité de mise en place et protection hyper basique (loin d'être incontournable mais suffisant pour décourager le non-geek)
@Céroce
Ou alors, il faut le modifier avant d'envoyer l'appli au client.
---> oui, c'est ce que je comptais faire
@Ali : j'aime bien ta solution.
Le seul avantage à ma solution est qu'il semble que l'appli n'est pas protégée !
Je compte distribuer l'application à des amis/contacts, mais je ne veux pas qu'elle se propage !
Oui, ça marche, sauf qu'après avoir analysé le calcul embarqué dans l'application (hum, ça peu être long à faire!) on est capable de faire un calculateur de code qui marche à tous les coups.
Je l'avais fait dans les années 95, 96 pour un programme qui au premier lancement indiquait les informations à téléphoner au fabricant. En réponse, celui-ci renvoyait le code d'activation. En fait, ce code était le résultat d'un calcul polynomial. L'adresse MAC de la machine, le nom d'utilisateur et la date d'installation de l'application étant utilisés pour modifier les coefficients du polynôme.
J'ai très vite arrêté ce genre de chose, pas d'intérêts pour moi.
Pour moi, le fait rédhibitoire est que l'application contient le calcul qui vérifie le code. Ce calcul est à la disposition de celui qui veut cracké le code.
On ne peut pas empêcher un crack de sortir un jour (soit un générateur de code, soit un crack qui modifie le binaire de l'appli et change l'instruction assembleur Jump-If-Not-Zero en Jump-If-Zero et basta) donc c'est pas la peine de se prendre la tête à essayer de faire un truc compliqué vu que dans tous les cas il sera cracké si qqun a la volonté. On veut juste que ça bloque Mme Michu.