ADB Lock non-root mode [fr / en]

English version below…

Android réserve ses fonctions les plus sensibles aux applications "système". C'est par exemple le cas de "Paramètres", l'application système que vous utilisez le plus souvent, qui est autorisée à activer ou désactiver ADB sans recourir au root.

Une application Système est une application classique : elle est au format APK, elle doit déclarer ses permissions. LA différence est qu'elle est placée dans /system/ (un dossier spécial et protégé) au lieu de /data/app comme toutes les autres apps.

L'app ADB-Lock est capable de détecter toute seule si elle est Système et dans ce cas cesse d'utiliser le mécanisme ROOT pour permuter l'état de l'ADB.

Il y a au moins 4 manières de passer ADB-Lock en mode Système : avec une app, avec le shell adb, avec un script  ou avec un zip (recovery ou TWRP). Bref vous avez l'embarras du choix.

État de l'art de la triche sur Ruzzle… et plus encore !

mise à jour 2/07 : Présentation de Ruzzle+GIF et synthèses des manipulations des vidéos.

Intro

What you must learn is that these rules are no different than the rules of a computer system...some of them can can be bent. Others...can be broken. Understand?  - Morpheus

Cette réplique de Matrix illustre assez bien ma conception de l'informatique en général et dans les jeux vidéos en particulier. Je triche, je cheat, je n'ai acun esprit de fair play, je ne respecte pas les règles du ou des développeurs mais je respecte les miennes : utiliser, comprendre, détourner, retourner. Bref … corrompre !

La première modification que j'ai apporté au Ruzzle concernait l'horloge. Mes manches durent 4 minutes, celles de l'adversaire 2. Malgré cet avantage mes adversaires arrivaient à taper des scores équivalents aux miens. Diable ! MAIS TOUT LE MONDE TRICHE !!!

fill_parent ou match_parent

Selon votre plus ou moins grande ancienneté avec le SDK Android, il doit vous arriver de mélanger au sein d'une même description d'interface XML des “fill_parent“ ou des “match_parent“ pour vos “android:layout_width“ ou vos “android:layout_height“.

Les deux valeurs sont équivalentes, le widget doit prendre toute la place laissée vacante dans le widget parent. La différence réside dans la version de l'API. Si votre projet vise les SDK < 7, vous devez utiliser “fill_parent“. Au delà, pour le SDK 8 et supérieurs, la valeur conseillée est “match_parent“.

Si votre projet vise un numéro d'API strictement plus grand que 7 :

find . -iname "*.xml" -exec sed -i "" "s/fill_parent/match_parent/g" {} \;

Si votre projet vise un numéro d'API strictement inférieur ou égale à 7 :

find . -iname "*.xml" -exec sed -i "" "s/match_parent/fill_parent/g" {} \;

Plus de lecture : ici (Anglais).

Mettre à jour un Galaxy Nexus chiffré sans perdre de données.

Dans un précédent billet, je donnais une méthode propre pour passer son Galaxy Nexus en rom aokp. Propre, ok mais au prix de vos données.
Il est possible de mettre à jour la partie ROM du terminal sans toucher à la partie RWM. Simple sans être trivial, voici comment faire.
Attention, cette méthode de mise à jour est conforme à l'esprit de la norme ISO 1664.

Sauvegardez vos données. Sauvegardez vos données. Sauvegardez vos données.

Cette méthode n'a été vérifiée QUE et UNIQUEMENT sur un terminal chiffré équipé d'une ROM AOKP.

Préparer la rom AOKP qui va bien.

Durant cette phase, les commandes seront exécutées sur mon ordinateur personnel. La préparation doit se faire sur une machine séparée pour plusieurs raisons :

• On ne peut pas échanger de données entre une session chiffrée et une session en clair (cwm).
• Zip et Bzip2 sont des opérations gourmandes en temps CPU et I/O.

Le billet est réalisé avec la build 32 de la rom aokp récupérable ici
Une fois téléchargé, je prépare 2 archives supplémentaires : system.zip et system.tar.bz2

$ cd /tmp/
$ unzip aokp_maguro_build-32.zip
$ cd aokp_maguro_build-32/system/
$ # Création de l'archive ZIP
$ zip -r ../../system.zip *
$ # Création de l'archive tar.bz2
$ tar cjf ../../system.tar.bz2 *

Un ordre d'idée des tailles obtenues :

$ ls -alh  /tmp/system.*
 -rw-r--r--  1 ckg  ckg   107M 17 avr 14:23 /tmp/system.tar.bz2
 -rw-r--r--  1 ckg  ckg   108M 17 avr 14:20 /tmp/system.zip

Sauvegardez apk+data (méthode intelligente)

Pour une sauvegarde en toute tranquillité, utilisez Titanium Backup ou Rerware Backup sur le play store.

Sauvegardez apk+data (méthode barbare)

~ # # Création des dossiers
~ # mkdir /mnt/sdcard/backup/apk
~ # mkdir /mnt/sdcard/backup/apk-data
~ # # Sauvegarde des apk
~ # cp /data/app/*.apk /mnt/backup/apk
~ # cd /data/data/
~ # # Purge des caches
~ # rm -r */cache/*
~ # # Dans l'absolu, lib/ est optionnel
~ # for i in *;do tar cjf /mnt/sdcard/backup/apk-data/$i.tar.bz2 $i;done;

Si vous souhaitez récupérer les sous-dossiers de /mnt/sdcard/backup via MTP il faut forcer le daemon mtp à recharger sa liste de fichier :

~ # pkill -HUP f_mtp 

il ne reste plus qu'a sauvegarder la carte SD.

Shell minimal : Clockwork Mode Recovery

La suite des opérations se fait dans le mode recovery.

$ adb reboot recovery

Une fois le recovery actif, je lance une session shell.
Le mount m'indique que seule la partition /cache est chargée :

~ # mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/block/platform/omap/omap_hsmmc.0/by-name/cache on /cache type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered)

Visiblement, pas de /system monté. Le chemin pour trouver /system est indiqué par /cache.
Pour monter /system :

~ # mkdir /x
~ # mount /dev/block/platform/omap/omap_hsmmc.0/by-name/system /x/

On peut vérifier :

~ # ls /x/
addon.d     build.prop  framework   media       tts         xbin
app         etc         lib         su-backup   usr
bin         fonts       lost+found  system      vendor

La partition /system/ n'est pas chiffrée.
Si votre téléphone est saisi par un tiers vous pouvez le considérer comme corrompu. Je reviendrai un autre jour sur le "comment détecter la compromission d'un terminal". C'est la fin de la phase de préparation depuis le shell minimal.

Pousser la rom aokp complete

Normalement, vous devriez avoir la place de pousser la rom complete dans le /data/media de votre terminal. Depuis l'ordinateur :

$ adb push system.zip /data/media

Depuis la session shell (adb shell)

~ # unzip -o /data/media/system.zip -d /x/

Si vous obtenez "unzip: zip flags 1 and 8 are not supported", utilisez l'archive system.tar.bz2 définie plus haut alors, depuis l'ordinateur :

$ adb push system.tar.bz2 /data/media

Depuis la session shell (adb shell)

~ # cd /data/media/
~ # bunzip2 system.tar.bz2
~ # tar xf system.tar -C /x/

Fin

Avant de débrancher, il faut umount puis reboot :

~ # umount /x/
~ # reboot

Reinstaller manuellement une sauvegarde RerBackup Root

Si comme moi vous effacez régulièrement le contenu de votre téléphone, la partie la plus pénible que vous devez rencontrer est la réinstallation de toutes vos applications. Lourdingue.

La solution passe par l'outil interne "pm" qui est la version en ligne de commande de PackageManager. Cet outil nécessite que vous soyez root sur votre terminal.

La commande magique est pm install avec comme option :

pm install: installs a package to the system. Options: -l: install the package with FORWARD_LOCK. -r: reinstall an exisiting app, keeping its data. -t: allow test .apks to be installed. -i: specify the installer package name. -s: install package on sdcard. -f: install package on internal flash.

Nous allons utiliser -r pour éviter les messages de type

pkg: com.endomondo.android.pro_63.apk Failure [INSTALL_FAILED_ALREADY_EXISTS]

Les commandes, avec la boucle bash qui va bien :

# cd /mnt/sdcard/rerware/MyBackup/AllAppsBackups/AppsMedia_2012_03_07/Apps
# for i in *.apk; do pm install -r $i;done;

That's all folks, tout en automatique. La restauration des données est un peu plus funky. Prochain Billet.