Comment protéger un fichier .plist? (données d'achats in-app)

[Paul009]

Salut,

j'aimerais protéger un fichier .plist dans mon application, pour mettre des achats in-app. J'aimerais savoir comment ça marche, lorsque quelqu'un veut hacker l'appli : le hacker a accès à quoi exactement? Un code compilé? Est-ce que le fichier .plist et le code .swift (ou .h/.m) est lisible de la même façon, ou le .plist apparaît différemment? J'ai vu des classes qui utilisent Keychain, mais si on a accès au code, on peut simplement envoyer de nouvelles valeurs via le fichier de code (le même fichier que le développeur utilise pour enregistrer des valeurs dans le plist) Le hacker ferait alors la même chose que le développeur, en utilisant son fichier?

J'ai vu ailleurs, que des .plist pouvaient être partagés? Un utilisateur gagne tous les trophées, extrait le .plist, et l'envoie à un ami?

Il est aussi souvent conseillé de passer par internet, un serveur pour stocker les données, mais je vais plutôt utiliser un fichier sur le portable, pour pouvoir jouer offline. C'est pas grave si le jeu est hacké par le hacker number 1. Je veux simplement protéger les données pour que ce ne soit pas trop facile de hacker l'appli. Avoir au minimum une couche de protection.

Merci

[PBell]

Bonsoir Paul,
Vaste sujet !

Effectivement l'accès à un serveur internet avec un système de cryptage clé publique/clé privée est certainement le pus sécurisé.

Si tout reste sur ton PC, n'importe quel utilisateur verra en quelques clicks les fichiers que ton application utilise et les copiera d'une machine à l'autre pour récupérer les données de la première machine (les trophées !).

Mais si tu t'adresses à des néophytes, alors tu peux cacher un fichier ou encore, mettre des données dans le dossier content/resources de ton application elle-même. L'avantage est que cet accès à ton application sera caché au milieu de l'accès normal au code et donc plus difficile à détecté qu'un accès à un autre fichier même caché !
Tout dépend du niveau de protection acceptable et du type de développement que tu fais (xCode, Applescript, java,..)
Tu peux effectivement combiner des données avec les Keychains ce qui offre un premier niveau.

Lorsque le programme est très simple (type applescript) mais que je ne veux pas qu'il soit copié d'une machine à l'autre (sauf la version initiale dite "vierge" que je garde pour l'installation) je passe par les property dont les valeurs sont cryptées dans le code lui-même.
Lors de la première utilisation sur une machine, la valeur est vierge, je crypte une nouvelle valeur avec par exemple le nom de la machine et celui du disque.
Lors des lancements successifs, je relis la valeur et, si non vide, je la compare avec les noms machine/disque pour déterminer si c'est copié.
Pour parer à cela, le mauvais joueur doit, soit avoir une version vierge (en principe je ne la laisse pas trainer), soit être capable de décoder du script compilé de properties pour en changer la valeur (bonjour !!)

Si ta Plist n'est pas trop grosse, cette méthode est plus simple. Si tu gardes une plist dans un fichier indépendant, seuls les utilisateurs incapable d'ouvrir le fichier bibliothèques/preferences ou application support seront bloqués. Pour les autres, se sera un jeu d'enfant ! Autant dire que la protection sera très simpliste.

Cordialement

[Paul009]

Merci PBell! Alors, j'ai plusieurs questions:
"le dossier content/resources" : qu'entends-tu par ça? Un dossier en faisant "Resources > Asset catalog" ?
Sinon, décompiler un code est compliqué pour un hacker de base? Tu fais référence au property cryptés à décompiler, mais le code source en lui-même?
Si par exemple le hacker trouve le fichier .plist, et ce fichier est compilé, il le décompile, puis il voit que le fichier est crypté (j'ai trouvé ça : stackoverflow ), il décrypte simplement le fichier de la même façon que le développeur décrypte le fichier dans le jeu? Je crois qu'il existe 2 ou 3 façons d'encrypter/décrypter, donc il peut essayer les 2,3 façons et voir le résultat?

Je pense que je vais suivre ce que tu dis : mettre le nom du device dans le plist, et vérifier dans le code à chaque appel à ce plist.

[PBell]

Bonjour Paul,
Voici , en Applescript, une méthode pour protéger des variables et la copie de ton application.
Il faut enregistrer ce script avec l'éditeur de script, sous forme d'application en cochant l'option "Executable uniquement". Ainsi seul le code est enregistré et pas la source du script.

Les variables Property sont enregistrées par le compilateur et leurs valeurs sont insérées directement dans le code.
L'avantage est que cela limite la copie de tes données aux experts qui peuvent décrypter cette partie... et il n'y en a pas beaucoup !
Qui plus est, il leur sera difficile de mettre d'autres valeurs si tu ajoutes un module interne de cryptage : Par exemple les caractères du nom de la machine peuvent être décalés de x codes ASCI. Cela ne sera pas alors directement lisible même en regardant le code (qui se trouve dans le sous dossier Contents/Resources/Scripts de l'aplication que tu peux voir avec un click droit / Afficher le contenu du paquet).

Tu peux augmenter la protection en ajoutant des routines de cryptage internes plus complexes à ton programme.

L'exemple ci-dessous utilise une fonction peu connue des Property à savoir que tant que l'application n'est pas recompilée, property est une variable et pas une constante (comme beaucoup le croient)

CODE

property Mac : ""
property Disque : ""
-- on peut ajouter d'autres properties ici, au lieu de stocker en fichier plist
property mon_Score : 0
property mon_Personnage : "Batman"
property mes_Pref : {"jaune", 1, "le matin"}

if (Mac is "") and (Disque is "") then -- premier lancement : on personalise le code avec le nom machine et le nom du disque
    set Mac to computer name of (system info)
    tell application "Finder" to set Disque to name of startup disk
end if

-- test pour vérifier que l'application n'est pas copiée
set Mac_Actuel to computer name of (system info)
tell application "Finder" to set Disque_Actuel to name of startup disk
if not ((Mac_Actuel is Mac) and (Disque_Actuel is Disque)) then
    display alert "Cette application a été copiée. Cet ordinateur ne dispose pas des droits." buttons {"Terminer"}
    return
end if

-- si on est passé, alors reste du code : par exemple avec assignation de nouvelles valeurs
set mon_Score to mon_Score + 1
display dialog mon_Score
set choix to display dialog "Bonjour " & mon_Personnage & "!." & return & "Voulez vous changer de nom" default answer mon_Personnage
if button returned of choix is "OK" then
    set mon_Personnage to text returned of choix
end if

Enfin décompiler un code est toujours possible. C'est juste une question de temps, et d'envie. Si la décompilation peut rapporter gloire ou argent, il y aura toujours des hackers pour tenter et parfois trouver. Même les meilleur algo de cryptage avec clé 128 ou 256 bits sont théoriquement craquables. mais il faut des heures, voir des jours ou des années selon pour en venir à bout.
ta carte bleue est basé sur ce principe en comptant un niveau de complexité qui demande juste quelques années à de puissants serveurs !
Ton application a-t-elle besoin de ce niveau de sécurité ? sans doute non. Il est même probable qu'elle n'intéresse pas des hackers ! Donc ajuste ta protection à la cible de ton public.

Enfin j'ajoute qu'il exit heureusement une infinité de façon de crypter, même si les algo les plus puissants se retrouvent souvent. Il n'y as pas seulement 2 ou 3 façons de crypter. Certaines méthodes font appel à des notions relativement (!!) simple comme des série ou des fonctions polynomiales, mais d'autres font appels à des concepts mathématiques plus costauds.


Dernier mot : si tu mets le nom du device dans la plist, sans rien d'autre, autant dire qu'un habitué du Mac ne mettra que quelques secondes pour le trouver !
Cordialement

[Paul009]

Merci PBell, j'ai appris pas mal de trucs Pour l'applescript, c'est assez nouveau pour moi. Je vais peut-être mettre ça de côté et analyser le code, les property etc. pour bien tout comprendre. (Est-ce que mon_Score est une variable déjà présente dans mon code? Est-ce que tout ça est pour l'objective-c uniquement, ou peut marcher avec Swift? Mon application est en Swift).

J'ai regardé aussi comment on décalait l'ascii, mais je ne suis pas sûr de comprendre la technique, j'ai trouvé cette réponse . En effet ça pourrait être pas mal de mettre ça dans le code, pour chaque appel à la plist.
Merci en tout cas, j'y vois un peu plus clair maintenant

Ce message a été modifié par Paul009 - 29 Mar 2015, 21:56.

[PBell]

Bonsoir,
L'exemple que j'ai donné n'est qu'en Applescript. Si tu es en Objective C ou mieux en Swift, il faut sans doute recourir à d'autres techniques.

Oui, dans l'exemple, mon_score était juste un exemple de variable pour ton code (car tu as parlé d'un jeu !).

Pour le décalage d'ASCII, ce n'est que la transposition de ce que faisaient sans doute les plus âgés d'entre nous aux scouts en décalant le A devient C, le B, devient D, le C devient E et ainsi de suite (décalage de +2). Le site auquel tu fais référence, contient un script qui me semble un peu tordu, mais cela y ressemble.

En Appelscript, cela donne ceci :

CODE

set Source to "Ceci est un essai"
set Decale to 5 -- le decalage ASCII

set mes_lettres to every character of Source
set Crypte to ""
repeat with une_lettre in mes_lettres
    set une_lettre to ASCII character of (((ASCII number of une_lettre) + Decale) mod 128)
    set Crypte to Crypte & une_lettre
end repeat -- le résultat crypté est dans la variable Crypte

Cordialement