Insomni’hack finals – InsomniDroid Level 1 Writeup

The challenge was delivered as a zip file ( The first challenge was perhaps to download it (with its 602.5 MiB). The zip file contains a single file: mmcblk0.dd. A file command gives some information:

$ file mmcblk0.dd

mmcblk0.dd: x86 boot sector; partition 1: ID=0xc, starthead 0, startsector 1, 212991 sectors; partition 2: ID=0x4d, active, starthead 0, startsector 212992, 1000 sectors; partition 3: ID=0x46, starthead 0, startsector 213992, 7192 sectors; partition 4: ID=0x5, starthead 0, startsector 221184, 7512064 sectors, code offset 0x0

I am using Mac OS X, but it is not the best platform to study Android. So let’s switch to Linux (for example Kali Linux or Santoku). The command fdisk gives the complete list of partitions:

$ fdisk -l mmcblk0.dd

Disk mmcblk0.dd: 3959 MB, 3959422976 bytes
1 heads, 63 sectors/track, 122749 cylinders, total 7733248 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
mmcblk0.dd1 1 212991 106495+ c W95 FAT32 (LBA)
mmcblk0.dd2 * 212992 213991 500 4d QNX4.x
mmcblk0.dd3 213992 221183 3596 46 Unknown
mmcblk0.dd4 221184 7733247 3756032 5 Extended
mmcblk0.dd5 229376 239615 5120 47 Unknown
mmcblk0.dd6 245760 285759 20000 49 Unknown
mmcblk0.dd7 286720 292863 3072 58 Unknown
mmcblk0.dd8 294912 306175 5632 48 Unknown
mmcblk0.dd9 311296 324271 6488 50 OnTrack DM
mmcblk0.dd10 327680 333823 3072 4a Unknown
mmcblk0.dd11 335872 342015 3072 4b Unknown
mmcblk0.dd12 344064 360447 8192 90 Unknown
mmcblk0.dd13 360448 375807 7680 91 Unknown
mmcblk0.dd14 376832 387071 5120 92 Unknown
mmcblk0.dd15 393216 1488895 547840 93 Amoeba
mmcblk0.dd16 1490944 1613823 61440 94 Amoeba BBT
mmcblk0.dd17 1613824 3887103 1136640 95 Unknown
mmcblk0.dd18 3891200 3993599 51200 96 Unknown
mmcblk0.dd19 3997696 3998695 500 97 Unknown
mmcblk0.dd20 4005888 4013079 3596 98 Unknown
mmcblk0.dd21 4014080 4024319 5120 99 Unknown
mmcblk0.dd22 4030464 4070463 20000 9a Unknown
mmcblk0.dd23 4071424 4081663 5120 9b Unknown
mmcblk0.dd24 4087808 4101807 7000 9c Unknown
mmcblk0.dd25 4104192 4114431 5120 9d Unknown
mmcblk0.dd26 4120576 4130815 5120 9e Unknown
mmcblk0.dd27 4136960 4147199 5120 9f BSD/OS
mmcblk0.dd28 4153344 7733247 1789952 a0 IBM Thinkpad hibernation

So we have 28 partitions with some strange systems. We can try to identify partitions one by one and hope we will be able to read something useful, but there is another way. The description of the challenge says that “The device is a Samsung W (GT-I8150) and apparently it runs the Cyanogen flavour of Android KitKat.” This device is not officially supported by Cyanogen, but there is an unofficial port:

The port is published in GitHub:

Be sure to select the “cm-11.0” branch and you have the complete project. Inside “rootdir”, you find:

The interesting file is “fstab.qcom”. As its name indicates, it gives the file system table:


So the 17th partition is /system and the 28th one is /data. In fact, it is not difficult to guess it because they are the biggest partitions. Something more interesting is the complete line regarding /data:

/dev/block/mmcblk0p28 /data ext4 noatime,nosuid,nodev,data=ordered,

Data is encrypted (as stated in the description of the challenge) and the length of the footer is 16384 bytes (as it is often the case). OK, this is the lazy way (i.e. Google way). But this “fstab.qcom” file is somewhere in the bit-per-bit copy, isn’t it? Why not extract it directly to be sure of its content. Because it is more complicated and I am lazy. But since you are a nice girl, I will show you how to extract this file. This file is in the root partition. But how to identify this partition? Well, on Samsung devices, it has often ID 0x48. To confirm which partition is the right one, we can use the PIT. On Samsung devices, PIT (Partition Information Table) describes the formatting of the memory of the mobile:


So, the partition (boot.img) we are looking for is:

mmcblk0.dd8 294912 306175 5632 48 Unknown

To extract boot.img, we can use the famous DD command:

$ dd if=mmcblk0.dd of=boot.img bs=512 skip= 294912 count=$((306175-294912 +1))

The block size (512) is indicated by fdisk (Units = 512 bytes), skip is given by “Start” and count is simply the difference between Start and End (plus 1 because it includes the End sector).

boot.img (like recovery images) are packaged with mkbootimg. We need an equivalent tool to unpack it (personally, I am using bootimg-tools from

$ ./unmkbootimg -i boot.img

It extracts the kernel and the ram disk. It is not finished! The ram disk is archived and compressed with gzip and cpio. So to decompress:

$ gunzip -c ramdisk.cpio.gz | cpio -i

We have our files! We get our fstab.qcom, identical to the other one found on GitHub. Google-way is more simple, isn’t it?

So we have to decrypt the user partition without knowing the password. We first need to extract the partition data:

$ dd if=mmcblk0.dd of=mmcblk0p28.dd bs=512 skip=4153344 count=$((7733247-4153344+1))

Again, the block size (512) is indicated by fdisk (Units = 512 bytes), skip is given by “Start” and count is simply the difference between Start and End (plus 1 because it includes the End sector). It gives a file of 1.8 GiB.

In order to decrypt it, Google is again our friend and replies with a blog article from Nikolay Elenkov

By the way, all the articles of this blog are fantastic and Nikolay is also the author of “Android Security Internals” book. If you are interested by Android security, you have to read it.

But let’s go back to our challenge. Nikolay has adapted a script (from Santoku Linux) for KitKat (Android 4.4) and it is published on GitHub:

To run this script, you need a header, a footer and the maximum length of the PIN code. It says that it will take around 5 minutes to try 1200 PIN combinations, so let’s try that.

The footer is… the footer. We just need its size. This is exactly what we retrieved from fstab (16384).

$ dd if=mmcblk0p28.dd bs=1 count=16384 skip=1832894464 of=footer.dd

1832894464 is the difference between the size of our encrypted file (1832910848) and 16384.

The header is the beginning of our data and is just only to check if the decryption succeed or not:

$ dd if=mmcblk0p28.dd bs=1 count=512 of=header.dd

And now, we can try to brute force, like in the example of Nikolay:

$ python header.dd footer.dd

Be sure to have M2Crypto and script installed. On Mac OS X, you may also need to install version 3.0.4 (not 3.0.5) of Swig. It depends of your computer, but around 6 minutes later, you will get:

Trying: 1964
Trying: 1965
Trying: 1966
Trying: 1967
Trying: 1968
Trying: 1969
Trying: 1970
Found PIN!: 1970

No, it is not the year of my birth. We found the PIN code, great. But we now have to decrypt the data. It is not very complicated to adapt to decrypt, but there is another way: using Linux and cryptsetup. All we need is the key in an appropriate format. already contains appropriate code (decryptDecodeScryptKey function). We can make a generic script to handle different cases such as:

import sys
from os import path
import struct
from bruteforce_stdcrypto import *

def getDecryptionKey(footer, pin):
	cryptoFooter = getCryptoData(footer)

	# make the decryption key from the password
	decKey = ''
	if cryptoFooter.kdf == KDF_PBKDF:
		decKey = decryptDecodePbkdf2Key(cryptoFooter, pin)
	elif cryptoFooter.kdf == KDF_SCRYPT:
		decKey = decryptDecodeScryptKey(cryptoFooter, pin)
		raise Exception("Unknown or unsupported KDF: " + str(cryptoFooter.kdf))

	return decKey

def main(args):

	if len(args) < 2:
		print 'Usage: python [footer file] [pin]'
		print '[] = Mandatory'
		print ''
		# use inputed filenames for the two files
		footerFile  = args[1]
		pin 		= args[2]

		assert path.isfile(footerFile), "Footer file '%s' not found." % footerFile
		footerSize = path.getsize(footerFile)

		assert (footerSize >= 16384), "Input file '%s' must be at least 16384 bytes" % footerFile

		decKey = getDecryptionKey(footerFile, pin)
		print 'Key: ', decKey.encode('hex').upper()

if __name__ == "__main__":

If we execute it with appropriate parameters:

$ python footer.dd 1970

It gives:

Android FDE crypto footer
Magic : 0xD0B5B1C4
Major Version : 1
Minor Version : 2
Footer Size : 192 bytes
Flags : 0x00000000
Key Size : 128 bits
Failed Decrypts : 0
Crypto Type : aes-cbc-essiv:sha256
Encrypted Key : 0x0CB33742A157543F46111448FC63BC10
Salt : 0xE53FD71CF38B6E3BE0BF6C9FC824C104
KDF : scrypt
N_factor : 15 (N=32768)
r_factor : 3 (r=8)
p_factor : 1 (p=2)
Key: FF6D9DEB77BA1120E355D5F95F9B5BE3

We have our key! It is also saved in a file named “decryption.key”.

We now have all we need. First, we setup a loop device, then we setup disk decryption and then we mount the device:

$ losetup /dev/loop3 mmcblk0p28.dd
$ cryptsetup --type plain open -c aes-cbc-essiv:sha256 -s 128 -d decryption.key /dev/loop3 userdata
$ mkdir mnt
$ mount /dev/mapper/userdata mnt

We have now access to decrypted data:

$ ls -l mnt

total 164
drwxrwxr-x. 2 1000 inetsim 4096 Oct 6 15:45 anr
drwxrwx--x. 2 1000 inetsim 4096 Feb 24 06:20 app
drwx------. 2 root root 4096 Oct 6 15:42 app-asec
drwxrwx--x. 3 1000 inetsim 4096 Feb 24 06:20 app-lib
drwxrwx--x. 2 1000 inetsim 4096 Oct 6 15:42 app-private
drwx------. 5 1000 inetsim 4096 Oct 6 15:45 backup
lrwxrwxrwx. 1 root root 45 Oct 6 15:42 bugreports -> /data/data/
drwxrwx--x. 2 1000 inetsim 4096 Feb 24 06:20 dalvik-cache
drwxrwx--x. 89 1000 inetsim 4096 Feb 24 06:20 data
drwxr-x---. 2 root 1007 4096 Oct 6 15:42 dontpanic
drwxrwx---. 3 1019 1019 4096 Oct 6 15:46 drm
-rw-rw-rw-. 1 root root 138 Feb 24 09:39 FLAG1.txt
drwxr-x--x. 3 root root 4096 Oct 6 15:42 local
drwxrwxr-x. 2 1000 1007 4096 Oct 6 15:42 log
drwxrwx---. 2 root root 4096 Dec 31 1969 lost+found
drwxrwx---. 5 1023 1023 4096 Oct 6 15:45 media
drwxrwx---. 2 1031 1031 4096 Oct 6 15:42 mediadrm
drwxrwx--t. 16 1000 9998 4096 Jan 7 14:15 misc
drwx------. 2 root root 4096 Feb 23 02:30 property
drwxrwx---. 2 1001 1001 4096 Oct 6 15:42 radio
drwxrwx--x. 2 1000 inetsim 4096 Oct 6 15:42 resource-cache
drwx--x--x. 2 1000 inetsim 4096 Oct 6 15:42 security
drwxr-x---. 3 root 2000 4096 Feb 19 17:16 ssh
drwxrwxr-x. 13 1000 inetsim 4096 Feb 24 09:53 system
drwx------. 2 1000 inetsim 4096 Feb 20 07:56 tombstones
drwx--x--x. 2 1000 inetsim 4096 Oct 6 15:42 user

There is a file named “FLAG1.txt” and it contains:

$ cat FLAG1.txt

Congratulations, you found the first flag:

You can now try to crack the application to get the second flag...

By the way, the application in question is in app and its files in data.

When you have retrieved data, do simply:

$ umount mnt
$ cryptsetup close user data
$ losetup -d /dev/loop3

See you next year!

Catalogue de formations 2013

Pour 2013 SCRT étoffe à nouveau son catalogue de formations techniques afin de répondre au mieux au monde de la sécurité en perpétuelle évolution, notamment avec les formations sur le développement d’applications pour terminaux mobiles (COD102 & COD103) ainsi que la gestion des logs dans le contexte de la sécurité informatique (FOR102).

Vous trouverez dans la suite de cet article la liste des formations mise à jour. N’hésitez pas à nous contacter pour de plus amples informations.


INF101 – Fortinet

Cette formation prépare au premier niveau de certification Fortinet : le FCNSA (Fortinet Certified Network. Securtiy Administrator).
Profils : Administrateurs systèmes
Pré-requis : N/A
Durée du cours : 1 jour

INF102 – Sécurisation d’infrastructures virtualisées VMware

Ce cours présente les nouveaux risques liés aux architectures virtualisées, ainsi que les bonnes pratiques à adopter dans l’administration de ces environnements.
Profils : Administrateurs système, Administrateurs d’infrastructures VMware ESX
Pré-requis : Connaissances de base VMware ESX
Durée du cours : 1 journée

INF103 – Sécurité windows 7/2008

Cette formation présente les différentes options et bonnes pratiques permettant de mieux sécuriser les systèmes Microsoft Windows 7 & 2008.
Profils : Administrateurs système, RSSI
Pré-requis : Administration Windows
Durée du cours : 1 journée

INF104 – Sécurisation / administration Linux

Découvrez au travers de cette formation les options et outils permettant de sécuriser au mieux un serveur Linux.
Profils : RSSI, chef de projet, administrateur système
Pré-requis : Notions / connaissances de base des systèmes Linux
Durée du cours : 1 journée

INF105 – Sécurité des architectures web

Cette formation présente les fondamenteux de la sécurité des architectures web : sécurité des architectures N tiers, cryptographie, équipements liés à la sécurité des architectures web (firewall, IPS, WAF, …), enjeux et méthodes, protocoles de fédération d’identité… .
Profils : Développeurs, chefs de projet, administrateurs systèmes, RSSI
Pré-requis : N/A
Durée du cours : 1 journée

INF203 – Bootcamp sécurité Windows

Les administrateurs systèmes sont souvent amenés à configurer des points clefs de la sécurité d’un système d’exploitation. C’est en partant de ce constat et pour ainsi les aider à mieux comprendre les fondements de la sécurité du système d’exploitation Windows que nous avons crée cette formation.
Après avoir présenté les fondements de la sécurité du système d’exploitation ainsi que les méthodes pour faire un état des lieux, les points permettant de faire face à une attaque en la comprenant et en sécurisant le système seront abordés.
La pratique ne sera pas oubliée avec des démonstrations et des exercices dans des environnements virtualisés pour illustrer le tout.
Profils : Administrateurs système Windows
Pré-requis : N/A
Durée du cours : 1 journée


HAK101 – Outils et méthodes de hacking – niveau intermédiaire

Cette formation a pour but d’enseigner l’identification et l’exploitation des failles de sécurité les plus courantes. Au travers d’une dizaine d’exercices pratiques, les participants apprendront à déceler et à exploiter des vulnérabilités telles que les injections SQL ou le cross-site scripting. Ils apprendront également à tirer parti d’un serveur mal configuré ou encore à mener une attaque par “brute-force” sur un mot de passe.
Profils : Administrateurs systèmes/réseaux, RSSI, développeurs
Pré-requis : Connaissances basiques HTML, SQL, réseau
Durée du cours : 1 journée

HAK201 – Outils et méthodes de hacking – niveau expert

A l’instar de Outils et méthodes de hacking – Niveau 2, cette formation pratique a pour but d’enseigner la détection et l’exploitation de vulnérabilités réelles. La théorie et les exercices (en environnement de laboratoire) permettront ainsi aux participants de comprendre et de mener des attaques avancées telles que l’exploitation de buffer overflows, l’interception réseau ou encore l’attaque de réseaux sans-fil.
Profils : Administrateurs systèmes/réseaux, RSSI, développeurs
Pré-requis : Outils et méthodes de hacking niveau intermédiaire & connaissances basiques HTML, SQL, réseau
Durée du cours : 1 journée

HAK102 – Nouvelles attaques web

Cette formation présente les nouvelles attaques ciblant plus particulièrement les sites web : Cross site request forgery, click-jacking, attaques navigateur,… .
Profils : Administrateurs systèmes, développeurs, RSSI
Pré-requis : Connaissances des attaques « classiques » telles que XSS, SQLi, …
Durée du cours : ½ journée

HAK202 – Sécurité des nouvelles technologies web

Cette formation présente les nouvelles menaces et attaques sur les technologies récentes du Web : Node.js, bases de données NoSQL, HTML5. Ce cours comprend des exemples pratiques ainsi que des travaux pratiques permettant de mettre en oeuvre et de contrer ces attaques.
Profils: Développeurs, Chefs de projet
Pré-requis: Connaissances de bases sur les technologies web
Durée du cours : 1 journée


COD101 – Secure coding OWASP

Découvrez le TOP10 des failles OWASP, les conseils et solutions pour éviter ces erreurs, ainsi qu’une série d’exemples et conseils adaptés aux langages uilisés par vos équipes (PHP, Java, C, …).
Profils : Développeurs, chef de projet
Pré-requis : Connaissances de base langage sélectionné
Durée du cours : 1/2 à  1 journée

COD102 – Secure coding iOS

Cette formation présente les erreurs de développement pouvant introduire des vulnérabilités lors du développement d’applications pour plateforme iOS en se basant sur le référentiel de l’OWASP mais également notre retour d’expérience d’audits d’applications.
Durée de la formation : 1/2 journée

COD103 – Secure coding Android

Cette formation présente les erreurs de développement pouvant introduire des vulnérabilités lors du développement d’applications pour plateforme Android en se basant sur le référentiel de l’OWASP mais également notre retour d’expérience d’audits d’applications.
Profils: développeurs
Pré-requis: développement et plateforme Android
Durée du cours: 1 journée


FOR101 – Forensics

Formation visant à mieux connaître les outils open-source permettant de
mener à bien une analyse forensique.
Profils : RSSI, administrateurs systèmes
Pré-requis : N/A
Durée du cours : 1 journée

FOR102 – Log management in Depth

Cette formation présente les fondamentaux du log management et de son intégration. Elle regroupe les analyses forensiques, les mises en conformité avec les normes ISO27001, PCI-DSS, HIPAA ainsi que l’exploitation de logs pour le monitoring de service, le troubleshooting et la détection d’intrusion. Profils: RSSI, administrateurs systèmes et réseaux
Pré-requis: N/A
Durée du cours: 1 jour

Sensibilisation utilisateurs

(cette formation n’a pas de thème, elle est seule). Les mesures de sécurité les plus complexes peuvent généralement être déjouées en attaquant le maillon le plus faible de la sécurité de votre système d’information : l’utilisateur. Cette formation, basée sur des démonstrations et exemples concrets, vise à donner les bons reflexes aux utilisateurs. Le contenu de la formation peut être adapté en fonction de vos attentes : Social engineering, code malveillant, réseaux sociaux, utiliteurs nomades, équipements mobiles, attaques de type MiTM, … .
Profils : Utilisateurs finaux
Pré-requis : N/A
Durée du cours : 2 heures

Calendrier des formations 2013
Calendrier des formations 2013

Sécurité des terminaux Android


Lors d’un précédent article nous nous intéressions à la sécurité des terminaux iOS, notamment face aux outils de jailbreak permettant de contourner le chiffrement de la NAND. Bien que le marché Suisse soit majoritairement tourné vers iOS pour le moment, la sécurité des terminaux Android n’est pas à négliger, d’autant plus que leur popularité est grandissante.

Contrairement au cas iOS, il est beaucoup plus difficile de généraliser sur la sécurité des terminaux Android du fait de la grande diversité de constructeurs sur le marché et des modifications ou spécificités que chacun d’eux peut introduire dans ses terminaux. De plus, contrairement à iOS dont les terminaux ont tendance à converger assez rapidement vers la dernière version disponible, un large éventail de versions Android peut être rencontré en parallèle, pour lesquelles les fonctionnalités qui nous intéressent peuvent ne pas être uniformes (un exemple de ceci est la disponibilité de la fonction de chiffrement). Ceci étant dit, nous détaillons dans cet article quelques cas que nous espérons suffisamment génériques pour être applicables à une majorité de terminaux.

Récupération des données

Dans le cas d’un terminal Android « lambda », un certain nombre de fonctionnalités ou de limitations peuvent avoir un impact direct sur la sécurité du terminal face à une tentative de récupération de données, par exemple en cas de perte ou de vol de l’appareil. Certaines des ces fonctionnalités sont liées à des aspects « hardware » et donc directement liées à des choix faits par le constructeur. Parmi celles-ci nous allons notamment considérer le verrouillage du bootloader (qui empêche le démarrage du terminal sur une image système modifiée) et la présence d’éventuelles interfaces de debug accessibles (JTAG, UART, …).

A l’inverse d’autres fonctionnalités sont directement proposées par le système d’exploitation (Android) et donc communes à tous les constructeurs, notamment ADB (Android Debug Bridge), le verrouillage du téléphone par un code ou un schéma ou encore le chiffrement des données (disponible depuis Android 3.0 pour les tablettes et depuis Android 4.0 pour les téléphones).

Cas #1 : out-of-the-box

Dans une grande majorité des cas, les terminaux Android sont vendus avec une configuration assez peu « intéressante » pour un attaquant, comprendre par là que la protection des données est assez bien garantie. En effet, le bootloader est généralement verrouillé par défaut et ADB n’est pas activé. Seul bémol (mais de taille) à cela, le chiffrement des données n’est pas activé par défaut sur les terminaux actuellement disponibles. Bien entendu, tout cela est inutile si l’utilisateur ne protège pas son terminal par un code d’accès (passcode). Toutefois ce cas étant trivial, nous n’allons pas le considérer et nous partons du principe que cette fonctionnalité est activée.

Un attaquant a alors trois options principales pour extraire des données d’un terminal:

  • « Deviner » le passcode (ou tenter une smudge attack s’il s’agit d’un schéma de verrouillage)
  • Extraire des données de la carte externe (micro-SD) si le terminal en dispose (ce qui n’est, par exemple, pas le cas des terminaux de type Nexus de Google). Les données contenues par la micro-SD peuvent toutefois ne pas être les plus intéressantes pour l’attaquant
  • Utiliser un équipement permettant l’extraction des données de la NAND, par exemple via l’interface JTAG

Cette dernière option est généralement toujours envisageable, mais elle demande du matériel spécifique ainsi que le démontage plus ou moins profond du téléphone, suivant les modèles. Si ces deux conditions sont remplies, il devient alors toutefois possible d’extraire l’intégralité des données en faisant un « dump » complet de la mémoire flash.


Lors des tests menés dans notre laboratoire sur des terminaux équipés d’une NAND de 4Go, il aura fallu environ 4h pour réaliser une copie bit-à-bit au travers de l’interface JTAG.



Toutefois, une fois cette copie effectuée il aura suffi de quelques secondes (à l’aide d’un petit script Python) pour localiser les « hash » du passcode, le « salt » correspondant ainsi que pour récupérer le code par brute-force (PIN de 4 chiffres). Cette récupération est par ailleurs déjà bien documentée sur Internet.

Une fois le passcode récupéré il suffit alors de remonter pour en prendre le contrôle total et obtenir l’accès à ses données. Si ceci s’avère impossible, il est évidemment également possible d’extraire les autres données intéressantes directement à partir du dump de la flash. Il faut toutefois, pour cela, s’affranchir du fait que le dump est très bas niveau et ne fournit pas directement un système de fichiers pouvant être monté. Néanmoins, comme pour le cas du passcode, en sachant ce que l’on recherche quelques expressions régulières peuvent faire des miracles.

Cas #2 : Android Debug Bridge

Cette fonctionnalité se découpe sous la forme d’un client installé avec le SDK et d’une partie serveur lancée sur le terminal Android. Très utilisé dans le cadre du développement d’applications, il offre des options intéressantes pour un attaquant, telles que l’installation et le lancement d’applications.

Dans le cas où cette fonctionnalité est activée sur un terminal, un attaquant peut aisément accéder aux données de l’utilisateur, installer des applications et les lancer et ce sans avoir besoin du passcode.

Il est donc très important, pour la sécurité d’un terminal Android, de s’assurer que ADB n’est pas activé par mégarde.

Cas #3 : bootloader déverrouillé

Le bootloader est responsable du démarrage de l’appareil et de l’amorce du système d’exploitation. C’est donc lui qui démarre Android et qui fournit également la possibilités de démarrer le terminal sur une image de « recovery » permettant ainsi, par exemple, de flasher un nouveau système. Dans son mode de fonctionnement par défaut (verrouillé), ce bootloader ne permet le démarrage d’une image système que si cette dernière est signée par le constructeur. Toutefois, la plupart des constructeurs permettent maintenant de déverrouiller le bootloader afin de démarrer (ou de flasher) une image système non-signée (par exemple un système Android « rooté »).

Ainsi, si le bootloader du terminal à attaquer n’est pas verrouillé il est possible de démarrer le terminal sur une image « recovery » modifiée, contenant – par exemple – des outils de forensique offensif dans le but d’extraire des informations. Le système de recovery ayant généralement un accès complet à la flash (des particularités peuvent exister pour certains constructeurs, notamment pour ce qui est des droits d’écriture) il est alors possible, depuis là, d’accéder à l’intégralité des données utilisateur.

Une contre-mesure à cela est fournie par le chiffrement des données, toutefois, il sera alors possible (si le terminal a été dérobé alors qu’il était démarré mais verrouillé) de tenter des attaques de type cold-boot visant à récupérer la clé de chiffrement.

A ce stade le lecteur est en droit de se demander pourquoi il ne suffit pas – alors – pour l’attaquant de déverrouiller le bootloader du terminal pour en extraire les données. La raison est simple : l’opération de déverrouillage du bootloader entraîne, chez tous les constructeurs qui le permettent, la remise à zéro du terminal et ainsi l’effacement des données. Il ne s’agit pas là d’une contrainte technique mais bel et bien d’une fonctionnalité de sécurité visant justement à empêcher la compromission des données.


Comme nous avons tenté de le présenter dans cet article, la combinaisons des différentes fonctionnalités de sécurité peut rendre plus ou moins complexe la récupération des données sur un terminal Android. Les configurations d’usine sont généralement prévues pour être sûres toutefois, la grande liberté laissée à l’utilisateur dans la modification de son terminal Android (par opposition aux terminaux iOS) permet également à ce dernier d’effectuer des modifications entraînant un risque pour la sécurité de ses données.

De plus, il est à relever que même dans le cas où le terminal dispose d’un bootloader verrouillé et que ADB n’est pas démarré, il reste possible pour un attaquant ayant quelques connaissances en électronique (et surtout l’équipement approprié), de procéder à une copie bit-à-bit de la NAND et ainsi accéder aux données stockées sur le terminal, pour autant qu’elles ne soient pas chiffrées.

Pour conclure nous relèverons donc que, bien que ceci ne soit – malheureusement – pas fait par défaut sur les terminaux Android, l’activation du chiffrement des données apparaît comme une composante de base indispensable à une bonne protection des données de l’utilisateur.

Julien Bachmann
Sergio Alves Domingues