Travail de Master

Transcription

Travail de Master

Travail de Master
Forensic Analysis and Data Recovery from
Mobile Phones
2008
Gian-Luca CORBO
Sous la direction de Mr. David BILLARD
ii
Table des matières
1 Introduction
1.1 Préambule . . . . . . . .
1.2 But . . . . . . . . . . . .
1.3 Etat de l’art . . . . . . .
1.4 Environnement de travail
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 JTAG
2.1 Introduction à JTAG . . . . . . . .
2.2 Le fonctionnement de JTAG . . . .
2.3 Lecture de la mémoire du téléphone
2.4 Les difficultés . . . . . . . . . . . .
2.5 Conclusion . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
4
.
.
.
.
.
7
7
8
9
12
13
3 Dump Mémoire
17
3.1 Choix du logiciel et du mobile . . . . . . . . . . . . . . . . . . 17
3.2 Comment effectuer un Dump . . . . . . . . . . . . . . . . . . 18
4 Extraction des vidéos
4.1 Introduction . . . . . . . .
4.2 Norme 3GP . . . . . . . .
4.3 Structure d’une vidéo 3GP
4.4 Analyse dump mémoire . .
4.5 Reconstruction de vidéo .
4.6 Résultats et conclusion . .
5 Extraction des messages
5.1 Introduction . . . . . . .
5.2 Détails techniques . . . .
5.3 Le format PDU . . . . .
5.4 Recherche dans le Dump
5.5 Extraction des SMS . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
21
22
25
30
34
.
.
.
.
.
37
37
38
40
41
44
iv
TABLE DES MATIÈRES
5.6
Résultats et conclusion . . . . . . . . . . . . . . . . . . . . . . 47
6 Extraction des contacts
6.1 Introduction . . . . . . .
6.2 Détails techniques . . . .
6.3 Recherche dans le Dump
6.4 Extraction des contacts .
6.5 Résultats et conclusion .
7 Logiciel développé
7.1 Explication . . . . . .
7.2 SourceForge . . . . . .
7.3 Fonctionnalité de base
7.4 Inversion de fichier . .
7.5 Exportation CSV . . .
7.6 Captures d’écran . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
51
51
52
54
57
.
.
.
.
.
.
59
59
59
59
60
60
61
8 Conclusion
63
9 Remerciement
67
Bibliographie
69
Table des figures
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
Interface interne TAP . . . . . . . . . . . . . . . . . . .
Machine d’état . . . . . . . . . . . . . . . . . . . . . .
Exemple d’envoi de l’instruction BYPASS sur le TDI .
Exemple d’un système embarqué classique . . . . . . .
Utilisation du mode Extest pour accéder à la mémoire
Port JTAG sur le Sony Ericsson K700i . . . . . . . . .
Mobile Sagem V65 . . . . . . . . . . . . . . . . . . . .
Mobile Nokia 1110i . . . . . . . . . . . . . . . . . . . .
3.1
3.2
Flash and backup - Ecran initial . . . . . . . . . . . . . . . . . 19
Flash and backup - Ecran lecture mémoire . . . . . . . . . . . 20
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Structure du format MPEG-4 . . . . . . . . . . . . . . . . .
Structure de la (( moov box )) . . . . . . . . . . . . . . . . . .
Structure d’un entête vidéo avec le nom . . . . . . . . . . . .
Structure d’une boı̂te mdat . . . . . . . . . . . . . . . . . .
Structure général d’une vidéo dans un dump . . . . . . . . .
Flowchart pour la recherche et la reconstruction d’une vidéo
Architecture d’une vidéo dans un dump . . . . . . . . . . . .
.
.
.
.
.
.
.
23
24
27
28
29
34
35
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
Signature d’un SMS . . . . . . . . . . . . . . . .
Première version d’une structure d’un SMS dans
Structure d’un header SMS . . . . . . . . . . .
Pattern date . . . . . . . . . . . . . . . . . . . .
Exemple du format d’un numéro de téléphone .
Calcul permettant de savoir le début du SMS .
Table ASCII permettant de faire la conversion .
Flowchart pour la recherche d’un SMS . . . . .
Pattern de recherche pour Motorola V3R . . . .
.
.
.
.
.
.
.
.
.
42
43
44
44
46
46
47
48
49
6.1
6.2
Pattern pour un contact . . . . . . . . . . . . . . . . . . . . . 53
Structure d’une entrée dans le répertoire . . . . . . . . . . . . 54
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . .
un dump
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
10
10
11
12
14
15
15
vi
TABLE DES FIGURES
6.3
6.4
6.5
Différence entre la taille SMS et contact . . . . . . . . . . . . 55
Flowchart pour la recherche d’un contact . . . . . . . . . . . . 56
Pattern de recherche pour Motorola V3R . . . . . . . . . . . . 58
7.1
7.2
7.3
7.4
Capture
Capture
Capture
Capture
du
du
du
du
programme une fois l’exécution terminée . .
fichier de sortie contenant le nom des vidéos
fichier de sortie contenant les SMS . . . . . .
fichier de sortie contenant les contacts . . . .
.
.
.
.
.
.
.
.
.
.
.
.
61
61
62
62
Chapitre 1
Introduction
1.1
Préambule
De nos jours, les téléphones mobiles sont devenus omniprésents dans
la société. Tout d’abord, au niveau financier, le marché des mobiles est
désormais un marché de masse qui comprend 51 millions de clients, et ce,
seulement 15 ans après la commercialisation des premiers services. L’idée
d’être joignable et de pouvoir appeler partout dans le monde ou dans n’importe quelle situation renforce le besoin d’avoir un mobile. De plus, la multitude de fonctionnalités que proposent les différents fabriquant, tels que
photos, vidéos, vidéophonie et même l’accès Wifi1 ne font que favoriser cette
croissance. Malheureusement, ces fonctionnalités sont quelques fois utilisées à
des fins violentes, voir criminelles dans les cas les plus extrêmes. Cette néfaste
utilisation entraı̂ne aussi la perte de la fonction première du téléphone qui
est celle de téléphoner.
En effet, les auteurs de violences n’hésitent pas à se mettre en scène avec
leur propre mobile ou devant l’objectif d’un camarade au moment où ils commettent des délits. Les plus prudents se contentent de montrer ces images à
leurs copains, dans les cours de récréation ou en petit comité, alors que les
plus violents font circuler les images dans le but d’humilier leurs victimes et
d’affirmer leur supériorité physique. Les moyens les plus utilisés pour faire
véhiculer l’information sont les MMS2 et Internet (grâce à la récente prolifération des blogs accessibles à tous). L’envoi de MMS et la publication
de blogs peuvent très souvent donner lieu à des conséquences dramatiques,
comme lors de la diffusion d’images du viol d’une collégienne en 2005. Son
agresseur, mineur, a montré les images enregistrées sur son portable au sein
de son établissement de Nice. Dans un élan de fierté, l’agresseur a envoyé
1
Wireless Fidelity - Technique de réseau informatique sans fil mis en place pour fonctionner en réseau interne
2
Multimedia Messaging Service - messages multimédias permettant l’envoi de photos
ou de vidéos par téléphone portable
1
2
CHAPITRE 1. INTRODUCTION
par MMS les images choquantes du viol, et par conséquent, c’est par le biais
de camarades que la victime a appris que les photos circulaient sur tous les
téléphones mobiles de ses camarades.
Il est important de rajouter que la possession de téléphones mobiles atteint des taux très impressionnants surtout chez les jeunes de 15 ans. En
effet, près de 4 personnes sur 5 âgées de 15 ans et plus étaient en possession d’un téléphone mobile à la fin 2006 et les taux ne cessent de progresser.
Mais l’ampleur du phénomène concernant les actes de violences reste difficile à estimer. D’un point de vue judiciaire, peu d’affaires ont fait l’objet
de poursuites, car les preuves peuvent être très facilement supprimées. C’est
pour lutter contre cette injustice sociale dont font l’objet de nombreuses victimes qu’est née l’idée d’analyser la mémoire des téléphones et de pouvoir y
récupérer certaines données intentionnellement effacées.
1.2
But
Le but de ce sujet de Master est d’analyser le fonctionnement de la
mémoire d’un téléphone mobile et de prouver qu’il est possible d’en récupérer
les informations intentionnellement supprimées à travers les différents supports que sont les SMS3 , les vidéos, les photos ou les MMS.
La récupération de données du contenu du téléphone ne peut s’accomplir
qu’à travers la lecture de la mémoire interne de l’appareil. Cependant, il
faut tout d’abord comprendre le fonctionnement d’un système embarqué,
dans notre cas un téléphone mobile, et les différentes connexions qui sont
proposées avant de pouvoir procéder à la lecture. En effet, la réalisation d’un
dump de la mémoire, à proprement parlé, peut s’avérer difficile à cause de
l’importante variété de téléphone mobile présente sur le marché et à cause
de la non divulgation d’informations de la part du fabriquant. Il est bon de
noter que plusieurs méthodes permettant la récupération de données existent
dans la littérature.
Dans un premier temps, nous allons essayer d’extraire les données au
moyen de la méthode JTAG4 dont les détails concernant la procédure sont
reportés au chapitre 2 intitulé JTAG. Dans un deuxième temps, nous extrairons ces données grâce à un logiciel qui a pour but d’effectuer cette manipulation par simple interface USB. Ce logiciel est fourni et projeté par un
tiers fabriquant, mais qui lui nécessite les drivers du téléphone mobile réalisé
par le fabriquant. Lorsque la mémoire est obtenue, grâce à l’une des deux
3
4
Short Message Service - message texte sous forme électronique
Joint Test Action Group - Port de tests
1.3. ETAT DE L’ART
3
méthodes citées ci-dessus, l’objectif de ce projet - l’analyse des données des
mobiles - peut alors débuter.
1.3
Etat de l’art
Cette section fait l’objet d’une synthèse des solutions qui existent et que
nous avons pu rencontrer. Dans le domaine de la recherche digitale, beaucoup de solutions proposées peuvent être plus ou moins convaincantes. La
récupération de données existe depuis de nombreuses années sur les ordinateurs étant donné que le support de stockage est très bien connu et comporte
des normes détaillées. C’est pour cela que beaucoup de logiciels permettant
la recherche et la récupération des données effacées ou intentionnellement
(( cachées )) sur un disque dur existent. Le plus connu et le plus utilisé par
R Forensic qui existe sur le marché depuis de
les enquêteurs est EnCase
nombreuses années et qui a fait ses preuves dans de nombreux cas. Ensuite
viennent des petits logiciels qui permettent une récupération assez basique
comme c’est le cas de PC INSPECTOR File Recovery qui à l’avantage d’être gratuit. Mais quand à la récupération sur des téléphones mobiles,
les solutions sont moins communes et surtout elles ont un point faible non
négligeable. Cette faiblesse se situe au niveau de la méthode de recherche
elle-même. En effet, dans la plupart des solutions existantes, le téléphone
doit être allumé et par conséquent, ceci peut comporter certains risques de
modifications involontaires de données. De plus, survient le problème du verrouillage du téléphone au moyen d’un code de sécurité. Il est impératif d’en
connaı̂tre le code afin que le logiciel puisse correctement s’exécuter. Il existe
une solution qui, d’après le fabriquant, permet de récupérer tous types de
données sur un téléphone mobile par le biais d’une connexion Bluetooth5
et garantit la préservation des données. Ce logiciel, qui n’est pas gratuit, se
nomme (( Oxygen Forensic Suite 2 )). Les fabricants proposent une version
d’essai, mais celle-ci est limitée à l’extraction de cinq résultats.
Si nous continuons à regarder dans la littérature, nous pouvons constater,
qu’à l’heure actuelle, aucuns logiciels permettant de manipuler un dump6
mémoire et capable d’en extraire son contenu uniquement grâce à l’analyse
de celui-ci n’a pu être trouvé. En revanche, beaucoup de scientifiques ainsi
que des centres de recherche ont commencé à se lancer dans cette voie et à
chercher des solutions pour accéder aux données.
5
technologie radio courte distance permettant la connexion entre les appareils
électroniques
6
Mot anglais qui signifie copier le tout ou seulement une partie du contenu d’une
mémoire
4
En effet, un article scientifique très populaire [Breeuwsa, 2006], parle des
différentes méthodes qu’il est possible d’utiliser avec le port JTAG et ceci afin
de pouvoir lire les données dans un téléphone, ainsi que de pouvoir extraire
toute la mémoire de celui-ci et de la sauvegarder sur un ordinateur dans le
but de pouvoir travailler avec une copie de la mémoire et par conséquent,
la donnée qui réside dans le téléphone ne peut être altérée. Etant donnée
l’importance du sujet de cet article, nous y ferons référence plus tard au
cours de ce travail.
Un autre article [Breeuwsa et al., 2007], toujours du même auteur, explique la façon de procéder pour pouvoir lire une mémoire flash. La lecture de ce type de mémoire peut paraı̂tre hors contexte, mais il faut savoir
que les téléphones actuels intègrent comme unité de stockage des mémoires
flash. Il est donc intéressant de connaı̂tre diverses techniques pour permettre
d’accéder et de lire les données de ces mémoires. Dans son article, l’auteur explique différents procédés, qui sont plus ou moins réalisables, et émet quelques
suppositions quant aux procédés. De plus, il explique que la méthode la plus
efficace, mais qui est de loin la moins facilement réalisable, est de dessouder
la puce et de la placer sur un lecteur de mémoire flash. Il est évident que
cette méthode ne peut pas être utilisée dans la plupart des cas étant donné
qu’il faut des appareils spéciaux et de plus cette manipulation peut entraı̂ner
un non-fonctionnement de l’appareil.
Afin de continuer dans l’extraction de données de l’appareil mobile, un
travail de thèse [McCarthy, 2005] portant sur l’étude des différentes investigations numériques légales concernant les téléphones mobile a été effectué
dans la University of South Australia. Ceci démontre bien que le sujet étudié
dans ce travail comporte un réel intérêt et par conséquent, il commence à
devenir un besoin concret. Malgré toutes ses références citées ci-dessus, nous
pouvons constater que les études menées jusqu’à présent, couvrent en grande
partie la façon de procéder à un (( dump )) mémoire, mais aucun article explique ou ne parle de la manière de traiter ou d’analyser les données contenues
dans celui-ci. En effet, l’ampleur et la complexité de ce point ne doivent être
négligées, car elles représentent un travail considérable. Nous pouvons donc
nous prononcer sur le fait que ce travail est un (( Proof Of Concept )) et qu’il
est possible de rechercher et de reconstituer des données en ayant à disposition uniquement l’image mémoire d’un téléphone.
1.4
Environnement de travail
Afin de mener à bien ce travail, il a fallu se munir de plusieurs outils et de
deux environnements de travail adéquats. Voici la liste des programmes des
1.4. ENVIRONNEMENT DE TRAVAIL
5
langages de programmation et des différents outils qui ont été utilisés tout
au long de ce travail.
Environnement et OS
Deux systèmes d’exploitations interviennent dans notre travail.
– Le premier système qui va nous servir à coder et à exécuter le programme est Linux Ubuntu 8.04 - Hardy Heron
– Le deuxième système qui va nous permettre d’effectuer une image
mémoire est Windows XP sp2
Processeur Intel de la classe Pentium cadencé à 1,6 Ghz - 1Gb de ram
Langages de programmation et espace de développement
Programmation en C
L’aide au développement a été assurée par Netbeans
Programmes complémentaires
Flash and backup permettant de faire des images
SETool2 lite
6
Chapitre 2
JTAG
2.1
Introduction à JTAG
La norme JTAG a été définie en 1990 par un consortium d’entreprises qui
s’est penché sur la problématique suivante qui consiste à tester et à contrôler
le bon fonctionnement des circuits imprimés. Ceci a donné naissance à un
standard de test et de débogage. Ce standard s’appelle IEEE std. 1149.1,
plus communément connu sous le nom de JTAG (JTAG provient du nom du
groupe qui a mis au point cette norme).
Le principe de ce standard consiste à ajouter un port supplémentaire ou
des points de connexions sur le circuit imprimé. Cette fonctionnalité qui, en
principe, est utilisée uniquement à la fin de la phase de production, permet de
détecter certains défauts de conception et de s’assurer qu’aucun bug n’est apparu durant le processus de fabrication. Lorsque le produit est définitivement
fini et testé, ce port n’est en (( général )) pas retiré du circuit imprimé, mais
il reste tout de même inaccessible (par des voies standards) à l’utilisateur de
tous les jours. Toutefois, bien que ce soit dans de rares cas, ce port peut être
désactivé volontairement par le fabriquant.
Pour conclure cette brève introduction sur JTAG, voici une liste non
exhaustive des différents modes opératoires que comporte l’interface JTAG.
Ces différentes fonctions vont être vues plus en détails dans les paragraphes
suivants.
– Extest1 :
Mode permettant de commander les broches d’entrée-sortie des composants externes afin de tester les interconnexions de la carte.
– Debug Mode :
Mode utilisé pour analyser et vérifier le fonctionnement du programme.
Utile pour effectuer du pas à pas.
– Normal
1
External Test mode
7
8
CHAPITRE 2. JTAG
Mode de fonctionnement normal. Le JTAG est court-circuité (bypass).
2.2
Le fonctionnement de JTAG
Dans ce paragraphe, nous allons parcourir brièvement et succinctement
le fonctionnement de l’interface JTAG. Le premier élément à entrer en considération est le connecteur. Ce bus de test utilise quatre signaux au minimum, cependant il peut en comporter un cinquième qui est le (( reset )). Le
tableau 2.1 ci-dessous énumère les caractéristiques des signaux ainsi que leurs
utilisations.
TCK
Test Clock
TMS
Mode Select
TDI
TDO
TRST
Data In
Data Out
Test Reset
horloge qui permet de synchroniser le périphérique
de test avec le périphérique à tester
signal permettant de sélectionner le mode de fonctionnement du JTAG
permet d’envoyer des données (données séries)
permet de recevoir des données (données séries)
entrée optionnelle qui permet l’initialisation du
séquenceur de test
Tab. 2.1 – Signaux JTAG
La figure 2.1 est la représentation schématique des différentes interfaces
que possèdent les circuits implémentant la norme JTAG avec les quatre, voir
cinq, signaux de contrôle du TAP2 . Maintenant que nous avons brièvement
étudié l’aspect électrique de l’interface JTAG, nous allons en analyser son
fonctionnement. La figure 2.2 représente le fonctionnement de la norme
JTAG qui est entièrement basé sur (( une machine d’état )). Afin de facilité la
compréhension du procédé de cette machine d’état, nous allons, tout d’abord,
nous focaliser sur la séquence représentée par la figure 2.3. Dans cet exemple, nous allons envoyer une simple instruction à l’interface JTAG. Cette
instruction ne sera rien d’autre que la commande (( BYPASS )) (11111111).
La séquence peut être résumée de la façon suivante :
Dans un premier temps, nous nous trouvons dans un état de (( reset ))
logique permanent, mais grâce aux tests (Run-Test) que nous effectuons au
moyen d’une transition vers le bas du signal TMS, puis au moyen de deux
transitions vers le haut du signal TMS, nous nous retrouvons dans l’état
(( Select IR-Scan )). Pour se faire, nous allons mettre l’entrée TDI à 1 et
2
Test Acces Point - Points d’accès au module
2.3. LECTURE DE LA MÉMOIRE DU TÉLÉPHONE
9
Fig. 2.1 – Interface interne TAP
envoyer huit coups de clock. Afin de déterminer le terme de l’envoi, le signal
TMS remonte à 1 ce qui permet la mise à jour du registre et l’envoi de
l’instruction insérée dans le registre au préalablement. Cet exemple, nous
montre à quel point il est essentiel de comprendre la machine d’état, car la
totalité du fonctionnement du port JTAG est basé sur celle-ci. Toutes ces
étapes sont détaillées dans la figure 2.3.
Pour conclure ce paragraphe, il est intéressant de noter que l’envoi et la
réception d’instructions peuvent s’avérer compliqués et fastidieux, c’est pour
cela qu’il existe des modules (( préfabriqués )) que l’on branche directement
sur le port USB. Celui-ci contient l’intégralité de la mécanique nécessaire à
l’envoi et à la réception de messages entre le port JTAG et le périphérique
connecté. Ce périphérique peut être un téléphone mobile, un Pocket-PC ou
tout autre appareil ayant intégré la norme et le connecteur JTAG.
2.3
Lecture de la mémoire du téléphone
Dans ce paragraphe, nous allons observer de plus près le procédé de lecture de la mémoire grâce à un port qui sert principalement au débogage
(JTAG). Il est important de préciser que les observations qui apparaissent
dans ce paragraphe sont principalement tirées d’un fondement théorique. De
plus, il est indispensable de rappeler que le mode de fonctionnement qui
10
CHAPITRE 2. JTAG
Fig. 2.2 – Machine d’état
Fig. 2.3 – Exemple d’envoi de l’instruction BYPASS sur le TDI
2.3. LECTURE DE LA MÉMOIRE DU TÉLÉPHONE
11
Fig. 2.4 – Exemple d’un système embarqué classique
permet la lecture de la mémoire du téléphone est (( Extest )) (mode étudié
dans la section 2.1). Dans la plupart des cas, les mémoires non-volatiles
ainsi que les mémoires volatiles ne sont pas directement connectées au port
JTAG, car les mémoires contenant une interface JTAG sont rares et couteuses. C’est pourquoi, on ne peut accéder directement à la mémoire que
par le biais du port de débogage. Afin de limiter les complications liées à la
lecture de la mémoire, nous adoptons la solution élaborée par un des nombreux articles [Breeuwsa, 2006] qui sont les plus reconnus dans le domaine
du (( forensic )).
La figure 2.4 illustrée ci-dessus est un bref rappel de l’interconnexion
d’un système embarqué classique. En observant cette image, nous pouvons
constater que la mémoire est connectée par un bus de données au processeur.
Ainsi, en passant par le processeur, il est possible d’envoyer directement une
instruction à celui-ci en lui demandant de lire une adresse en mémoire et de
nous la retourner. En principe, le tour est joué, cependant des difficultés
peuvent survenir comme nous le verrons au paragraphe suivant. Voici la
théorie proposée par [Breeuwsa, 2006] en ce qui concerne la manipulation
responsable de la lecture de la mémoire du téléphone.
1. Tout d’abord, il faut envoyer un vecteur de test contenant l’adresse
mémoire que l’on désire lire suivi d’un signal de contrôle (le signal
de contrôle sert à indiquer si nous sommes en lecture ou en écriture,
mieux connu sous l’abréviation R/W). Dans notre cas, nous utiliserons
uniquement (( Read ))étant donné que l’on désire lire la mémoire et non
y écrire dedans. Pour illustrer ce point, il faut se référer à la première
12
CHAPITRE 2. JTAG
Fig. 2.5 – Utilisation du mode Extest pour accéder à la mémoire
étape de la figure 2.5.
2. Une fois envoyé ce vecteur dans le registre, il faut activer ce registre
grâce au signal TMS. Après un bref délai, la mémoire transmet comme
information la donnée que l’on a demandée. Toutefois, l’instruction doit
être correcte et l’adresse mémoire existante. Maintenant, ces informations sont sur le bus de données. Pour illustrer ce point, il faut se référer
à la deuxième étape de la figure 2.5.
3. Une fois arrivé à ce stade, il faut envoyer une commande afin de capturer
les informations se trouvant sur ce bus. Le but du second vecteur est de
faire un (( shift )) de la valeur lue sur la sortie TDO. Au même moment,
on peut envoyer la nouvelle adresse à lire sur l’entrée TDI. Pour illustrer
ce point, il faut se référer à la troisième étape de la figure 2.5.
Afin d’obtenir une image complète de la mémoire, il suffit de répéter cette
manipulation avec les différents emplacements mémoire que l’on désire lire.
La mémoire peut être également lue au moyen du fonctionnement (( Debug Mode )), mais cette méthode ne sera pas prise en compte dans l’analyse de ce projet, car elle nécessite du matériel très spécifique ainsi que des
compétences qui dépassent de loin le périmètre de ce travail. Pour de plus
amples informations à ce sujet, il est possible de se référer à la page 34 de
l’article [Breeuwsa, 2006], car il traite la fonction (( Debug Mode )) plus en
détails.
2.4
Les difficultés
Dans ce paragraphe, nous allons tenter de comprendre pourquoi la lecture
de l’adresse mémoire a échoué malgré un fondement théorique approprié et
une marche à suivre bien détaillée.
2.5. CONCLUSION
13
La raison de cet échec est relativement simple à comprendre. Il s’est avéré
difficile, voir impossible, de trouver le port JTAG. En effet, les constructeurs
de téléphones mobiles ne veulent en aucun cas divulguer des informations au
sujet de l’emplacement de ces ports dans le but de protéger leurs produits.
Comme nous avons pu le constater tout au long de ce chapitre, il est relativement dangereux pour le constructeur qu’une personne arrive à accéder
à ce port, car elle pourrait en modifier le fonctionnement de l’appareil en
écrivant des données dans la mémoire ou procéder à une manipulation de
reverse engineering3 .
Malgré les nombreuses heures passées à éplucher les forums, les sites de
forensic et sans compter les innombrables mails envoyés aux différents constructeurs, ces fameux ports restent introuvables. Le travail de Bachelor de
McCarthy [McCarthy, 2005] qui porte sur l’analyse des téléphones mobiles ne
désigne cependant que les ports JTAG de certains modèles, comme le Nokia
3410 dont le port JTAG se situe à l’arrière de la batterie. Malheureusement, après diverses recherches, il s’est avéré que cette information est inexacte et il en est de même pour les emplacements JTAG des autres modèles
de Nokia. Les ports qui sont illustrés par la photo de la page 37 du travail [McCarthy, 2005] ne sont rien d’autres que des ports M-BUS4 . Ce pattern
est utilisé dans plusieurs mobiles Nokia comme le montre la figure 2.8. Les
informations qui indiquent que ce port est bien le port M-BUS/F-BUS ont
été tirées du site [pinouts.ru, 2007] qui regroupe bon nombre de (( pinout ))
de différents appareils électroniques, ainsi que du site[Peacock, 2005] qui explique le fonctionnement et les capacités de ce port. En ce qui concerne la
marque Sony Ericsson, nous avons pu déterminer l’emplacement du port
JTAG. En effet, cette compagnie utilise un pattern présent dans d’autres
modèles. Malheureusement, vu la taille réduite des pastilles (voir figure 2.6),
il s’est avéré impossible d’effectuer une soudure précise avec le matériel mis à
disposition par l’université de Genève (Département CUI) ainsi que par celui
de l’école d’ingénieur de Genève (laboratoire de microsystème).
2.5
Conclusion
Les difficultés rencontrées liées aux secrets professionnels du constructeur
et au matériel inapproprié m’ont contraint à l’incapacité d’effectuer des tests
3
Consiste à étudier un objet pour en déterminer le fonctionnement interne ou sa
méthode de fabrication
4
M-Bus est un bus de connexion bidirectionnel qui permet de transmettre et de recevoir
des données du téléphone mobile. C’est une connexion relativement lente (9600bps) et elle
est uniquement half-duplex
14
CHAPITRE 2. JTAG
Fig. 2.6 – Port JTAG sur le Sony Ericsson K700i
relatifs à la lecture de la mémoire. En revanche, tout porte à croire que si
le port JTAG est trouvé, que celui-ci est correctement connecté à l’ordinateur et qu’il n’est pas désactivé par le constructeur, la lecture de la mémoire
peut s’effectuer en procédant de la manière expliquée au paragraphe 2.3,
démarche testée et démontrée par l’article de [Breeuwsa et al., 2007] et que
l’on retrouve également à l’adresse [Openwince, 2007]. L’exemple cité à l’adresse
suivante montre que la personne se connecte directement aux pastilles en y
soudant des câbles, ainsi elle parvient à analyser la mémoire et à en introduire
ses propres données. De plus, afin de renforcer la conviction que la lecture
de la mémoire interne sur un téléphone mobile est possible, il suffit de lire
l’article de [Willassen, 2005] qui démontre l’exactitude de ce procédé. En revanche, il faut préciser que pour parvenir à la lecture, il est primordial d’avoir
en sa possession les schémas électriques ainsi que les informations relatives
aux composants des différents modèles à analyser. Malgré ces précieuses informations, il s’est avéré que dans la documentation électronique concernant
les Nokia 5110, les ports JTAG étaient indiqués comme (( not assembled )).
Tout ceci porte à croire que pour qu’un jour cette méthode puisse fonctionner et devenir un (( standard )) qui permette de lire les mémoires, il faudrait
une plus grande collaboration entre les fabricants et les scientifiques désirant
récupérer des informations primordiales se situant dans les mémoires internes
2.5. CONCLUSION
15
Fig. 2.7 – Mobile Sagem V65
Fig. 2.8 – Mobile Nokia 1110i
des téléphones mobiles.
Pour conclure ce chapitre, voici des photos de différentes cartes mères de
mobiles.
La figure 2.7 montre un mobile de la marque Sagem, modèle V65. Plusieurs
composants sont facilement identifiables dont le processeur (1), la caméra (2)
et la mémoire flash (3). Toutefois, l’emplacement du port JTAG demeure inconnu.
La figure 2.8 montre le mobile de la marque Nokia, modèle 1110i. Sur
cette illustration également plusieurs composants sont identifiables comme le
processeur (1), le port M-BUS (2) et la mémoire flash (3). Ici aussi, le port
JTAG demeure inconnu.
16
CHAPITRE 2. JTAG
Chapitre 3
Dump Mémoire
3.1
Choix du logiciel et du mobile
Suite à l’échec que nous avons pu constater dans le chapitre précédant de
l’extraction de la mémoire avec le procédé JTAG, afin de continuer ce travail,
il faut absolument disposer d’une image mémoire. C’est pour cela que nous
allons utiliser une autre méthode et d’où la nécessité de se tourner vers un
logiciel permettant d’accomplir cette tâche. Plusieurs recherches ont montré
qu’il existe diverses solutions qui permettent d’effectuer des (( flash )) de la
mémoire ou des modifications de fonctionnalités dans les téléphones. Mais ces
méthodes ne nous intéressent pas, car dans notre cas, le but est de pouvoir lire
la mémoire et non d’y écrire des données. Après plusieurs recherches, deux
programmes ont retenu mon attention, car ils sont très simples d’utilisation
et ils permettent de lire la mémoire. Voici les deux logiciels en question :
– Le premier se nomme SeTool2lite
Ce logiciel est un logiciel spécialisé dans les mobiles Sony Ericsson.
Il permet de lire exclusivement les mémoires des téléphones de cette
marque.
– Le deuxième se nomme Flash and Backup
Ce logiciel est un logiciel payant spécialisé dans les mobiles Motorola.
Il permet de lire exclusivement les mémoires des téléphones de cette
marque.
D’après l’analyse comparative des avantages et des inconvénients des deux
logiciels qui sont reportés dans le tableau 3.1, le logiciel Flash and Backup
semble être le plus approprié. D’après nos exigences, ce logiciel sera donc
retenu, car la connaissance de la position des différentes adresses mémoire
dans le téléphone, dont celle des données utilisateur, est une information
primordiale. Cependant, le choix de celui-ci impose également des restrictions
quant aux téléphones. En effet, ce logiciel étant spécifique aux téléphones
Motorola, notre analyse va donc porter exclusivement sur cette marque. C’est
pour cela que tout le travail sera fait au moyen du téléphone Motorola V3i.
17
18
CHAPITRE 3. DUMP MÉMOIRE
Nom
Avantages
SeTool2lite - Logiciel complètement gratuit et
100% fonctionnel (aucune restriction).
- Ne nécessite pas l’installation de
nombreuses librairies tierces (les
(( dll )) sont embarquées dans le
programme).
Flash and
Les
différentes
adresses
Backup
mémoires sont connues pour
de nombreux téléphones (par
exemple : les données utilisateur,
le firmware, etc.).
- Affiche les commandes utilisées
pour effectuer une opération.
Inconvénients
- Les plages mémoires à lire
doivent être introduites à la main,
ainsi que la taille du bloc de lecture.
- Logiciel payant, utilisable
uniquement 30 jours.
- Il faut au préalable installer le
logiciel de mise à jour de Motorola pour que celui-ci installe les
différentes librairies dont à besoin
l’application pour qu’elle puisse
fonctionner
Tab. 3.1 – Comparaison de logiciels
3.2
Comment effectuer un Dump
Comme expliqué dans la section 3.1, le choix a été porté sur le logiciel Flash and Backup. Afin d’installer correctement ce logiciel, il faut
tout d’abord être sous un environnement Windows. Ensuite, il faut se procurer et installer le logiciel de mise à jour de Motorola, celui-ci peut être
téléchargé sur le site du fabriquant dans la rubrique support - http://
www.motorola.com. L’installation de ce logiciel a pour but de copier dans
le répertoire système de Windows les librairies nécessaires au bon fonctionnement du téléphone. Une fois cette opération effectuée, il faut se procurer le logiciel Flash and Backup, celui-ci peut être téléchargé sur le site
- http://www.motorola-tools.com/backup-tool.php. Une fois que nous
avons procédé à la mise en place des différents logiciels, l’application est
prête à être utilisée.
Attention ! Etant donné que ce logiciel est payant, il ne peut être utilisé
gratuitement que durant la période limitée de 30 jours.
Voici maintenant la marche à suivre qui permet d’effectuer un dump :
– Etape 1
Allumer le téléphone en mode Program. Pour lancer ce mode, il faut
maintenir la touche * et la touche # enfoncées et allumer le téléphone.
3.2. COMMENT EFFECTUER UN DUMP
19
Fig. 3.1 – Flash and backup - Ecran initial
–
–
–
–
Cette manipulation fonctionne avec la plupart des modèles Motorola,
mais il est possible que cette manipulation soit différente sur certains
modèles, voir des modèles à venir. Une fois le téléphone allumé, sur
l’écran apparaı̂t la version du boot loader et une information indique
que le système est prêt à être connecté à un ordinateur.
Etape 2
Installer le programme de mise à jour de Motorola. Il ne sert qu’à
installer les drivers et les librairies adéquates.
Etape 3
Connecter le téléphone à l’ordinateur grâce au câble USB. Une fois
celui-ci connecté, Windows installe correctement les drivers. Attendre
la fin de l’installation.
Etape 4
Exécuter le programme. Une fenêtre ressemblant à la fig 3.1 doit apparaı̂tre à l’écran. Sur celle-ci, plusieurs informations sont visibles :
L’état et la version du téléphone(1), le chemin de stockage des backups(2) et le modèle du téléphone que l’on désire lire(3). Une fois que le
modèle du téléphone est choisi et que le chemin des backups est entré,
il suffit de passer à l’étape suivante en sélectionnant l’onglet (( Read
Data )).
Etape 5
Une fenêtre ressemblant à la fig 3.2 apparaı̂t. Sur celle-ci, on peut
20
CHAPITRE 3. DUMP MÉMOIRE
Fig. 3.2 – Flash and backup - Ecran lecture mémoire
sélectionner la zone mémoire que l’on désire lire(1) (dans notre cas,
il s’agit de la CG2 Flex ) puis il faut choisir le mode de format du
backup(2) (dans notre cas le SMG binary files). Une fois entré toutes
les informations, il suffit de cliquer sur le bouton (( Read data )) et de
patienter un certain moment.
Lorsque ces opérations sont terminées, nous avons en notre possession
un dump complet de la zone mémoire des données utilisateur. Celles-ci se
présentent sous forme d’un fichier binaire. Maintenant, il s’agit de passer à
l’étape suivante qui consiste à analyser le fichier obtenu. Afin de protéger
les données des mauvaises manipulations lors de l’analyse, il faut procéder
systématiquement à la recherche de la signature du fichier. Cette signature
peut être obtenue grâce à la commande (( md5 )) ou (( sha1 )). Ces deux instructions ont comme objectif d’obtenir une signature unique pour chacun des
fichiers et ceci permet de s’assurer que le fichier ne subit aucunes altérations
de la part du logiciel ou de l’utilisateur.
Chapitre 4
Extraction des vidéos
4.1
Introduction
Ce chapitre va s’articuler de la manière suivante, tout d’abord nous allons
procéder à l’analyse des vidéos, puis à la recherche et enfin à la reconstruction de celles-ci. Le choix de commencer par la recherche et l’extraction des
séquences vidéo est simplement dû à la taille de celles-ci. En effet, ce type
de document multimédia est composé de nombreux éléments qui peuvent
être représentés sous forme de boı̂tes. Cette caractéristique sera analysée
plus en détails dans les sections suivantes. Etant donné le nombre important
de boı̂tes et la conséquente taille de celles-ci, une très grande partie de la
mémoire va être affectée et donc elle sera plus facilement repérable. Il ne faut
pas oublier qu’en moyenne la taille d’un dump d’un Motorola V3i est approximativement de 28MB. C’est pourquoi, si les modifications sont minimes, il
sera plus difficile de les trouver. En ce qui concerne le document multimédia,
nous utiliserons une vidéo ayant le format 3GP. Ce format est réputé pour
être utilisé par les appareils mobiles, ceci est dû à ses caractéristiques et à ces
spécificités qui vont être vues en détails dans les sections suivantes. De plus,
le fait de commencer par la recherche de cet élément comporte un autre avantage. En effet, les différentes boı̂tes que nous allons étudier dans ce chapitre
peuvent se situer à des endroits différents de la mémoire du téléphone ce
qui peut avoir pour effet de nous obliger à effectuer un certain nombre de
recherches et de déplacements dans le dump, nous permettant ainsi de nous
familiariser avec les outils de travail et de comprendre la structure du dump.
4.2
Norme 3GP
Cette section à pour objectif d’expliquer dans les grandes lignes la norme
3GP et ses dérivés. De plus, elle explique les avantages qu’apportent ce format
et pourquoi il est si diffusé dans le monde des appareils mobiles. Pour obtenir
21
22
CHAPITRE 4. EXTRACTION DES VIDÉOS
de plus amples informations sur les différentes normes, il suffit de se référer
aux sources qui leurs sont associées, lesquelles sont citées ci-dessous.
Pour commencer, il est important de savoir que le 3GP est un conteneur vidéo défini par la norme 3GPP1 [Lecomte et al., 2000] qui lui n’est
rien d’autre qu’une version simplifiée[Pereira and Ebrahimi, 2002] du format
MPEG-4 partie 142 . L’objectif principal de ce format est de réduire le volume
de stockage d’une vidéo et les besoins en bande passante, ceci afin de faciliter
la vision, que ce soit en direct ou en streaming3 depuis un serveur multimédia
ainsi que le transfert d’un appareil mobile à un autre. Il contient entre autre
la description de la taille des images et le (( Bit rate )), ce qui facilite l’obtention d’informations au sujet de la vidéo. De plus, lors d’un transfert d’un
support à un autre, l’envoi du plus grand et du plus important octet d’informations est toujours envoyé en premier, ceci afin de savoir ce qui va être
reçu et donc de pouvoir corriger, en cas d’erreur de transmission, les données
reçues. Dans le cas où une altération des données est trop importante, il est
possible que le receveur demande à nouveau un certain nombre de paquets.
C’est pour les raisons évoquées ci-dessus que ce support est surtout destiné aux téléphones mobiles de troisième génération, c’est à dire ce qui disposent de la fonction UMTS ou plus connu sous le nom 3G, mais on peut le
trouver tout aussi bien sur ceux de deuxième génération, de simples GSM,
ou encore sur des appareils mobiles comme des Palms, des Ipod, etc.
4.3
Structure d’une vidéo 3GP
Comme expliqué dans la section 4.2, la norme 3GP n’est rien d’autre
qu’un dérivé de MPEG-4. C’est pour cela que ces deux normes sont très
semblables et c’est pourquoi elles doivent être étudiées en respectant un ordre
bien précis qui consiste donc à comprendre, au préalable, la norme MPEG4 et uniquement par la suite le 3GP, car celui-ci n’est en fait rien d’autre
qu’une version simplifiée de la norme MPEG-4. La figure 4.1 nous montre
la hiérarchie principale de MPEG-4, qui dans notre cas est identique à celle
que nous étudions. Nous pouvons constater qu’elle est composée d’un certain
nombre de (( boı̂tes )) qui sont communément appelées (( box )) et elles ont
une disposition bien définie. Il est intéressant de noter que c’est en partie
grâce à cette hiérarchisation en forme de boı̂te que le MPEG-4 est devenu le
standard le plus diffusé parmi tous les formats vidéo. En effet, il est très bien
1
3rd Generation Partnership Project - assure la maintenance et le développement de
spécifications techniques pour les normes mobiles
2
Norme ISO/IEC 14496-14
3
permet la lecture d’un flux audio ou vidéo, à mesure qu’il est diffusé
4.3. STRUCTURE D’UNE VIDÉO 3GP
23
Fig. 4.1 – Structure du format MPEG-4
structuré et il suit une hiérarchie bien précise et logique. De plus, celui-ci
comporte diverses extensions permettant l’indexation d’images dans la vidéo
ou bien encore la superposition de différents plans dans une même image
afin de modifier différentes informations dans la vidéo, comme par exemple,
dans un match de football, le nom des sponsors en bordure de stades peut
être modifié en fonction de la chaı̂ne de télévision qui les diffuse. Mais ce
qui est relatif à la modification de la vidéo ou des trames, ne sera pas traité
dans ce document. Afin d’essayer de comprendre la figure 4.1, nous allons
analyser les boı̂tes les plus importantes ainsi que celles qui nous permettent
de reconstruire une vidéo pouvant être lue par un lecteur multimédia.
La première (( boı̂te )) qui nous intéresse est la boı̂te nommée (( ftyp4 )). Le
rôle de celle-ci consiste à indiquer, au périphérique qui va lire cette vidéo, le
format de la (( boı̂te )). Dans notre cas, ce sera principalement du 3GP(3GP1),
voir du 3GP2. Il est intéressant de préciser qu’un logiciel sachant lire une version antérieure, comme par exemple le 3GP1, est capable de lire un format
3GP2. Ceci est dû au fait que le format MPEG-4 a la propriété (( Compatibilité avant et arrière )).
La deuxième (( boı̂te )) qui nous intéresse se nomme (( moov5 )). Le but de
cette boı̂te si complexe est de décrire la vidéo et son contenu. Elle contient
toutes les métadonnées sur le document multimédia. En d’autres termes,
elle contient toutes les informations relatives à la vidéo. C’est à l’aide des
informations inscrites dans cette hiérarchie qu’il est possible de se promener
4
5
ftyp - File Type
moov - Movie
24
Fig. 4.2 – Structure de la (( moov box ))
dans la vidéo, d’aller de chapitre en chapitre, d’avoir le son synchronisé avec
l’image, de savoir combien de pistes audio elle contient, etc. Il est donc facile
de concevoir que cette boı̂te est primordiale. La figure 4.2 est une tentative
de représentation de la structure complexe de la (( moov box )), car il en va
de soit que cette figure n’est là qu’à titre indicatif dans le but de montrer
que la structure de cette boı̂te peut encapsuler énormément d’informations.
C’est également grâce à cette boı̂te que le streaming est en partie possible.
En effet, comme expliqué brièvement dans la section 4.2, c’est le premier
élément qui est envoyé. Permettant ainsi à la personne qui reçoit d’être en
possession de toutes les données nécessaires pour diffuser les données avant
la réception des données elles-mêmes.
Enfin, vient la dernière boı̂te qui nous intéresse. Elle contient les données
proprement dites de la vidéo. Celle-ci se nomme (( mdat6 )). Son but est de
contenir la séquence du film sous forme binaire. Les données contenues dans
celle-ci sont entrelacées, ce qui permet de jouer les flux synchronisés au fur et
à mesure de leur arrivée. Il est possible qu’il en existe plusieurs si le contenu
devait s’avérer trop volumineux pour être contenu en une seule boı̂te.
Le but est de trouver ces éléments. Si nous arrivons à réunir et à remettre
dans le bon ordre les trois boı̂tes citées ci-dessus, alors la vidéo serait reconstituée et elle pourrait à nouveau être lue. Il en va de soit que si la moov
box ou la mdat box venaient à être supprimées, il s’avérerait difficile, voir
impossible, de reconstruire la vidéo correctement. En revanche, s’il venait à
6
mdat - Media Data
4.4. ANALYSE DUMP MÉMOIRE
25
manquer la ftyp box, une reconstruction partielle, voir complète, serait envisageable grâce aux éléments des deux autres boı̂tes et aux spécifications du
mobile, dans notre cas celle du 3GP.
4.4
Analyse dump mémoire
Maintenant que nous savons de quoi est formée une vidéo au format 3GP
et que nous savons quelles boı̂tes sont importantes pour pouvoir afficher une
vidéo, nous pouvons procéder à la recherche de ces informations dans le dump
mémoire du téléphone mobile. Ceci n’est pas une mince affaire, car comme
expliqué dans l’introduction, la taille approximative d’une sauvegarde est
d’environ 28Mb et afin de retrouver des informations utiles à la reconstruction
de la vidéo, il faut avoir une méthode structurée et bien détaillée. Avant de
commencer quoi que ce soit, il faut être en possession d’un outil permettant
d’éditer des fichiers hexadécimaux qui devra en outre intégrer une fonction
de recherche. Le logiciel retenu pour effectuer ces manipulations est (( Gedit )).
Il a l’avantage d’être léger et facile à prendre en main. Maintenant que nous
avons le logiciel, il nous faut une méthode de travail qui nous permette de
retrouver les vidéos enregistrées.
Voici la procédure qui a été utilisée afin d’effectuer l’analyse et la recherche
d’informations.
– Etape 1
Effectuer un dump mémoire en suivant les étapes vues dans le chapitre 3
section 3.2 et nommer le fichier, par exemple (( dump initial )).
– Etape 2
Attendre la fin du dump et allumer le téléphone en mode normal (sans
le mode Program).
– Etape 3
Enregistrer une séquence vidéo assez courte (entre 4 et 8 secondes).
– Etape 4
Eteindre le téléphone et le démarrer en mode Program.
– Etape 5
Effectuer un nouveau dump mais cette fois-ci le nommer différemment,
par exemple (( dump final )).
Une fois ces opérations terminées, nous avons en notre possession un
dump initial, sans vidéo, et un autre final qui lui contient la vidéo enregistrée. Arrivé à ce stade, l’idéal serait de pouvoir effectuer une comparaison
entre les deux et examiner les différences qui s’y rapportent. En procédant
ainsi, il serait plus facile de retrouver la nouvelle vidéo qui a été enregistrée.
26
Malheureusement, l’outil qui a été choisi au départ, ne permet pas la comparaison entre deux fichiers, et l’idée de procéder à une comparaison manuelle
ne serait pas envisageable étant donné la taille et l’important contenu des
fichiers. Il faut donc trouver un outil permettant de comparer deux fichiers
hexadécimaux. Le programme comprenant cette exigence est (( emacs )). À
la base, c’est un logiciel qui permet d’éditer de simples textes, mais en basculant dans le mode hexl-mode, il est possible d’afficher correctement un
fichier au format binaire. De plus, il permet la comparaison de deux, voir
trois fichiers. En revanche, la fonction de recherche n’est pas aussi efficace
que celle de (( Gedit )), c’est donc pour cela que nous allons travailler avec les
deux logiciels en parallèle. Le premier qui va servir de recherche et l’autre
va servir de comparateur. Maintenant que nous disposons de tous les outils utiles pour analyser la mémoire, nous pouvons aller de l’avant et passer
à l’étape suivante. Celle-ci consiste à interpréter les différences et à comprendre lesquelles interviennent au niveau de l’enregistrement, car (( emacs ))
rencontre en moyenne 400 différences par comparaison. Il en va de soi que
le simple fait d’allumer ou d’éteindre le mobile provoque plusieurs modifications dans les données utilisateurs. Il est en outre possible qu’il utilise une
certaine partie de la mémoire comme (( mémoire temporaire )) pour charger
différents éléments pour lui essentiel mais qui n’entrent pas en compte dans
la création d’une vidéo. En faisant le tri, cette fois-ci de façon manuelle, nous
arrivons à identifier certaines zones qui sont plus significatives que d’autres.
En effet, celles-ci contiennent des symboles connus dans le format MPEG-4,
comme par exemple MOOV ou MDAT. Une fois ces zones isolées, les phases
de compréhension, de recherche et d’analyse peuvent commencer. Ces phases
sont typiquement du reverse engineering, elles consistent à essayer de comprendre comment sont goupillées les données par le fabriquant, et ceci afin de
trouver une logique au placement des diverses informations, et trouver une
façon générique de pouvoir lires et récupérer les données. C’est sans aucun
doute la partie la plus complexe et la plus longue du travail. C’est après
plusieurs jours de recherche que les résultats suivants ont pu être déduits.
Il est important de préciser que certains termes utilisés dans l’explication
proviennent des déductions qui ont été effectuées durant la recherche. Il est
donc possible qu’ils ne soient pas corrects, mais ce sont des termes qui ont
été jugés appropriés pour expliquer la fonction de l’instruction ou même pour
décrire un certain bloc.
Tout d’abord, il est intéressant de constater que le nom d’un fichier vidéo
est écrit sous forme ASCII, mais séparé par des zéros. Cette représentation
est plus connue sous le nom d’unicode.
Par exemple, (( test.3gp ))
– en ASCII simple : 74 65 73 74 2E 33 67 70
27
Signature
Nom Fichier
Série de FFF
Moov box
Fig. 4.3 – Structure d’un entête vidéo avec le nom
– en ASCII unicode : 74 00 65 00 73 00 74 00 2E 00 33 00 67 00 70
Une fois que l’on connaı̂t cette petite subtilité, il est facile de trouver
tous les noms des vidéos qui sont contenus dans le téléphone. Arrivé à ce
stade, il est intéressant de constater qu’il y a des noms de fichiers qui ne sont
pas visibles même par l’intermédiaire de l’explorateur du mobile. Il est donc
facile de comprendre que nous sommes en présence de noms de vidéos qui
ont dû être pris et supprimés par la suite. Maintenant que nous avons trouvé
sous quelle forme sont transcrits les noms des vidéos dans la mémoire, nous
pouvons procéder à l’analyse des (( alentours )) du nom, c’est-à-dire avant et
après les noms dans le but d’essayer de trouver d’autres informations utiles
à la reconstruction. Il s’avère que le nom est immédiatement suivi de l’entête
d’une (( moov box )). Ceci est une information forte intéressante, car cela
signifie que le nom du fichier est directement associé à un entête de vidéo. De
plus, en comparant un certain nombre de noms de vidéo, il s’est avéré qu’une
certaine séquence de bit apparaı̂t toujours sous la même forme juste avant
le nom, à l’exception des vidéos qui ne sont pas filmées par le téléphone luimême, mais qui sont des séquences que Motorola a inséré directement. Ceci
nous porte à croire qu’il existe une signature spécifique à la nature de la
prise de la vidéo. Voici donc les deux signatures qui vont nous permettre de
déterminer et surtout de différencier les vidéos du fabriquant de celles prises
par le téléphone.
Signature 3GP Constructeur
Signature 3GP Personnel
00 07 00 04 00 00 00
00 0E 00 04 00 00 00
La figure 4.3 consiste en la représentation de la structure d’un entête de
vidéo avec son nom associé.
Maintenant que nous avons une structure correcte pour la boı̂te (( moov
box )) et le nom qui lui est associé, il faut essayer de trouver et d’analyser le
contenu proprement dit de la vidéo, c’est-à-dire la (( mdat box )). Celle-ci s’est
avérée facilement identifiable. En effet, le simple fait d’effectuer une recherche
avec comme terme mdat nous amène directement à la boı̂te en question.
28
0x10000
0x10000
0x1C00
0x1C00
0x11C00
0x11C00
0x1C00
0x1C00
0x13800
0x13800
0x1C00
0x1C00
0x15400
0x15400
0x1C00
0x1C00
0x17000
??????
Taille (4bits)
Série de FF
Mdat
Signature
Taille (4bits)
Taille (4bits)
Série de FF
Fdat
0x17000
Mdat
Signature
Fig. 4.4 – Structure d’une boı̂te mdat
L’analyse de la boı̂te (( mdat )) est possible étant donné que nous avons
réussi à trouver un moyen de l’identifier dans la mémoire. La première chose
qu’il est possible de constater, c’est que la structure diffère énormément de
celle de la (( moov box )). En effet, la boı̂te contenant l’entête de la vidéo
est écrite dans le sens croissant des adresses, ce qui signifie que les données
partent par exemple de l’adresse 0x1000 et se finissent en 0x1FFF. Tandis
que dans cette boı̂te, les données sont écrites dans le sens décroissant, c’està-dire qu’elle commence à l’adresse 0x1FFF et se termine en 0x1000. Mais
après mûre réflexion et analyse, il s’est avéré que la structure est nettement
plus complexe qu’elle n’y paraissait. Comme expliqué ci-dessus, les données
sont écrites dans l’ordre décroissant, mais en plus d’être inversées, elles sont
écrites par des blocs qui ont une taille bien définie. Cette dimension vaut
0x1C00 ce qui correspond à une taille de 7 KB. Mais dans cette boı̂te, les
données sont inscrites dans un ordre tout à fait normal, c’est-à-dire en sens
croissant. L’image de gauche de la figure 4.4 permet d’illustrer cette structure
si spécifique. De plus, nous y voyons figurer aussi la structure de la (( fdat ))
qui est expliquée ci-dessous et un élément de signature qui sera expliqué par
la suite.
La boı̂te (( ftyp ))peut être trouvée de la même façon que les autres, c’est
à dire qu’il suffit d’effectuer une simple rechercher du terme (( fdat )) dans la
mémoire, et ceci nous amène directement à l’endroit contenant le début de
la boı̂te. La structure est la même que pour celle d’une (( mdat box )), c’est-àdire que les quatre premiers bits nous indiquent la taille et que la façon dont
sont inscrites les données est normale (croissant). Il est intéressant de noter
qu’il n’est pas possible de savoir si les blocs sont inscrits par taille de 0x1C00,
car la taille de cette boı̂te est extrêmement réduite (environ 20 bit).Il reste à
savoir comment est fait le lien entre cette boı̂te et les autres. La jointure se
fait presque automatiquement, car la boı̂te (( ftyp )) est immédiatement suivie
29
Dump mémoire
Signature + nom de fichier
Moov box
Ftyp box
Mdat box
Fig. 4.5 – Structure général d’une vidéo dans un dump
de la boı̂te étudiée précédemment, c’est-à-dire la (( mdat )). L’image de droite
de la figure 4.4 représente une vue d’ensemble de la structure (( fdat )) ainsi
que de la structure (( mdat )).
Maintenant que nous sommes en possession de tous les éléments nécessaires
à la reconstruction de la vidéo, c’est-à-dire le nom du fichier, les boı̂tes
(( moov )), (( ftyp )) et (( mdat )), il nous reste à les réunir dans le bon ordre et
à effectuer un lien entre l’entête de la vidéo et les données de celles-ci, car
jusqu’à présent, nous avons analysé tous les éléments séparément mais nous
n’avons trouvé aucun lien permettant l’union des deux. En fait, cette liaison
est assurée par (( une signature unique )) que l’on retrouve avant la signature
indiquant la nature de la vidéo, avant le nom de fichier (se référer à la fig 4.3)
et juste après les données de la vidéo (dans la figure 4.4 cette signature est
déjà présente). C’est en effet après de nombreux jours de recherches et de
comparaisons que cette déduction a pu être faite. Cette (( signature unique ))
(terme inventé) est codée sur 8 Bytes qui n’est autre qu’une séquence de 4
Bytes répétée deux fois. Voici un exemple de cette (( signature unique )).
47 4D 63 1C
47 4D 63 1C
C’est grâce à cette information qu’il est maintenant possible d’associer
un entête de vidéo, qui lui comporte un nom de fichier avec son contenu. La
figure 4.5 résume l’architecture d’un fichier vidéo tel qu’il a pu être déduit
jusqu’à présent dans le fichier binaire de départ.
Il faut noter que cette architecture est le fruit d’une analyse menée au
cours de nombreuses comparaisons de fichiers, de nombreux tests et essais. Il
se peut très bien que celle-ci ne soit pas exacte et pourrait comporter quelques
erreurs. Mais dans notre cas, elle apporte des résultats plutôt satisfaisants.
Enfin, il faut souligner que cette architecture fonctionne très bien pour les
30
vidéos de nature personnelle, mais hélas, elle ne peut pas s’appliquer aux
vidéos du fabriquant, car celles-ci ont un format différent de celui qui a
été jusqu’à présent analysé. De plus, il s’est avéré impossible de créer ou de
reconstituer une vidéo avec les mêmes spécificités que celles enregistrées par le
fabricant, d’où la décision de ne pas étudier, ni analyser ce type d’architecture
différente.
4.5
Reconstruction de vidéo
Maintenant que nous avons analysé la mémoire et que nous connaissons la
façon dont sont sauvegardées les données au sein de celle-ci, il faut reconstruire la vidéo grâce à toutes les informations recueillies jusqu’à présent. Pour
procéder à cette reconstruction, nous devons mettre au point un programme
qui sera écrit en langage C. Le choix de ce langage est dû au fait que celui-ci
s’applique très bien en bas niveau, lecture-écriture bit à bit, et permet de
se promener dans les fichiers binaires de manière très facile grâce aux pointeurs. De plus, étant donné qu’il est particulièrement efficace en bas niveau,
l’exécution de celui-ci s’avère très rapide. A présent passons à l’explication
du code et surtout aux difficultés encourues durant la partie proprement dite
de programmation.
La première étape consiste à (( mapper )) un pointeur sur le fichier, ainsi
il sera plus facile de naviguer à l’intérieur de celui-ci. Cette manipulation est
réalisée grâce à l’instruction suivante :
mmap(adress, length, read-write, flags, file descriptor, offset)
Cette instruction provient de la librairie standard du C et elle permet
de retourner un pointeur sur le fichier passé en paramètres. Maintenant que
nous avons un moyen de déplacement dans le fichier, voici la façon dont nous
allons procéder pour reconstruire la vidéo. Mais avant de commencer, il est
important de noter que certaines informations étudiées dans les sections 4.3
et 4.4 peuvent s’avérer manquantes dans le cas de vidéos effacées. Il faut
donc prévoir à l’avance ce cas de figure. C’est pourquoi, il nous faut travailler
avec une structure pouvant contenir toutes les informations nécessaires à la
reconstruction.
Voici la forme de cette structure.
4.5. RECONSTRUCTION DE VIDÉO
31
VideoStructure
– char *title
– char *ID
– long moovAddress
– int moovSize
– long ftypAddress
– int ftypSize
– long mdatAddress
– int mdatSize
Celle-ci contient toutes les informations utiles et nécessaires à la reconstruction d’une vidéo. Le rôle du programme est de remplir ces informations,
puis, toujours grâce à ces informations, il sera possible de recréer l’objet multimédia. De plus, grâce à cette structure, il est possible de remplir au fur et
à mesure les données et uniquement à la fin, il est possible de contrôler si la
vidéo peut être reconstruite ou pas. En effet, trois passes dans le fichier sont
nécessaires pour remplir tous les champs.
La première passe sert à trouver tous les noms de fichiers et toutes
les signatures. De plus, cette manipulation permet de remplir les champs
moovAdress et moovSize. En effet, comme expliqué dans la section précédente,
la (( moov box )) est précédée par le nom du fichier s’il en existe (dans notre
cas c’est le nom de la vidéo qui a été supprimée). C’est uniquement arrivé à
la fin du premier passage, qu’il sera possible de savoir exactement combien
de vidéos nommées sont contenues dans toute la mémoire et il ne pourra
pas y en avoir une de plus. Ce premier passage terminé, trois cas de figures
peuvent se présenter.
Le premier cas de figure est celui où toutes les informations désirées ont
été trouvées. Nous allons donc créer un tableau de vidéos (( namedVideo ))
qui contiendra toutes les structures nommées.
Voici à quoi ressemble la structure dans ce cas de figure.
VideoStructure
– title
– ID
– moovAddress
– moovSize
Le deuxième cas de figure est celui où les informations sur la (( moov box ))
sont manquantes. Cette structure peut être insérée dans le tableau des vidéos
nommées, mais malheureusement nous sommes dans un cas où la vidéo ne
pourra pas être complètement reconstruite, voir pas du tout. En effet, les
informations contenues dans la (( moov box )) sont primordiales étant donné
32
qu’elle contient toutes les informations relatives à la vidéo, et sans cette boite
la vidéo ne peut être visionnée.
VideoStructure
– title
– ID
Le troisième et dernier cas de figure qui peut survenir est celui où les
informations sur le nom seraient manquantes. Nous allons donc pour cela
créer une nouvelle variable qui sera un tableau de vidéos (( unNamedVideo ))
qui contiendra toutes les structures non nommées avec quelques informations.
Cette fois-ci, nous sommes dans un cas où la vidéo peut être reconstruite
facilement à condition que l’ID soit présent. Si ce n’est pas le cas, la vidéo
pourra peut-être être reconstruite, mais seulement à l’aide de différents essais.
VideoStructure
– ID (il est possible que cette information ne soit pas
trouvée)
– moovAddress
– moovSize
Maintenant, il faut procéder à un nouveau passage afin d’essayer de trouver et d’associer, si possible, le contenu de la vidéo avec son entête. Cette
opération peut être menée à bien grâce à l’information contenu dans ID de la
structure. Pour ce faire, il suffit de reparcourir à nouveau toute la mémoire,
mais cette fois-ci en cherchant toutes les boı̂tes (( Mdat )). Une fois trouvé une
boı̂te, la signature de celle-ci est comparée à celles en notre possession qui
ont été obtenues lors du premier passage. Si la même est trouvée cela signifie qu’une association entre un entête et son contenu a été trouvée. Il suffit
donc de compléter les informations relatives à l’adresse et à la taille de la
(( moovBox )) dans notre structure. Dans le cas où la signature ne correspond
à aucunes en notre possession, il nous faut ajouter un nouvel élément dans le
tableau des vidéos (( unNamedVideo )) avec comme informations uniquement
l’adresse et la taille de la (( mdatbox )).
A ce stade voici la structure que l’on obtient dans le cas d’une vidéo dont
nous avons tous les renseignements.
4.5. RECONSTRUCTION DE VIDÉO
33
VideoStructure
– title
– ID
– moovAddress
– moovSize
– mdatAddress
– mdatSize
Pour finir, vient le troisième et dernier passage, qui lui permet de rechercher
et de remplir les champs manquant, c’est-à-dire les informations sur la boı̂te
(( ftyp )). Comme dans les autres cas, il peut s’avérer que la (( signature unique ))
ne corresponde à aucune autre que l’on possède. Il faut donc ajouter ce nouvel élément au tableau des vidéos non nommées. Dans le cas contraire, la
structure sera complète et nous pourrons passer à l’étape de reconstruction
de la vidéo grâce à tous les renseignements obtenus jusqu’à présent.
Nous allons commencer par l’analyse du tableau des vidéos nommées.
Tout d’abord, nous parcourons la totalité des éléments du tableau, puis nous
contrôlons si toutes les valeurs de la structure sont valables. Si effectivement
c’est le cas, nous reconstruisons la vidéo en suivant le schéma et les instructions de la norme 3GP vus dans la section 4.3. Si en revanche, une des deux
boı̂tes, c’est-à-dire soit la (( fdat )) soit la (( mdat )), n’est pas valable ou serait
manquante, nous serions contraints d’essayer de reconstruire la vidéo avec
les éléments se trouvant dans le tableau des vidéos qui sont non nommées,
cependant à condition que celles-ci soient existantes et valides à leur tour.
Ceci permet de faire des essais avec différents éléments dont il n’a pas été possible de trouver ce fameux lien qui permette d’unir l’entête avec les données.
La figure 4.6 permet d’illustrer toutes les étapes expliquées jusqu’à présent
et ceci de façon schématique.
Enfin, nous parcourons les éléments du tableau dont on ne connaı̂t pas
le nom du fichier. Cela ne sert à rien d’essayer de faire des combinaisons
avec les éléments du tableau nommé, car celles-ci ont déjà été effectuées
précédemment. En revanche, il serait utile de parcourir tous les éléments et
de contrôler si la boı̂te (( mdat )) n’est pas corrompue. Si c’est le cas, il est
intéressant de construire cette boı̂te afin d’essayer de l’examiner avec d’autres
outils de (( Forensics )). Il en va de soi que malheureusement cet élément ne
pourra être visionné par aucun lecteur multimédia étant donné que l’entête
est manquant.
Ceci met fin au programme et au processus de reconstruction des vidéos.
A l’écran apparaı̂t un résumé concernant le nombre de vidéos nommées ou
non nommées trouvées, ainsi que la taille du fichier, etc.
34
Fig. 4.6 – Flowchart pour la recherche et la reconstruction d’une vidéo
4.6
Résultats et conclusion
Les résultats de cette exécution du programme produisent des vidéos qui
se situent dans un répertoire portant l’heure actuelle et la date du jour. Ces
fichiers portent si possible le nom réel de la vidéo (si on a pu le trouver) et
peuvent être visionnés par un lecteur multimédia ayant les codecs7 adéquats.
Après une exécution sur notre dump, nous pouvons constater que les
vidéos enregistrées ainsi que celles effacées ou bien même celles qui n’ont
pas été sauvegardées ont été récupérées. Ceci est un résultat fort satisfaisant,
cependant, les vidéos sont incomplètes... En effet, il s’est avéré que le contenu
de la vidéo (la boı̂te (( mdat ))) n’est pas enregistré à la suite. Arrivé à un
certain stade, les données sont écrites dans une autre partie de la mémoire
comme le montre la figure 4.7. Malheureusement, aucuns liens ni aucunes
informations n’ont été trouvés à ce sujet. Aucunes informations se trouvant
dans les alentours des boı̂tes étudiées n’ont pu être utiles à la détermination
du nombre de saut de 0x1C00 qu’il faut effectuer avant de devoir lire la
mémoire dans un autre endroit. Il n’a même pas été possible de savoir à quel
7
COdeur / DECodeur - permet de décoder ou d’encoder un type de vidéo ayant un
certain format (dans notre cas 3GP)
4.6. RÉSULTATS ET CONCLUSION
35
Dump mémoire
0x05000
0x1C00
0x06C00
0x1C00
?????????
0x10000
0x1C00
?????????
0x11C00
0x1C00
0x13800
0x1C00
0x15400
0x1C00
Taille (4bits)
Taille (4bits)
Série de FF
Fdat
0x17000
Mdat
Signature
Fig. 4.7 – Architecture d’une vidéo dans un dump
endroit se trouve la suite de la vidéo. Après de nombreuses suppositions,
celle qui paraı̂t la plus plausible est que le téléphone tient à jour une base de
données qui permet de savoir où sont localisés exactement tous les fragments
de la vidéo. Mais étant donné le nombre important de modifications dans la
mémoire et la compréhension des données modifiées, il s’est avéré impossible
de trouver cette soit disant base de données. Cette méthode a donc une limite
quant à la validité en tant que preuve, car la vidéo est incomplète et elle ne
comporte que le début.
Un autre point négatif est l’exécution de ce même programme sur un
téléphone dérivé du Motorola V3. En effet, il a été effectué un dump de la
mémoire d’un téléphone V3r en suivant les instructions du chapitre 3 et il
s’est avéré que les informations ne sont pas stockées de la même manière
que sur un V3i. Ceci a donné lieu à l’impossibilité d’extraire correctement
toutes les vidéos et celles qui ont été trouvées ne comportaient aucun nom
et étaient, elles aussi, incomplètes.
Ceci nous amène à la conclusions que malgré tous les efforts fournis pour
trouver une méthode aussi générique que possible, chaque téléphone a sa
propre méthode d’écriture des vidéos et par conséquent elle ne peut être
considérée comme générique en ce qui concerne la recherche de vidéo. De
plus, la vidéo est incomplète, ce qui se résume à un échec partiel de la reconstruction d’une vidéo. Mais malgré tous ces points négatifs, il faut souligner
qu’il a été prouvé qu’il est possible de retrouver des informations qui ont
été supprimées, voir même jamais enregistrées. Si le temps le permettait, il
serait intéressant de passer plus de temps sur ce type d’analyse. Cependant
36
il faudrait élargir la recherche à d’autres méthodes et à d’autres modèles de
téléphone tout en collaborant avec les fabricants, comme il a déjà été évoqué
au préalable dans le chapitre 2, et ceci afin de pouvoir mettre au point une
(( base de connaissance )) aussi riche et juste que possible.
Chapitre 5
Extraction des messages
5.1
Introduction
Les messages, plus connus sous l’acronyme de SMS1 ou encore (( texto2 )),
permettent de transmettre du texte, de taille relativement réduite, d’un
téléphone mobile à un autre ou d’un téléphone mobile à un ordinateur. Le
premier SMS écrit depuis un terminal remonte à décembre de 1992 et il aurait
été envoyé par un employé de Sema Group. En revanche, le premier message
rédigé et envoyé depuis un téléphone mobile par un étudiant en ingénierie
de Nokia remonte à 1993. L’invention du minimessage avait pour principal
objectif de permettre à l’opérateur d’envoyer des messages aux clients, mais
par la suite, le texto a pris une toute autre forme dans notre société et celui-ci
est devenu rapidement un moyen de communication très prisé, tout particulièrement parmi les jeunes. Sa popularité est telle que de nos jours, l’envoi
de messages par minute dans le monde est équivalent à 50’000 SMS3 .
De plus, l’étendue de son utilisation est tellement vaste que chaque jour
les utilisateurs particuliers ou les professionnels spécialisés dans le domaine
découvrent de nouvelles techniques de communication. Ainsi, les SMS peuvent, par exemple, être utilisés dans les communications de machine à machine, ce qui est le cas des afficheurs à LED4 qui sont contrôlés par SMS
ou encore dans des systèmes d’alarmes qui envoient un message lors d’une
intrusion, etc.
Les SMS sont transportés dans des canaux de signalisation définis par
la norme GSM et donc ils n’occupent pas la bande passante réservée aux
transports de la voix. La taille du SMS étant limitée à un certain nombre de
caractères, son transport ne coûte à l’opérateur que très peu.
1
Short Message Service
Marque déposée par l’opérateur SFR
3
Source : Guiness World Records 2007 - Hachette - p. 91
4
LED ou DEL - Diode électroluminescente
2
37
38
CHAPITRE 5. EXTRACTION DES MESSAGES
La version améliorée du SMS n’est autre que le MMS qui permet de transmettre des messages beaucoup plus longs et au contenu riche et élaboré tels
que le sont les photos, les messages vocaux ou encore les vidéos. Contrairement aux SMS, les MMS utilisent des canaux spécifiques qui doivent donc
être prévus par l’opérateur.
5.2
Détails techniques
L’envoi et la diffusion de SMS sont basés sur deux protocoles différents
qui suivent chacun une norme précise.
– La première est basée sur le protocole Short Message Service - Point
to Point (SMS-PP) qui est défini par la norme de téléphonie mobile
GSM 03.40[ETSI, 2001]. Cette méthode permet l’envoi et la réception
de message d’un point à un autre, c’est-à-dire d’un téléphone mobile,
ordinateur, etc.
– La deuxième est basée sur le protocole Short Message Service - Cell
Broadcast (SMS-CB) qui est défini par la norme GSM 03.41[ETSI, 2002].
Cette deuxième méthode permet de diffuser des messages publicitaires,
informations publiques, etc, à tous les utilisateurs de mobiles d’une
zone géographique déterminée.
La taille d’un SMS est relativement réduite, cependant elle varie en fonction de l’encodage utilisé. Ainsi la taille maximum d’un message est de 160
caractères si l’encodage de celui-ci est sur 7 bits (standard), en revanche, si
l’encodage est sur 8 bits, alors la taille maximum du SMS sera de 140 caractères, et enfin si l’encodage est sur 16 bits alors le message de disposera que
de 70 caractères. Un texte plus long, appelé SMS long ou SMS concaténé,
peut être envoyé par le biais de la segmentation que l’appareil mobile fait
de manière automatique donnant lieu à plusieurs messages. C’est ensuite à
l’appareil qui reçoit de devoir reconstituer le message d’origine en rassemblant tous les segments. En théorie, il serait possible de concaténer jusqu’à
255 messages, mais en pratique, nous sommes limités entre 4 et 8 messages
à la suite. Il est important de souligner que l’opérateur facture chaque SMS
indépendamment. Pour toutes informations relatives à l’alphabet utilisé ou
à l’encodage utilisé, il faut se référer à la norme GSM 03.38 [ETSI, 1998].
L’envoi d’un message est basé sur le mécanisme du (( Store and forward )).
Ce mécanisme a pour but d’enregistrer une information à un endroit et par la
suite de l’envoyer. En effet, lors de l’envoi d’un sms, il est envoyé à un centre
SMS (SMSC) qui essaie de le transmettre au destinataire. Si ce dernier n’est
pas joignable, le centre stocke le message pour le retransmettre plus tard et
ceci jusqu’à ce que le destinataire soit disponible ou que la période de validité
5.2. DÉTAILS TECHNIQUES
39
du message soit dépassée.
Pour que cette mécanique soit possible, il y a deux opérations :
– Mobile Originating (MO), pour ceux qui sont envoyés depuis un terminal mobile.
– Mobile Terminated (MT), pour les messages envoyés à un terminal
mobile,
La livraison du message étant basée sur la politique du (( best effort5 )),
il n’y a donc aucune garantie qu’un message soit effectivement délivré à
son destinataire. L’expéditeur peut demander un accusé de réception de son
message, mais les notifications d’échec ou de réussite ne peuvent pas être
garanties, car elles aussi sont basées sur la même politique.
Pour finir cette section, il est intéressant de savoir qu’il existe plusieurs
classes de messages. En effet, quand un SMS est reçu par un téléphone mobile,
il est traité de manière différente en fonction de sa classe. Voici une brève
description de celles-ci.
– Classe 0
Le message est directement affiché à l’utilisateur sur l’écran du mobile
à la réception. Un rapport est envoyé ensuite au centre de service. Le
message n’est enregistré ni dans la mémoire du téléphone ni dans la
carte SIM6 . Il est effacé dès que l’utilisateur a validé la visualisation.
– Classe 1
Le message est directement enregistré dans la mémoire du téléphone,
en revanche, si cette mémoire est pleine, il est enregistré dans la carte
SIM par défaut.
– Classe 2
Le message est enregistré sur la carte USIM7 . Un accusé de réception
est envoyé au centre de services une fois que le message a bien été
transféré sur l’USIM.
– Classe 3
Le message est transféré sur un équipement externe connecté au mobile
(PDA, PC portable, etc.)
5
Meilleur effort - Aucune garantie de livraison, mais fournis l’effort maximum pour y
parvenir
6
Subscriber Identity Module
7
Universal Subscriber Identity Module- gère le 3G
40
5.3
Le format PDU
Pour permettre l’envoi et la réception de messages, deux méthodes s’offrent à nous, le (( Text Mode )) et le PDU8 mode. Le (( text mode )) est simplement l’encodage d’un flux de bits qui représente uniquement le message.
Il est important de savoir que certains téléphones ne sont pas compatibles
avec ce mode.
Le mode PDU est le moyen d’encoder un message avec toutes les informations relatives à celui-ci. En effet, le PDU ne contient pas seulement le
message, mais beaucoup d’autres méta-informations comme par exemple l’envoyeur, l’heure et la date d’envoi, le numéro du centre de messagerie(SMSC),
etc. Ces informations peuvent être écrites sous deux formes différentes. Sous
la forme hexadécimale octets ou la forme décimale semi-octets. La séquence
d’octets du PDU est constituée de trois parties principales : les informations
sur le SMSC, les informations sur l’envoyeur, et la date et l’heure. Pour essayer de comprendre davantage ce format, nous allons utiliser une suite de
bits comme exemple pratique. Le tableau 5.1 regroupe et donne une explication des différents octets qui sont contenus dans la chaı̂ne.
Voici l’exemple :
07917283010010F5040BC87238880900F10000993092516195800AE832
Octet(s)
Description
07
Taille des informations SMSC
91
Type d’adresse de l’SMSC*.
72 83 01 00 10 F5
Numéro du Centre de service
04
Premiers octets du SMS-DELIVER
0B
Taille des informations de l’émetteur
C8
Type d’adresse de l’émetteur*.
72 38 88 09 00 F1
Numéro du l’émetteur
00
TP-PID Protocol identifier
00
TP-DCS Data coding scheme
99 30 92 51 61 95 80 TP-SCTS Time stamp (date et heure)
0A
TP-UDL User data length, taille du message
E8 32
TP-UD Message
∗91 est le format international de numéro de téléphone
Tab. 5.1 – Explication des octets PDU
8
Protocol Description Unit
5.4. RECHERCHE DANS LE DUMP
41
Ceux pour qui l’explication concernant les derniers bits peut paraı̂tre un
peu floue, la référence [Pettersson, 2007] apporte davantage d’informations.
Il est important de souligner que l’exemple qui précède a été tiré de cette
même référence.
Pour finir cette section, il est important de dire que le format PDU comporte plusieurs avantages. Premièrement, n’importe quel encodage de caractère peut être implémenté et utilisé pour l’envoi de messages. Deuxièmement,
tous les téléphones sont compatibles avec ce mode, et enfin, comme expliqué
ci-dessus, ce format ne contient pas uniquement le message, mais énormément
d’informations complémentaires qui se révèlent d’une grande importance,
comme par exemple l’heure, la date de réception, etc.
Il est important de comprendre ce format, car il y a de fortes chances que le
message soit stocké dans la mémoire sous cette forme.
5.4
Recherche dans le Dump
Maintenant que nous sommes en possession de toutes les informations
relatives à la norme SMS, au format du message et à l’encodage de celui-ci, il
est maintenant possible de passer à l’étape suivante qui consiste à rechercher
les minimessages dans le dump mémoire et à pouvoir en extraire toutes les
informations le concernant.
Pour commencer, nous aller procéder de la même méthode qui a été vue
dans les chapitres précédents, c’est-à-dire que nous allons d’abord essayer de
trouver dans la mémoire un message existant et uniquement par la suite,
nous allons voir s’il en existe pas des autres qui ne seraient pas visibles
par le téléphone mobile. Dans le modèle que nous avons à disposition, il
existe un message avec le mot (( SAMSUNG )). Nous allons utiliser ce mot
assez (( spécifique )) pour essayer de le retrouver dans le dump. Le simple
fait de rechercher cette expression en simple format ascii nous apporte aussi
ses fruits. En effet, nous atterrissons directement là où le message est stocké
dans la mémoire et celui-ci est écrit en clair dans la zone mémoire, c’est à dire
que simplement avec l’éditeur hexadécimal il est possible de lire le message,
cependant surviennent quelques exceptions. En effet, un certain nombre de
caractères n’apparaissent pas dans l’éditeur. Ce phénomène est dû aux caractères spéciaux tels que, les caractères accentués, les apostrophes, etc. Tout
caractère qui n’est pas une simple lettre ou chiffre n’apparaı̂t malheureusement pas dans l’éditeur étant donné son encodage. Mais nous verrons par la
suite comment traiter ces exceptions et trouver le moyen de rendre visible
ces caractères, non pas dans l’éditeur hexadécimal, mais dans un fichier texte
par exemple.
42
Maintenant que nous avons réussi à trouver un message, il faut découvrir
un moyen de pouvoir chercher les autres. Dans le cas précédent, nous avons
fait une recherche sur un terme connu et spécifique. Il est impossible de
retrouver un autre message avec cette expression. Il faut donc chercher un
(( pattern )) qui nous permettra de trouver d’autres messages et pourquoi pas
les messages effacés. Afin de découvrir ce pattern, il est nécessaire d’avoir
plusieurs échantillons comme pour les vidéos. Nous allons donc effectuer la
manipulation de recherche avec d’autres messages et d’autres termes exactement comme expliqué dans le paragraphe précédent. Grâce à tous ces messages, il est donc possible de trouver un éventuel pattern. C’est après quelques
heures de recherches et de raisonnements qu’un pattern susceptible d’en être
un, a été trouvé. La figure 5.1 illustre la signature trouvée.
00 91 00 00
Fig. 5.1 – Signature d’un SMS
Malheureusement, cette signature est beaucoup trop large, ce qui signifie qu’elle ramène des éléments qui ne sont pas des messages. Il faut donc
trouver un moyen d’éliminer les (( faux messages )). Pour réussir à supprimer
les intrus, il faut au préalable savoir, qu’avant ce pattern se trouve la taille
du message complet. En effet, cette découverte est nécessaire pour permettre
le filtrage des messages qui sont vides. L’idée de trouver la taille est venue
grâce au chapitre précédent (chapitre 4, Les vidéos), dont le but consistait
à déterminer la taille de chacune des boı̂tes. Cette démarche s’est avérée
positive étant donné qu’il existe aussi une taille pour chaque message. Il est
intéressant de souligner que la taille du message est codée 4 bytes.
Arrivé à ce stade il serait intéressant de voir le schéma de la figure 5.2 qui
représente la structure des SMS décrite jusqu’à maintenant. Il est important
de rappeler que tous les SMS étudiés jusqu’à présent sont (( courts )), c’està-dire qu’ils ont une longueur maximum de 160 caractères et ils ne sont pas
composés de plusieurs morceaux.
Maintenant que nous avons le début du SMS et la taille de celui-ci, nous
pouvons constater qu’entre le pattern et le début du texte, il y a une bonne
quantité de bits qui sont présents. Tout porte à croire qu’il s’agit du Header
du message qui est codé de façon spécifique, comme il a été vu dans la section 5.2. Le but est de réussir à déchiffrer le contenu de cet entête. D’après
la fig 5.2 et les constatations évoquées précédemment, l’entête se situe entre le pattern et le contenu du message écrit sous forme ascii. De plus, la
chaı̂ne de bits dont est constitué l’entête est relativement long, mais ceci est
compréhensible, car nous devrions y retrouver les informations principales
suivantes :
43
Taille total du SMS
(header inclus)
Pattern
00 91 00 00
Header
(voir plus bas)
SMS
sous forme
ASCII
Fig. 5.2 – Première version d’une structure d’un SMS dans un dump
–
–
–
–
numéro SMSC
numéro expéditeur
date de l’envoi
heure de l’envoi
Après de nombreux essais et de nombreux jours de recherche, les informations les plus importantes ont pu être extraites du header. Pour aboutir dans
cette entreprise, les informations vues au préalable dans la section 5.3 - Format PDU - sont primordiales. En effet, les données sont inscrites de manière
à suivre l’ordre du tableau 5.1, mais elles ne sont pas toujours représentées
de la manière décrite et surtout elles ne sont pas toujours présentes, cette absence est souvent relevée pour les numéros SMSC. De plus, en ce qui concerne
la date, elle n’est pas encodée de la même manière qu’expliqué dans la norme
PDU, car si nous prenons le cas de l’année, celle-ci fait référence au nombre
d’années suivant l’an 1970. Ainsi, par exemple, pour indiquer l’année 2008,
nous allons trouver comme information 38, qui correspond à 38 ans après
l’an 1970. Afin de mieux comprendre l’entête, il faut se référer à la figure 5.3
Comme le montre cette figure, certains éléments demeurent inconnus,
mais une chose importante qu’il faut souligner c’est que la date est précédée
d’un autre pattern. Celui-ci va nous être utile afin de nous positionner au
commencement de la date.
Voici le pattern de la date :
Maintenant que nous avons toutes les informations nécessaires, que nous
44
Signature
00 91 00 00
Inconnu
Patterne date
???
90 00 00 01 01
Numéro SMSC
taille num. format
Date
Année
Mois
Numéro expediteur
numéro
taille num. format
numéro
Heure
Jour
Heure
Minute
Inconnu
???
Seconde
SMS
taille SMS
SMS ASCII
Fig. 5.3 – Structure d’un header SMS
90 00 00 01 01
Fig. 5.4 – Pattern date
savons comment est formée l’entête d’un SMS et surtout de quoi il est composé, nous pouvons passer à l’étape d’extraction de ces éléments de façon
automatisée. Les informations et le texte du SMS seront inscrits dans un
fichier texte qui pourra être ouvert par un quelconque éditeur de texte.
5.5
Extraction des SMS
Pour commencer, il est important de savoir qu’une bonne partie de l’algorithme a été repris du chapitre 4, surtout la façon de parcourir et d’explorer
le dump mémoire. En effet, la méthode qui est utilisée est la même que pour
celle des vidéos mais le pattern de recherche change, comme nous avons pu le
voir à la figure 5.1 de la section 5.4. De la même manière que précédemment
nous allons travailler avec une structure de données que nous allons compléter
au fur et à mesure que nous rencontrons les informations à insérer.
Voici à quoi ressemble la structure :
5.5. EXTRACTION DES SMS
45
smsStructure
– long total adress
– int total size
– long sms adress
– int sms size
– char *SMSC number
– char *phone number
– int date year
– int date month
– int date day
– int time houre
– int time minute
– int time second
– unsigned char *sms text
Maintenant que nous avons tous les éléments, nous pouvons commencer l’explication de la recherche et de l’extraction.
Pour commencer, nous parcourrons le dump et lorsque l’on rencontre le
pattern, il nous faut voir si la taille du message est différente de zéro. Si c’est
le cas, nous pouvons procéder à l’extraction et au décodage de l’entête du
(( texto )). Pour se faire, nous allons commencer par trouver la date grâce au
pattern défini par la figure 5.4, mais avec une marge de sécurité, c’est-à-dire
que nous allons essayer de rechercher le pattern avec un incrément maximum
de la position que l’on ne peut pas dépasser. Si cette sécurité est dépassée,
par exemple si la sécurité est de cinq et que la date n’est toujours pas trouvée,
alors nous considérons que ce n’est pas un sms et nous quittons la fonction.
Si en revanche la date est trouvée, nous nous positionnons au début et nous
commençons à remplir les entrées de la structure avec les données concernant
l’année, le mois, le jour, l’heure, les minutes et pour finir les secondes. Ces
informations sont inscrites sous forme hexadécimale. Il faut donc les convertir
en décimales pour les rendre compréhensibles. Pour la conversion, ce sera le
langage C qui va s’en charger lors de l’écriture dans le fichier. Il faut juste
spécifier que l’on désire une écriture en décimales.
Une fois cette opération terminée, nous pouvons passer aux numéros
de téléphones. D’abord, vient le numéro SMSC et ensuite le numéro de l’expéditeur. Pour les trouver nous utilisons aussi une marge de sécurité qui
fonctionnera de la même manière que précédemment. Il n’existe pas de pattern pour les numéros, mais d’après les normes PDU, il y a le type d’adresse
qui permet de savoir si le numéro est international ou pas, c’est à dire s’il est
sous la forme +41 76 333 33 33 ou sous la forme 076 333 33 33. C’est donc
au moyen de ce paramètre que nous allons pouvoir les retrouver. Comme il
46
a été expliqué dans la section précédente, les numéros sont précédés de leur
longueur. Nous allons donc copier le numéro en faisant attention à son format, car ce dernier est assez particulier, il est sous forme ascii, mais inversé
deux à deux. De plus, si la longueur du numéro de téléphone est impaire, le
dernier byte sera un F. Pour expliquer au mieux ce format, voici un exemple :
91 33 06 09 10 93 F0
+ 33 60 90 01 39 0
Fig. 5.5 – Exemple du format d’un numéro de téléphone
Afin de permettre le décodage, la fonction (( decoding number )) a dû être
mise au point. Elle a pour but de retourner une chaı̂ne de caractères contenant le numéro correctement écrit y compris avec le format international
si cela s’avère nécessaire. Ce numéro est inscrit dans la structure à l’endroit
correspondant. Une fois fini, cette opération est répétée pour le numéro de
l’expéditeur qui est structuré de la même manière.
Maintenant que les informations voulues de l’entête ont été inscrites dans
leur emplacement respectif, il faut s’occuper du contenu du message. Pour ce
faire nous allons procéder de la manière suivante. Nous connaissons la taille
complète du message, y compris l’entête, et nous avons vu qu’au début du
contenu du SMS se situe le nombre de caractères que contient ce dernier.
Nous pouvons donc faire le calcul se reportant à la figure 5.6 pour savoir si
nous nous trouvons au début du message :
position depuis le début du sms + byte actuelle = taille total du SMS
Fig. 5.6 – Calcul permettant de savoir le début du SMS
Si l’égalité de la figure 5.6 est vérifiée, alors nous avons trouvé le début du
message. Maintenant, il suffit de retranscrire les valeurs ascii dans la structure en modifiant les caractères spéciaux, car les caractères accentués et non
standard comme les (( é, ê, ç, etc. )) ne s’affichent pas correctement. Il faut
donc, en suivant la conversion de la figure 5.7, faire la correspondance entre
le caractère inscrit dans le message et la table. Ainsi il est possible d’afficher
correctement tous les caractères, qu’ils soient accentués ou normaux. La fonction qui permet de retranscrire le message dans la structure de données se
charge aussi de la conversion.
Arrivé à ce stade, nous sommes en possession de toutes les informations
concernant le SMS y compris le texte lui-même. Il suffit de répéter toutes ces
opérations afin de trouver tous les messages effacés. Une fois que le dump
47
Fig. 5.7 – Table ASCII permettant de faire la conversion
mémoire a été entièrement parcouru, une fonction va se charger de parcourir
toutes les structures et de retranscrire les informations dans un fichier texte.
Ainsi tous les messages seront sauvegardés dans un fichier qui pourra être
consulté par la suite. Celui-ci va se trouver à la racine du répertoire qui a été
créé par la recherche de vidéos dans le chapitre 4. Pour conclure cette section,
une synthèse de l’extraction des SMS a été effectuée grâce au (( flowchart ))
représenté par la figure 5.8. Il contient les étapes et les choix principaux du
programme.
5.6
Le résultat de l’exécution du programme va être sous forme d’un fichier
texte qui sera sauvegardé dans le répertoire créé auparavant. Il contient tous
les SMS récupérés dans la mémoire avec les informations suivantes :
–
–
–
–
–
–
–
Numéro du sms
Date du SMS
Heure du SMS
Numéro SMSC
Numéro de téléphone
Taille du SMS
Contenu du SMS
48
Fig. 5.8 – Flowchart pour la recherche d’un SMS
Maintenant, afin de clore ce chapitre, il est important de faire le bilan du
nombre d’SMS retrouvés, et heureusement celui-ci est très positif. En effet,
nombreux sont les SMS qui ont été retrouvés, malgré le fait que certains
d’entre eux soient incomplets. Ce phénomène est dû au fait qu’un nouveau
message est venu écraser la fin d’un SMS qui a été supprimé, c’est pourquoi
ce dernier n’apparaı̂t plus dans la base de données internes du téléphone. Un
problème survient lorsque la nouvelle entrée vient écraser le début d’un SMS
au préalable supprimé, car étant donné que nous effectuons la recherche sur
un pattern qui se situe au début, si celui-ci venait à manquer, il serait impossible pour le programme de retrouver ce SMS. C’est malheureusement ce qui
arrive dans certains cas, mais heureusement sur un très faible pourcentage
de messages.
Une remarque importante découle de cette étude, c’est qu’il est impossible de supprimer définitivement un SMS uniquement par le biais du
téléphone mobile, car le fait d’exécuter l’action de suppression ne fait que retirer l’entrée dans la base de données. Il faut par la suite attendre qu’un autre
message vienne écraser la quasi-totalité du message. Le seul moyen d’augmenter les chances de suppression est de s’envoyer énormément de SMS pour
remplir un maximum la mémoire.
Maintenant un mot en ce qui concerne la méthode de recherche et d’extraction. Comme dans le cas précédent, cette méthode ne peut pas être considérée comme générique. Rien que le fait d’avoir un pattern de recherche
49
pour les SMS et un autre pour les dates constitue une contrainte importante.
En effet, ce programme a été exécuté sur le dump d’un Motorola V3R et il
n’a donné lieu à aucuns résultats satisfaisants, aucun SMS n’a été trouvé. Il a
fallu trouver de nouveaux patterns afin de pouvoir récupérer les messages. En
revanche, la méthode de recherche et d’extraction synthétisée par la figure ??
fonctionne très bien, à condition de mettre les patterns suivants :
pattern SMS : 01 45 00 00
pattern date : 00 FF 00 00 00
Fig. 5.9 – Pattern de recherche pour Motorola V3R
Avec ces deux patterns, la recherche fonctionne sur un V3R et sur un
V3I, mais il est impossible de savoir si ceux-ci fonctionneraient sur un autre
modèle. C’est pour cela qu’il serait intéressant d’effectuer une étude ou une
recherche sur les patterns de différents modèles, voir de différentes marques.
A la suite de ce test, une légère modification a été apportée au code lui
permettant ainsi d’accepter les dump des modèles V3I et V3R.
Enfin un dernier mot sur les messages récupérés, il a malheureusement été
impossible de savoir si le message récupéré a été envoyé ou reçu. Mais étant
donné que l’on connaı̂t exactement la date et l’heure il serait envisageable
de contacter l’opérateur et de demander la facture détaillée, ainsi il serait
possible de savoir si le message a été reçu ou envoyé.
50
Chapitre 6
Extraction des contacts
6.1
Introduction
Les contacts ou plus communément appelé répertoire téléphonique sont
simplement des noms avec des numéros de téléphones qui sont stockés dans
le mobile. Cette fonctionnalité est présente de base sur les téléphones de
différentes marques. En effet, depuis l’apparition du premier téléphone mobile, cette fonction de mémorisation des numéros téléphoniques existait déjà.
Certes, la quantité de numéros que l’on pouvait insérer dans la base de
données du téléphone était limitée par rapport à l’espace disponible sur les
téléphones actuels, ainsi que les données complémentaires pour un contact
ne pouvaient être introduites à l’époque. Les données complémentaires sont
relatives à l’adresse, la date de naissance, l’adresse e-mail, etc. Ces données
varient en fonction du modèle de téléphone.
Le fait de pouvoir récupérer une partie ou la totalité des contacts ainsi que
les données complémentaires est une étape obligatoire dans notre processus
de récupération de données. En effet, ce sont des informations très précieuses
qui permettent par la suite de pouvoir (( tisser )) un réseau de connaissances
avec la personne ayant eu le téléphone mobile.
6.2
Détails techniques
Cette section comporte beaucoup moins de théorie et de thermes techniques que les sections étudiées précédemment. En effet, aucune norme ni
aucune méthode de stockage de données ne sont définies. En revanche, dans
ce chapitre, nous allons nous heurter à un tout autre type de difficultés qui
est celui de la modification ou de la suppression partielle de données. Dans
les chapitres étudiés précédemment, cette problématique n’existait pas étant
donné la nature non modifiable de l’objet. En effet, un message reçu peut
être transféré ou supprimé, mais il ne peut aucunement être modifié. Il en
51
52
CHAPITRE 6. EXTRACTION DES CONTACTS
est de même pour les vidéos, elles peuvent être envoyées par Bluetooth ou
supprimées, mais son contenu ne peut être altéré par le téléphone mobile.
En revanche, dans notre cas, un contact peut se voir supprimé un numéro de
téléphone tout en existant encore et en ayant toujours une adresse, ou tout
simplement que les données concernant le numéro ou l’adresse changent.
Dans un premier temps, nous allons faire abstraction de la modification
de données d’un contact et nous concentrer uniquement sur la recherche et
l’extraction de données. Par la suite, quand les premières données auront été
extraites, nous pourrons analyser la gestion de ce phénomène. Cependant,
nous pouvons déjà émettre quelques hypothèses.
La première hypothèse que nous pouvons faire est celle dont la nouvelle
donnée vient remplacer l’ancienne et dans ce cas il n’y aurait aucune trace
de celle précédente, ce qui signifie que l’on pourrait récupérer uniquement la
nouvelle valeur.
La deuxième hypothèse est que l’enregistrement soit écrit à nouveau avec
les bonnes valeurs, ce qui signifie qu’il y aurait deux fois le même contact
mais avec des données différentes. Dans cette situation, il serait possible de
récupérer toutes les informations, mais le problème qui risque de surgir est
celui de savoir laquelle des données est la bonne.
Voici pour ce qui en est des principales hypothèses. Maintenant il reste à
rechercher les valeurs dans le dump mémoire et à les extraire.
6.3
Recherche dans le Dump
Pour essayer de rechercher les contacts dans le dump mémoire, nous allons
procéder de la même manière que pour les vidéos et les SMS vu dans les
chapitres précédents. Pour ce faire, nous allons créer un contact avec toutes
les informations et un numéro facilement identifiable.
Voici les informations du nouveau contact :
Information Contact
– Nom : Test
– Prénom : Test Prénom
– Numéro : 1234567
– Adresse : Rue Ville
– Complément : 1227 Etat Pays
Ensuite, nous faisons le dump et nous effectuons une recherche ASCII
avec le numéro (( 1234567 )) qui est le numéro du contact qui a été créer, ainsi
celle-ci nous permettrait de nous positionner à l’endroit souhaité comme il
s’est avéré dans les cas précédents. Malheureusement, la recherche n’aboutit
53
qu’à des résultats négatifs. Il est donc impossible de rechercher un contact
directement par le numéro de téléphone. C’est pourquoi, nous allons procéder
à une nouvelle recherche, mais cette fois avec comme information de base,
le nom du contact qui est (( Test )) tout en respectant bien la casse. Cette
fois-ci, la recherche est positive et elle nous positionne directement au bon
endroit. Nous pouvons constater que le numéro de téléphone se trouve sous la
même forme que les numéros qu’il a fallu décoder dans la section SMS (voir
section 5.4 et section 5.5 du chapitre 5). Ceci explique pourquoi la recherche
par numéros de téléphone n’a pu aboutir à aucuns résultats positifs. En
procédant à la même marche à suivre que lors des exemples précédents, nous
devons impérativement trouver une signature nous permettant de pouvoir
rechercher tous les autres contacts de manière aussi générale que possible. Le
pattern qui a été trouvé est représenté par la figure 6.1
Signature : 02 FE
Fig. 6.1 – Pattern pour un contact
Cependant, cette signature est beaucoup trop large, ce qui signifie qu’elle
ramène des éléments qui ne sont pas des contacts. Il faut donc essayer de trouver un moyen de filtrer les objets qui ne sont pas valides. Malheureusement,
après de nombreuses heures passées à analyser la structure, aucunes informations ne peuvent nous être utiles pour connaı̂tre avec certitude si le pattern
trouvé est celui d’un contact ou pas. Il faut donc procéder différemment pour
filtrer les bons résultats. La solution retenue sera expliqué plus en détails dans
la section 6.4
Maintenant, il nous faut étudier les éléments d’un contact, c’est-à-dire les
informations le concernant, comme par exemple le nom, le prénom, l’adresse,
etc. L’analyse qui en découle est que chaque élément d’un contact est séparé,
soit par la séquence 0xFF, soit par une série de 0xFF, à l’exception du nom
et du prénom. En effet, ils sont considérés comme une seule et même entité.
Ce qui au premier abord ne pose aucun problème. L’adresse aussi ne forme
qu’un seul bloc d’informations qui contient la rue, le numéro, la ville et enfin
le pays. En ce qui concerne ces informations, elles sont stockées sous forme
ASCII et chaque lettre est séparée par un caractère vide. Ce format rappelle
beaucoup la façon dont est sauvegardé le nom d’une vidéo dans la mémoire
(voir chapitre 4). Enfin, le contact se termine par la séquence suivante :
Fin contact : FF FE
Pour conclure cette section, nous allons résumer grâce à la figure 6.2
les différentes parties d’un contact et l’enchaı̂nement qu’elles ont dans la
54
Pattern
02 FE
Nom Prénom
0xFF
Numéro téléphone
0xFF
FF FF FF FF
Adresse complète
0xFF
????????
Pattern fin
FF FE
Fig. 6.2 – Structure d’une entrée dans le répertoire
mémoire. Il est important de souligner qu’il n’a pas été possible de trouver la
signification pour toutes les différentes parties. Celles-ci sont notées par des
(( ? )). En effet, il est possible que ces champs puissent être complétés par le
téléphone pour ajouter une photo à un contact ou une sonnerie particulière,
mais si tel était le cas, ces informations ne seraient pas indispensables pour
nous.
6.4
Extraction des contacts
Pour commencer, il est important de savoir qu’une grande partie de l’algorithme a été repris du chapitre 4 concernant les vidéos et le chapitre 5 qui
traite les SMS. En effet, la méthode permettant de parcourir et d’explorer le
dump mémoire est identique au deux précédents à l’exception du pattern de
recherche, qui lui est différent, comme nous avons pu le voir à la figure 6.1 de
la section 6.3. Pour garder une homogénéité dans le travail, nous procédons
de la même manière que précédemment et pour ce faire, nous utilisons une
structure de données que nous allons compléter au fur et à mesure que nous
rencontrerons les informations à insérer.
Voici à quoi ressemble la structure :
6.4. EXTRACTION DES CONTACTS
55
contactStructure
– long memory adress
– char *name
– char *adress
– char *phone number
Maintenant que nous avons tous les éléments, nous pouvons commencer l’explication de la recherche et de l’extraction.
Nous allons commencer par parcourir le dump à la recherche du pattern
(( contact )). Une fois celui-ci rencontré, il nous faut savoir si nous sommes en
présence d’un contact valide ou pas. Comme il a été dit dans la section 6.3,
il n’a pas été possible de trouver une taille ou un tout autre élément capable
d’indiquer que nous sommes en présence d’un contact valide. Il faut donc
utiliser une autre méthode, qui consiste à chercher le pattern de séparation
de l’élément dans une limite donnée. En résumé, une fois trouvé la signature
d’un contact, il nous faut chercher le pattern (( 0xFF )) avec une limite que l’on
se définit. Si ce pattern est trouvé, il y a de fortes chances que le contact soit
valide, sinon le contact est forcément corrompu et dans ce cas, la recherche
se poursuit.
Dans le cas d’un contact valide, on commence par renseigner le champ
concernant l’adresse mémoire. Ensuite, on décode le nom et le prénom, qui
pour rappel, sont dans un même et unique bloc. Il est important de souligner
que cette fois-ci le nom ne subit aucuns traitements, c’est-à-dire que les espaces séparant chaque lettre ne sont pas éliminés. Ce choix a été fait suite
à la difficulté rencontrée lors de la distinction entre un espace voulu et un
espace imposé par le téléphone mobile. En effet, entre le nom et le prénom
il existe un espace ou qu’il peut y avoir des blancs dans un nom à particules
et ainsi de suite. C’est pour cette raison que le bloc est copié tel-quel dans
la structure.
Quant au numéro de téléphone. Celui-ci a le même encodage que les SMS
à l’exception de la taille. En effet, cette fois, la taille ne désigne plus le nombre
de chiffres que comporte le numéro de téléphone, mais il indique le nombre
de blocs de deux bytes dont il est composé. Grâce à la figure 6.3 il et possible
de voir la différence entre la taille exprimée par un SMS et celle exprimée
par un contact.
Exemple numéro d’un message : 07 91 14 22 37 33 33 F3
Exemple numéro d’un contact : 0B 91 33 16 79 88 30 F7
Fig. 6.3 – Différence entre la taille SMS et contact
Etant donné que la différence entre l’encodage d’un numéro SMS et celui
56
Fig. 6.4 – Flowchart pour la recherche d’un contact
d’un contact est minime, il est donc possible d’utiliser la fonction qui permet de décoder les numéros SMS pour décoder les numéros des contacts en
lui appliquant certaines modifications. Une fois celui-ci lisible, il suffit de le
mémoriser dans notre structure.
Enfin vient l’adresse qui est un unique bloc. En effet, la rue, le code
postal, l’état et le pays sont réunis dans un seul bloc séparé par des espaces
et se terminant par le séparateur 0xFF. Ces informations sont sauvegardées
sous forme ASCII de la même manière que le nom et le prénom. Pour les
raisons évoquées précédemment, nous n’allons faire aucuns traitements sur la
chaı̂ne de caractères contenant les informations. Il est donc possible, pour lire
l’adresse, d’utiliser la même fonction que celle qui a été utilisée précédemment
pour le nom et le prénom. Une fois cette opération terminée, il faut sauvegarder les informations dans notre structure. Cette étape met un terme à la
structure et ainsi nous pouvons rechercher un autre contact en commençant
l’itération depuis le début. Pour résumer les étapes du processus d’extraction des entrées dans le répertoire téléphonique, la figure 6.4 nous montre les
étapes importantes de façon schématique.
6.5
57
Le résultat de l’exécution du programme va être présenté sous forme d’un
fichier texte qui sera sauvegardé dans le répertoire créé auparavant. Il contient
toutes les entrées récupérées dans la mémoire avec les informations suivantes
(il se peut que l’adresse ne soit pas valable)
– Adresse mémoire du contact trouvé
– Nom et prénom du contact
– Numéro de téléphone du contact
– Adresse du contact
Afin de clore ce chapitre, il est important de faire un bilan du nombre
de contacts retrouvés. Celui-ci est satisfaisant, car de nombreux contacts ont
pu être récupérés, malgré le fait que certains d’entre eux soient incomplets
ou corrompus. En ce qui concerne les entrées incomplètes, celles-ci sont très
rares, en effet, sur une moyenne de 140 contacts trouvés, seulement trois ou
quatre ne portent par de numéro. L’adresse est très souvent absente, mais
ceci est dû au fait qu’elle n’a jamais été entrée. En revanche, la présence du
nombre d’entrées corrompues, par corrompu on sous-entend que ce n’est pas
un contact, s’élève à une dizaine. Mais ceci n’est pas un gros problème étant
donné qu’elle ne contient aucunes informations utiles, le seul inconvénient
de ce phénomène consiste en la possibilité de fausser le nombre de contacts retrouvé. De plus nous avons évoqué une problématique au début de ce
chapitre qui est celle de la modification des entrées. Arrivé à ce stade, il est
possible de répondre à cette problématique en disant que les données sont
doublées. En effet, quand on modifie une valeur, l’appareil écrit à nouveau
toutes les informations dans une autre partie de la mémoire en ayant pour
conséquence de doubler l’entrée. Il reste à savoir laquelle des deux valeurs est
la plus récente.
Un point important qui découle de cette étude et qui rejoint la même
remarque faite lors des messages, c’est qu’il est impossible de supprimer
définitivement un contact uniquement par le biais du téléphone mobile,
car le fait d’exécuter l’action de suppression ne fait que retirer l’entrée dans la
base de données. Il faut par la suite attendre qu’une autre donnée (message,
vidéo, contact) vienne écraser la totalité ou la quasi-totalité du contenu pour
que la donnée soit totalement supprimée.
En ce qui concerne la méthode de recherche et d’extraction de données,
comme nous avons pu le voir dans les cas précédents, cette méthode ne
peut pas être considérée comme générique. La contrainte d’avoir un pattern spécifique est beaucoup trop restrictif et rend la méthode beaucoup
trop spécialisée. En effet, ce programme a été exécuté sur le dump d’un
58
pattern contact V3R : 00 FE
Fig. 6.5 – Pattern de recherche pour Motorola V3R
Motorola V3R et il a retrouvé uniquement deux ou trois contacts, ce qui
signifie que ce pattern ne doit pas être le principal dans le V3R. Il a donc été
nécessaire de trouver un autre pattern pour le V3R. Une fois celui-ci trouvé,
il a tout simplement fallu l’intégrer à notre code et les contacts ont ainsi
pu être récupérés sans aucunes difficultés. En effet, la méthode synthétisée
par la figure 6.4 fonctionne toujours à condition de mettre les patterns de la
figure 6.5.
Avec ces deux patterns, la recherche fonctionne sur un V3R et sur un
V3I, mais il est impossible de savoir si ceux-ci fonctionneraient sur un autre
modèle. C’est pour cela qu’il serait intéressant d’effectuer une étude ou une
recherche sur les patterns de différents modèles, voir de différentes marques.
Chapitre 7
Logiciel développé
7.1
Explication
Ce chapitre à pour but de faire un récapitulatif des fonctions qu’intègre
le logiciel développé ainsi que d’expliquer les fonctionnalités qui n’ont pu
être vues dans les chapitres ou sections précédentes. Ces fonctionnalités
supplémentaires ont été rajoutées suite à divers besoins ou exigences qui
sont apparues en deuxième lieu.
7.2
SourceForge
Il a été décidé de mettre à disposition les sources du projet sur la plateforme d’hébergement de projets mondialement connue SourceForge. Le
choix de mettre ce projet sur ce site est dû au fait que les logiciels libres
sont en train de connaı̂tre une grande expansion. De plus, le fait que d’autres
développeurs puissent enrichir et améliorer le projet est un atout considérable
pour l’évolution de ce logiciel.
L’adresse du projet est la suivante :
https://sourceforge.net/projects/motomoviefinder
7.3
Fonctionnalité de base
Les fonctions nommées de bases sont celles qui ont été étudiées tout au
long de ce travail, c’est-à-dire :
– Recherche et reconstruction des vidéos
– Recherche et reconstruction des SMS
– Recherche et reconstruction des contacts
Elles s’exécutent les unes après les autres de façon complètement automatique
ainsi l’utilisateur n’a pas besoin d’interagir. Une fois ces opérations terminées,
59
60
CHAPITRE 7. LOGICIEL DÉVELOPPÉ
viennent les opérations complémentaires qui sont énumérées et expliquées
dans les paragraphes suivants.
7.4
Inversion de fichier
Cette fonction a été rajoutée à la suite de l’analyse des vidéos. En effet,
après mûre réflexion, il a été constaté que les boı̂tes (( mdat ))sont inversées par
bloc de 0x1C00, comme nous avons pu le voir dans la section 4.3 du chapitre 4.
De ce fait, aucuns programmes permettant la recherche de segments vidéo ne
peuvent fonctionner sur ces données. Il a donc été décidé de mettre au point
une fonction qui est capable d’inverser tout le dump mémoire de la valeur
0x1C00. Ceci permet donc de (( retourner )) le fichier et ainsi il peut être traité
par un programme comme (( Defraser1 )) qui permet de trouver des parties de
séquences vidéos qui auraient échappé à notre programme. Cette fonction,
qui se nomme (( swap file )) est automatiquement exécutée par le programme
sans que l’utilisateur n’ait à faire une quelconque manipulation. Pendant la
phase de développement et afin de vérifier son bon fonctionnement, il suffit
d’effectuer deux fois l’inversion sur le même fichier et de contrôler que la
signature MD5 soit inchangée. Ceci permet d’affirmer que l’image mémoire
ne subit aucunes autres modifications. En ce qui concerne le fichier de sortie,
celui-ci porte le même nom que le fichier de base, mais il comporte un suffixe
(( swap )) qui indiquer qu’il a été modifié.
7.5
Exportation CSV
Cette fonctionnalité a dû être implémentée suite aux exigences nécessaires
à l’intégration des résultats dans un rapport. En effet, les résultats sont
stockés sous forme de fichier texte et peuvent être difficilement intégrés dans
un tableur tel qu’Excel de Microsoft. Il est donc intéressant de pouvoir avoir
un fichier qui soit compatible avec la plupart des tableurs. Ce type d’extension est le format CSV 2 qui représente les données sous forme de valeurs
séparées par des virgules. Il est donc possible, grâce à ces fichiers, de pouvoir
faire des statistiques ou toutes autres formes d’analyses. C’est donc pour les
raisons évoquées ci-dessus qu’il a été décidé d’intégrer cette fonctionnalité
qui ne nécessite aucunes manipulations supplémentaires de la part de l’utilisateur, car les données sont automatiquement exportées en CSV et celles-ci
vont être créées dans le même répertoire que les données sous forme de texte.
1
2
Outil d’analyse forensique qui permet de détecter des fichiers multimédia
Comma-separated values
7.6. CAPTURES D’ÉCRAN
7.6
61
Captures d’écran
Voici quelques capture d’écran des différents résultats que le logiciel est
capable de fournir.
Fig. 7.1 – Capture du programme une fois l’exécution terminée
Fig. 7.2 – Capture du fichier de sortie contenant le nom des vidéos
62
CHAPITRE 7. LOGICIEL DÉVELOPPÉ
Fig. 7.3 – Capture du fichier de sortie contenant les SMS
Fig. 7.4 – Capture du fichier de sortie contenant les contacts
Chapitre 8
Conclusion
La recherche de données sur un téléphone mobile est à ce stade très satisfaisante en ce qui concerne ce modèle. En effet, nous avons pu constater,
tout au long de notre analyse, qu’il est possible d’extraire des données effacées ou simplement enregistrées dans une mémoire tampon et ceci avec les
différents supports que nous offre le téléphone mobile : les SMS, les vidéos
et les répertoires téléphoniques, car les informations ne sont jamais vraiment
supprimées de l’appareil. La fonction (( effacer )) dans le mobile ne supprime
que l’entrée dans la base de données et non le contenu lui-même donnant ainsi
l’illusion au possesseur du téléphone d’avoir effacer les données. La recherche
et l’extraction de données nous a permis de mettre en place une méthode de
travail efficace, concluante et applicable à chacun des supports du mobile et
aux différentes marques de téléphone, simplifiant ainsi l’analyse. La méthode
est la suivante :
1. Effectuer un dump mémoire
2. Insérer une donnée personnalisée (un contact avec un nom particulier,
s’envoyer un SMS avec du texte à répétition, etc.) avec des informations
très spécifiques pour permettre de les retrouver facilement
3. Effectuer un nouveau dump mémoire
4. Rechercher les données dans le dump. Si les informations sont vite
retrouvées, analyser les données afin d’essayer de trouver des patterns,
etc. Si en revanche il est difficile de trouver la donnée, comme dans le
cas des vidéos, alors il faut procéder à l’étape suivante
5. Utiliser un programme permettant de comparer deux fichiers hexadécimaux
et rechercher les différences entre le dump effectué avant d’insérer les
données personnalisées et celui effectué après. Ceci permet d’identifier
les zones qui ont été impactées par l’insertion de la donnée.
Cependant, comme nous avons pu le constater lors de ce projet, la méthode
de travail ne suffit pas à déchiffrer les données pour lesquelles il n’existe pas de
63
64
CHAPITRE 8. CONCLUSION
méthode systématique et fiable. Seul l’analyse, la déduction, les hypothèses,
les essais, etc. peuvent nous amener à la lecture finale des données.
De plus, notre recherche s’est portée exclusivement sur la marque de
téléphone mobile Motorola V3i et par conséquent nos résultats satisfaisants
sont propres à ce modèle. En effet, chacun des modèles de téléphone a un pattern spécifique pour un certain type de données et le simple fait de changer
de modèle de mobile modifie le pattern de celui-ci nous empêchant ainsi de
retrouver les données. Toutefois, si l’on retrouve le pattern correspondant
au modèle étudié, il suffit de l’appliquer au code comme nous avons pu le
constater lors de l’analyse du V3R. Malheureusement, n’ayant à disposition
aucun système de fichier sur lequel se baser et ne possédant aucune documentation technique sur la manière dont sont stockées les données, la recherche
de pattern a semblé être le moyen le plus judicieux et le plus facile à mettre en
oeuvre pour qu’il soit facilement extensible à d’autres modèles. De plus, une
autre restriction entre en jeu, celle du fabricant. En effet, le fait de changer
de fabriquant pourrait entraı̂ner le non-fonctionnement global du logiciel, car
rien ne prouve que les données soient (( encodées )) de la même manière.
Le travail s’étant déroulé exclusivement sur une marque de téléphone et
sur un modèle bien précis, ceci nous permet de relever un point très important. En effet, l’analyse approfondie de la structure des données ainsi
que l’interprétation de celles-ci dans la mémoire ont pris une grande partie
du temps mis à disposition. Ceci est d’une part dû au fait qu’il n’existe, à
l’heure actuelle, aucuns outils efficaces permettant d’aider à l’analyse d’un
dump mémoire. D’autre part, la documentation mise à disposition par les
fabricants touche uniquement l’aspect (( programmation )) de logiciels, mais
nullement l’aspect fonctionnel du téléphone ou de la représentation interne
des données.
De plus, il est essentiel de rappeler qu’avant de pouvoir analyser un dump
mémoire, il est indispensable d’être en possession de celui-ci et son contenu doit être identique à son référentiel de départ, qui est dans notre cas
la mémoire du téléphone mobile. Cette étape qui est fortement compliquée
s’avère être primordiale et dans les cas les plus extrêmes, elle peut ne pas s’effectuer, comme nous l’a si bien démontré l’utilisation du port JTAG. Dans
notre situation, il s’est avéré impossible d’effectuer une copie par le biais de
ce système, c’est pourquoi il a été essentiel de trouver une alternative au
problème afin de pouvoir tout de même obtenir le dump mémoire.
Pour terminer, la recherche et l’extraction de données sur le Motorola
V3i sont très satisfaisantes et positives, car elles sont un premier pas vers
la recherche scientifique et policière, mais toutefois elles restent encore insuffisantes. En effet, l’analyse de données de mobile est encore fortement
obstruée par les fabricants eux-mêmes qui refusent de divulguer des données
65
relatives à leurs produits, sans doute pour des raisons de concurrence du
marché, comme nous avons pu le constater avec l’utilisation du port JTAG.
Cependant l’enjeu scientifique et sociale devrait primer sur l’économie, c’est
pourquoi il est essentiel de continuer à persévérer dans cette direction et à
exiger une plus grande collaboration entre les fabricants et la police ce qui
amènerait, qui sait peut-être, à diminuer toute forme de violence, aujourd’hui
et plus que jamais, fortement présente dans notre société.
66
CHAPITRE 8. CONCLUSION
Chapitre 9
Remerciement
Je tiens à remercier tous ceux qui m’ont permis de mener à bien ce travail
à savoir Mr. David Billard, professeur au CUI et à l’école de police, qui m’a
offert l’opportunité de collaborer avec le milieu de la forensique qui m’a
toujours beaucoup attiré et enfin Mr. Beuchat, résponsable du Laboratoire
de Systèmes Numériques de l’école d’ingénieur de Genève qui m’a dédié une
grande partie de son temps à m’expliquer la norme et le protocole JTAG.
67
68
CHAPITRE 9. REMERCIEMENT
Bibliographie
[Breeuwsa, 2006] Breeuwsa, I. M. (2006). Forensic imaging of embedded
systems using jtag (bundary-scan). Digital investigation, 3 :32–42.
[Breeuwsa et al., 2007] Breeuwsa, M., de Jongh, M., Klaver, C., van des Knijff, R., and Roeloffs, M. (2007). Forensic data recovery from flash memory.
Small scale digital device forensics journal, 1 :4–6.
[ETSI, 2002] ETSI (Août 2002). [online] gsm 03.41 - technical realization of
short message service cell broadcast (smscb). Digital cellular telecommunications system (Phase 2+),
http://pda.etsi.org/pda/AQuery.asp?qSEARCH_STRING=03.41.
[ETSI, 2001] ETSI (Décembre 2001). [online] gsm 03.40 - technical realization of short message service (sms) point-to-point (pp). Digital cellular
telecommunications system (Phase 2+),
[ETSI, 1998] ETSI (Juillet 1998). [online] gsm 03.38 - alphabets and
language-specific information. Digital cellular telecommunications system
(Phase 2+),
[Lecomte et al., 2000] Lecomte, D., Cohen, D., de Bellefonds, P., and Barda,
J. (2000). Les normes et les standards du multimédia. Dunod.
[McCarthy, 2005] McCarthy, P. (2005). Forensic Analysis of a Mobile
Phones. PhD thesis, University of South Australia.
[Openwince, 2007] Openwince (2007). [online] fitting a jtag interface to an
ipaq 3600. openwince,
http://openwince.sourceforge.net/jtag/iPAQ-3600/.
[Peacock, 2005] Peacock, W. (Samedi, 9 Avril, 2005). [online] nokia f-bus
protocol. Embedtronics,
http://www.embedtronics.com/nokia/fbus.html.
[Pereira and Ebrahimi, 2002] Pereira, F. and Ebrahimi, T. (2002).
MPEG-4 Book. IMSC Press Multimedia Series/Andrew Tescher.
69
The
70
BIBLIOGRAPHIE
[Pettersson, 2007] Pettersson, L. (2007). [online] sms and the pdu format.
GSM,
http://www.dreamfabric.com/sms/.
[pinouts.ru, 2007] pinouts.ru (2007). [online] handbook of hardware pinouts,
cables schemes and connectors layouts. Pinouts,
http://pinouts.ru/CellularPhones-Nokia/nokia_3310_pinout.
shtml.
[Willassen, 2005] Willassen, S. Y. (2005). Forensic analysis of mobile phone
internal memory, volume 194/2005. Springer Boston.

Travail de Master

Transcription

Documents pareils

09_la_croisade_des_enfants_-_jacques_higelin ( PDF

Fiche PDF Château Lamouroux

Notice du jeu MOV - Orthophonie et Logiciels Libres

ACCESS UNLIMITED CALLS ACCEDEZ AUX APPELS ILLIMITES

Mise en avant Les atouts Spécifications principales

VoIP interconnect Form

FFF-218

Réussir sa rentrée en BCPST

TP : Analyse Linéaire Discriminante (LDA)