Accueil > hack, Linux > Linux is everywhere_PQI AIRCard ,partie I: découverte

Linux is everywhere_PQI AIRCard ,partie I: découverte

pqi-air-cardDans la série « Linux is Everywhere » je vous présente aujourd’hui une SdCard Wifi de chez pqi: la AIR Card

Le projet initial qui m’a fait m’intéresser à une carte SD Wifi a pour but la visibilité par le réseau d’un équipement complètement fermé. La seule possibilité d’ interagir avec l’équipement en question et de passer par un slot SD-Card disponible. Parmi les applications les plus courantes, on trouvera l’ accessibilité à des appareils photos numériques. C’est d’ailleurs la seule fonction assurée nativement par le produit présenté. Mais en cherchant bien, je suis sûr que vous trouverez des projets vraiment excitants et dignes de figurer dans le « Wall of Fame » de Hackaday.   Pour ma part, c’est en rapport avec du matériel avionique. Mais qu’importe, là n’est pas le sujet du post.

Je vous propose donc de plonger au coeur du firmware.

Motivé par le projet mentionné, je m’étais par le passé intéressé au seul matériel disponible qui était la carte Eye-Fi. Celle-ci bien que moins chère que la pqi AIRCard,  présente l’inconvénient majeur de na pas être modifiable dans son fonctionnement (jusqu’à preuve du contraire). Pour préserver leur « Business Model », les fabriquants ont mis en place une communication entre la carte et un applicatif via leur serveur sur la toile. Donc pas de communication directe entre le PC et la carte. C’est le premier inconvénient.

Les seuls fichiers disponibles à l’échange, sont les photos (reconnues selon leur format de fichier). De plus ces photos doivent être disponibles selon la hiérarchie de stockage prévue dans les APN, cad un répertoire DCIM etc… C’est le deuxième inconvénient.

Enfin, côté matériel, rien de bien exploitable à l’horizon. A part le fait que cela semble tourner sur eCos, pas de pin disponible pour la maintenance. J’ai cherché sans succès un UART, JTAG …. C’est le troisième inconvénient.

Vous l’aurez compris, rien de bien exploitable dans tout ca. Aussi j’espérais l’apparation de clônes un peu plus ouverts à l’expérimentation. C’est je pense le cas avec la pqi AIRCard.

Le fonctionnement de la pqi AIRcard est le suivant:  la carte expose un point d’acces Wifi sur lequel on peut se connecter avec son smartphone par exemple. Ensuite, on peut accéder   à un serveur Web embarqué adressé sur l’ IP: 192.168.1.1. L’interface Web permet de « downloader » ou « d’uploader » des photos sur la carte. C’est donc déjà un gros progrès par rapport à la Eye-FI; il existe une communication directe. Par contre,  la carte souffre aussi des limitations de la Eye-Fi à savoir, la possibilité de n’échanger que certains types de fichiers (pas que des photos ceci-dit) placées dans les répertoires ad-hoc.

En parcourant le site Web du constructeur voilà que je tombe sur un « firmware upgrade« . On a donc la possibilité d’upgrader le firmware de la carte. Intéressant n’est-ce pas ? Voyons ça:

En dézippant le firmware téléchargé, on tombe entre autre sur les choses suivantes:

lemoi@T60:~/temp/pqiAIRCard$ ls -alh
(…)
-rwxrwxrwx 1 lemoi lemoi 1,0K 17 déc. 06:32 autoload.tbl
-rwxrwxrwx 1 lemoi lemoi 2,6M 14 déc. 07:40 Image3
-rwxrwxrwx 1 lemoi lemoi 2,5M 20 déc. 06:26 initramfs3.gz
-rwxrwxrwx 1 lemoi lemoi 1,0M 17 déc. 06:57 mtd_jffs2.bin
-rwxrwxrwx 1 lemoi lemoi 112K 17 déc. 06:32 program.bin …..
(…)

L’excitation me gagne, serait-il possible que … on continue d’investiguer:

lemoi@T60:~/temp/pqiAIRCard$ file initramfs3.gz
initramfs3.gz: data
lemoi@T60:~/temp/pqiAIRCard$ gunzip initramfs3.gz
gzip: initramfs3.gz: not in gzip format

Tiens bizarre je m’attendais à du gzip visiblement pas reconnu du premier coup. On verra ça après.

Je pensais (à tort) que le root file system était contenu dans le mtd_jffs2.bin. On le monte comme ça:

root@T60:/home/lemoi/temp/pqiAIRCard# mkdir jffs2
root@T60:/home/lemoi/temp/pqiAIRCard# mknod /tmp/mtdblock0 b 31 0
root@T60:/home/lemoi/temp/pqiAIRCard# modprobe mtdblock
root@T60:/home/lemoi/temp/pqiAIRCard# modprobe block2mtd
root@T60:/home/lemoi/temp/pqiAIRCard# losetup /dev/loop0 mtd_jffs2.bin
root@T60:/home/lemoi/temp/pqiAIRCard# echo « /dev/loop0,128KiB » > /sys/module/block2mtd/parameters/block2mtd
root@T60:/home/lemoi/temp/pqiAIRCard# modprobe jffs2
root@T60:/home/lemoi/temp/pqiAIRCard# mount -t jffs2 /tmp/mtdblock0 ./jffs2
root@T60:/home/lemoi/temp/pqiAIRCard# df -h
Sys. de fichiers Taille Uti. Disp. Uti% Monté sur
(….)
/tmp/mtdblock0 1,0M 452K 572K 45% /home/lemoi/temp/pqiAIRCard/jffs2r
root@T60:/home/lemoi/temp/pqiAIRCard# cd jffs2/

root@T60:/home/lemoi/temp/pqiAIRCard/jffs2# ls -alh
total 4,0K
drwxr-xr-x 4 root root 0 1 janv. 1970 .
drwxr-xr-x 4 lemoi lemoi 4,0K 10 févr. 18:45 ..
drwxrwxrwx 2 root root 0 3 mai 2012 config
-rwxrwxrwx 1 root root 0 31 déc. 1979 wifilist.txt

On tombe donc uniquement sur deux fichiers de config peu intéressants pour l’instant. Intéressons nous maintenant à program.bin. Un bon début consiste à examiner les caractères lisibles contenus dans ce binaire. Et là,  on a la confirmation de ce que l’on recherchait :

lemoi@T60:~/temp/pqiAIRCard$ strings program.bin | cat -n
(…)
154   – boot application image stored in memory
155     passing arguments ‘arg …’; when booting a Linux kernel,
156     ‘arg’ can be the address of an initrd image
(…)
732    ## Transferring control to Linux (at address %08lx) …
733    Starting kernel …
734    Running theKernel … r0=%x, r1=%x, r2=%p
(…)

Et voilà pour la confirmation; le système est bien basé sur Linux. L’analyse des strings nous apprendra aussi que program.bin est en fait basé sur U-Boot (version 2010.06-rc1) le célèbre bootloader pour l’embarqué. Le processeur est déclaré comme étant un KeyAsic.

KeyAsic c’est une société qui fabrique des SOC sur mesure. Pour celui dont il est question ici, le voici placé sur une carte de dev fournie par le fabriquant (surement la carte utilisée par le constructeur pqi pour l’élaboration de leur produit  ). On retiendra les choses importantes suivantes:

– CPU 32 Bits ARM9 cadencé à 200MHz
– support natif de linux 2.6.32
– IO Voltage: 2.7 ~ 3.3V, Compliant with SD card Supply Voltage Specification
– Little Endian
– En vrac Uart, SSI, SDIO Host , SD Slave , Pwm pour controle du buzzer embarqué (donc au moins une GPIO disponible ).

La même technique d’analyse des chaines de caractères sur le fichier Image3 nous apprendra qu’il s’agit en fait de la version Linux 2.6.32.28.

J’attends d’avoir le système en ma possession pour prendre connaissance de la taille exacte de la ram et de la flash utilisée dans le SOC. C’est fou quand même tant de possibilité dans si peu d’espace. On vit vraiment une époque formidable .

Résumons la situation:
nous avons donc un bootloader basé sur U-Boot, il s’agit du fichier program.bin. Le noyau Linux lui est contenu dans Image3. La configuration sera assurée par un sytème de fichier jffs2 résidant dans la flash (surement avec une partition en lecture / écriture). L’image de ce système de fichier est contenue dans mtd_jffs2.bin . Reste donc à étudier (et modifier) le Root File System pour espérer hacker la carte.

Contrairement à un Linux classique (cad non embarqué) l ‘ initrd (ici  initramfs3.gz)  ne sert pas de système de fichier racine temporaire (système pivot) mais contiendra la structure de fichier finale de l’OS. Pour autant, nous avons vu précédemment qu’il était difficile de l’extraire. Essayons d’y voir plus clair.

Si on regarde les 10 premiers octets du fichier initramfs3.gz, on trouve quelque chose d’assez inhabituel dans ce type d’archive:

lemoi@T60:~/temp/pqiAIRCard$ head -c 10 initramfs3.gz
KAGZ' »1�

Cela ressemble à une en-tête. Si l’ archive de l’initrd a une en-tête, c’est sûrement pour valider son intégrité au bootloader. Hormis l’en-tête, tout semble à croire que le fichier est une archive gzip. Si on étudie de plus près ce type d’archive notamment avec la RFC du format, on apprend qu’un fichier gzip commence invariablement par les octets: 0x1f et 0x8b. Des octets qu’on retrouve à la neuvième position dans l’initramfs:

lemoi@T60:~/temp/pqiAIRCard$ hexdump -C initramfs3.gz | more
00000000 4b 41 47 5a 00 27 22 31 1f 8b 08 00 93 a1 d2 50 |KAGZ.' »1…….P|
(….)

Si on enlève l’en-tête « KAGZ » et les 4 octets suivants on devrait obtenir quelque chose d’exploitable. On essaye:

lemoi@T60:~/temp/pqiAIRCard$ dd if=initramfs3.gz of=initramfs.gz bs=1 skip=8
2564657+0 enregistrements lus
2564657+0 enregistrements écrits
2564657 octets (2,6 MB) copiés, 9,06352 s, 283 kB/s
lemoi@T60:~/temp/pqiAIRCard$ file initramfs.gz
initramfs.gz: gzip compressed data, from Unix, last modified: Thu Dec 20 06:26:43 2012

Voilà, je préfère !! On va donc pouvoir accéder au Root File System.
Y accéder c’est bien mais sera-t on en mesure de le modifier et de le réinjecter par la suite ?  Dans les 8 premiers octets qui ont été supprimés:

lemoi@T60:~/temp/pqiAIRCard$ hexdump -n 8 -C initramfs3.gz
4b 41 47 5a 00 27 22 31           |       KAGZ….

les octets 4b,41,47,5A correspondent à la chaîne « KAGZ » les 4 suivants correspondent en fait à la taille de l’initramfs.gz (le fichier débarrassé de l’en-tête)

lemoi@T60:~/temp/pqiAIRCard$ ls -l initramfs.gz
(…..)           2564657 initramfs.gz

2564657 est bien la représentation décimale de 0x00,0x27,0x22,0x31 . Voilà on sera donc désormais en mesure de reconstruire nos propres en-tête de fichiers si on en vient à modifier le firmware🙂

Cela étant dit, observons un peu l’arborescence. On désarchive de cette façon:

lemoi@T60:~/temp/pqiAIRCard$ gunzip initramfs.gz
lemoi@T60:~/temp/pqiAIRCard$ mkdir RFS
lemoi@T60:~/temp/pqiAIRCard$ cd RFS/
lemoi@T60:~/temp/pqiAIRCard/RFS$ cpio -i < ../initramfs
(….)
lemoi@T60:~/temp/pqiAIRCard/RFS$ ls
bin dev etc home init lib linuxrc lost+found mnt proc root sbin sys tmp usr var www

Je vous laisse le soin d’analyser les répertoires. En voilà la synthèse.

Système construit sur Busybox (le couteau Suisse du Linux Embarqué)
Visiblement Busybox est buildé sur la libc et non la uclibc (à confirmer)
La plupart des binaires sont issus de busybox, peu de binaires spécifiques au constructeur
Boa comme serveur Web ( from busybox)
On trouve du Perl (intéressant du Perl sur le système natif …)
wpa_supplicant, les utilitaires iwscan, iwlist habituels
et puis même des aplicatifs non utilisés par l’application Middleware mais qui seront bien pratiques:
client telnet, serveur telnet , client ftp,  serveur ftp etc …

C’est vraiment une bonne nouvelle, il y a déjà de quoi faire avant même de s’intéresser à cross compiler ses propres binaires. Il y a en tout cas suffisamment de choses pour commencer à modifier le comportement par défaut de la carte. Par exemple, lui faire adopter un mode client Wifi ( par défaut c’est un AP) et partager les fichiers que l’on veut n’importe où sur la carte de stockage. Pour peu que l’on trouve les Pins d’une UART, ca serait vraiment le bonheur.

J’ai donc commandé en direct de Hong-Kong. Je suis vraiment impatient de recevoir le colis. La suite dans un prochain épisode …

Catégories :hack, Linux Étiquettes : , , ,

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :