* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Les primes HackenProof ne sont lancées que lorsque les clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.
**Chaque application se voit attribuer un identifiant d'utilisateur (UID) spécifique**. Cela est fait lors de l'installation de l'application afin que l'application ne puisse interagir qu'avec les fichiers appartenant à son UID ou les fichiers partagés. Par conséquent, seule l'application elle-même, certains composants du système d'exploitation et l'utilisateur root peuvent accéder aux données des applications.
**Deux applications peuvent être configurées pour utiliser le même UID**. Cela peut être utile pour partager des informations, mais si l'une d'entre elles est compromise, les données des deux applications seront compromises. C'est pourquoi ce comportement est **déconseillé**.\
Le **bac à sable des applications Android** permet d'exécuter **chaque application** en tant que **processus distinct sous un identifiant d'utilisateur distinct**. Chaque processus a sa propre machine virtuelle, de sorte que le code d'une application s'exécute de manière isolée des autres applications.\
À partir d'Android 5.0 (L), **SELinux** est appliqué. Fondamentalement, SELinux refuse toutes les interactions entre les processus, puis crée des politiques pour **autoriser uniquement les interactions attendues entre eux**.
Lorsque vous installez une **application et qu'elle demande des autorisations**, l'application demande les autorisations configurées dans les éléments **`uses-permission`** du fichier **AndroidManifest.xml**. L'élément **uses-permission** indique le nom de l'autorisation demandée dans l'attribut **name**. Il a également l'attribut **maxSdkVersion** qui arrête de demander des autorisations sur les versions supérieures à celle spécifiée.\
Notez que les applications Android n'ont pas besoin de demander toutes les autorisations au début, elles peuvent également **demander des autorisations dynamiquement**, mais toutes les autorisations doivent être **déclarées** dans le manifeste.
* **Normal** : Utilisé lorsqu'il n'y a **aucune menace connue** pour l'application. L'utilisateur **n'est pas tenu d'approuver**.
* **Dangerous** : Indique que l'autorisation accorde à l'application demandeur un **accès accru**. **Les utilisateurs sont invités à les approuver**.
* **Signature** : Seules les **applications signées par le même certificat que celui** exportant le composant peuvent se voir accorder l'autorisation. Il s'agit du type de protection le plus fort.
* **SignatureOrSystem** : Seules les **applications signées par le même certificat que celui** exportant le composant ou les **applications s'exécutant avec un accès de niveau système** peuvent se voir accorder des autorisations.
Ces applications se trouvent généralement dans les répertoires **`/system/app`** ou **`/system/priv-app`** et certaines d'entre elles sont **optimisées** (vous ne trouverez peut-être même pas le fichier `classes.dex`). Ces applications valent la peine d'être vérifiées car elles sont parfois **exécutées avec trop de permissions** (en tant que root).
* Ajoutées par le **fournisseur de téléphonie mobile** (si acheté chez eux)
## Rooting
Pour obtenir un accès root sur un appareil Android physique, vous avez généralement besoin d'exploiter 1 ou 2 vulnérabilités spécifiques à l'appareil et à la version. Une fois l'exploit réussi, le binaire Linux `su` est généralement copié dans un emplacement spécifié dans la variable d'environnement PATH de l'utilisateur, comme `/system/xbin`.
Une fois que le binaire su est configuré, une autre application Android est utilisée pour interagir avec le binaire su et traiter les demandes d'accès root, comme Superuser et SuperSU (disponibles sur Google Play Store).
{% hint style="danger" %}
Notez que le processus de rootage est très dangereux et peut endommager gravement l'appareil.
{% endhint %}
### ROMs
Il est possible de remplacer le système d'exploitation en installant un firmware personnalisé. En faisant cela, il est possible d'étendre l'utilité d'un ancien appareil, contourner les restrictions logicielles ou accéder au code Android le plus récent. OmniROM et LineageOS sont deux des firmwares les plus populaires à utiliser.
Notez que ce n'est pas toujours nécessaire de rooter l'appareil pour installer un firmware personnalisé. Certains fabricants permettent le déverrouillage de leurs chargeurs d'amorçage de manière bien documentée et sécurisée.
### Implications
Une fois qu'un appareil est rooté, n'importe quelle application peut demander un accès en tant que root. Si une application malveillante l'obtient, elle aura accès à presque tout et pourra endommager le téléphone.
## Fondamentaux des applications Android <a href="#2-android-application-fundamentals" id="2-android-application-fundamentals"></a>
Cette introduction est tirée de [https://maddiestone.github.io/AndroidAppRE/app\_fundamentals.html](https://maddiestone.github.io/AndroidAppRE/app\_fundamentals.html)
### Révision des fondamentaux <a href="#fundamentals-review" id="fundamentals-review"></a>
* Les applications Android sont au format de fichier APK. APK est essentiellement un fichier ZIP. (Vous pouvez renommer l'extension de fichier en .zip et utiliser unzip pour l'ouvrir et voir son contenu.)
* Contenu de l'APK (non exhaustif)
* AndroidManifest.xml
* resources.arsc/strings.xml
* resources.arsc : un fichier contenant des ressources précompilées, telles que du XML binaire par exemple.
* res/xml/files\_paths.xml
* META-INF/
* Le certificat se trouve ici !
* classes.dex
* Octets de code Dalvik pour l'application au format de fichier DEX. Il s'agit du code Java (ou Kotlin) compilé que l'application exécutera par défaut.
* lib/
* Bibliothèques natives pour l'application, par défaut, se trouvent ici ! Sous le répertoire lib/, il y a les répertoires spécifiques au processeur.
*`armeabi` : code compilé pour tous les processeurs ARM uniquement
*`armeabi-v7a` : code compilé pour tous les processeurs ARMv7 et supérieurs uniquement
*`x86` : code compilé pour X86
*`mips` : code compilé pour les processeurs MIPS uniquement
* assets/
* Tout autre fichier pouvant être nécessaire à l'application.
* Des bibliothèques natives supplémentaires ou des fichiers DEX peuvent être inclus ici. Cela peut se produire notamment lorsque les auteurs de logiciels malveillants veulent essayer de "cacher" du code supplémentaire, natif ou Dalvik, en ne l'incluant pas aux emplacements par défaut.
* res/
* Le répertoire contenant les ressources non compilées dans resources.arsc
La plupart des applications Android sont écrites en Java. Kotlin est également pris en charge et interopérable avec Java. Pour plus de simplicité, pour le reste de cet atelier, lorsque je parle de "Java", vous pouvez supposer que je veux dire "Java ou Kotlin". Au lieu que le code Java s'exécute dans une machine virtuelle Java (JVM) comme les applications de bureau, dans Android, le Java est compilé en bytecode Dalvik exécutable (DEX). Pour les versions antérieures d'Android, le bytecode était traduit par la machine virtuelle Dalvik. Pour les versions plus récentes d'Android, l'Android Runtime (ART) est utilisé.
Si les développeurs écrivent en Java et que le code est compilé en bytecode DEX, pour effectuer une rétro-ingénierie, nous travaillons dans la direction opposée.
Smali est la version lisible par l'homme du bytecode Dalvik. Techniquement, Smali et baksmali sont les noms des outils (assembleur et désassembleur, respectivement), mais en Android, nous utilisons souvent le terme "Smali" pour désigner les instructions. Si vous avez déjà fait de la rétro-ingénierie ou de l'architecture informatique sur du code C/C++ compilé, SMALI est comme le langage d'assemblage : entre le code source de plus haut niveau et le bytecode.
Les primes HackenProof ne sont lancées que lorsque leurs clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.
Les Intents sont le principal moyen de communication entre les applications Android et leurs composants ou avec d'autres applications. Ces objets de message peuvent également transporter des données entre les applications ou les composants, de manière similaire à l'utilisation des requêtes GET/POST dans les communications HTTP.
Ainsi, un Intent est essentiellement un message qui est transmis entre les composants. Les Intents peuvent être dirigés vers des composants ou des applications spécifiques, ou peuvent être envoyés sans destinataire spécifique.
Pour simplifier, un Intent peut être utilisé :
* Pour démarrer une activité, ouvrir généralement une interface utilisateur pour une application
* Comme des diffusions pour informer le système et les applications des changements
* Pour démarrer, arrêter et communiquer avec un service en arrière-plan
* Pour accéder aux données via des ContentProviders
* Comme des rappels pour gérer des événements
Une implémentation incorrecte peut entraîner une fuite de données, l'appel de fonctions restreintes et la manipulation du flux de programme.
Un filtre d'Intent spécifie les types d'Intent auxquels une activité, un service ou un récepteur de diffusion peut répondre. Il spécifie ce qu'une activité ou un service peut faire et les types de diffusions qu'un récepteur peut gérer. Il permet au composant correspondant de recevoir des Intents du type déclaré. Les filtres d'Intent sont généralement définis via le fichier AndroidManifest.xml. Pour un récepteur de diffusion, il est également possible de les définir dans le code. Un filtre d'Intent est défini par sa catégorie, ses actions et ses filtres de données. Il peut également contenir des métadonnées supplémentaires.
Dans Android, une activité/service/fournisseur de contenu/récepteur de diffusion est public lorsque l'attribut `exported` est défini sur `true`, mais un composant est également public si le manifeste spécifie un filtre d'Intent pour celui-ci. Cependant, les développeurs peuvent rendre explicitement les composants privés (indépendamment de tout filtre d'Intent) en définissant l'attribut `exported` sur `false` pour chaque composant dans le fichier manifeste. Les développeurs peuvent également définir l'attribut `permission` pour exiger une certaine autorisation d'accès au composant, limitant ainsi l'accès à celui-ci.
L'**Action** de l'intent précédemment déclaré est **ACTION\_SEND** et l'**Extra** est un **Uri** mailto (l'Extra est l'information supplémentaire que l'intent attend).
Le processus de "résolution de l'intention" détermine quelle application doit recevoir chaque message. Ce processus prend en compte l'attribut de priorité, qui peut être défini dans la déclaration de l'intent-filter, et celui avec la priorité la plus élevée sera sélectionné. Cette priorité peut être définie entre -1000 et 1000 et les applications peuvent utiliser la valeur `SYSTEM_HIGH_PRIORITY`. En cas de conflit, une fenêtre "choisir" apparaît pour que l'utilisateur puisse décider.
Celles-ci permettent à d'autres applications de **prendre des actions au nom de votre application**, en utilisant l'identité et les permissions de votre application. Pour construire une intention en attente, il faut **spécifier une intention et l'action à effectuer**. Si l'intention **déclarée n'est pas explicite** (ne déclare pas quelle intention peut l'appeler), une **application malveillante pourrait effectuer l'action déclarée** au nom de l'application victime. De plus, **si aucune action n'est spécifiée**, l'application malveillante pourra effectuer **n'importe quelle action au nom de la victime**.
Contrairement aux intentions précédentes, qui ne sont reçues que par une seule application, les intentions de diffusion **peuvent être reçues par plusieurs applications**. Cependant, à partir de la version API 14, il est **possible de spécifier l'application qui doit recevoir** le message en utilisant Intent.setPackage.
Il existe **deux types** de diffusions : **normales** (asynchrones) et **ordonnées** (synchrones). L'**ordre** est basé sur la **priorité configurée dans l'élément récepteur**. **Chaque application peut traiter, relayer ou supprimer la diffusion**.
Vous pouvez également utiliser la fonction **`sendBroadcast`** de **`LocalBroadCastManager`** qui garantit que le **message ne quitte jamais l'application**. En utilisant cela, vous n'aurez même pas besoin d'exporter un composant récepteur.
Si vous trouvez des fonctions contenant le mot "persistant" comme **`sendStickyBroadcast`** ou **`sendStickyBroadcastAsUser`**, **vérifiez l'impact et essayez de les supprimer**.
**Les liens profonds permettent de déclencher une intention via une URL**. Une application peut déclarer un **schéma d'URL** à l'intérieur d'une activité, de sorte que chaque fois que l'appareil Android essaie d'**accéder à une adresse en utilisant ce schéma**, l'activité de l'application sera appelée :
Cela signifiera qu'il attend une URL commençant par `example://gizmos`\
Dans ce cas, vous pouvez essayer d'exploiter la fonctionnalité en créant un site web avec les charges utiles suivantes. Cela essaiera de naviguer vers des pages arbitraires et d'exécuter du code JS :
Le **langage de définition d'interface Android** (AIDL) vous permet de définir l'interface de programmation sur laquelle le client et le service s'accordent pour **communiquer entre eux en utilisant une communication interprocessus** (IPC). Sur Android, **un processus ne peut normalement pas accéder à la mémoire d'un autre processus**. Ainsi, pour communiquer, ils doivent décomposer leurs objets en primitives que le **système d'exploitation** peut comprendre, et marquer les objets de part et d'autre de cette frontière pour vous. Le code pour effectuer cette marquage est fastidieux à écrire, c'est pourquoi Android le gère pour vous avec AIDL.
Les services utilisant AIDL sont appelés **services liés**. Dans la classe du service, vous trouverez la méthode **`onBind`**. C'est **ici que commence l'interaction**, c'est donc la première partie du code à examiner à la recherche de vulnérabilités potentielles.
Un service lié est le serveur dans une interface client-serveur. **Il permet aux composants (comme les activités) de se lier au service, d'envoyer des requêtes, de recevoir des réponses et d'effectuer une communication interprocessus** (IPC). Un service lié vit généralement seulement tant qu'il sert un autre composant d'application et ne s'exécute pas indéfiniment en arrière-plan.
Un Messenger est un autre type de mécanisme IPC. Étant donné que le **Messenger est également un "service lié"**, les données transmises depuis l'application cliente sont également traitées par la méthode `onBind`. Ainsi, l'examen du code devrait commencer par cette méthode et vous devriez rechercher l'invocation de fonctionnalités sensibles ou une manipulation non sécurisée des données.
Il est rare de trouver une classe Binder invoquée directement car il est beaucoup plus facile d'utiliser AIDL (qui abstrait la classe Binder). Cependant, il est bon de savoir que **Binder est un pilote de niveau noyau qui déplace les données de la mémoire d'un processus vers celle d'un autre** ([https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8)).
Une **activité Android** est un écran de l'interface utilisateur de l'application Android. De cette manière, une **activité Android** est très similaire aux fenêtres d'une application de bureau. Une application Android peut contenir une ou plusieurs activités, c'est-à-dire une ou plusieurs écrans.
L'**activité de lancement** est ce que la plupart des gens considèrent comme le **point d'entrée** d'une application Android. L'activité de lancement est l'activité qui est démarrée lorsque l'utilisateur clique sur l'icône d'une application. Vous pouvez déterminer l'activité de lancement en regardant le manifeste de l'application. L'activité de lancement aura les intentions MAIN et LAUNCHER suivantes répertoriées.
Gardez à l'esprit que toutes les applications n'auront pas une activité de lancement, en particulier les applications sans interface utilisateur. Des exemples d'applications sans interface utilisateur (et donc sans activité de lancement) sont les applications préinstallées qui fournissent des services en arrière-plan, tels que la messagerie vocale.
Les activités peuvent être exportées, ce qui permet à d'autres processus sur l'appareil de lancer l'activité. Par défaut, elles ne sont pas exportées, mais vous pouvez les exporter en définissant :
Notez que la capacité à contourner les protections d'activité n'est pas toujours une vulnérabilité, vous devez vérifier à quelles données vous avez accès.
De plus, certaines activités renvoient des données à l'appelant. Dans ces scénarios, vous devez rechercher la méthode `setResult` et vérifier les données qui sont transmises en paramètre de l'Intent. Si ce sont des données sensibles, vous pourriez avoir une vulnérabilité de fuite d'informations et elle peut être exploitée avec des applications capables de communiquer avec l'activité.
Les applications Android peuvent définir une sous-classe de [Application](https://developer.android.com/reference/android/app/Application). Les applications peuvent, mais n'ont pas besoin de définir une sous-classe personnalisée de Application. Si une application Android définit une sous-classe de Application, cette classe est instanciée avant toute autre classe de l'application.
[Les services](https://developer.android.com/guide/components/services) s'exécutent en arrière-plan sans interface utilisateur. Ils sont utilisés pour effectuer des processus longs, même si l'utilisateur commence à utiliser une autre application.
Il existe une multitude de façons de les démarrer et ils constituent donc un point d'entrée pour les applications. La façon par défaut de démarrer un service en tant que point d'entrée d'une application est par le biais d'Intents.
Lorsque la méthode `startService` est appelée pour démarrer un service, la méthode `onStart` dans le service est exécutée. Elle s'exécutera indéfiniment jusqu'à ce que la méthode `stopService` soit appelée. Si le service n'est nécessaire que tant que le client est connecté, le client doit s'y "lier" en utilisant la méthode `bindService`.
Par exemple, un service peut jouer de la musique en arrière-plan pendant que l'utilisateur se trouve dans une autre application, ou il peut récupérer des données via le réseau sans bloquer l'interaction de l'utilisateur avec une activité.
Un service peut être exporté, ce qui permet à d'autres processus sur l'appareil de démarrer le service. Par défaut, les services ne sont pas exportés, mais cela peut être configuré dans le Manifeste :
Les diffusions peuvent être considérées comme un système de messagerie et les récepteurs de diffusion sont les auditeurs. Si une application a enregistré un récepteur pour une diffusion spécifique, le code de ce récepteur est exécuté lorsque le système envoie la diffusion. Notez que dans ce cas, plusieurs applications peuvent recevoir le même message.
Il existe 2 façons pour une application de s'enregistrer en tant que récepteur : dans le manifeste de l'application ou enregistré dynamiquement dans le code de l'application en utilisant l'appel d'API `registerReceiver`. Dans le manifeste, vous pouvez limiter les diffusions que vous acceptez en utilisant des autorisations dans l'élément récepteur. Lorsqu'il est défini dynamiquement, vous pouvez transmettre l'autorisation à la méthode `registerReceiver`.
Dans les deux cas, pour enregistrer le récepteur, les filtres d'intention pour le récepteur sont définis. Ces filtres d'intention sont les diffusions qui doivent déclencher le récepteur.
Lorsque les diffusions spécifiques pour lesquelles le récepteur est enregistré sont envoyées, la méthode `onReceive` de la classe BroadcastReceiver est exécutée.
Une application peut par exemple s'enregistrer en tant que récepteur pour le message de batterie faible et modifier son comportement en fonction de cette information.
La diffusion peut être asynchrone (chaque récepteur la reçoit) ou synchrone (la diffusion est reçue de manière ordonnée en fonction de la priorité définie pour la recevoir).
Pour examiner le code implémenté dans un récepteur de diffusion, vous devez rechercher la méthode `onReceive` de la classe du récepteur. Notez que les diffusions ordonnées peuvent supprimer l'intention reçue ou même la modifier en utilisant l'une des méthodes setter. Par conséquent, les récepteurs doivent valider les données.
Les fournisseurs de contenu sont la façon dont les applications partagent des données structurées, telles que des bases de données relationnelles. Il est donc très important d'utiliser des autorisations et de définir le niveau de protection approprié pour les protéger. Les fournisseurs de contenu peuvent utiliser les attributs `readPermission` et `writePermission` pour spécifier les autorisations qu'une application doit avoir. Ces autorisations ont la priorité sur l'attribut d'autorisation. De plus, ils peuvent également autoriser des exceptions temporaires en définissant `grantUriPermission` sur true, puis en configurant les paramètres appropriés dans l'élément `grant-uri-permission` à l'intérieur de l'élément fournisseur du fichier manifeste.
- Le composant fournisseur de contenu fournit des données d'une application à d'autres sur demande.
- Vous pouvez stocker les données dans le système de fichiers, une base de données SQLite, sur le web ou tout autre emplacement de stockage persistant accessible par votre application.
- Grâce au fournisseur de contenu, d'autres applications peuvent interroger ou même modifier les données (si le fournisseur de contenu le permet).
- Le fournisseur de contenu est utile dans les cas où une application souhaite partager des données avec une autre application.
Il s'agit d'un type de fournisseur de contenu qui permet de partager des fichiers à partir d'un dossier. Vous pouvez déclarer un fournisseur de fichiers de la manière suivante :
Notez que la configuration `android:resource="@xml/filepaths"` indique que le fichier _res/xml/filepaths.xml_ contient la configuration des **dossiers** que ce **FileProvider** va **partager**. Voici un exemple de comment indiquer le partage d'un dossier dans ce fichier :
Partager quelque chose comme **`path="."`** pourrait être **dangereux** même si le fournisseur n'est pas exporté s'il existe une autre vulnérabilité dans une partie du code qui tente d'accéder à ce fournisseur.\
L'élément `<paths>` peut avoir plusieurs enfants, chacun spécifiant un répertoire différent à partager. En plus de l'élément **`<files-path>`**, vous pouvez utiliser l'élément **`<external-path>`** pour partager des répertoires dans le **stockage externe**, et l'élément **`<cache-path>`** pour partager des répertoires dans votre **répertoire de cache interne**.\
[Pour plus d'informations sur les attributs spécifiques des fournisseurs de fichiers, consultez ici.](https://developer.android.com/reference/androidx/core/content/FileProvider)
Les WebViews sont en fait des **navigateurs Web** intégrés aux applications Android.\
Le contenu des WebViews peut être extrait de sites distants ou peut être des fichiers inclus dans l'application.\
Les WebViews sont **vulnérables aux mêmes vulnérabilités affectant tous les navigateurs Web**. Cependant, il existe certaines **configurations** qui peuvent être utiles pour **limiter** la **surface d'attaque**.
* Le **WebViewClient**, le mieux adapté pour le rendu simple du HTML. Cela n'exécutera pas la fonction d'alerte JS. Ainsi, les tests XSS utilisant cette fonction seront invalides.
* Le **client WebChrome**, qui est un navigateur Chrome.
Pour charger une URL ou un fichier, il est possible d'utiliser les fonctions **`loadUrl`**, **`loadData`** ou **`loadDataWithBaseURL`**. **Il est important d'accéder uniquement aux URL sanitaires.**\
La sécurité des WebView peut être configurée via l'objet **`WebSettings`**.\
Par exemple, l'exécution du code JS peut être désactivée en utilisant la méthode **`setJavaScriptEnabled`** avec la valeur **`false`**. Cela **supprimera** la possibilité d'une **XSS** et d'autres vulnérabilités liées à JS.
La fonctionnalité JavaScript "**Bridge**" **injecte des objets Java dans un WebView les rendant accessibles à JS**. À partir d'Android 4.2, les méthodes doivent être annotées avec **`@JavascriptInterface`** pour être accessibles à JavaScript.
Si **`true`** est passé à **`setAllowContentAccess`**, les WebViews pourront accéder aux fournisseurs de contenu via le schéma **`content://`**. Cela pose évidemment un risque pour la sécurité. Notez que si cet accès est accordé, il est très important de **s'assurer** que l'URL **`content://`** est **sûre**.
Par défaut, les fichiers locaux peuvent être accessibles par les WebViews via les URL file://, mais il existe plusieurs façons d'empêcher ce comportement :
* Passer **`false`** à **`setAllowFileAccess`** empêche l'accès au système de fichiers à l'exception des ressources via `file:///android_asset`_et_`file:///android_res`. Ces chemins ne doivent être utilisés que pour des données non sensibles (comme des images), donc cela devrait être sûr.
* La méthode **`setAllowFileAccess`** indique si un chemin à partir d'une URL `file://` doit pouvoir accéder au contenu d'autres URL de schéma de fichier.
* La méthode **`setAllowUniversalAccessFromFileURLs`** indique si un chemin à partir d'une URL `file://` doit pouvoir accéder au contenu de n'importe quelle origine.
* Android exige que **toutes les applications soient signées numériquement avec un certificat** avant de pouvoir être installées. Android utilise ce certificat pour identifier l'auteur d'une application.
* Pour exécuter une application sur l'appareil, elle doit être signée. Lorsqu'une application est installée sur un appareil, le **gestionnaire de packages vérifie** si l'application a été correctement signée avec le certificat du fichier APK ou non.
* Une application peut être auto-signée ou signée par une autorité de certification (CA).
* La signature de l'application garantit qu'une application ne peut pas accéder à une autre application sauf par le biais d'IPC bien définis et qu'elle est transmise sans modification à l'appareil.
* Android 4.2 et versions ultérieures prennent en charge la vérification d'application. Les utilisateurs peuvent choisir d'activer la fonction "Vérifier les applications" et faire évaluer les applications par un vérificateur d'applications avant l'installation.
* La vérification de l'application peut avertir l'utilisateur s'il essaie d'installer une application potentiellement dangereuse ; si une application est particulièrement mauvaise, elle peut bloquer l'installation.
MDM ou Mobile Device Management sont des suites logicielles utilisées pour **assurer un contrôle et des exigences de sécurité** sur les appareils mobiles. Ces suites utilisent les fonctionnalités appelées API d'administration de périphérique et nécessitent l'installation d'une application Android.
Généralement, les solutions MDM effectuent des fonctions telles que l'application de politiques de mot de passe, le chiffrement forcé du stockage et la possibilité d'effacer à distance les données de l'appareil.
Les primes HackenProof ne sont lancées que lorsque leurs clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bogue.
* Vous travaillez dans une **entreprise de cybersécurité** ? Vous souhaitez voir votre **entreprise annoncée dans HackTricks** ? ou souhaitez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
