iPhone Explorer - Attention à la sécurisation de vos applis
Smy
Membre
Bonjour
Connaissez vous iPhone Explorer sur Mac ou PC, qui permet d'accéder aux fichiers d'un iPhone non jailbreaké, et surtout de modifier ces fichiers >:( ?
http://www.macroplant.com/iphoneexplorer/
Je viens de le tester, et l'on peut très simplement naviguer dans l'arborescence de l'iPhone, accéder à tous nos précieux fichiers de nos applis, et modifier les prefs.
Du coup, attention à vos logiques de sécurisations dans le cas d'In App Purchase !
J'ai deux projets en cours sur lesquels je vais revoir pas mal de choses...
Connaissez vous iPhone Explorer sur Mac ou PC, qui permet d'accéder aux fichiers d'un iPhone non jailbreaké, et surtout de modifier ces fichiers >:( ?
http://www.macroplant.com/iphoneexplorer/
Je viens de le tester, et l'on peut très simplement naviguer dans l'arborescence de l'iPhone, accéder à tous nos précieux fichiers de nos applis, et modifier les prefs.
Du coup, attention à vos logiques de sécurisations dans le cas d'In App Purchase !
J'ai deux projets en cours sur lesquels je vais revoir pas mal de choses...
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
(ne le prends pas mal, j'apprécie beaucoup tes réponses )
Merci pour le liens
Heu, le but de mon post n'est pas de hacker ou vous expliquer comment hacker un iPhone, mais au contraire de vous faire réaliser qu'il faut proprement sécuriser vos applis.
Pfff, encore raté, tu es trop fort pour moi
Bon, je suis surpris qu'il n'y ai pas de réaction. Suis-je le seul à découvrir que iOS est une catastrophe coté sécurisation ?
Sur Mac, j'avais l'habitude du clic droit/afficher le contenu du paquet, mais je pensais que c'était plus protégé sur iPhone. Avec tout leur blah blah sur la compartimentation des applications, l'arborescence "chrootée", etc.
Du coup, il va falloir crypter les prefs, mettre des clés, et galérer avec les déclarations à l'exportation pour l'usage de cryptage. Ou au minimum utiliser du md5 qui ne rentre pas dans les déclarations...
Grrrrr
T'as peur de quoi en fait ? Qu'on craque ton appli ? Bah, de toutes façons, elle sera crackée donc autant pas perdre de tps la dessus....
Je m'en doute, mais une appli craquée sur un iPhone jailbreaké, je ne peux rien faire. Afficher le contenu d'une appli, je ne peux rien faire non plus puisqu'il suffit de renommer un .ipa en .zip.
Par contre, que la modification des prefs soit si simple sur un iPhone normal, ça me choque beaucoup plus, c'est tout.
Si tu veux un exemple, il était possible sur une version de Wired sur iPad de modifier les prefs pour faire comme si tous les numéros étaient achetés (je ne sais pas si c'est encore possible)...
C'est donc à nous développeurs de sécuriser au maximum les prefs et la façon de stocker les achats In App Purchase.
Et puis quand on doit stocker des données sécurisées, il faut utiliser tout ce que iOS nous fournit pour ça ! La KeyChain, la Security API, la lib CommonCrypto pour crypter les données, etc... c'est fait pour justement !
Security Architecture Overview : iOS
GenericKeychain Sample Code
CryptoExercise Sample Code
etc., etc.
Je me suis un peu penché sur le sujet...
Pour les property list, on peut déjà enregistrer au format binaire.
Si on l'ouvre dans un éditeur de texte, c'est illisible.
Par contre, si on l'ouvre dans property list editor, c'est parfaitement lisible.
En butinant un peu sur le net, j'ai trouvé des catégories de NSData qui permettent d'encrypter/décrypter les données.
Je vous colle plus bas le code.
Sur le site, il est indiqué que ce code peut être utilisé sans déclarer de cryptage à Apple (quand on soumet l'appli) car c'est des fonctions embarquées, standards Apple.
Qu'en pensez vous ?
CommonCrypto permet de faire de la crypto, avec plein d'algos, que ce soit AES ou autre. Ca reste de la crypto, qui doit être signalée comme tel lors de la soumission de l'appli. Mais bon je vois pas en quoi ça serait gênant de devoir le signaler à Apple (et si on ne le signale pas y'a des chances que l'appli soit refusée)
Par contre pourquoi ne pas utiliser La protection des fichiers proposée par Apple, qui crypte à la volée ?
Ca fait quoi ça ?
Ils expliquent pas vraiment... A part que ça protège les fichiers...
Imaginons que je fasse ça sur une property list. Ca veut dire qu'une fois récupérée via iphone explorer, elle sera illisible ?
Pour les données de vos applis, par exemple les recettes de muqaddar , un cryptage tout simple à l'intérieur des champs sqlite peut suffir pour les pirates en herbe (genre XOR).
Il me semble qu'il est possible de compiler la librairie SQLite avec une option permettant de crypter les pages de données. Tout est transparent pour l'utilisateur (le développeur en fait). Mais (car il y a un mais) les fonctions ce cryptages ne sont pas libre et il faut acheter un option de support auprès de l'auteur de SQLite. Enfin c'était le cas lorsque j'ai ajouté le support sqlite pour une application sur un TPE. Cependant (oui il y a aussi un cependant) il me semble qu'il est possible d'écrire ses propres API de cryptages... évidemment pour avoir plus d'infos à ce sujet rien ne vaut un petit détour sur www.sqlite.org et plus spécifiquement là www.sqlite.org/support.html.
Je vais regarder tout ça de plus près. C'est intéressant en effet.
Merci pour cette info.
Test effectué. C'est négatif.
Visiblement, en mettant cet attribut, le fichier est effectivement crypté mais uniquement quand l'appareil est locké.
Sinon, le fichier est normal.
J'ai fait le test d'enregistrer mon fichier en mode "protégé", et avec iphone explorer, je le récupère tranquille et l'ouvre comme avant.
Donc c'est pas une alternative visiblement (dommage, ca aurait été simple :-))
A+
Je vais lancer ma prochaine appli sur un modèle payant, mais je garde en tête de la faire évoluer en freemium si jamais le payant ne prends pas. Dans ce cas, une mise à jour la passerait en gratuit avec fonctionnalités réduites + inAppPurchase pour la version complète.
Je ne veux cependant pas pénaliser les acheteurs de la première heure, et je dois donc mémoriser dès la 1.0 qu'ils sont déjà sur une version complète, au cas où la 1.1 serait freemium.
Comment à votre avis mémoriser cette info critique, puisque l'on sait que les prefs sont modifiables facilement.
Le Key Chain est-il adapté ? Sur Mac il est possible de modifier une valeur avec le Trousseau d'accès, mais je n'ai pas l'impression que ce soit possible en iOS.
Merci
Pas encore eu le temps d'essayer mais ça m'a l'air très efficace et transparent à l'utilisation une fois tout en place.
Tiens, je déterre ce sujet...
L'utilisation de Magical Record + CoreData s'étant révélée "magique" pour les nouvelles datas de mon appli, je songe à transférer mes fichiers plist en CoreData.
Seulement autant mes nouvelles données n'étaient pas critiques, autant les anciennes, c'est le coeur de notre passion et ça me ferait suer qu'on me le repique. Mes plist étaient cryptés en AES256. Mais si je bascule tout sur CoreData, comment ça marche ?
Sachant que c'est pour du iOS6/7. Quelles sont les best practices ?
Merci
- Doc Apple : Protecting Data Using On-Disk Encryption
- Et un article de Nick Harris (qui date de 2010 mais est toujours d'actualité même s'il parle de CoreData sans MagicalRecord) mais il suffit d'appliquer le même principe sur le fichier sqlite utilisé par MagicalRecord si tu utilise MR, le principe est le même.
Les gens, vous serriez gentil de parler de chiffrement et de chiffrer au lieu d'encryption ou de cryptage...
Sinon, avant d'aller plus loin dans ce domaine il est important de vous demander ce que vous chercher à faire :
Si nous somme dans le premier cas, c'est bien, mais arrêter de vous emmerder, la seule chose à faire c'est se reposer sur les API de cryptographie d'Apple et indiquer que vos données doivent être accessible uniquement lorsque le terminal est déverrouiller. Sauf à faire entrer un mot de passe à l'utilisateur à chaque fois, il est fort peu probable que vous fassiez une meilleur sécurité que ça.
Si nous sommes dans le second cas, rendez-vous bien compte que cela ne sert strictement à rien. La clef de déchiffrement étant forcément stocké sur le système (que ce soit via le keychain ou directement dans le binaire), 5min de reverse engineering amèneront quelqu'un de motiver à comprendre le système de chiffrement et trouver la clef. L'AES256 ne sera pas plus intéressant ici que du ROT13...
Perso, je suis dans le second cas...
/* mode provoc' */
Prouve moi que 5 mn suffisent en m'envoyant mes plist en clair
Moi j'utilise ça pour mon Sqlite:
http://sqlcipher.net
Le plus intéressant est que tu t'essaye toi même au reverse pour comprendre ce qu'est et ce que n'est pas une sécurité logicielle :-)
http://lightbulbone.com/post/27887705317/reversing-ios-applications-part-1
C'est un combat perdu d'avance :-) D'ailleurs il me semble que le terme cryptage apparaà®t dans les dico.