Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Archive for 2011

Niveau :      
Résumé : iptables android

Maintenant nous savons tout ce qui passe par la tête d'un android. Mais on a découvert des choses qui ne nous plaisent pas.

Couper des communications

Donc vous voulez interdire certaines communications, par exemple la connexion au serveur de votre ennemi héréditaire (on ne sait jamais, la paranoïa peut mener loin).

C'est simple linux a un firewall, profitez-en et utilisez iptables pour couper la communication :

# toujours sur le téléphone
$ chroot $ROOT
$ iptables -A OUTPUT -d 10.0.0.1 -j DROP

Au fait vous savez comment s'affichent les pubs ? ;-)

Proxy transparent

Vous pouvez même filtrer un peu mieux tout simplement en, redirigeant le traffic vers un service adapté.

C'est simplement la technique du portail captif, mais cette fois à votre avantage. Par exemple pour rediriger le DNS vers votre serveur local :

$ iptables -A OUTPUT -p udp --port 53 -j REDIRECT
$ iptables -A OUTPUT -p tcp --port 53 -j REDIRECT
/// 

Bien sûr il faut mettre un serveur dns local que vous maitrisez.

Et bien sûr vous pouvez faire pareil avec un proxy http qui prendra la décision au niveau du dessus.

$ iptables -A OUTPUT -p tcp --port 80 -j REDIRECT ///

Et pour ceux qu'android n'intéresse pas, n'oubliez pas que ça marche aussi sur votre passerelle à l'entrée de votre réseau ou n'importe quel PC ...

Niveau :      
Résumé : tcpdump ssl ; ptrace ; ltrace

Vous attendez la suite de mon article sur ce qui passe par les oreilles d'un android ? Hé bien vous allez attendre encore un peu ...

Lorsque vous récupérez via tcpdump un flux SSL (au hasard du https), il est chiffré et c'est justement l'intérêt du SSL de vous empêcher de lire ce flux.

Mais si si vous maitrisez une des deux extrémités, il devrait être normal que vous puissiez lire ce flux. C'est pourquoi nous allons le faire.

Côté serveur

Dans le cas où vous maitrisez le côté serveur, il suffit d'ouvrir la trace tcpdump (sauvegardée avec l'option -s0 -w file) sous wireshark et de le configurer pour qu'il utilise la clé serveur pour déchiffrer le flux :comme ici et de choisir de suivre le flux ssl au lieu du flux TCP.

C'est simple et efficace.

Côté client

Maintenant si vous êtes côté client sans certificat client, vous êtes coincés. Et c'est là que j'ai une solution à vous proposer.

Il existe plusieurs moyen pour espionner vos processus, tout d'abord vous pouvez créer un wrapper autour de la lib SSL et utiliser LD_PRELOAD pour la charger avant le processus. C'est bien mais difficile à mettre en œuvre, surtout si le processus tourne déjà, je vous laisse explorer cette voie de votre côté.

La deuxième solution est d'utiliser ptrace pour espionner le processus. Techniquement complexe, cette méthode nous est grandement facilitée par l'outil ltrace.

Pour la suite je vais supposer que les services à espionner passent par openssl, mais rien ne vous empêche de faire la même chose avec gnutls.

Espionner un processus

C'est simple :

# vous le lancez directement : 
$  ltrace ma commande
# ou vous espionnez un processus qui tourne déjà 
$ ltrace -p pid

Ça vous montre le fonctionnement, mais c'est aussi illisible qu'un strace.

Espionner le SSL

Ajoutons quelques options pour trier ce fouillis :

$ ltrace -l /usr/lib/libssl.so.0.9.8 -s 20000 -e SSL_read,SSL_write

Et voilà, la liste des appels ! Mais ce n'est pas suffisant.

Ajoutons les lignes suivantes dans /etc/ltrace.conf (ou dans ~/.ltrace.conf) :

int SSL_read(addr,string[retval],int);
int SSL_write(addr,string[arg3],int);

On relance la commande et maintenant nous avons le contenu de la communication en clair.

Mais il y a un petit bug dans ltrace, string[retval] devrait couper les chaines de SSL_read en fonction de la valeur de retour, mails ne le fait pas.

Corrigeons cela avec un petit script de formatage et cette fois nous avons toute la communication en clair !

$ ltrace -l /usr/lib/libssl.so.0.9.8 -s 20000 -e SSL_read,SSL_write -p pid 2> /tmp/trace
$ perl -pe 's/(SSL_read.*?, ")(.*)(".*? )(\d+)$/$1.substr($2,0,$4).$3.$4/e' /tmp/trace | less

Niveau :      
Résumé : tcpdump, wireshark

Espionnage

Tout le monde le sait, les téléphones nous espionnent. Mais que communiquent-ils ? A qui communiquent-ils ? Que peut-on y faire ?

Aujourd'hui nous somme armés d'une vraie distribution GNU. Nous pouvons donc utiliser des vrais outils.

# on se connecte sur le téléphone
$ ./adb shell
# mettez votre debian dans ce $ROOT
$ chroot $ROOT
$ apt-get install tcpdump
$ nohup tcpdump -i any -s 0 -w /tmp/dump.`date +"%Y-%d-%m"` &

maintenant déconnectez-vous et laissez tourner toute la journée dans son coin après avoir vérifié qu'il reste de la place sur le disque.

Quelque temps plus tard; :

# sur le téléphone
$ chroot debian
$ pkill tcpdump
# sur le pc
$ ./adb get $ROOT/tmp/dump.*

Analyse

Maintenant revenons à notre poste et regardons ce qui s'est passé. Pour cela on utilise wireshark.

On ouvre le fichier dump et c'est parti :

  • on trie par protocole -> LARQ, DNS, ipv6, http, https, ...
  • on trie par adresse -> on a la liste de qui communique avec notre machine
  • on liste des requêtes dns -> on a les noms des précédents

Ce que j'ai découvert pour l'instant

LARQ (limited automatic repeat request) : protocole utilisé pour la retransmission rapide de frame en cas de perte sur la couche de liaison. Très pratique pour améliorer la qualité des transmissions. On ne trouve quasiment pas d'infos sur le net à ce sujet, à part un brevet.

IPv6 : il est activé par défaut chez moi, ouf

DNS : il semble qu'android utilise le resolver public de google (pratique pour ne pas être embêté par les limitations de l'opérateur et les problèmes de configuration).

Niveau :      
Résumé : debootstrap --foreign ; debian.apk

Android is Not GNU

Maintenant qu'on est root, on peut faire tout ce qu'on veut sur notre android. Mais il faut bien avouer que busybox est assez limitée pour les habitués des systèmes GNU que nous sommes.

C'est pourquoi nous allons mettre un système GNU complet sur notre android. Et de préférence sans influer sur la bonne marche du téléphone.

Pour cela, il faut laisser tourner l'android tel quel, et surtout garder son noyau. Mettre un 2e système sur un noyau qui tourne, on sait faire, dans sa version la plus simple ça s'appelle un chroot, c'est disponible de base et c'est exactement ce dont on a besoin.

Notez que les commandes indiquées ici se basent sur un shell et les commandes fournies par busybox telles qu'installée dans l'article précédent. Vous pouvez vous en passer, mais quelques adaptations seront nécessaires (par exemple -o bind à la place de --bind).

Comment qu'on fait ?

Comment créer un chroot sans se presser ?

Choisissons (au hasard) la distribution debian. Elle nous propose ... wait for it ... un créateur de chroot. Il s'appelle debootstrap.

Seul problème nous ne pouvons pas le lancer directement sur le téléphone. Il faut donc le lancer sur une autre machine. Et à moins d'avoir une machine arm sous le coude, nous ne serons pas sur la bonne architecture.

Heureusement debian est bien structuré et debootstrap a tout prévu. Nous allons le lancer 2 fois. La première fois sur notre machine habituelle :

$  debootstrap --foreign --arch armel wheezy mydebian 

Pour ceux qui n'ont pas debian, sachez qu'il est possible de télécharger et d'exécuter debootstrap sur n'importe quel autre linux.

Et pour ceux qui voudraient essayer une autre méthode, suivez ce lien : http://wiki.debian.org/EmDebian/Cro...


continue reading...

Niveau :      
Résumé : mv ; rm ; top

Maintenant que vous êtes passé root vous êtes impatient d'optimiser votre téléphone.

Plusieurs choses sont importantes à savoir :

  • une application ce n'est qu'un fichier .apk, ce qui veut dire que supprimer le fichier suffit pour supprimer l'application (mais pas ses données)
  • le firmware n'est rien d'autre qu'un système de fichier standard, donc rien ne vous empêche de le modifier
  • android distingue une carte sd "interne" du reste du système. Sur mob téléphone, il s'agit en pratique de la même mémoire flash découpée en partitions mais formatée avec différents systèmes de fichier

Lister et supprimer les application inutiles

Tout d'abord je vous conseille juiceplotter pour regarder quand et combien consomme votre téléphone.

Ensuite, puisque vous avez un shell, ne vous privez pas et utilisez la commande top lorsque la consommation vous parait importante ou que la machine rame (attention aux bizareries du top d'android, comme la charge)

Enfin je vous recommande de supprimer les applications du système qui ne vous servent pas mais qui semblent se réveiller fréquemment.

Voici comment faire (en root sur le téléphone) :

$ mkdir /sdcard/app-backup
$ mount -o remount,rw  /system # si vous n'utilisez pas busybpox, vous devrez passer tous les paramètres a mount
$ mv /system/app/<applicaiton>.apk /sdcard/app-backup
$ mount -o remount,ro  /system

Ainsi vous gardez l'application sous le coude si vous voulez revenir en arrière.

Sur mon optimus 2x

J'ai supprimé :

  • l'antivirus F-Secure (il consomme pas mal et je n'ai toujours pas vu de virus)
  • PCSync jamais besoin et il est actif le bougre
  • LGOnScreenPhone même chose
  • LGLauncher le home du téléphone, ne pas supprimer si vous n'en installez pas une autre avant
  • LGEmail je n'utilise pas, trop limité (K9-mail est très bien)
  • SNS : se connecte automatiquement a tous vos réseaux sociaux, mais aucun moyen de l'en empecher

Au passage j'ai installé ADW, très bonne home qui remplace celle par défaut, qui permet les thèmes, qui permet de faire des raccourcis vers des activités et qui permet de faire des groupes d'applications pour y accéder plus rapidement. Notez qu'il est possible d'avoir 2 home en même temps mais j'ai tout de même supprimé l'original. Petite touche finale, elle est sous licence libre ...

Et pour vous montrer ce que j'ai gagné, lorsque j'ai eu mon téléphone, il consommait entre 10 et 15% de batterie par nuit. Maintenant après ces suppressions (et après avoir désactivé la 3G) il consomme entre 3% et 4% par nuit !

Niveau :      
Résumé : /etc/inittab ; /etc/gdm.conf ; /etc/sshd.conf

Pour ceux qui voudraient essayer le parachutisme, je vous le conseille, c'est très fort ! Par contre ça vous empêche d'écrire des articles ...

Vous venez de faire un chroot et vous voulez pouvoir vous connecter dessus comme s'il s'agissait de votre machine locale ?
Pas de panique, c'est tout simple.

Pour cela nous allons regarder 3 méthodes différentes de connexion à votre chroot : le terminal local, ssh et l'environnement graphique. Mais avant tout préparons le chroot à ressembler à une distribution normale.

$ mount --bind /dev $CHROOT_BASE/dev
$ mount --bind /proc $CHROOT_BASE/proc
$ mount --bind /sys $CHROOT_BASE/sys

Terminal local

Pour se connecter en local à votre machine, vous utilisez les consoles disponibles (alt-Fx ou ctrl-alt-Fx si vous êtes en mode graphique). Vous en avez 6 à disposition.

Pour faire simple, nous allons juste faire en sorte que les consoles 4 à 6 redirigent dans le chroot tandis que les 1 à 3 resteront dédiées à la machine principale.

Il suffit de modifier /etc/inittab :

# /etc/inittab
1:2345:respawn:/sbin/getty tty1
2:2345:respawn:/sbin/getty tty2
3:2345:respawn:/sbin/getty tty3
4:2345:respawn:chroot <chroot_base> /sbin/getty tty4
5:2345:respawn:chroot </chroot_base><chroot_base> /sbin/getty tty5
6:2345:respawn:chroot </chroot_base><chroot_base> /sbin/getty tty6

Et là, soit vous redémarrez (bof on n'est pas sous windows) soit vous forcez init à relire sa configuration :


continue reading...

Correction  : j'ai modifié cet article car le système pour rendre le rootage permanent ne fonctionnait pas !

Niveau :      
Résumé : adb shell

Il y a peu je me suis offert un téléphone android. Devinez quoi ... c'est un linux (pas GNU pour une fois, plutôt un dalvik/linux).

Seule ombre au programme, je ne suis pas root dessus. C'est pas très fair play de la part du vendeur sachant que le téléphone m'appartient. Comment faire pour supprimer les applications installées par le fabriquant et qui me cassent les *** à se lancer sans me demander mon avis ?

Ma première mission est donc de devenir root.

Les habitués des OS de bureau auront l'idée de toucher au bootloader pendant qu'il boote. Bonne idée, mais sur une telle machine le bootloader est assez sobre, et plutôt protégé, ne parlons pas du bios. J'ai donc ignoré cette technique pour passer à une méthode plus courantes pour les bidouilleurs de tout poil : exploiter une faille de sécurité.

C'est donc grâce aux failles de sécurité que je vais avoir le droit d'accéder au système de ma propre machine ! Autrement dit, c'est parce que le fabriquant protège mal le système qu'il m'a vendu que mes droits de consommateur sont respectés ...


continue reading...