Aujourd'hui tout le monde connaît et utilise screen. Miracle de la technologie, il permet de survivre aux déconnexions, de lancer des commandes longues sans avoir peur, de faire passer tous ses shells dans une seule connexion et on le trouve souvent associé à l'indémodable irssi.

Comme vous le savez peut-être screen n'est plus maintenu. Ayant un code un difficile à lire et à maintenir, des développeurs ont choisi lui faire un concurrent plutôt que de le reprendre.

Ce concurrent se nomme tmux. Il dispose de la plupart des fonctionnalités de screen et d'autres en plus. Comme vous le verrez, votre problème sera essentiellement de vous adapter aux nouveaux raccourcis. Pour le reste c'est tout bon.

Tmux dispose de presque toutes les fonctionnalités de screen sauf la communication par port série (rapport choucroute, toussa).

Commençons par le lancement :

# lancer un nouveau multiplexeur
$ screen 
$ tmux
# s'attacher à un multiplexeur existant 
$ screen -d -r
$ tmux attach

Les raccourcis :

• Nouvelle fenêtre
  • screen : ctrl-a ctrl-c
  • tmux : ctrl-b c
• Se détacher :
  • screen : ctrl-a d
  • tmux : ctrl-b d
• Passer à la fenêtre suivante
  • screen : ctrl-a <espace>
  • tmux : ctrl-b n

Je dois dire que ça y est je suis passé entièrement à tmux, le mélange ctrl-a ctrl-b entre screen et tmux commençait à être difficile. A propos d'adaptation, j'ai eu une seule difficulté c'est de m'habituer au nouveau scrollback. Il n'est pas possible de le faire à la souris, comme dans screen avec l'astuce du termcapinfo. Remarquez, c'est plus propre car du coup il n'y a pas de mélange des bufffer de scrollback entre les différents terminaux. Donc la méthode propre dans tmux c'est ctrl-b suivi de pgUp et là vous êtes en mode copy (qui permet entre autre le scrollback), vous pouvez alors naviguer avec pgUp, pgDown ou les touches directionnelles. Et pour Revenir au mode normal, Esc tout simplement.

Dans un prochain article nous verrons comment changer la configuration de tmux, même si les valeurs par défaut sont plutôt bonnes.

Si vous avez aimé, il y a aussi :

1. Screen et irssi
2. Configuration de tmux
3. Geek et partage

I'm back ! Ça faisait longtemps ! Vous m'avez manqué.

J'ai quelques petits articles pour vous. Oui c'est vraiment la reprise, même si c'est pas encore du triple A.

Aujourd'hui ngrep. Ngrep est un pote de tcpdump, il sait utiliser les mêmes filtres que tcpdump et stocker les paquets dans un format pcap lisible par wireshark si besoin. Mais son intérêt principal est qu'il sait matcher le contenu des paquets.

Là où en tcpdump vous feriez :

$ tcpdump host 10.0.0.1 and port 80

Vous pouvez utiliser ngrep récupérer un paquet particulier :

$ ngrep 'GET' 'host 10.0.0.1 and port 80'

Dans les options les plus utiles on trouve :

• -O pour sauvegarder les paquets et les analyser ensuite, par exemple avec wireshark
• -x pour dumper la version hexadécimale du paquet (pratique pour un protocole binaire)
• -X pour matcher sur la version hexadécimale du paquet (pratique pour un protocole binaire)
• -K1 pour tuer la connexion en envoyant un paquet RST à la source du paquet en question (pas de garantie 100% avec cette méthode :)

Et un exemple pour la route pour couper la connexion de celui qui dirait du mal de vous sur un serveur irc :

$ ngrep -K1 'peck sux' 'dst 10.0.0.1 and dst port 6667'

Si vous avez aimé, il y a aussi :

1. Lire dans les paquets
2. Analyse réseau
3. Espionner son android

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

Si vous avez aimé, il y a aussi :

1. Analyse réseau

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).

Si vous avez aimé, il y a aussi :

1. Une distribution GNU sur android
2. Personnalisez votre android
3. Root d’android

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...

Déplaçons tout ça sur le téléphone :

# toujours sur le pc
$ tar cf debian.tar mydebian 
$ adb push debian.tar /sdcard/debian.tar

Une debian basique est relativement petite, nous devrions pouvoir trouver une place sur le téléphone. Seule contrainte, il faut la déposer sur une partition qui utilise les droits posix (et donc pas sur /sdcard qui est en FAT). J'ai choisi /data/local/tmp

# sur l'android (avec busybox)
$ cd /data/local/tmp
$ tar xf /sdcard/debian.tar 

Profitons-en pour terminer le debootstrap (il faut être root sur l'android et il vaut mieux utiliser les commandes busybox) :

# on prépare le chroot
$ NEW=/data/local/tmp/mydebian
$ mount --bind /dev $NEW/dev
$ mount --bind /proc $NEW/proc
$ mount --bind /sys $NEW/sys
$ mount --bind /dev/pts $NEW/dev/pts
# et on termine debootstrap dedans
export PATH=/bin:/sbin:/usr/bin:/usr/sbin
$ chroot $NEW/debian debootstrap --second-stage

Et voilà !

Vous pouvez compléter par :

• modifier /etc/hostname
• modifier /etc/resolv.conf (nameserver 8.8.8.8 pour utiliser le resolver de google disponible partout)
• ... dites-moi ce que vous avez fait

Comment qu'on l'utilise ?

Maintenant que tout est prêt il faut pouvoir réutiliser ces commandes à tout moment. Pour ma part j'ai fait le petit script suivant qui me permet de rentrer dans le chroot :

ROOT=/data/local/tmp/mydebian
BB=/data/busybox/
if ! ls $ROOT/proc/1 > /dev/null
then
    $BB/mount --bind /dev $ROOT/dev
    $BB/mount --bind /proc $ROOT/proc
    $BB/mount --bind /sys $ROOT/sys
    $BB/mount --bind /dev/pts $ROOT/dev/pts
fi
export PATH=/bin:/sbin:/usr/bin:/usr/sbin
/system/bb/su -c "$BB/chroot $ROOT /bin/bash"

Et pour les gens qui aiment le tout réseau vous pouvez mettre un serveur ssh dans le chroot, ça vous le rendra accessible à distance. Pensez juste à vous connecter au chroot et à le relancer à chaque fois que le téléphone redémarre.

Conclusion

N'oubliez pas, votre téléphone continue de tourner, le chroot n'est qu'un moyen d'avoir accès aux commandes debian (dont apt-get install qui est une commande magnifique pour un android, plus besoin d'installer des machins à la main).

Mais même si votre shell tourne dans un chroot, le noyau reste le même et tous les services en dehors du chroot continuent leur vie comme d'habitude. Cela permet au téléphone de rester un vrai téléphone d'origine. Revenir en arrière consiste à rebooter et à supprimer le répertoire debian.

Amusez-vous bien !

Si vous avez aimé, il y a aussi :

1. Espionner son android
2. Personnalisez votre android
3. Root d’android

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 !

Si vous avez aimé, il y a aussi :

1. Une distribution GNU sur android
2. Root d’android
3. Espionner son android

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> /sbin/getty tty5
6:2345:respawn:chroot <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 :

# en root
$ telinit q
$ pkill getty

Et maintenant passez à la console 4 (ctrl-F4) et vous pouvez vous connecter avec votre utilisateur intérieur au chroot.

SSH

Si vous vous connectez à votre machine en ssh, vous pouvez vouloir faire de même pour votre chroot.

Pour ce faire, vous pouvez lancer un service ssh à l'intérieur du chroot. Tout simplement :

$ chroot $CHROOT_BASE
$ apt-get install openssh-server

Par contre vous ne pouvez pas laisser ssh tourner sur le même port que le ssh qui tourne déjà. Utilisez donc un autre port, par exemple le 1022 :

$ vi $CHROOT_BASE/etc/ssh/sshd_config
> Port 1022

Puis lancez ssh dans le chroot :

$ chroot $CHROOT_BASE /etc/init.d/ssh restart

Vous pouvez maintenant vous connecter directement au chroot :

$ ssh -p 1022 user@leserveur.com 

GDM

Maintenant si votre habitude est d'avoir un environnement de bureau comme gnome, il faut faire pareil pour lui.

Tout passe par le login manager. Je prends l'exemple de GDM, mais vous pouvez faire la même chose avec KDM.

Tout d'abord, vous devez avoir un gdm d'installé dans le chroot, donc un environnement graphique minimal.

Une fois installé dans le chroot, par exemple avec :

$ chroot $CHROOT_BASE apt-get install gnome

Éditez le fichier de configuration de gdm $CHROOT_BASE/etc/gdm/gdm.conf :

[daemon]
# ceci devrait être inutile, mais on ne sait jamais
FirstVT=8

[server]
0=Standard device=/dev/console

Relancez gdm dans le chroot :

$ chroot $CHROOT_BASE /etc/init.d/gdm restart

Et voilà, rendez-vous sur la console 8 (ctrl-alt-F8) pour obtenir un login graphique dans le chroot. Sur la console 7 (ctrl-alt-F7) le login original est toujours disponible.

Si vous avez aimé, il y a aussi :

1. Configuration de init
2. Chroot
3. Chroot toujours