<summary><strong>Lernen Sie das Hacken von AWS von Grund auf mit</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegramm-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositories senden.
Finden Sie die wichtigsten Sicherheitslücken, damit Sie sie schneller beheben können. Intruder verfolgt Ihre Angriffsfläche, führt proaktive Bedrohungsscans durch und findet Probleme in Ihrer gesamten Technologie-Stack, von APIs über Webanwendungen bis hin zu Cloud-Systemen. [**Probieren Sie es noch heute kostenlos aus**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks).
**Jede Anwendung erhält eine bestimmte Benutzer-ID**. Dies geschieht während der Installation der App, damit die App nur mit Dateien interagieren kann, die ihrer Benutzer-ID gehören oder gemeinsam genutzte Dateien. Daher können nur die App selbst, bestimmte Komponenten des Betriebssystems und der Root-Benutzer auf die App-Daten zugreifen.
**Zwei Anwendungen können so konfiguriert werden, dass sie dieselbe UID verwenden**. Dies kann nützlich sein, um Informationen zu teilen, aber wenn eine davon kompromittiert ist, werden die Daten beider Anwendungen kompromittiert. Aus diesem Grund wird dieses Verhalten **nicht empfohlen**.\
**Um dieselbe UID zu teilen, müssen Anwendungen denselben `android:sharedUserId`-Wert in ihren Manifesten definieren.**
Die **Android Application Sandbox** ermöglicht das Ausführen **jeder Anwendung** als **eigenständiger Prozess unter einer separaten Benutzer-ID**. Jeder Prozess hat seine eigene virtuelle Maschine, sodass der Code einer App isoliert von anderen Apps ausgeführt wird.\
Ab Android 5.0(L) wird **SELinux** durchgesetzt. Grundsätzlich verweigert SELinux alle Prozessinteraktionen und erstellt dann Richtlinien, um **nur die erwarteten Interaktionen zwischen ihnen zuzulassen**.
Wenn Sie eine **App installieren und sie um Berechtigungen bitten**, fragt die App nach den in den **`uses-permission`**-Elementen in der **AndroidManifest.xml**-Datei konfigurierten Berechtigungen. Das **uses-permission**-Element gibt den Namen der angeforderten Berechtigung im **name**-Attribut an. Es hat auch das **maxSdkVersion**-Attribut, das das Bitten um Berechtigungen in Versionen höher als der angegebenen stoppt.\
Beachten Sie, dass Android-Anwendungen nicht alle Berechtigungen von Anfang an beantragen müssen, sie können auch **dynamisch Berechtigungen beantragen**, aber alle Berechtigungen müssen im Manifest **deklariert** sein.
* Das **permission-group**-Attribut, das das Gruppieren verwandter Berechtigungen ermöglicht.
* Das **protection-level**, das angibt, wie die Berechtigungen gewährt werden. Es gibt vier Arten:
* **Normal**: Wird verwendet, wenn für die App **keine bekannten Bedrohungen** bestehen. Der Benutzer muss sie **nicht genehmigen**.
* **Gefährlich**: Gibt an, dass die Berechtigung der anfordernden Anwendung einen **erhöhten Zugriff** gewährt. **Benutzer werden aufgefordert, sie zu genehmigen**.
* **Signature**: Nur **Apps, die mit demselben Zertifikat wie das exportierende** Komponente signiert sind, können Berechtigungen erhalten. Dies ist die stärkste Art des Schutzes.
* **SignatureOrSystem**: Nur **Apps, die mit demselben Zertifikat wie das exportierende** Komponente signiert sind oder **Apps, die mit Systemzugriff ausgeführt werden**, können Berechtigungen erhalten.
Diese Apps befinden sich in der Regel in den Verzeichnissen **`/system/app`** oder **`/system/priv-app`** und einige von ihnen sind **optimiert** (möglicherweise finden Sie nicht einmal die Datei `classes.dex`). Diese Anwendungen sind es wert, überprüft zu werden, da sie manchmal mit zu vielen Berechtigungen (als Root) ausgeführt werden.
Um Root-Zugriff auf ein physisches Android-Gerät zu erhalten, müssen Sie in der Regel 1 oder 2 **Schwachstellen ausnutzen**, die normalerweise **spezifisch** für das **Gerät** und die **Version** sind.\
Sobald der Exploit funktioniert hat, wird normalerweise das Linux `su`-Binär in einen Ort kopiert, der in der PATH-Umgebungsvariable des Benutzers angegeben ist, z. B. `/system/xbin`.
Sobald das su-Binär konfiguriert ist, wird eine andere Android-App verwendet, um mit dem `su`-Binär zu kommunizieren und **Anfragen für Root-Zugriff zu verarbeiten**, wie z. B. **Superuser** und **SuperSU** (im Google Play Store erhältlich).
Es ist möglich, das Betriebssystem durch Installation einer benutzerdefinierten Firmware zu **ersetzen**. Dadurch kann die Nützlichkeit eines alten Geräts erweitert, Softwarebeschränkungen umgangen oder Zugriff auf den neuesten Android-Code erhalten werden.\
**OmniROM** und **LineageOS** sind zwei der beliebtesten Firmware-Versionen.
Beachten Sie, dass **nicht immer eine Root-Berechtigung erforderlich ist**, um eine benutzerdefinierte Firmware zu installieren. **Einige Hersteller erlauben** das Entsperren ihrer Bootloader auf dokumentierte und sichere Weise.
### Auswirkungen
Sobald ein Gerät gerootet ist, kann jede App Zugriff als Root anfordern. Wenn eine bösartige Anwendung dies erhält, hat sie Zugriff auf fast alles und kann das Telefon beschädigen.
## Grundlagen von Android-Anwendungen <a href="#2-android-application-fundamentals" id="2-android-application-fundamentals"></a>
- Das Format von Android-Anwendungen wird als _APK-Dateiformat_ bezeichnet. Es handelt sich im Wesentlichen um eine **ZIP-Datei** (durch Umbenennen der Dateierweiterung in .zip können die Inhalte extrahiert und angezeigt werden).
In der Android-Entwicklung werden **Java oder Kotlin** zur Erstellung von Apps verwendet. Anstelle des JVM wie bei Desktop-Apps kompiliert Android diesen Code in **Dalvik Executable (DEX) Bytecode**. Früher wurde dies vom Dalvik-Virtual-Machine-Bytecode behandelt, aber jetzt übernimmt die Android Runtime (ART) in neueren Android-Versionen.
Für Reverse Engineering wird **Smali** entscheidend. Es ist die menschenlesbare Version des DEX-Bytecodes und fungiert wie eine Assemblersprache, indem es den Quellcode in Bytecode-Anweisungen übersetzt. Smali und baksmali beziehen sich in diesem Zusammenhang auf die Assembly- und Disassembly-Tools.
Finden Sie die wichtigsten Schwachstellen, damit Sie sie schneller beheben können. Intruder verfolgt Ihre Angriffsfläche, führt proaktive Bedrohungsscans durch und findet Probleme in Ihrer gesamten Technologie-Stack, von APIs über Web-Apps bis hin zu Cloud-Systemen. [**Probieren Sie es noch heute kostenlos aus**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks).
Intents sind das Hauptmittel, mit dem Android-Apps zwischen ihren Komponenten oder mit anderen Apps kommunizieren. Diese Nachrichtenobjekte können auch Daten zwischen Apps oder Komponenten transportieren, ähnlich wie GET/POST-Anfragen in der HTTP-Kommunikation verwendet werden.
Ein Intent ist also eine **Nachricht, die zwischen Komponenten übermittelt wird**. Intents **können an bestimmte Komponenten oder Apps gerichtet werden**, **oder ohne einen bestimmten Empfänger gesendet werden**.\
Um es einfach auszudrücken, kann ein Intent verwendet werden:
**Intent-Filter** definieren **wie eine Aktivität, ein Dienst oder ein Broadcast Receiver mit verschiedenen Arten von Intents interagieren kann**. Sie beschreiben im Wesentlichen die Fähigkeiten dieser Komponenten, wie z.B. welche Aktionen sie ausführen können oder welche Arten von Broadcasts sie verarbeiten können. Der primäre Ort, um diese Filter zu deklarieren, ist die **AndroidManifest.xml-Datei**, obwohl sie auch für Broadcast Receiver codiert werden können.
Intent-Filter bestehen aus Kategorien, Aktionen und Datenfiltern, mit der Möglichkeit, zusätzliche Metadaten einzuschließen. Diese Einrichtung ermöglicht es Komponenten, spezifische Intents zu verarbeiten, die den deklarierten Kriterien entsprechen.
Ein wesentlicher Aspekt von Android-Komponenten (Aktivitäten/Dienste/Content Provider/Broadcast Receiver) ist ihre Sichtbarkeit oder **öffentlicher Status**. Eine Komponente gilt als öffentlich und kann mit anderen Apps interagieren, wenn sie mit einem Wert von **`true`** als **`exported`** markiert ist oder wenn für sie ein Intent-Filter im Manifest deklariert ist. Es gibt jedoch eine Möglichkeit für Entwickler, diese Komponenten explizit privat zu halten, um sicherzustellen, dass sie nicht unbeabsichtigt mit anderen Apps interagieren. Dies wird erreicht, indem das Attribut **`exported`** in ihren Manifestdefinitionen auf **`false`** gesetzt wird.
Darüber hinaus haben Entwickler die Möglichkeit, den Zugriff auf diese Komponenten weiter abzusichern, indem sie bestimmte Berechtigungen verlangen. Das Attribut **`permission`** kann festgelegt werden, um durchzusetzen, dass nur Apps mit der festgelegten Berechtigung auf die Komponente zugreifen können. Dadurch wird eine zusätzliche Sicherheitsebene und Kontrolle darüber hinzugefügt, wer mit ihr interagieren kann.
Die **Aktion** des zuvor deklarierten Intents ist **ACTION\_SEND** und das **Extra** ist eine mailto-**Uri** (das Extra ist die zusätzliche Information, die der Intent erwartet).
Der "Intent-Auflösungsprozess" bestimmt, welche App jede Nachricht erhalten soll. Dieser Prozess berücksichtigt das **Prioritätsattribut**, das in der **Intent-Filter-Deklaration** festgelegt werden kann, und **diejenige mit der höheren Priorität wird ausgewählt**. Diese Priorität kann zwischen -1000 und 1000 festgelegt werden und Anwendungen können den Wert `SYSTEM_HIGH_PRIORITY` verwenden. Wenn ein **Konflikt** auftritt, erscheint ein "Chooser"-Fenster, damit der **Benutzer entscheiden kann**.
Diese ermöglichen es anderen Anwendungen, im Namen Ihrer Anwendung Aktionen auszuführen, unter Verwendung der Identität und Berechtigungen Ihrer App. Beim Erstellen einer ausstehenden Absicht muss eine Absicht und die auszuführende Aktion angegeben werden. Wenn die deklarierte Absicht nicht explizit ist (nicht angibt, welche Absicht sie aufrufen kann), kann eine bösartige Anwendung die deklarierte Aktion im Namen der Opfer-App ausführen. Darüber hinaus, wenn keine Aktion angegeben ist, kann die bösartige App beliebige Aktionen im Namen des Opfers ausführen.
Im Gegensatz zu den vorherigen Absichten, die nur von einer App empfangen werden, können Broadcast-Absichten von mehreren Apps empfangen werden. Ab API-Version 14 ist es möglich, die App anzugeben, die die Nachricht erhalten soll, indem Intent.setPackage verwendet wird.
Es gibt zwei Arten von Broadcasts: Normal (asynchron) und Ordered (synchron). Die Reihenfolge basiert auf der konfigurierten Priorität innerhalb des Empfängerelements. Jede App kann den Broadcast verarbeiten, weiterleiten oder verwerfen.
Es ist möglich, einen Broadcast mithilfe der Funktion `sendBroadcast(intent, receiverPermission)` aus der Klasse `Context` zu senden. Sie können auch die Funktion `sendBroadcast` aus dem `LocalBroadCastManager` verwenden, um sicherzustellen, dass die Nachricht die App nie verlässt. Dadurch müssen Sie nicht einmal einen Empfänger exportieren.
Diese Art von Broadcasts kann lange nach dem Senden darauf zugegriffen werden. Sie wurden in der API-Ebene 21 veraltet und es wird empfohlen, sie nicht zu verwenden. Sie ermöglichen es jeder Anwendung, die Daten abzufangen, aber auch zu ändern.
Wenn Sie Funktionen finden, die das Wort "sticky" enthalten, wie `sendStickyBroadcast` oder `sendStickyBroadcastAsUser`, überprüfen Sie die Auswirkungen und versuchen Sie, sie zu entfernen.
In Android-Anwendungen werden Deep Links verwendet, um eine Aktion (Intent) direkt über eine URL zu initiieren. Dies geschieht durch Deklarieren eines spezifischen URL-Schemas innerhalb einer Aktivität. Wenn ein Android-Gerät versucht, auf eine URL mit diesem Schema zuzugreifen, wird die angegebene Aktivität innerhalb der Anwendung gestartet.
Um den **Code, der in der App ausgeführt wird**, zu finden, gehe zur Aktivität, die durch den Deeplink aufgerufen wird, und suche nach der Funktion **`onNewIntent`**.
Die **Android Interface Definition Language (AIDL)** wurde entwickelt, um die Kommunikation zwischen Client und Service in Android-Anwendungen durch **Interprozesskommunikation** (IPC) zu erleichtern. Da der direkte Zugriff auf den Speicher eines anderen Prozesses auf Android nicht erlaubt ist, vereinfacht AIDL den Prozess, indem es Objekte in ein vom Betriebssystem verstandenes Format umwandelt und so die Kommunikation zwischen verschiedenen Prozessen erleichtert.
- **Bound Services**: Diese Services nutzen AIDL für IPC und ermöglichen es Aktivitäten oder Komponenten, sich an einen Service zu binden, Anfragen zu stellen und Antworten zu erhalten. Die Methode `onBind` in der Klasse des Services ist entscheidend für die Initiierung der Interaktion und stellt daher einen wichtigen Bereich für die Sicherheitsüberprüfung auf Schwachstellen dar.
- **Messenger**: Als gebundener Service ermöglicht Messenger IPC mit dem Schwerpunkt auf der Verarbeitung von Daten durch die `onBind`-Methode. Es ist wichtig, diese Methode genau auf unsichere Datenverarbeitung oder die Ausführung sensibler Funktionen zu überprüfen.
- **Binder**: Obwohl die direkte Verwendung der Binder-Klasse aufgrund der Abstraktion von AIDL weniger häufig vorkommt, ist es hilfreich zu verstehen, dass Binder als Kernel-Treiber fungiert, der den Datentransfer zwischen den Speicherbereichen verschiedener Prozesse ermöglicht. Für ein besseres Verständnis steht eine Ressource unter [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8) zur Verfügung.
In Android-Apps sind **Aktivitäten** wie Bildschirme, die verschiedene Teile der Benutzeroberfläche der App anzeigen. Eine App kann viele Aktivitäten haben, von denen jede einen einzigartigen Bildschirm für den Benutzer darstellt.
Die **Launcher-Aktivität** ist das Haupttor zu einer App und wird gestartet, wenn Sie auf das Symbol der App tippen. Sie wird in der Manifestdatei der App mit spezifischen MAIN- und LAUNCHER-Intents definiert:
Aktivitäten können für andere Apps oder Prozesse verfügbar gemacht werden, indem sie im Manifest als "exportiert" markiert werden. Diese Einstellung ermöglicht es anderen Apps, diese Aktivität zu starten:
Jedoch ist der Zugriff auf eine Aktivität von einer anderen App nicht immer ein Sicherheitsrisiko. Die Bedenken entstehen, wenn sensible Daten unsachgemäß geteilt werden, was zu Informationslecks führen könnte.
Der Lebenszyklus einer Aktivität **beginnt mit der onCreate-Methode**, die die Benutzeroberfläche einrichtet und die Aktivität auf die Interaktion mit dem Benutzer vorbereitet.
Bei der Android-Entwicklung hat eine App die Möglichkeit, eine **Unterklasse** der [Application](https://developer.android.com/reference/android/app/Application)-Klasse zu erstellen, obwohl dies nicht obligatorisch ist. Wenn eine solche Unterklasse definiert ist, wird sie als erste Klasse innerhalb der App instanziiert. Die Methode **`attachBaseContext`**, wenn sie in dieser Unterklasse implementiert ist, wird vor der **`onCreate`**-Methode ausgeführt. Diese Einrichtung ermöglicht eine frühe Initialisierung, bevor der Rest der Anwendung startet.
[Dienste](https://developer.android.com/guide/components/services) sind **Hintergrundoperationen**, die in der Lage sind, Aufgaben ohne Benutzeroberfläche auszuführen. Diese Aufgaben können auch dann weiterlaufen, wenn Benutzer zu anderen Anwendungen wechseln, wodurch Dienste für **lang andauernde Operationen** unerlässlich sind.
Dienste sind vielseitig einsetzbar; sie können auf verschiedene Arten gestartet werden, wobei **Intents** die primäre Methode zum Starten als Einstiegspunkt einer Anwendung sind. Sobald ein Dienst mit der Methode `startService` gestartet wird, wird seine Methode `onStart` aktiviert und läuft weiter, bis die Methode `stopService` explizit aufgerufen wird. Alternativ, wenn die Rolle eines Dienstes von einer aktiven Client-Verbindung abhängt, wird die Methode `bindService` verwendet, um den Client an den Dienst zu binden und die Methode `onBind` für den Datenaustausch zu nutzen.
Eine interessante Anwendung von Diensten umfasst das Abspielen von Hintergrundmusik oder das Abrufen von Netzwerkdaten, ohne die Interaktion des Benutzers mit einer App zu beeinträchtigen. Darüber hinaus können Dienste für andere Prozesse auf demselben Gerät über **Exportieren** zugänglich gemacht werden. Dies ist nicht das Standardverhalten und erfordert eine explizite Konfiguration in der Android Manifest-Datei:
**Broadcast Receiver** fungieren als Zuhörer in einem Messaging-System und ermöglichen es mehreren Anwendungen, auf dieselben Nachrichten vom System zu reagieren. Eine App kann einen Empfänger auf zwei Hauptarten **registrieren**: über das **Manifest** der App oder **dynamisch** im Code der App über die **`registerReceiver`** API. Im Manifest werden Broadcasts mit Berechtigungen gefiltert, während bei dynamisch registrierten Empfängern Berechtigungen auch bei der Registrierung angegeben werden können.
**Intent-Filter** sind in beiden Registrierungsmethoden entscheidend und bestimmen, welche Broadcasts den Empfänger auslösen. Sobald ein passender Broadcast gesendet wird, wird die Methode **`onReceive`** des Empfängers aufgerufen, sodass die App entsprechend reagieren kann, z. B. das Verhalten anpassen, um auf eine niedrige Akkuanzeige zu reagieren.
Broadcasts können entweder **asynchron** sein und alle Empfänger ohne Reihenfolge erreichen oder **synchron**, bei denen Empfänger den Broadcast basierend auf festgelegten Prioritäten erhalten. Es ist jedoch wichtig zu beachten, dass hier ein potenzielles Sicherheitsrisiko besteht, da jede App sich selbst priorisieren kann, um einen Broadcast abzufangen.
Um die Funktionalität eines Empfängers zu verstehen, suchen Sie nach der Methode **`onReceive`** innerhalb seiner Klasse. Der Code dieser Methode kann das empfangene Intent manipulieren, was die Notwendigkeit der Datenvalidierung durch Empfänger hervorhebt, insbesondere bei **geordneten Broadcasts**, die das Intent ändern oder verwerfen können.
**Content Provider** sind für das **Teilen strukturierter Daten** zwischen Apps unerlässlich und betonen die Bedeutung der Implementierung von **Berechtigungen**, um die Datensicherheit zu gewährleisten. Sie ermöglichen Apps den Zugriff auf Daten aus verschiedenen Quellen, einschließlich Datenbanken, Dateisystemen oder dem Web. Spezifische Berechtigungen wie **`readPermission`** und **`writePermission`** sind entscheidend für die Kontrolle des Zugriffs. Darüber hinaus kann über die Einstellungen **`grantUriPermission`** im Manifest der App ein temporärer Zugriff gewährt werden, wobei Attribute wie `path`, `pathPrefix` und `pathPattern` für eine detaillierte Zugriffskontrolle genutzt werden.
Die Eingabevalidierung ist entscheidend, um Sicherheitslücken wie SQL-Injection zu verhindern. Content Provider unterstützen grundlegende Operationen wie `insert()`, `update()`, `delete()` und `query()`, die die Manipulation und den Austausch von Daten zwischen Anwendungen erleichtern.
**FileProvider**, ein spezialisierter Content Provider, konzentriert sich auf das sichere Teilen von Dateien. Er wird im Manifest der App mit spezifischen Attributen definiert, um den Zugriff auf Ordner zu kontrollieren, die durch `android:exported` und `android:resource` auf Ordnerkonfigurationen verweisen. Es wird empfohlen, Vorsicht walten zu lassen, wenn Verzeichnisse freigegeben werden, um versehentlich sensible Daten preiszugeben.
WebViews sind wie **Mini-Webbrowser** innerhalb von Android-Apps, die Inhalte entweder aus dem Web oder aus lokalen Dateien abrufen. Sie sind ähnlichen Risiken wie reguläre Browser ausgesetzt, aber es gibt Möglichkeiten, diese Risiken durch spezifische **Einstellungen** zu **minimieren**.
- **WebViewClient** ist gut für grundlegendes HTML, unterstützt jedoch nicht die JavaScript-Alert-Funktion, was sich darauf auswirkt, wie XSS-Angriffe getestet werden können.
- **WebChromeClient** verhält sich eher wie die vollständige Chrome-Browser-Erfahrung.
Für das Laden von Inhalten stehen Methoden wie ````loadUrl````, ````loadData````, und ````loadDataWithBaseURL```` zur Verfügung. Es ist entscheidend sicherzustellen, dass diese URLs oder Dateien **sicher verwendet** werden können. Sicherheitseinstellungen können über die Klasse ````WebSettings```` verwaltet werden. Zum Beispiel kann das Deaktivieren von JavaScript mit ````setJavaScriptEnabled(false)```` XSS-Angriffe verhindern.
Die JavaScript-"Bridge" ermöglicht es Java-Objekten, mit JavaScript zu interagieren. Ab Android 4.2 müssen Methoden mit ````@JavascriptInterface```` markiert werden, um die Sicherheit zu gewährleisten.
Das Zulassen des Zugriffs auf Inhalte (````setAllowContentAccess(true)````) ermöglicht es WebViews, auf Content Provider zuzugreifen, was ein Risiko darstellen kann, es sei denn, die Inhalts-URLs werden als sicher überprüft.
- Das Deaktivieren des Dateizugriffs (````setAllowFileAccess(false)````) beschränkt den Zugriff auf das Dateisystem, mit Ausnahmen für bestimmte Ressourcen, um sicherzustellen, dass sie nur für nicht sensible Inhalte verwendet werden.
- Die **digitale Signierung** ist ein Muss für Android-Apps, um sicherzustellen, dass sie vor der Installation **authentisch erstellt** wurden. Dieser Prozess verwendet ein Zertifikat zur App-Identifizierung und muss vom Paketmanager des Geräts bei der Installation überprüft werden. Apps können **selbst signiert oder von einer externen Zertifizierungsstelle zertifiziert** sein, um unbefugten Zugriff zu verhindern und sicherzustellen, dass die App während der Auslieferung an das Gerät nicht manipuliert wurde.
- Ab **Android 4.2** ermöglicht eine Funktion namens **Verify Apps** Benutzern, Apps vor der Installation auf Sicherheit zu überprüfen. Dieser **Verifizierungsprozess** kann Benutzer vor potenziell schädlichen Apps warnen oder sogar die Installation besonders bösartiger Apps verhindern und die Sicherheit der Benutzer erhöhen.
- **MDM-Lösungen** bieten Überwachung und Sicherheit für mobile Geräte über die **Device Administration API**. Sie erfordern die Installation einer Android-App, um mobile Geräte effektiv zu verwalten und zu sichern. Zu den wichtigsten Funktionen gehören die **Durchsetzung von Passwortrichtlinien**, die **Verpflichtung zur Speicherung von Verschlüsselung** und die **Ermöglichung des Remote-Datenlöschens**, um umfassende Kontrolle und Sicherheit über mobile Geräte zu gewährleisten.
Finden Sie die wichtigsten Sicherheitslücken, damit Sie sie schneller beheben können. Intruder verfolgt Ihre Angriffsfläche, führt proaktive Bedrohungsscans durch und findet Probleme in Ihrer gesamten Technologie-Stack, von APIs über Webanwendungen bis hin zu Cloud-Systemen. [**Probieren Sie es noch heute kostenlos aus**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks).
<summary><strong>Lernen Sie AWS-Hacking von Null auf Held mit</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Wenn Sie Ihr **Unternehmen in HackTricks bewerben möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories senden.
