Comme nous pouvons le lire dans le tutoriel « L’extraction d’apk d’un appareil Android via QtADB sur PC », il existe de bonnes raisons de vouloir copier un apk depuis un appareil Android via un PC. Dans ce même tutoriel, nous pouvons voir qu’il est possible d’utiliser les explorateurs Android pour PC, et que lesdits explorateurs sont en fait des interfaces graphiques pour ADB (ADB est un des outils développés par et pour les programmeurs Android, qui permet de communiquer avec un appareil Android ou un émulateur). Oui mais voilà…
Android progresse très vite et ADB suit également cette évolution. Par exemple les explorateurs proposent en général la possibilité de réaliser des captures d’écran alors que ADB est, depuis KitKat, en mesure de réaliser des captures animées au format mp4. Les ROMs de certains fabricants, tel SAMSUNG, présentent quelques spécificités que ne gèrent pas les explorateurs en question (comme les liens symboliques qui pointent sur les applications).
Parmi les explorateurs que nous avons eu l’occasion de tester, tous présentaient des failles, de surcroît, comme nous l’avons vu plus haut, ceux-ci ne sont guère plus que des interfaces graphiques pour ADB. Utiliser une application qui utilise une application qui utilise une application qui utilise une application, etc. c’est multiplier les risques d’erreur.
C’est pourquoi nous allons voir comment utiliser ADB …
Dans le tutoriel mentionné plus haut, nous pouvons également y lire que ADB est peut-être déjà sur notre PC – puisque nombre de programmes incluent celui-ci dans leurs ressources – ou que nous pouvons le télécharger en utilisant le SDK Manager, un gestionnaire spécialisé, comme expliqué dans le tutoriel : Installation de adb sans le SDK Android en utilisant le SDK Manager
Pour être sûr d’avoir la dernière version de ADB, il est préférable d’installer celui-ci via le SDK Manager.
Quelles que soient vos motivations, l’importation d’apk système dans une ROM, le reverse-engineering, etc. sortent du cadre du tutoriel et sont l’affaire d’autres tutos.
Prérequis
- ADB (est-il nécessaire de le dire ?).
- Le JDK installé sur le PC.
- Un appareil Android rooté et BusyBox installé sur celui-ci.
- Pour utiliser « ADB » il faudra également que le mode débogage soit activé sur l’appareil et que les drivers de ce dernier soit installés sur le PC, si ce n’est pas le cas, suivez le tutoriel « suivant » pour activer le débogage USB sur votre mobile et ce tutoriel pour installer les pilotes USB de votre mobile sur votre PC.
- Effectuez toujours une sauvegarde de votre appareil avant d’utiliser un outil capable d’intervenir sur votre système, Voici deux excellents tutos sur le sujet :
Utiliser ADB pour extraire des APK depuis son mobile vers son PC
Si vous avez opté pour utiliser une version de ADB embarquée par un programme comme VTS, Kingo ou Apk_OneClick ou que vous ne connaissez pas bien la console, je vous invite à consulter le tutoriel sur l’emploi du SDK Manager cité plus haut, où l’on peut voir comment lancer ADB ou l’ajouter aux variables d’environnement de Windows.
Étape 1 :
Tout d’abord connectons notre appareil – mode débogage activé – à notre ordinateur.
Étape 2 :
Pour obtenir la liste des applications tierces installées, lançons ADB avec les arguments adéquats, pour cela dans la console, nous tapons : adb shell pm list packages -f -3
Nous obtenons la liste et la localisation des applications tierces sur notre appareil (les couleurs sont celles du tutoriel afin de simplifier la lecture) :
- répertoire en vert
- nom de l’application une fois installée en jaune
- le signe égal « = »
- en bleu le nom du paquet
Étape 3 :
Nous copions le chemin complet, c’est à dire « répertoire/nom de l’application une fois installée » (vert/jaune). Maintenant, Nous tapons : « adb pull » et collons le chemin de l’apk (dans notre exemple : « /data/app/Macchanger.apk ») …
Étape 4 :
Nous constatons que l’application est extraite (dans le répertoire de ADB).
Quelques explications :
Le gestionnaire de paquets
Reprenons notre premier lancement de ADB et étudions les commandes et options :
- adb shell pm list packages -f -3
- adb : signal au système d’exploitation qu’on veut causer à ADB.
- shell : ouvre un interpréteur de commandes qui, via la console, permet d’utiliser les commandes UNIX situées sur l’appareil Android.
- pm : ouvre le gestionnaire de paquets (« package manager » un des outils situés sur l’appareil).
- list packages : commande au gestionnaire de lister les apk localisés sur l’appareil.
- -f : option « voir le fichier associé au paquet » passée à pm.
- -3 : option « afficher uniquement les applications tierces » passée à pm.
Si nous souhaitons n’afficher que les applications systèmes, il nous suffit de remplacer l’option « -3 » par « -s » et si nous souhaitons la liste de toutes les applications nous ne mettons pas d’option.
L’option « -f » nous est nécessaire puisqu’elle permet de connaître le chemin de l’apk ainsi que le nom de celui-ci une fois installé. Une autre façon de procéder pourrait être de d’abord obtenir la liste des paquets en ne mettant pas l’option « -f », puis, d’utiliser ensuite la commande « path ». Ce qui nous donne : adb shell pm list packages -3
Nous obtenons la liste des paquets. Nous cherchons le nom du paquet, le copions, puis nous tapons :
« adb shell pm path nom_du_paquet » (dans notre exemple « com.wireless.macchanger »).
Nous obtenons le chemin du fichier associé au paquet. Il ne reste plus qu’à extraire l’apk via la commande « pull » comme nous l’avons vu précédemment.
La commande « pull »
La syntaxe de « pull » est la suivante : pull
La commande « pull » (tirer en français) permet d’extraire des fichiers ou répertoires depuis, qui est un terminal ou un émulateur Android, sur, qui est la machine qui a lancé ADB. Plus simplement, est le chemin du répertoire ou du fichier à extraire et est le chemin de destination de la copie hors de :
- Si est le chemin d’un fichier, peut être soit le chemin d’un répertoire, soit celui d’un fichier, dans le premier cas le chemin de celui-ci se terminera par un nom de répertoire existant, dans le second par un nom de fichier facultatif qui sera attribué à la copie.
Ainsi la commande suivante copiera l’apk « xxx.apk » dans le répertoire « Destination » en renommant le fichier en « yyy.apk » dans la foulée : adb pull /system/app/xxx.apk Destinationyyy.apk
Alors que « adb pull /system/app/xxx.apk Destination » ne modifiera pas le nom du fichier. - Si le ou les répertoires qui composent le chemin de destination n’existent pas, ceux-ci seront créés dans la foulée, un nom de fichier est impératif. Par exemple : adb pull /system/app/xxx.apk nouveau_repertoirexxx.apk
Attention : si le nom du fichier est omis, l’apk sera – dans notre exemple – renommé « nouveau_repertoire » et placé sur le disque « C: ».
- Si est le chemin d’un répertoire, tous les fichiers présents dans celui-ci seront copiés. Ainsi pour extraire en une fois tous les fichiers situés dans « /system/app » nous taperons : adb pull /system/app repertoire_ou_copier_les_apk
Les apk du framework peuvent être obtenus de la même façon, le chemin est cette fois-ci : /system/framework
Petits bémols Sur certaines ROM Samsung (TouchWiz), le répertoire « /system/app » contient principalement des « raccourcis » vers le répertoire « /preload/symlink/system/app », qui comprend la plupart des applications système. C’est donc le chemin de ce dernier qu’il faudra donner à ADB. D’autres ROM (Acer, Sony etc.) comportent des apk dans les répertoires « /system/vendor/app » et « /vendor/overlay/framework ». Une parenthèse pour les slashs Le premier slash ou anti-slash ( / ou ) correspond au répertoire racine du système d’exploitation, les chemins suivant mèneront tous les quatre au disque « C: » :
- /
- C:
- C:/
Bien que sur Windows slashs et anti-slashs fonctionnent, une bonne habitude est d’utiliser des slashs pour les chemins sur l’appareil Android et des anti-slashs pour ceux de Windows et de proscrire les espaces et les lettre accentuées. Aller on slash!! Si j’ose dire… Une petite fantaisie pour copier sur le disque « C: » tout ce que ADB est en mesure d’extraire de l’appareil : adb pull / Ce qui ne présente aucune utilité évidemment et de surcroît peut prendre du temps si l’appareil contient beaucoup de fichiers volumineux (j’ai testé, je sais de quoi je parle!)
Le shell
Supposons maintenant que nous souhaitions copier l’application « xxx.apk » et la sauvegarder sur la carte sd, ce que la commande pull ne permet pas. Nous l’avons vu, ADB, via le shell, nous permet d’utiliser les commandes UNIX qui se trouvent sur l’appareil et justement une de celles-ci – « cp » (copy) – est là pour copier répertoires ou fichiers. En voici la syntaxe : cp [options] source dest Par exemple, pour copier l’apk système « xxx.apk » sur la carte sd nous tapons : adb shell cp /system/app/xxx.apk /sdcard En ajoutant l’option « -r », nous pouvons copier un répertoire. Ainsi, la commande suivante copiera le contenu du répertoire « /data/app » sur la carte sd : adb shell cp -r /data/app /sdcard N’hésitez pas à consulter les documentations concernant les commandes et essayez-les, la curiosité est souvent une bonne maladie… mais surtout : SAUVEGARDEZ, SAUVEGARDEZ, SAUVEGARDEZ!!! Si l’appareil est rooté mais que le kernel de celui-ci est un kernel d’origine (« fabricant »), il se peut que ADB ne puisse avoir l’accès root via le shell. Pour remédier à ce souci, utilisez l’application « [root] adbd Insecure » :
[root] adbd Insecure – Google Play
[root] adbd Insecure – APK
- adbd Insecure v2.00 (adbd-Insecure-v2.00.apk)