Android : la protection des licences déjà « facilement » détournée
Google minimise et défend son système de signature

Le , par Gordon Fowler, Expert éminent sénior
Mise à jour du 25/08/2010 par Idelways

Le système de protection des licences de l'Android Market, mis en place par Google il y'a moins d'un mois (lire ci-avant) est déjà craqué. Et d'une manière relativement simple.

Sur un message posté sur AndridPolice, un développeur prétend — démonstration à l'appui — pouvoir briser la protection LVL (Licence Verification Library) en changeant quelque lignes de codes.

Justin Case, l'auteur de l'article se dit pourtant « opposé au piratage et pro-Google » et explique que le but de sa démarche est d'améliorer les systèmes de protection des applications.

Pourtant, même si l'utilisateur lambda n'est pas en mesure d'exploiter directement cette faille, beaucoup d'utilisateurs avancés (dont font partie les membres de ce forum) peuvent craquer les applications et pourraient en distribuer des copies illégales.

La réponse de Google ne s'est pas faite attendre.

Tim Bray tente de clarifier quelques informations à propos de LVL.

Il concède que "la protection à 100% contre la piraterie n'existe pas pour les systèmes qui exécutent du code tiers", mais il dit qu'avec une bonne sécurité, il est possible de rendre extrêmement difficile et coûteux le piratage logiciel.

Bray prend la défense de son système de protection, qu'il qualifie de « très jeune », sa première version inclurait pour l'instant l'implémentation la plus simple et la plus transparente pour des raisons de clarté.

Dans le détail, l'exploit (ou plus exactement le « crack ») s'appuie sur le fait que les applications pour Android sont distribuées sous forme de byte-codes comme toute application Java. Ce bytecode peut être décompilé en un code source très proche du code original.

Une fois ce code obtenu, le « pirate » n'a qu'à trouver la classe LicenceValidator et changer le comportement de l'application quand le serveur de vérification répond que la licence est invalide. Ne reste plus qu'à recompiler et redistribuer l'application.



Une prochaine version de LVL devrait donc assez rapidement voir le jour.

Même si comme Tim Bray le souligne, cette première version est déjà très populaire auprès des développeurs. Et qu'elle rend, quoi qu'on en dise, la crackage des applications Android déjà nettement moins « user friendly » que par le passé.

Source : Site AndroidPolice

Lire aussi :

L'Android Market passe la barre des 100 000 applications

Android : premier « Cheval de Troie » camouflé dans un jeu, Tapesnake envoie le positionnement GPS du smartphone à des tiers

Oracle poursuit Google en justice pour son utilisation de Java dans Android : le succès de l'OS mobile attiserait-il les appétits

Et vous ?

Google arrivera-t-il à protéger les applications Android payantes contre le piratage ?

Quels protections proposez-vous pour y arriver ?

En collaboration avec Gordon Fowler

Android : nouveau système de sécurité pour protéger les applications
Payantes du piratage, elles devront se connecter aux serveurs de Google

Google lance un nouveau process d'authentification des applications payantes sous Android pour lutter contre le piratage. Ce nouveau « Licensing Service for Android » consiste à obliger l'application à se connecter aux serveurs de Google pour vérifier qu'elle a bien été achetée et non pas illégalement copiée... si son auteur souhaite protéger sa création bien entendu.

Cette sécurisation de type Cloud, pose quelques problèmes. La principale question, pour l'utilisateur, est de savoir ce qui se passe s'il veut utiliser l'application dans un endroit sans couverture internet.

Google précise que le développeur pourra choisir la fréquence du Ping avec les serveurs de Moutain View : à chaque lancement ou une fois par semaine par exemple.

Autre question : que faire lorsqu'une application piratée est repérée ?

Là encore le choix sera laissé au développeur. L'application pourra être bloquée ou, de manière plus commerciale, passer directement en mode de démo limitée pour pousser à l'achat.

Cette nouvelle fonctionnalité de contrôle pourra être implémentée sur les versions 1.5 et supérieures d'Android (autrement dit quasiment toutes les versions de l'OS). Le guide de développement se trouve ici.

Des détails techniques, notamment sur le nouvel outil du SDK (le License Verification Library, alias LVL) sont également exposés sur cette page.

Et comme un dessin vaut toujours mieux qu'un long discours, voici, en résumé, ces détails techniques :



Source : Annonce de Google

Lire aussi :

« Nous désactivons toute application qui s'avèrerait malicieuse pour l'utilisateur », répond Google, après l'étude sur Android Market

Les rubriques (actu, forums, tutos) de Développez :

Android
Sécurité
Mobiles

Et vous ?

En temps que développeur, trouvez-vous que ce nouveau mécanisme de protection soit une bonne idée ?

Et en temps qu'utilisateur ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de dams78 dams78 - Membre chevronné http://www.developpez.com
le 29/07/2010 à 13:59
Citation Envoyé par GanYoshi  Voir le message
Mais par contre tu tiens absolument à utiliser les applications qui nécessitent un accès au net toutes les semaines pour se lancer ?

Si non on est d'accord alors

Non non, je parlais de la seule appli que j'ai de payante : CoPilot, il s'agit d'un GPS, qui n'a donc pas besoin de se connecter au net.
Avatar de sinople sinople - Membre chevronné http://www.developpez.com
le 29/07/2010 à 14:28
Il y a de bonne et de mauvais chose dans cette API à mon avis.

Bien :
- Mettre à disposition une API de protection aux développeur permet à ces derniers d'être correctement rétribué pour leur travail. Et vu que sur smartphone le prix qu'est prêt à payer l'utilisateur est proche de 0, on imagine qu'il n'hésite pas à passer dans l'illégalité quand l'offre gratuite s'étouffe...

Particulièrement les "petits" développeurs qui n'ont ni le temps, ni les moyens de mettre en place leur propres solutions de protection.

Pas Bien:
- Il y a beaucoup trop de paramètre disponible pour le développeur qui peut rendre la protection de transparente à vraiment lourd pour l'utilisateur. Et comme il n'est pas possible pour le client final de savoir à quel point son application va lui casser les c*bip* avec ces protections avant l'achat.
Il suffira d'une mauvais expérience pour que ce dernier développe une certaine paranoia et se tourne définitivement vers les applications piratées.

Un truc développé par des ingénieurs pour des ingénieurs...
Avatar de mwyann mwyann - Candidat au Club http://www.developpez.com
le 05/08/2010 à 21:47
Déjà, le fait même d'avoir implémenté un système de cache des clés, c'est 90% de chances pour que des applis "For Root Users" voient le jour pour débloquer toutes les clés qu'on veut en un clic. Les pirates vont même se réjouir de n'avoir qu'une seule méthode à appliquer pour pirater n'importe quelle appli (par le biais de l'API) là où le piratage de chaque méthode de chaque développeur est bien plus longue. Mais soit.

Je pense que, encore une fois, et comme dans de nombreux cas que j'ai croisé, le plus embêté dans l'histoire ça va finir par être l'utilisateur légitime (exemples : le pirate va utiliser un NoCD là où le joueur légitime devrait à chaque fois insérer son CD, les dongles USB qui prennent un port USB et qui ralentissent l'application, le logiciel qui va avoir besoin de l'accès au net pour valider l'autorisation de fonctionnement, les étapes longues et fastidieuses pour insérer un numéro de série, enregistrement, activation là où un simple fichier exe cracké suffit...).

Maintenant, si je critique il faut bien que je propose autre chose en retour (c'est trop facile de critiquer). Malheureusement, il n'y a aucun système fiable et non contournable à ce jour, mais celui que je préconiserais le plus serait celle-ci :

Pour chaque utilisateur de portable sous Androïd (identifié par son identifiant Google), une clé de type RSA serait créée chez Google. La clé privée chez Google et la clé publique fournie au téléphone. Ensuite, dès lors qu'une application payante doit être installée, Google va au préalable signer le paquet d'installation POUR l'utilisateur (et le téléphone gardera l'apk signé), l'installation décodera l'apk par la suite (un apk marqué comme payant devrait obligatoirement être signé pour s'installer). De cette manière, impossible de se passer les apk car signés pour un utilisateur unique. Cela remettrait en cause l'installation des apk d'Android, mais il n'empêche pas une rétro-compatibilité (les terminaux incompatibles se verraient toujours fournir les anciens apk non signés).
Avatar de Idelways Idelways - Expert éminent sénior http://www.developpez.com
le 25/08/2010 à 13:14
Android : la protection des licences déjà « facilement » détournée
Google minimise et défend son système de signature

Mise à jour du 25/08/2010 par Idelways

Le système de protection des licences de l'Android Market, mis en place par Google il y a moins d'un mois (lire ci-avant) est déjà craqué. Et d'une manière relativement simple.

Sur un message posté sur AndridPolice, un développeur prétend — démonstration à l'appui — pouvoir briser la protection LVL (Licence Verification Library) en changeant quelque lignes de codes.

Justin Case, l'auteur de l'article se dit pourtant « opposé au piratage et pro-Google » et explique que le but de sa démarche est d'améliorer les systèmes de protection des applications.

Pourtant, même si l'utilisateur lambda n'est pas en mesure d'exploiter directement cette faille, beaucoup d'utilisateurs avancés (dont font partie les membres de ce forum) peuvent craquer les applications et pourraient en distribuer des copies illégales.

La réponse de Google ne s'est pas faite attendre.

Tim Bray tente de clarifier quelques informations à propos de LVL.

Il concède que "la protection à 100% contre la piraterie n'existe pas pour les systèmes qui exécutent du code tiers", mais il dit qu'avec une bonne sécurité, il est possible de rendre extrêmement difficile et coûteux le piratage logiciel.

Bray prend la défense de son système de protection, qu'il qualifie de « très jeune », sa première version inclurait pour l'instant l'implémentation la plus simple et la plus transparente pour des raisons de clarté.

Dans le détail, l'exploit (ou plus exactement le « crack ») s'appuie sur le fait que les applications pour Android sont distribuées sous forme de byte-codes comme toute application Java. Ce bytecode peut être décompilé en un code source très proche du code original.

Une fois ce code obtenu, le « pirate » n'a qu'à trouver la classe LicenceValidator et changer le comportement de l'application quand le serveur de vérification répond que la licence est invalide. Ne reste plus qu'à recompiler et redistribuer l'application.

[ame="http://www.youtube.com/watch?v=eMZ4qYbpN_s"]Vidéo : Briser l'Android Licensing Verification Library (LVL)[/ame]

Une prochaine version de LVL devrait donc assez rapidement voir le jour.

Même si comme Tim Bray le souligne, cette première version est déjà très populaire auprès des développeurs. Et qu'elle rend, quoi qu'on en dise, la crackage des applications Android déjà nettement moins « user friendly » que par le passé.

Source : Site AndroidPolice

Lire aussi :

L'Android Market passe la barre des 100 000 applications

Android : premier « Cheval de Troie » camouflé dans un jeu, Tapesnake envoie le positionnement GPS du smartphone à des tiers

Oracle poursuit Google en justice pour son utilisation de Java dans Android : le succès de l'OS mobile attiserait-il les appétits

Et vous ?

Google arrivera-t-il à protéger les applications Android payantes contre le piratage ?

Quelles protections proposez-vous pour y arriver ?

En collaboration avec Gordon Fowler
Avatar de galien galien - Membre averti http://www.developpez.com
le 25/08/2010 à 14:33
Pourquoi google n'utilise pas la sécurité de java tout simplement, il ont déjà pompé les 3/4 de la JVM avec Davik, ils en sont pas à ça près.
Avatar de MrDuChnok MrDuChnok - Rédacteur http://www.developpez.com
le 25/08/2010 à 14:54
C'est quoi cette "sécurité de java" dont tu parles ?
Avatar de Médinoc Médinoc - Expert éminent sénior http://www.developpez.com
le 25/08/2010 à 15:20
En gros, Palladium est arrivé.

Enfin, cette faille est sûrement facile à corriger avec des signatures numériques sur le code...
Avatar de galien galien - Membre averti http://www.developpez.com
le 25/08/2010 à 16:08
"C'est quoi cette "sécurité de java" dont tu parles ?"

Je sais pas la signature des jars par exemple.
Les politiques de sécurités du class loader, etc...
Bref tout ça

Edit: dire sécurité de la plateforme d'exécution java serait plus précis.
Avatar de mwyann mwyann - Candidat au Club http://www.developpez.com
le 04/09/2010 à 17:51
Et, c'est bien ce que j'avais dit juste avant cette news, une API anti-piratage = une seule méthode pour cracker les programmes = la simplicité pour les pirates. La preuve...
Avatar de ferfich25 ferfich25 - Nouveau Candidat au Club http://www.developpez.com
le 08/10/2015 à 19:17
j'ai lu sur http://www.apkwow.com que toutes les applications payantes que vous publiez sur Google Play peuvent utiliser le service de gestion de licence de celui-ci, et vous pouvez gérer les licences de toutes vos applications à partir de votre compte sur la console développeur Google Play. Aucun compte spécial ou enregistrement supplémentaire n'est nécessaire. Par ailleurs, du fait que ce service n'utilise aucune API dédiée du framework Android, vous pouvez mettre en œuvre le système de gestion de licence dans n'importe quelle application existante basée sur l'API niveau 3 ou une API de niveau supérieur.
Avatar de Paul TOTH Paul TOTH - Expert éminent sénior http://www.developpez.com
le 09/10/2015 à 9:22
Citation Envoyé par galien  Voir le message
Je sais pas la signature des jars par exemple.
Les politiques de sécurités du class loader, etc...
Bref tout ça

Edit: dire sécurité de la plateforme d'exécution java serait plus précis.

le lien que tu donnes implique la sécurisation du code, pas l'intégrité de l'application.

Si je prend une appli Java, que je la décompile, la modifie et la recompile, elle pourra toujours s'exécuter.
Offres d'emploi IT
Administrateur(trice) systèmes
NAMESHIELD - Pays de la Loire - Angers (49000)
ERP Developers
OpenERP sa - Luxembourg - Garnich
Managers grands projets si
EXTERNATIC - Pays de la Loire - Nantes (44000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil