Reversing / Modification / Optimisation des apk => futur [Tuto]?

[Gonfreecs]

Bonjour à tous je ne sais pas trop ou poster un sujet pareil mais je pense que je ne me trompe pas trop ici. (Ce post sera largement modifié au fur et à mesure des réponses s'il y en a :p)

Voila ma démarche :

J'ai récemment commencé à pas mal modifier le système android (libdvm, différents outils) pour des questions d'optimisation, ou d'apparence.

l'étape suivante c'est le reversing d'apk / jar. Ce que j'ai appris :

Les applications android ont pour la plupart l'extension .apk (ou .jar bien connu en Java pour certains composants système comme le framework).

Ce ne sont rien d'autre que des zip contenant certains fichiers, notamment :

• assets : différents fichiers images / son
  
• META-INF : le certificat permettant de vérifier la signature de l'application et les signatures SHA1 des fichiers importants
  
• res : Toutes les ressources de l'application (images, animations, layout xml...)
  
• AndroidManifest.xml : Hashs (signés?) de tous les fichiers de l'application
  
• classes.dex : byte code dalvik exécutable
  
• ressources.arsc : ????
  

( 1 ) Outils :

Un zipper (7zip, Izark...)

Sun/Oracle JDK (pour pouvoir signer les applications)

Smali/BackSmali pour assembler / désassembler le byte code => ici

Dexopt-wrapper pour optimiser le byte code =>ici

Comment reverser un byte code optimisé => ici

( 2 ) Modification d'applications utilisateurs (/data/app) :

Un wiki très clair et bien présenter explique bien le sujet => ici

Il est donc plutôt facile de "dézipper" une application, modifier les ressources ou le code, de la "recompresser" (j'utilise 7zip personnellement) :

7z a -tzip -mx1 toto.apk *

Le niveau de compression variant de mx0 (stockage) à mx5 (mx0 et mx1testé avec succès).

La signature de la nouvelle application se fait facilement (voir le tuto précédemment cité).

Seul hic, le certificat / la signature de l'application ayant changé, les mises à jour ne marchent plus :P

( 3 ) Modification d'applications système :

Sur le principe rien ne change. En pratique...

Le fameux classes.dex contenant le byte code est enlevé de l'application (il ne sera donc pas stocké dans le cache de dalvik sur la partition data, ce qui garanti l'intégrité de ce byte code alors non modifiable par l'utilisateur), optimisé statiquement (dexopt), renommé en .odex et stocké dans le même répertoire que le .apk / .jar correspondant (/system/app ou /system/framework par exemple).

A partir de la deux possibilités :

( 3.1 ) APPLICATIONS / DONNES (/system/*/*.apk) :

Rien ne change vraiment les hashs / signatures / fichiers sont toujours la à l'exception du classes.dex qui est optimisé et stocké en .odex, et que logiquement le hash du .odex n'est plus dans l'application. Seul une ouverture de ces .apk en graphique avec 7zip ou Izark et le remplacement de png par de nouveau par exemple marche, bien que cela fasse changer la signature de ces fichiers... Magie magie? :P

( 3.2 ) FRAMEWORK (/system/framework/*.jar) :

La on rentre dans un autre monde :P. Plus de hashs / signatures stockés dans les .jar. Cependant comme les .odex des applications un contrôle d'intégrité est toujours effectué et rend impossible leur modification. Magie magie? :P

Je suis donc en mesure de modifier le layout / les images du système mais pas son code.

Donc voila, je vous ai fait partager mes tests et déductions, en espérant avoir des retours et au mieux des explications si quelqu'un sait comment faire ;)

Modifié 23 juin 2010 par Gonfreecs

[bsegonnes]

Le bytecode généré par Eclipse n'est donc pas optimisé ? Il est possible d'en remettre une couche ?

L'idéal serait un pluging Eclipse qui se lance automatiquement pour optimisez le .apk lors de nos développements...

- Est-ce possible ?

- Un volontaire ?

[Gonfreecs]

En fait l'optimisation dépend très fortement du matériel =)

C'est donc une opération qui ne peut être faite qu'a l'installation ou pour un androphone donné. C'est complètement contraire a la notion de portabilité des applis android ^^' Mais convient très bien aux applis du système :)

[bsegonnes]

OK. On ne peut donc pas optimiser le bytecode java/dalvik. Domage

Merci pour la réponse.

[Puni]

Hum, si je comprends bien, à partir du fichier apk tu peux retrouver et modifier le code source de l'application ? o_0

[Grummfy]

apk => jar "spécial" +> jar peux contenir ou non les sources mais surtout le bytecode peux facilement être retrouver... avec assez d'efficacité.

Maintenant pour les dev qui font du propriétaire il existe des obfuscateur de code évitant que le code retrouver soit facilement lisible et compréhensible ...

[Gonfreecs]

Hum, si je comprends bien, à partir du fichier apk tu peux retrouver et modifier le code source de l'application ? o_0

Non pas du tout :P

Ce qui est disponible c'est le byte code de dalvik du programme, c'est de l'assembleur de machine virtuelle avec tous les appels des fonctions, leurs paramètres, le contenu des registres etc etc...

C'est beaucoup moins clair qu'un code source, ça peut-être obfusqué / packé pour éviter le reversing mais c'est pas incontournable tout ça :)

Puis un jar c'est un zip tout ce qu'il y a de plus normal (juste renomé) qui peut être signé (contient un dossier spécial renfermant les signatures). Exactement la même chose pour les apk ;)