Orange Labs MAPS/DVC 2 avenue Pierre Marzin Lannion. Sous la responsabilité de : Pierre Crégut, Orange Labs Olivier Barais, Istic

Transcription

1 Rapport de stage Orange Labs MAPS/DVC 2 avenue Pierre Marzin Lannion Master Informatique (2e année) Julien Névo Sous la responsabilité de : Pierre Crégut, Orange Labs Olivier Barais, Istic Adaptation de la bibliothèque ASM pour Dalvik Stage e ectué du 7 mars au 6 septembre 2011 à Orange Labs, Lannion. Soutenance à Rennes le 29 août istic-contact@univ-rennes1.fr istic-stages-info@univ-rennes1.fr istic-stages-elec@univ-rennes1.fr ISTIC - UFR Informatique et Électronique Université de Rennes 1, Campus de Beaulieu 263, avenue Général Leclerc CS 74205, Rennes CEDEX, France

2 Résumé Mon stage en entreprise s'est déroulé du 7 mars au 6 septembre 2011 à Orange Labs à Lannion. Mon travail a consisté à adapter au bytecode Android la bibliothèque ASM, dont le but est de manipuler du bytecode Java. Cette nouvelle bibliothèque est nommée AsmDex. Bien que la plate-forme Android soit également basée sur Java, le bytecode de la machine virtuelle qu'elle utilise a été entièrement repensé. Malgré cette diérence, il me fallait rester au plus près des interfaces proposées par ASM, an d'une part que les développeurs connaissant déjà ASM puissent trouver facilement leurs marques, mais surtout an que les programmes utilisant ASM aient le moins de modications possible à subir pour utiliser AsmDex. Les deux axes principaux de la bibliothèque ont été adaptés : le premier permet la lecture et production du bytecode de manière linéaire, tandis que l'autre le fait à la manière d'un arbre. ASM dispose de plusieurs outils annexes, nous étudierons celui qui a été adapté dans la nouvelle bibliothèque. Abstract My internship started on 7 March and ended on 6 September of 2011 at Orange Labs in Lannion. My work consisted in adapting the library called ASM to the Android bytecode. ASM allows to manipulate the Java bytecode. The new library is called AsmDex. Although the Android platform is also based on Java, the bytecode its virtual machine uses has been fully reorganised. However, in spite of this dierence, I had to stay as close as possible to the original interface so that developpers experienced with ASM could easily switch to AsmDex, but mostly for the programs using ASM not to need modications when working with AsmDex. The two main axis of the library have been adapted : the rst allows the reading and the production of bytecode in a linear way, whereas the other allows to do it as a random, tree-based access. ASM provides several tools and we'll study the one I adapted to the new library.

3 Remerciements Je tiens à remercier M. Yves-Marie Quémener pour m'avoir accepté au sein de son équipe. Je remercie également M. Pierre Crégut pour son aide technique, pour avoir pris le temps de répondre pertinemment à toutes mes questions, mais aussi pour la relecture et les corrections de ce rapport. Enn, je remercie l'équipe DVC pour son accueil.

4 TABLE DES MATIÈRES Table des matières I Introduction 1 II Présentation de l'entreprise 2 1 L'entreprise Le groupe France Télécom Orange Labs Activité Organisation Le laboratoire Devices III Présentation de ASM 4 1 Présentation générale 4 2 La Core API Génération d'une classe Génération de code à partir d'un chier compilé existant Exemple d'utilisation de ltre La Tree API Génération d'une classe Génération de code à partir d'un chier compilé Exemple de transformation Les outils annexes 12 IV Présentation de Dalvik 13 1 Présentation de la machine virtuelle Dalvik Contexte de Dalvik : Android Architecture Les instructions Comparaison entre le bytecode de Dalvik et de Java Le format dex Présentation Compilation d'un chier.dex Les diérents éléments à encoder Le Constant Pool Les descripteurs La structure d'un chier.dex Ordonnancement, alignement et unicité Les chiers.odex Les chiers.apk Génération d'un chier.apk i

5 TABLE DES MATIÈRES 4 Comparaison entre la JVM et Dalvik 22 V Présentation de AsmDex 23 1 Présentation générale Changements par rapport à ASM Réutilisation de l'existant Adaptation de la Core API Lecture Écriture Adaptation de la Tree API 31 4 Création de l'outil AsmDexier Présentation de AsmDexier Implémentation Tests Le test de l'applicationreader Le test de l'applicationwriter Le test des Adapter Le test de l'asmdexifier Performances Comparaison entre les Reader Comparaison entre les Writer Comparaison entre le Reader et le Writer d'asm et d'asmdex Core API vs Tree API Utilisation du court-circuit Conclusion sur les performances L'avenir d'asmdex 36 VI Conclusion 37 VII Annexes 38 1 Patron de conception Visiteur 38 2 Exemple d'utilisation de AsmDexier 38 3 Diagramme de classes de ASM 41 4 Organisation du test de l'applicationreader 42 ii

6 Première partie Introduction Mon travail au cours de ce stage a consisté à adapter la bibliothèque ASM pour le système d'exploitation Android. ASM est à l'origine prévue pour manipuler du bytecode Java. Il existe déjà plusieurs bibliothèques similaires, mais ASM dispose de nombreux atouts, comme sa rapidité, sa faible consommation en mémoire et sa simplicité d'utilisation. Orange Labs souhaite pouvoir manipuler le bytecode Android de leurs applications de manière ecace. L'entreprise a logiquement porté son choix sur une adaptation d'asm pour le bytecode de Dalvik, la machine virtuelle des appareils utilisant Android. La nouvelle bibliothèque, baptisée AsmDex, devra réutiliser les mêmes interfaces que la bibliothèque dont elle est issue et si possible en garder tous les avantages. On veillera également à réutiliser son code au maximum. Je vous présenterai d'abord ASM, à quoi la bibliothèque peut servir, son architecture et comment l'utiliser. Ensuite, après une brève présentation du système d'exploitation Android, je vous présenterai la machine virtuelle Dalvik et la manière dont elle stocke et gère ses données. Nous étudierons alors le format dex qui regroupe tout le bytecode que la machine virtuelle devra exécuter. Puis nous étudierons en détail AsmDex, la bibliothèque que j'ai développée, sous ses deux aspects principaux : d'une part, la génération de bytecode de manière linéaire, d'autre part grâce à un parcours d'arbre. Je parlerai des principales dicultés techniques que j'ai rencontrées, des diérentes solutions envisagées et de celle que j'ai nalement choisie. Une dernière partie concernera AsmDexier, l'un des outils dont dispose ASM et qui est le seul qu'orange Labs avait besoin de retrouver dans AsmDex. Enn, je vous parlerai de l'élaboration des tests de notre nouvelle bibliothèque et établirai une comparaison entre ses performances et celles d'asm. 1

7 2 ORANGE LABS Deuxième partie Présentation de l'entreprise 1 L'entreprise 1.1 Le groupe France Télécom Historique du groupe France Télécom est l'opérateur historique en France. Descendant des P&T puis des PTT, l'entreprise se sépare de l'état en 1990 tout en restant nationalisée. Il faut attendre 1996 pour que France Télécom devienne une société anonyme. En 1997 une partie du capital de France Télécom est ouverte aux investisseurs et depuis 2004, l'état n'est plus actionnaire majoritaire. France Télécom est devenue une entreprise privée compétitive et leader sur ses principaux segments de marché, autour d'orange, la marque phare de France Télécom. Fig. 1 Implantation de France Télécom dans le monde Activités du groupe France Télécom est présent dans 32 pays et territoires, emploie près de salariés et comptabilise 216 millions de clients dans le monde au 31 mars Le chire d'aaires réalisé au premier trimestre 2011 s'élève à 11,2 milliards d'euros. Orange est l'un des principaux opérateurs européens du mobile et l'accès internet ADSL et l'un des leaders mondiaux des services de télécommunications aux entreprises multinationales, sous la marque Orange Business Services. 2 Orange Labs 2.1 Activité Orange Labs est le moteur de l'innovation du groupe France Télécom et de ses liales, en France et à l'étranger. Ses laboratoires sont à l'origine d'environ 80% des produits et services commercialisés par le Groupe. Avec ses ingénieurs, scientiques et chercheurs, ses implantations sur 4 continents et des investissements importants (900 millions d'euros chaque année), Orange Labs joue un rôle moteur dans la croissance du groupe France Télécom, avec pour missions principales de développer des produits et services, de dégager de nouvelles sources de croissance et d'imaginer les solutions du futur. Ainsi, tous les ans plus de 500 inventions sont brevetées, soit un total de plus de 8300 brevets déposés. 2

8 2.2 Organisation 2.2 Organisation Sous la responsabilité de Marie-Noëlle Jégo-Laveissière, Orange Labs se compose de 6 centres de recherche et développement (CRD) localisés majoritairement en France : Issy-les-Moulineaux, Lannion, Grenoble, Caen, Rennes et Sophia Antipolis. J'ai intégré le CRD Middleware et plate-formes avancées (MAPS). Ce CRD est dirigé par Nadine Foulon-Belkacémi. Il a pour mission de faire émerger des concepts innovants dans le domaine des plate-formes de services Orange. Il contribue aussi à la spécication et au développement technique des nouveaux produits du groupe. MAPS se concentre tout particulièrement sur le masquage de la complexité technologique dans les usages mobiles, multimédia et audiovisuels. Le but est d'enrichir l'expérience utilisateur avec simplicité et en lui garantissant un service de qualité et sécurisé. Fig. 2 Organisation du Centre de Recherche et Développement MAPS 2.3 Le laboratoire Devices J'ai été alié au laboratoire Devices (DVC), dont le but est de développer des applications sur mobiles. Une centaine de personnes en font parti, réparties dans divers laboratoires répartis en France (Lannion, Rennes, Caen, Paris) mais aussi à l'étranger (Angleterre, Chine, Pologne, République dominicaine). Le laboratoire se consacrait à l'origine aux mobiles équipés des systèmes d'exploitation Symbian, Windows Mobile et utilisant l'api 1 Java MIDP. Cependant, l'arrivée des iphones et des systèmes Android changea l'orientation de DVC. Les travaux du laboratoire concernent également la sécurité et la normalisation de la téléphonie mobile. 1 API : Interface de programmation (Application Programming Interface). 3

9 1 PRÉSENTATION GÉNÉRALE Troisième partie Présentation de ASM 1 Présentation générale ASM 2 est une bibliothèque développée en Java par France Télécom et l'inria à Grenoble, et diusée par ObjectWeb, un consortium visant à créer des applications middleware en open-source. ASM permet la décompilation, la modication et la recomposition de classes binaires Java grâce à une API simple qui parcourt les données compilées. Une seconde API, aposée à la première, permet le parcours en arbre. ASM peut être utilisée à de nombreuses ns : ˆ Analyser un programme an de le déboguer ou vérier son comportement. ˆ Générer du code, partiellement ou non. ˆ Obfusquer un programme. ˆ Faire du reverse-engineering. ˆ Faire de la programmation orienté aspect, en ouvrant une classe et en ajoutant du code avant, après certaines méthodes, ou appel de méthodes. Il existe déjà quelques outils permettant de manipuler du bytecode Java, notamment BCEL et Javassist. Cependant c'est sur ASM qu'orange Labs a porté son intérêt : ˆ ASM dispose d'une API simple, prend peu de mémoire avec l'api de base. ˆ BCEL est trois fois plus lent qu'asm et l'api est complexe. ˆ Javassist est lui aussi plus lent qu'asm et dispose d'un mode source qui rend la manipulation du bytecode très aisée, mais très gourmande en mémoire. ˆ Enn, ASM traite Java 6 dans son intégralité, notamment au niveau de la généricité et des annotations. Le laboratoire DVC auquel j'ai été alié souhaiterait manipuler le bytecode d'applications compilées an : ˆ d'explorer les programmes utilisés par certaines applications que DVC développe en sous-traitance mais dont il ne dispose pas des sources, à des ns de débogages. ˆ de tester et améliorer la sécurité de ces mêmes programmes. ˆ de dresser des statistiques sur un grand nombre d'applications pour voir quelles instructions sont les moins utilisées. Le but est de les remplacer par de nouvelles instructions utiles à certains traitements spéciques, comme l'optimisation de méthodes récursives. 2 ASM : 4

10 2 La Core API Comme son nom l'indique, cette API est la base d'asm et donc également de la seconde API et des outils annexes. Cette API utilise le patron de conception Visiteur (voir annexe 1 page 38) an de parcourir de manière séquentielle toutes les structures d'une classe Java compilée. Des événements sont produits par la lecture du chier. On peut faire le rapprochement avec le fonctionnement de SAX 3 pour le traitement de chiers XML. L'API se base sur les classes décrites sur le schéma 3. Elle dispose de trois pans bien distincts : La production d'événements en lisant du code : La classe ClassReader, comme son nom l'indique, lit les données d'une classe compilée et appelle les méthodes de tout visiteur héritant de ClassVisitor, donné en paramètre à sa méthode accept. Par exemple, la rencontre avec un champ appellera la méthode visitfield du visiteur, accompagné des paramètres permettant de l'identier. Les ltres : Dérivant de ClassVisitor, les ltres ne font par défaut que transmettre les événements vers un autre visiteur. L'idée est de leur ajouter du comportement an de retirer, ajouter ou transformer du code. La génération de code en recevant des événements : Le visiteur ClassWriter (héritant donc de Class Visitor) a pour rôle de transformer tout événement reçu en bytecode. En sortie, il fournira un tableau d'octets représentant un chier.class, c'est-à-dire en bytecode Java. Un visiteur donné par l'utilisateur et à qui on envoie des événements dénit le comportement à adopter : ˆ Accepter et transmettre les événements : la continuité du programme n'est pas perturbée et il demeure inchangé. ˆ Les ignorer : le programme perd des éléments. On a donc retiré du code par rapport à l'original. ˆ En ajouter de nouveaux : il y a production de code. Du nouveau code est ajouté. Fig. 3 Diagramme de classes de ASM 3 SAX (Simple API for XML) : 5

11 2 LA CORE API 2.1 Génération d'une classe Pour générer une classe, il sut d'utiliser un ClassWriter. Nous allons pour l'instant l'utiliser seul : la génération de code se fait donc de manière programmatique, à partir de rien. Regardons la petite interface suivante : public interface MyInterface { public static final int MIN = 0 ; public static final int MAX = 10 ; public int compare(int a) ; Cette interface pourra être générée par le ClassWriter grâce au programme suivant : ClassWriter cw = new ClassWriter(0) ; // Déclaration de l'interface à générer. cw.visit(v1_6, ACC_PUBLIC + ACC_ABSTRACT + ACC_INTERFACE, "nevo/myinterface", null, "java/lang/object", null) ; // Déclarations des champs que l'interface contient. cw.visitfield(acc_public + ACC_FINAL + ACC_STATIC, "MIN", "I", null, 0).visitEnd() ; cw.visitfield(acc_public + ACC_FINAL + ACC_STATIC, "MAX", "I", null, 10).visitEnd() ; // Déclarations de la méthode que l'interface contient. cw.visitmethod(acc_public + ACC_ABSTRACT, "compare", "(I)I", null, null).visitend() ; // On annonce la fin de l'interface. cw.visitend() ; // On génère le bytecode. byte[] b = cw.tobytearray() ; Les visiteurs d'asm ont chacun une interface précise et leur documentation respective dénit l'ordre dans lequel les visites doivent être eectuées. Il est très important de le respecter pour ne pas créer de sorties mal formées. L'ordre des appels d'un ClassVisitor est le suivant : visit [visitsource] [visitouterclass] (visitannotation visitattribute)* (visitinnerclass visitfield visitmethod)* visitend. Signaler le début et la n de la visite de la classe est obligatoire, tandis que visitsource (qui informe du nom du chier source de la classe) et visitouterclass (qui informe du nom de la classe qui englobe la classe actuelle dans le cas d'une classe interne) sont optionnels. Notre programme ci-dessus respecte bien l'ordre déni par l'interface. 2.2 Génération de code à partir d'un chier compilé existant La plupart du temps, on voudra modier une classe compilée existante. ASM le permet simplement en liant un ClassReader à un ClassWriter. Tous les événements déclenchés par le Reader sont traduits en bytecode pour le Writer. On obtient donc exactement le même chier en sortie, comme le montre le schéma suivant : 6

12 2.3 Exemple d'utilisation de ltre Fig. 4 Exemple simple de la Core API Le programme Java suivant montre comme eectuer cette opération : byte[] b1 =... ; // b1 est le bytecode à lire. ClassWriter cw = new ClassWriter() ; ClassReader cr = new ClassReader(b1) ; // Donne le bytecode au Reader. cr.accept(cw, 0) ; // Les événements du Reader sont transmis au Writer. byte[] b2 = cw.tobytearray() ; // On récupère le bytecode généré par le Writer. Bien sûr, le véritable intérêt consiste à ajouter des ltres an de transformer la classe. Ces ltres sont appelés des Adapter : Fig. 5 Exemple simple de transformation avec la Core API Cela se traduit par le code Java suivant : byte[] b1 =... ; ClassWriter cw = new ClassWriter() ; // L'Adapter 2 transmet les événements au Writer. ClassAdapter ca2 = new ClassAdapterAddMethods(cw) ; // L'Adapter 1 transmet les événements à l'adapter 2. ClassAdapter ca1 = new ClassAdapterSuppressMethods(ca2) ; ClassReader cr = new ClassReader(b1) ; // Donne le bytecode au Reader. cr.accept(ca1, 0) ; // Les événements du Reader sont transmis à l'adapter 1. byte[] b2 = cw.tobytearray() ; // On récupère le bytecode généré par le Writer. 2.3 Exemple d'utilisation de ltre Imaginons un ltre volontairement simpliste qui préxe tous les champs privés de la chaîne m_. Il sut de dériver ClassAdapter, qui va modier l'événement visitfield selon la nature du champ : public class ChangeFieldNameAdapter extends ClassAdapter { public ChangeFieldNameAdapter(ClassVisitor cv) { // Le constructeur sauvegarde le ClassVisitor donné afin de lui // transmettre les évènements, modifiés ou non. super(cv) public void visitfield(int access, String name, String desc, 7

13 3 LA TREE API... String signature, Object value) { if (((access & ACC_PRIVATE)!= 0) && (!name.startswith("m_"))) { name = "m_" + name ; // Transmets l'événement, modifié ou non. cv.visitfield(access, name, desc, signature, value) ; Fig. 6 Diagramme de séquence simplié pour ChangeFieldNameAdapter Bien sûr, changer le nom des champs lors de leur rencontre n'est pas susant pour produire un programme valide : il faudra aussi faire de même avec les références à ces champs, mais le but ici n'est que de montrer le principe de fonctionnement d'asm. Ce qui amène une remarque importante : il est tout à fait possible de produire un programme qui sera refusé par la JVM. Diérents outils présents dans ASM permettent de vérier la validité du bytecode généré, mais nous n'étudierons pas ces outils dans le cadre de ce rapport. Le diagramme de séquence 6 montre le cheminement des événements entre le Reader, l'adapter et le Writer. La visite des éléments se contente de donner des informations sur ce qu'elle lit immédiatement, ce qui constitue une limite de la lecture séquentielle : transformer une classe peut devenir dicile sans avoir l'application complète sur laquelle travailler. C'est pour résoudre ce problème qu'a été introduite la seconde API. 3 La Tree API Tout comme la Core API peut être rapprochée de SAX, la Tree API peut l'être de DOM 4 dans la manière de représenter tout élément comme un objet. Cette API produit un arbre de données an de pouvoir outrepasser la limite de la lecture séquentielle et permettre l'accès à n'importe quel élément n'importe quand. L'inconvénient est la quantité de mémoire nécessaire au stockage des structures de l'application complète. Cette API est également plus lente que la Core API, de par la création de nombreux éléments. Ces éléments sont appelés noeuds (nodes) et le schéma 7 page ci-contre montre leur hiérarchie. Trois choses sont à noter : 4 DOM (Document Object Model) : 8

14 Fig. 7 Diagramme de classe de la Tree API ˆ Tout d'abord, la Tree API est basée sur la Core API. En eet, chaque noeud dérive de manière directe ou indirecte d'un visiteur. ˆ Ensuite, chaque noeud dispose lui-même des attributs qui le caractérise, qui lui sont donnés lors de son instanciation. ˆ Enn, les noeuds possèdent une méthode accept qui produisent les événements nécessaires à la visite de sa structure et de ses sous-structures. La Tree API fonctionne sur ce principe : la Core API permet de paramétrer les noeuds, tandis les méthodes héritées de MemberNode gèrent l'accès et le parcours des sous-structures. Par exemple, voici le code partiel de ClassNode : public class ClassNode extends MemberNode implements ClassVisitor { public List<MethodNode> methods ; public void visit(final int version, final int access, final String name, final String signature, final String supername, final String[] interfaces) { this.version = version ; this.access = access ; this.name = name ; this.signature = signature ; this.supername = supername ; if (interfaces!= null) { this.interfaces.addall(arrays.aslist(interfaces)) ; 9

15 3 LA TREE API public MethodVisitor visitmethod(final int access, final String name, final String desc, final String signature, final String[] exceptions) { MethodNode mn = new MethodNode(access, name, desc, signature, exceptions) ; methods.add(mn) ; return mn ;... On peut voir que si exécuter la méthode visit ne fait qu'initialiser la classe, exécuter visitmethod instancie un noeud de méthode (ce qui initialise celle-ci) et la stocke dans la liste de méthodes que la classe possède. Les méthodes de visite de la classe génèrent donc l'arbre de données qui la compose. Enn, la méthode accept envoie les évènements nécessaires à la génération de l'élément courant et de ses sous-structures. Le code suivant montre comment un ClassNode génère ses évènements auprès du visiteur qui lui est donné : public void accept(classvisitor cv) { // Début de la visite de la classe. cv.visit(version, access, name, signature, supername, interfaces) ;... // Visite les champs. for (i = 0 ; i < fields.size() ; ++i) ((FieldNode) fields.get(i)).accept(cv) ; // Visite les méthodes. for (i = 0 ; i < methods.size() ; ++i) ((MethodNode) methods.get(i)).accept(cv) ; // Fin de la visite. cv.visitend() ; 3.1 Génération d'une classe Pour générer une classe telle que celle décrite par l'interface en page 6 et de manière programmatique comme en section 2.1 page 6, il sut de créer les noeuds comme le programme ci-dessous le montre. Rappelons que cette API nous permet de créer les éléments de la classe dans l'ordre désiré. ClassNode cn = new ClassNode() ; cn.version = V1_6 ; cn.access = ACC_PUBLIC + ACC_ABSTRACT + ACC_INTERFACE ; cn.name = "nevo/myinterface" ; cn.supername = "java/lang/object" ; cn.fields.add(new FieldNode(ACC_PUBLIC + ACC_FINAL + ACC_STATIC, "MIN", "I", null, 0)) ; cn.fields.add(new FieldNode(ACC_PUBLIC + ACC_FINAL + ACC_STATIC, "MAX", "I", null, 10)) ; cn.methods.add(new MethodNode(ACC_PUBLIC + ACC_ABSTRACT, "compare", "(I)I", null, null) ; ClassWriter cw = new ClassWriter(0) ; cn.accept(cw) ; // Génération du bytecode. byte[] b = cw.tobytearray() ; Comme dit précédemment, les noeuds possèdent une méthode accept. Cette méthode est appelée par l'élément hiérarchique supérieur et correspond à une demande d'envoi des événements au visiteur qui lui est donné. 10

16 3.2 Génération de code à partir d'un chier compilé Il sut par exemple qu'un programme appelle la méthode accept d'un ClassNode avec un ClassWriter en paramètre, pour que le ClassNode en question envoie les événements nécessaires à sa génération. Cela se traduit également par un appel à la méthode accept de chacune de ses sous-structures. Le diagramme de séquence 8 montre la création de la classe MyInterface décrite en page 6. Fig. 8 Diagramme de séquence d'une génération de classe avec la Tree API 3.2 Génération de code à partir d'un chier compilé Pour générer une classe à partir d'un chier.class, il faut composer la Tree API avec la Core API : byte[] b1 =... ; ClassReader cr = new ClassReader(b1) ; ClassNode cn = new ClassNode() ; cr.accept(cn, 0) ; Chaque événement produit par le Reader est envoyé au visiteur qui lui est donné, soit le ClassNode dans le cas présent. Cela a pour eet la création de la classe entière, comme le montre le schéma 9 page suivante. Notons que la visite de la méthode ne consiste que d'un visitend, car il s'agit d'une interface et ne contient aucune instruction. On peut alors maintenant générer le bytecode de la classe nouvellement créée en faisant visiter le ClassNode pour un ClassWriter : ClassWriter cw = new ClassWriter(0) ; cn.accept(cw) ; b2 = cw.tobytearray() ; 3.3 Exemple de transformation Eectuer la même transformation qu'avec la Core API (voir section 2.3 page 7) est un peu diérent. Une fois la classe visitée (et donc stockée), il faut parcourir ses éléments pour les modier. 11

17 4 LES OUTILS ANNEXES Fig. 9 Diagramme de séquence de génération de code à partir d'un chier compilé, avec la Tree API byte[] b1 =... ; ClassReader cr = new ClassReader(b1) ; // Donne le bytecode au Reader. ClassNode cn = new ClassNode() ; cr.accept(cn, 0) ; // Initialise la classe et génère ses éléments grâce au Reader. // Parcours des champs de la classe pour transformation. for (FieldNode field : (List<FieldNode>)cn.fields) { if (((field.access & Opcodes.ACC_PRIVATE)!= 0) && (!field.name.startswith("m_"))) { field.name = "m_" + field.name ; // Génération du bytecode à partir du noeud de la classe. ClassWriter cw = new ClassWriter(0) ; cn.accept(cw) ; byte[] b = cw.tobytearray() ; Le procédé est plus lent, car il s'eectue en au moins deux passes alors qu'avec la Core API, la transformation s'eectue au moment de la visite. Cependant, tous les éléments de la classe sont connus ce qui permet de faire des traitements plus conséquents. 4 Les outils annexes ASM dispose de plusieurs outils annexes mais seul l'un d'entre eux sera étudié et adapté dans notre nouvelle bibliothèque. ASMier Cet outil génère le code Java qu'il faudrait exécuter pour générer le chier de classe compilé donné à ASMier. Cet utilitaire étant adapté dans AsmDex, il sera étudié plus en détail en section 4.1 page 32. TraceClassVisitor Cet outil permet d'acher le texte des classes visitées et de leur contenu. Cela permet donc d'obtenir une trace des événements, ce qui peut être très utile pour du déboguage. CheckClassAdapter Cet utilitaire permet de valider l'ordre des événements (et leurs paramètres) qu'il reçoit et transmet, an d'assurer que le bytecode généré soit valide et ainsi accepté par la JVM. 12

18 Quatrième partie Présentation de Dalvik 1 Présentation de la machine virtuelle Dalvik 1.1 Contexte de Dalvik : Android Dalvik est la machine virtuelle du système d'exploitation Android. Celui-ci fut créé à la base par la société Android Inc. en 2003, avant que Google ne la rachète en On peut trouver Android sur de nombreux appareils mobiles tels que les SmartPhones, Netbooks et tablettes. Le nombre de mobiles équipés de cet OS dépassait les 101 millions d'unité au premier quart de 2011, représentant alors 35% du marché des mobiles. Android est basé sur Linux, diusé principalement en open-source et permet le développement d'applications en Java. Leur code compilé est interprété par une machine virtuelle appelée Dalvik 5, mais ce code est incompatible avec la machine virtuelle de Java (JVM). Dalvik permet aux applications d'accéder au middleware d'android. 1.2 Architecture La machine virtuelle Dalvik a été créée spéciquement pour Android. C'est une machine à registres, à l'inverse de la JVM qui est une machine à pile. Une étude[4] montre que, bien que plus complexe à mettre en oeuvre, une machine à registres nécessite 47% moins d'instructions qu'une machine à pile lors de l'exécution d'un programme, pour un code 26% plus large. Le gain en rapidité est notamment dû aux similitudes entre l'architecture des instructions lues et celles des processeurs exécutant Dalvik. Puisqu'elle est une machine virtuelle, Dalvik interprète le bytecode des programmes qui lui sont donnés. Ceux-ci sont compilés au format dex qui sera étudié en section 2 page 15. Depuis la version 2.2, Dalvik dispose d'un compilateur Just-In-Time (JIT), dont la stratégie est de compiler le bytecode, le mettre en cache et le réutiliser autant de fois que nécessaire. JIT permet un gain de vitesse propre à la compilation statique, avec cependant un coût en mémoire pour le stockage du code compilé et un léger temps de compilation au lancement de l'application pendant que la compilation JIT s'eectue. 1.3 Les instructions Dalvik dispose de 217 instructions[3], ce qui permet un encodage de l'opcode (le numéro qui identie l'instruction) sur 8 bits. En revanche, l'adressage se fera toujours par mot de 16 bits, ce qui permet de multiplier par 2 le champ d'adressage. En conséquence, même la plus petite instruction sera encodée sur 16 bits et les autres par multiples de 16 bits. La plupart des instructions ayant des paramètres, il n'y a que très peu d'espace mémoire perdu par cette organisation de données. Les arguments d'une instruction sont ordonnés : la destination apparaît en premier, suivi de la ou les sources. Les opérations eectuées par Dalvik sont aussi classiques que peuvent être celles de n'importe quel processeur : aectations entre registres, aectations d'une valeur à un registre, sauts conditionnels ou non, opérations arithmétiques etc. On trouve cependant des instructions de plus haut niveau qui permettent la gestion de tableaux uni-dimensionnels, de switch/case et try/catch, d'invocations de méthodes avec ou sans paramètres, et d'instanciations d'objets. Il existe également des instructions optimisées qui seront évoquées en 2.8 page Les registres Dalvik étant basée sur une machine à registres, il est logique qu'il en manipule. Ceux-ci font systématiquement 32 bits. La taille allouée à leur désignation varie selon l'instruction, mais elle peut atteindre 16 bits, soit Ce nom étrange est en fait le nom du village Islandais où auraient vécu les ancêtres du créateur de la machine virtuelle, Dan Bornstein. 13