Fonctionnement d'Android, partie 4

Bonjour à tous! Nous avons pris le temps de poursuivre une série d'articles sur l'appareil interne Android. Dans cet article, je parlerai du processus de démarrage Android, du contenu du système de fichiers, de la façon dont les données des utilisateurs et des applications sont stockées, de l'accès root, de la portabilité des versions d'Android et du problème de fragmentation.

Articles de série:

• Fonctionnement d'Android, partie 1
• Fonctionnement d'Android, partie 2
• Fonctionnement d'Android, partie 3
• Fonctionnement d'Android, partie 4
• ...

Forfaits

Comme je l'ai déjà dit, l'architecture Android est construite autour d'applications. Ce sont les applications qui jouent un rôle clé dans le périphérique de nombreuses parties du système, c'est pour l'interaction harmonieuse des applications que les modèles d'activité et d'intention sont construits, et le modèle de sécurité Android est basé sur l'isolement des applications. Et si le gestionnaire d'activité est engagé dans l'orchestration de l'interaction des composants d'application, le gestionnaire de packages est responsable de l'installation, de la mise à jour et de la gestion des droits des applications (gestionnaire de packages - vous pouvez l'appeler dans le shell avec la commande pm ).

Comme son nom l'indique «gestionnaire de packages», à ce niveau, les applications sont souvent appelées packages . Les packages sont distribués au format APK (package Android) - archives zip spéciales. Chaque package a un nom (également appelé ID d'application ) qui identifie de manière unique cette application (mais pas sa version spécifique - au contraire, les noms des différentes versions du package doivent correspondre, sinon ils seront considérés comme des packages distincts). Les noms de package sont généralement écrits en notation du nom DNS inverse - par exemple, l'application YouTube utilise le nom de package com.google.android.youtube . Souvent, le nom du package correspond à l'espace de noms utilisé dans son code Java, mais Android ne l'exige pas (en outre, les fichiers APK de l'application incluent généralement des bibliothèques tierces, dont l'espace de noms, bien sûr, n'a rien à voir avec les noms de packages, qui les utilisent).

Chaque APK pendant l'assemblage doit être signé par le développeur à l'aide d'une signature numérique. Android vérifie la présence de cette signature lors de l'installation de l'application et lors de la mise à jour d'une application déjà installée, il compare en outre les clés publiques avec lesquelles l'ancienne et la nouvelle version sont signées; ils doivent correspondre, ce qui garantit que la nouvelle version a été créée par le même développeur que l'ancienne. (Si cette vérification n'était pas disponible, l'attaquant pourrait créer un package du même nom que l'application existante, convaincre l'utilisateur de l'installer en «mettant à jour» l'application, et accéder aux données de cette application.)

La mise à jour du package lui-même est l'installation de sa nouvelle version au lieu de l'ancienne avec la préservation des données et autorisations reçues de l'utilisateur. Vous pouvez également «rétrograder» les applications vers des versions plus anciennes, mais en même temps, par défaut, Android efface les données enregistrées par la nouvelle version, car l'ancienne version peut ne pas fonctionner avec les formats de données utilisés par la nouvelle version.

Comme je l'ai déjà dit, le code de chaque application est généralement exécuté sous son propre utilisateur Unix (UID), ce qui garantit leur isolation mutuelle. Plusieurs applications peuvent explicitement demander à Android d'utiliser un UID commun pour elles, ce qui leur permettra d'accéder directement aux fichiers des autres et même, si vous le souhaitez, de s'exécuter dans le même processus.

Bien que généralement un package corresponde à un fichier APK, Android prend en charge les packages composés de plusieurs APK (c'est ce qu'on appelle des APK fractionnés ou des APK fractionnés ). C'est la base de telles fonctionnalités "magiques" d'Android, telles que le chargement dynamique de modules d'application supplémentaires (modules de fonctionnalités dynamiques ) et Instant Run dans Android Studio (mise à jour automatique du code d'application en cours d'exécution sans sa réinstallation complète et, dans de nombreux cas, même sans redémarrage).

Système de fichiers

Le périphérique du système de fichiers est l'un des problèmes les plus importants et les plus intéressants de l'architecture du système d'exploitation, et le périphérique du système de fichiers dans Android ne fait pas exception.

L'intérêt est, tout d'abord, quels systèmes de fichiers sont utilisés, c'est-à-dire dans quel format le contenu des fichiers est enregistré sur un disque conditionnel (dans le cas d'Android, c'est généralement une mémoire flash et des cartes SD) et comment le noyau du système prend en charge ce format . Le noyau Linux utilisé dans Android, à un degré ou un autre, prend en charge un grand nombre de systèmes de fichiers différents - de ceux utilisés dans Windows FAT et NTFS et ceux utilisés à Darwin par le tristement célèbre HFS + et APFS moderne - au réseau 9pfs du Plan 9. Il existe de nombreux »Pour les systèmes de fichiers Linux - par exemple, Btrfs et la famille ext.

Le standard de facto pour Linux est depuis longtemps ext4 , utilisé par défaut par les distributions Linux les plus populaires. Par conséquent, il n'y a rien d'inattendu dans le fait qu'il soit utilisé dans Android. Certains assemblages (et certains passionnés) utilisent également F2FS (Flash-Friendly File System), optimisé spécifiquement pour la mémoire flash (cependant, avec ses avantages, tout n'est pas si clair ).

Deuxièmement, la disposition dite du système de fichiers est intéressante - l'emplacement des dossiers et fichiers système et utilisateur dans le système de fichiers. La disposition du système de fichiers dans «Linux ordinaire» mérite une description plus détaillée (qui peut être trouvée, par exemple, sur ce lien ); Je ne mentionnerai ici que quelques-uns des répertoires les plus importants:

• /home stocke les dossiers personnels des utilisateurs; ici, dans divers dossiers cachés ( .cache , .cache , .config et autres), les programmes stockent leurs paramètres, données et cache, spécifiques à l'utilisateur,
• /boot stocke le noyau Linux et l'image initramfs (système de fichiers de démarrage spécial),
• /usr (il serait plus logique d'appeler /system ) stocke la partie principale du système lui-même, y compris les bibliothèques, les fichiers exécutables, les fichiers de configuration, ainsi que les ressources - thèmes pour l'interface, icônes, contenu du manuel du système, etc.,
• /etc (il serait plus logique d'appeler /config ) stocke les paramètres à l'échelle du système,
• /dev stocke les fichiers de périphérique et d'autres fichiers spéciaux (par exemple, le socket /dev/log ),
• /var stocke des données mutables - journaux, cache système, contenu de base de données, etc.

Android utilise une disposition de système de fichiers similaire mais sensiblement différente. En voici quelques-unes des parties les plus importantes:

• /data stocke des données mutables,
• Le noyau et l'image initramfs sont stockés sur une partition flash distincte, qui ne peut pas être montée sur le système de fichiers principal.
• /system correspond à /usr et stocke le système,
• /vendor - un analogue de /system conçu pour les fichiers spécifiques à cet assemblage Android, et non inclus dans l'Android "standard",
• /dev , comme dans "Linux normal", stocke les fichiers de périphériques et autres fichiers spéciaux.

Les plus intéressants de ces répertoires sont /data et /system . Le contenu de /system décrit le système et contient la plupart de ses fichiers constitutifs. /system est situé sur une section distincte de la mémoire flash, qui est montée par défaut en mode lecture seule; généralement, les données ne changent que lorsque le système est mis à jour. /data également dans une section distincte et décrit l'état modifiable d'un appareil particulier, y compris les paramètres utilisateur, les applications installées et leurs données, les caches, etc. La suppression de toutes les données utilisateur, la soi-disant réinitialisation d'usine, avec ce schéma consiste simplement à supprimer le contenu de la section des données ; un système intact reste installé dans la section système .

 # mount | grep /system /dev/block/mmcblk0p14 on /system type ext4 (ro,seclabel,relatime,data=ordered) # mount | grep /data /dev/block/mmcblk0p24 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,data=writeback) 

Les applications - à savoir, leurs APK, fichiers odex (code Java compilé à l'avance) et bibliothèques ELF - sont installées dans /system/app (pour les applications /data/app avec le système) ou dans /data/app (pour les installées par l'utilisateur) applications). Lors de la création d'un assembly Android, chaque application préinstallée se voit attribuer un dossier portant le nom du formulaire /system/app/Terminal , et pour les applications installées par l'utilisateur lors de l'installation, des dossiers sont créés dont les noms commencent par le nom de leur package. Par exemple, une application YouTube est enregistrée dans un dossier avec un nom comme /data/app/com.google.android.youtube-bkJAtUtbTuzvAioW-LEStg==/ .

 # pm path com.android.egg package:/system/app/EasterEgg/EasterEgg.apk 

Étant donné que les applications préinstallées sont stockées dans la section système (dont le contenu, je me souviens, ne change que lorsque le système est mis à jour), elles ne peuvent pas être supprimées (à la place, Android offre la possibilité de les "désactiver"). Néanmoins, la mise à jour des applications préinstallées est prise en charge - dans ce cas, un dossier dans /data/app est créé pour la nouvelle version et la version fournie avec le système reste dans /system/app . Dans ce cas, l'utilisateur a la possibilité de "supprimer les mises à jour" d'une telle application, en revenant à la version depuis /system/app .

Une autre caractéristique des applications préinstallées est qu'elles peuvent recevoir des autorisations «système» spéciales . Par exemple, les applications tierces n'ont pas l'autorisation DELETE_PACKAGES , qui vous permet de supprimer d'autres applications, REBOOT , qui vous permet de redémarrer le système, et READ_FRAME_BUFFER , qui permet un accès direct au contenu de l'écran. Ces autorisations ont un niveau de protection de signature , c'est-à-dire que l'application essayant d'y accéder doit être signée avec la même clé que l'application ou le service dans lequel elles sont implémentées - dans ce cas, puisque ces autorisations sont implémentées par le système, la clé avec laquelle elle est signée Version Android

Pour stocker des données modifiables, chaque application se voit attribuer un dossier dans /data/data (par exemple, /data/data/com.google.android.youtube pour YouTube). Seule l'application elle-même a accès à ce dossier, c'est-à-dire uniquement l'UID sous lequel cette application est lancée (si l'application utilise plusieurs UID ou si plusieurs applications utilisent un UID commun, tout peut être plus compliqué). Dans ce dossier, les applications enregistrent les paramètres, le cache (dans les sous-dossiers shared_prefs et cache , respectivement) et toutes les autres données dont ils ont besoin:

 # ls /data/data/com.google.android.youtube/ cache code_cache databases files lib no_backup shared_prefs # cat /data/data/com.google.android.youtube/shared_prefs/youtube.xml <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="user_account">username@gmail.com</string> <boolean name="h264_main_profile_supported7.1.2" value="true" /> <int name="last_manual_video_quality_selection_max" value="-2" /> <...> </map> 

Le système connaît l'existence du dossier de cache et peut le nettoyer seul s'il n'y a pas assez d'espace. Lorsque vous désinstallez l'application, le dossier entier de cette application est complètement supprimé et l'application ne laisse aucune trace. Alternativement, les deux utilisateurs peuvent explicitement faire dans les paramètres:

Ce stockage de données alloué à chaque application est appelé stockage interne.

De plus, Android dispose d'un autre type de stockage - le stockage dit externe ( stockage externe - ce nom reflète l'idée originale que le stockage externe devrait être situé sur une carte SD externe insérée dans le téléphone). En fait, le stockage externe joue le rôle du dossier de départ de l' utilisateur - des dossiers tels que Documents, Téléchargement, Musique et Images s'y trouvent, c'est le stockage externe que les gestionnaires de fichiers ouvrent comme dossier par défaut, il permet à l'ordinateur d'accéder au contenu du stockage externe lorsqu'il est connecté par câble.

 # ls /sdcard Alarms Download Podcasts Android Movies Ringtones Books Music Subtitles DCIM Notifications bluetooth Documents Pictures 

Contrairement au stockage interne, divisé en dossiers d'applications individuelles, le stockage externe est une «zone commune»: toute application qui a reçu l'autorisation appropriée de l'utilisateur y a un accès complet. Comme je l'ai mentionné dans un article précédent, les applications telles que le gestionnaire de fichiers doivent demander cette autorisation; et pour la plupart des autres applications, il est préférable d'utiliser l'intention avec l'action ACTION_GET_CONTENT , donnant à l'utilisateur la possibilité de choisir le fichier souhaité dans le gestionnaire de fichiers système.

De nombreuses applications préfèrent enregistrer certains de leurs fichiers internes, qui sont volumineux (par exemple, un cache d'images téléchargées et de fichiers audio) dans un stockage externe. Pour ce faire, Android alloue aux applications dans des dossiers de stockage externes avec des noms de la forme Android/data/com.google.android.youtube . L'application elle - même n'a pas besoin d' autorisation pour accéder à l'intégralité du stockage externe pour accéder à ce dossier (puisque son UID est défini comme propriétaire de ce dossier), mais toute autre application qui a cette autorisation peut accéder à ce dossier, donc cela vaut vraiment la peine d'être utilisé Uniquement pour le stockage de données publiques et non critiques. Lorsque vous désinstallez l'application, le système supprimera également son dossier spécial dans le stockage externe; mais les fichiers créés par des applications dans un stockage externe en dehors de leur dossier spécial sont considérés comme appartenant à l'utilisateur et restent en place après la suppression de l'application qui les a créés.

Comme je l'ai mentionné ci-dessus, il était initialement supposé que le stockage externe serait en fait situé sur une carte SD externe, car à ce moment-là, le volume des cartes SD était considérablement plus élevé que la quantité de mémoire intégrée dans les téléphones (dans le même HTC Dream, il n'était que de 256 mégaoctets, dont environ 90 mégaoctets ont été alloués à la section des données ). Depuis lors, de nombreuses conditions ont changé; les téléphones modernes n'ont souvent pas de fente pour carte SD, mais une énorme quantité de mémoire interne est installée par les normes mobiles (par exemple, dans le Samsung Galaxy Note 9, elle peut aller jusqu'à 512 gigaoctets ).

Par conséquent, dans Android moderne, le stockage interne et externe sont presque toujours situés dans la mémoire interne. Le chemin réel le long duquel le stockage externe est situé dans le système de fichiers prend la forme /data/media/0 ( un stockage externe séparé est créé pour chaque utilisateur du périphérique, et le numéro dans le chemin correspond au numéro d'utilisateur). Pour des raisons de compatibilité, le stockage externe est également accessible via les /sdcard , /mnt/sdcard , /storage/self/primary , /storage/emulated/0 , plusieurs chemins commençant par /mnt/runtime/ et quelques autres.

D'un autre côté, de nombreux appareils ont toujours un emplacement pour carte SD. La carte SD insérée dans l'appareil Android peut être utilisée comme un disque externe ordinaire (sans la transformer en stockage interne ou externe du système) - enregistrez-y des fichiers, ouvrez des fichiers stockés dessus, utilisez-la pour transférer des fichiers vers d'autres appareils, etc. De plus, Android vous permet «d'emprunter» une carte SD et d'y placer du stockage interne et externe (c'est ce qu'on appelle le stockage emprunté - stockage adopté ). Dans le même temps, le système reformate la carte SD et chiffre son contenu - les données qui y sont stockées ne peuvent pas être lues en la connectant à un autre appareil.

Vous pouvez en savoir plus sur tout cela, par exemple, dans cet article et dans la documentation officielle pour les développeurs d'applications et les créateurs d'assemblages Android .

Chargement

L'approche traditionnelle de la sécurité des systèmes informatiques se limite à protéger le système contre les attaques logicielles. On pense que si un attaquant a un accès physique à un ordinateur, le jeu est déjà perdu : il peut avoir un accès complet à toutes les données qui y sont stockées. Pour ce faire, il lui suffit, par exemple, d'exécuter sur cet ordinateur un système d'exploitation arbitraire contrôlé par lui, qui lui permet de contourner toutes les restrictions imposées par le système "principal" de droits, ou de connecter directement le disque de données à un autre appareil. Si vous le souhaitez, un attaquant peut laisser l'ordinateur en état de fonctionnement, mais corriger le système installé sur celui-ci, installer des portes dérobées arbitraires, des enregistreurs de frappe, etc.

C'est la protection contre les attaques logicielles qui se concentre sur le modèle de restriction des droits des utilisateurs sous Unix (et la technologie sandbox de l'application basée sur celle-ci dans Android); La restriction Unix en soi ne protège pas le système contre un utilisateur qui s'est rendu dans la salle des serveurs et a obtenu un accès physique à l'ordinateur. Et si des serveurs multi-utilisateurs sérieux peuvent et doivent être protégés contre tout accès physique non autorisé aux ordinateurs personnels - et en particulier aux appareils mobiles - cette approche n'est tout simplement pas applicable.

Il y a deux façons d'essayer d'améliorer la situation avec une protection contre un attaquant qui a obtenu un accès physique à l'appareil:

• Premièrement, il est possible de crypter les données stockées sur un disque , empêchant ainsi un attaquant d'accéder aux données lui-même, même s'il a accès au contenu du disque.
• Deuxièmement, il est possible de limiter en quelque sorte la capacité de charger des systèmes d'exploitation arbitraires sur l'appareil , forçant un attaquant à passer par des procédures d'authentification et d'autorisation dans le système installé.

C'est à ces deux zones de protection que le modèle de démarrage sécurisé sous Android est associé.

Démarrage vérifié

Le processus de démarrage Android est conçu de sorte que, d'une part, il ne permet pas aux attaquants de charger un système d'exploitation arbitraire sur l'appareil, d'autre part, il permet aux utilisateurs d'installer des assemblages Android personnalisés (et d'autres systèmes).

Tout d'abord, les appareils Android, contrairement aux ordinateurs de bureau, ne permettent généralement pas à un utilisateur (ou à un attaquant) de démarrer à partir d'un support externe; à la place, le chargeur de démarrage installé sur le périphérique (chargeur de démarrage) démarre immédiatement. Bootloader est un programme relativement simple dont les tâches (lors du chargement en mode normal) comprennent:

• initialisation et configuration de Trusted Execution Environment (par exemple ARM TrustZone),
• trouver des partitions de mémoire interne qui stockent des images du noyau Linux et des initramfs,
• vérification de leur intégrité (intégrité) - sinon le téléchargement est interrompu par un message d'erreur - en vérifiant la signature numérique du constructeur,
• charger le noyau et initramfs dans la mémoire et transférer le contrôle au noyau.

Clignotement, déverrouillage, démarrage rapide et récupération

De plus, le chargeur de démarrage prend en charge des fonctionnalités supplémentaires pour la mise à jour et la réinstallation du système.

-, (Android) , recovery . recovery, Android- , , Android recovery .

«» bootloader', — ( flashing ) . bootloader , fastboot mode ( bootloader mode), bootloader' fastboot ( fastboot Android SDK ).

bootloader' . , Samsung, bootloader'a (Loke) (Odin). Odin Samsung ( Odin), Heimdall .

bootloader' ( ), recovery Android, , :

 $ fastboot flash recovery recovery.img $ fastboot flash boot boot.img $ fastboot flash system system.img 

; : , , bootloader' Android, , , , .

, bootloader' (unlocking the bootloader, OEM unlock) — bootloader' recovery, ( ). Android, LineageOS ( CyanogenMod ), Paranoid Android , AOKP , OmniROM .

bootloader' - , ( data ) . , , (, Google ), — , .

recovery bootloader , .

bootloader' :

recovery, «» (flashaholics) — TWRP (Team Win Recovery Project). - «», zip-, :

Android ( file-based encryption ). ext4 , Linux ( fscrypt ), .

, data , , (credential encrypted storage). , , . , , .

credential encrypted storage Android device encrypted storage — , ( Trusted Execution Environment). , , , . , Direct Boot : ; ( ) device encrypted storage, , . , Direct Boot , , - .

Root

root- — « root» (UID 0, ). , root — Unix-, — — , .

, Android , root- . , « », Android « », root- «», :

• — , APK ,
• : -, email-, , , , , , ( activity intent', ),
• (icon packs),
• , ,
• ( Android-) ,
• , Android, .

, , , root- . root- ( ), Android root . , , Unix-; shell, adb shell , Unix- shell .

, , root :

• -, root- Android — Android Studio QEMU, .
• -, root- Android ( pre-rooted ROMs).
• -, bootloader' root- Android , , su , bootloader.
• , -, , , root-, ( root- ). , 2016 , root- Dirty Cow .

? , root- . , root-, , , . — , . , , system ( ).

, root- — , .

root-

With great power comes great responsibility.

, . , root- .

, , . , root- , , , root- . root, , , , — , , , ..

, Unix, Android , — . root- , , . , root- Android, .

, , root- , . , , , , , . , — , Google Pay ( Android Pay) — root- , .

, - Pokémon GO root- , , .

Google Play root-

Google Google Play Store Google Play Services , root- , Android , , , , . Play Store — ( , ) Android, . ( — , Amazon Android Fire OS — Echo, Fire TV, Fire Phone, Kindle Fire Tablet — Google). root- Android-.

, Google , root-, Google Play ( Open GApps ); Google , .

Device manufacturers work with Google to certify that Android devices with Google apps installed are secure and will run apps correctly. To be certified, a device must pass Android compatibility tests. If you are unable to add a Google Account on your Android device, your Android device software might not have passed Android compatibility tests, or the device manufacturer has not submitted the results to Google to seek approval. As a result, your device is uncertified. This means that your device might not be secure.

If you are a User wanting to use custom ROMs on your device, please register your device by submitting your Google Services Framework Android ID below.

root

«» Linux, Unix-, root- ( sudo su ) ( , Unix- root, ) (, ). , root-.

su Android Open Source Project , Unix- shell ( root), root-. su , , , .

, su . su , root-. , SuperSU ; Magisk .

Magisk

Magisk — , , /system , system ( systemless-ly ), «» Linux . Magisk Hide — root-, root- Magisk — - Google Pay, root- . Magisk Hide root-, SafetyNet Google.

, , Google Pay root- — root- . , root-, - Google Pay. , .

Magisk systemless- «» Magisk Modules , Magisk. , , root- Xposed ViPER , .

SoC,

, «», , — , — (, Wi-Fi ).

, Android- (system on a chip, SoC). — , , -, , LTE-, Bluetooth- Wi-Fi- .. — . , , , , , .

, , . , «», , , , . , , -, , , , .

— Android — SoC . , , — LTE- — . , ; , , .

SoC (, Qualcomm) Android- (, Sony LG), Android, Android Open Source Project. , Android, , , .

Android Android-. , Android. Android , , . .

, : Android — , . Android, .

, , , Android. .

-, . , . , , , , .

-, Android — developer experience (DX, user experience/UX). , Android, API — Android Framework, OpenGL/Vulkan — . , , , Android — , , .

Don't Stop Thinking About Tomorrow

Android- . , Google Nexus Pixel , Android. Android , , , .

, , Android, SoC. Android «» (, , Android-x86 RemixOS ). Android ChromeOS, Chromebook' Android- Linux- -. — Android — Anbox , Android- «» Linux-. (, Android- x86-, , Java, .)

, Android — , Android .

— Android. , , . , , Android .

. 2017 Google Project Treble — , ( HAL, hardware abstraction layer) ( , ) . Treble , , , — — .

Treble . Treble (Sony, Nokia, OnePlus, Oppo, Xiaomi, Essential Vivo — Google) - Android Pie. Treble Essential Android Pie Essential Phone Android Pie. Android — - — , Treble, , SoC.

Treble . Java «write once, run everywhere» — Android- . Treble — , Android SoC. , , Treble. , Android- .

userspace Android: init, Zygote, Binder, props.