Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Android Security AutoRepro
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Das AutoRepro Gradle-Plug-in basiert auf dem Android Trade Federation-Test-Harness, um alle Android-Geräte auf Sicherheitslücken im Android-Sicherheitsbulletin zu testen. Diese Tests sind ausschließlich für Fehlerkorrekturen vorgesehen, die mit einer Common Vulnerabilities and Exposures (CVE) verknüpft sind oder verknüpft werden.

Mit dem Plug-in können Tradefed-Tests außerhalb des Android-Quellbaums mit Android Studio oder dem standardmäßigen Android SDK entwickelt werden. Es enthält alle Dienstprogramme, die zum Erstellen und Ausführen eines Tradefed-Tests erforderlich sind.

Sie wird hauptsächlich verwendet, um automatisch reproduzierbare Proof-of-Concepts für das Vulnerability Reward Program für Android einzureichen.

Beispiel für AutoRepro herunterladen

Voraussetzungen

Die Anleitung gilt für einen 64-Bit-Linux-PC.

Android Studio Ladybug oder höher: Kann auch über den Paketmanager Ihrer Distribution installiert werden.
Android SDK-Plattformtools (adb, fastboot): Müssen installiert und sich in $PATH befinden. Sie sollten adb also über die Befehlszeile ausführen können. Am einfachsten installieren Sie die Plattformtools über den Paketmanager Ihrer Distribution.
- Wenn Sie den SDK-Manager von Android Studio anstelle von eigenständigen Plattformtools verwenden, müssen Sie das platform-tools-Verzeichnis des SDK zu Ihrem $PATH für die Befehlszeilenentwicklung hinzufügen.
AAPT2. – Kann auch mit dem Paketmanager Ihrer Distribution installiert werden.
Java JDK 21 oder höher – kompatibel mit dem Android SDK und Gradle

Erste Schritte mit Android Studio

Nachdem Sie das Beispiel oder die Vorlage extrahiert haben, öffnen Sie das Verzeichnis in Android Studio als vorhandenes Projekt und warten Sie, bis die Gradle-Synchronisierung abgeschlossen ist. Es gibt mehrere vorkonfigurierte Android Studio-Ausführungskonfigurationen.

Gradle-Aufgaben:

assembleSubmissionSources – Quelldateien für die ZIP-Datei zur Einreichung zusammenstellen
assembleSubmissionZip – ZIP-Datei für den Upload zusammenstellen.
copyInvocationResultsToSubmission: Kopieren Sie die Ergebnisse aus früheren Tradefed-Aufrufen in das Verzeichnis mit den AutoRepro-Einreichungsquellen, um den Überprüfungsprozess zu unterstützen. Hinweis: Diese Datei enthält Protokolle sowohl vom Host als auch vom Gerät. Prüfen Sie den Inhalt vor oder nach dem Ausführen.

AutoRepro-Aufruf – Android Studio-Ausführungskonfigurationen:

autorepro_nonroot_arm64
autorepro_nonroot_x86_64
autorepro_root_arm64
autorepro_root_x86_64

Die Launcher-Konfigurationen haben das Format autorepro_{device_root}_{device_arch}. Es ist im Allgemeinen besser, keine Root-Berechtigungen zu verwenden, da Sicherheitslücken, die Root-Berechtigungen erfordern, weniger schwerwiegend sind. Die Verwendung von root für die Einrichtung oder Bereinigung kann jedoch akzeptabel sein, sofern dies klar dokumentiert und allgemein als gültiger Nicht-Root-Status akzeptiert wird. Es ist beispielsweise zulässig, Root-Rechte zu verwenden, um gefälschte SMS an das Gerät zu senden, um ein zweites Gerät und mehrere SIM-Karten zu vermeiden.

Dadurch wird Tradefed für Ihren Test gestartet. Tradefed wartet, bis ein gültiges Gerät verbunden ist. Achten Sie daher darauf, dass ein Gerät verbunden ist und das ADB-Debugging autorisiert ist.

AutoRepro-Test schreiben

Ein AutoRepro-Test besteht aus drei Teilen und drei entsprechenden Gradle-Plug-ins:

Gradle-Plug-in id("com.android.security.autorepro.javahosttest"): Der einzelne hostseitige Tradefed-Test, der über ADB mit dem Gerät interagiert. Im Beispiel wird es im Verzeichnis submission/hostTest/ verwendet.
Gradle-Plug-in id("com.android.security.autorepro.apptest"): Ein App- oder Dienst-APK, das über adb install auf dem Gerät installiert und vom hostseitigen Test gestartet wird. Die App oder der Dienst kann auch eigene JUnit-Behauptungen enthalten, die an den hostseitigen Runner gesendet werden. Im Beispiel wird es im Verzeichnis submission/appTest/ verwendet.
Gradle-Plug-in id("com.android.security.autorepro.ndktest"): Optionaler NDK-basierter Proof-of-Concept-Angriff, der über adb push auf das Gerät gepusht und vom hostseitigen Test ausgeführt wird. Im Beispiel wird es im Verzeichnis submission/ndkTest/ verwendet.

Ein typischer AutoRepro-Testablauf folgt in der Regel einem der beiden Muster:

Instrumentierte Test-App:
1. Beim hostseitigen Test wird ein APK mit einer instrumentierten App oder einem Dienst auf das Gerät geschoben.
2. Der hostseitige Test startet die geräteseitigen JUnit-Tests, die über runDeviceTest() mit dem APK gebündelt sind.
3. Die geräteseitigen JUnit-Tests tippen auf Schaltflächen und beobachten die App mit UIAutomator oder greifen anderweitig auf die Android APIs zu, um Sicherheitslücken aufzudecken.
4. Ob die geräteseitigen JUnit-Tests erfolgreich waren oder fehlgeschlagen sind, wird an den hostseitigen Test zurückgegeben. So kann ermittelt werden, ob der Test bestanden hat oder nicht. Die Fehlermeldung sollte detaillierte Informationen dazu enthalten, warum die Prüfung fehlgeschlagen ist, sowie bestimmte Objekte, Werte, Ausnahmen, Stack-Traces oder andere Artefakte als Nachweis der Sicherheitslücke.
NDK-Proof-of-Concept:
1. Beim hostseitigen Test wird eine ausführbare Linux-Datei auf das Gerät gesendet und dort ausgeführt.
2. Das native Programm stürzt ab oder gibt einen bestimmten Exit-Code zurück.
3. Beim hostseitigen Test wird nach Abstürzen, dem Logcat-Backtrace oder dem bestimmten Exit-Code gesucht, um festzustellen, ob der Angriff erfolgreich war. Die Fehlermeldung sollte detaillierte Informationen dazu enthalten, warum die Prüfung fehlgeschlagen ist, sowie bestimmte Strukturen, Werte, Stack-Traces oder andere Artefakte als Nachweis der Sicherheitslücke.

Eine Kombination der beiden Muster (z. B. das Ausführen eines nativen Programms in Verbindung mit geräteseitigen Tests) ist ebenfalls möglich. Es sind auch andere Instrumentierungsframeworks wie frida-inject verfügbar. Weitere Informationen finden Sie in den Referenzdokumenten zur Security Test Suite und in den Referenzdokumenten zu Tradefed.

Für meinen Proof-of-Concept-Angriff ist keine Test-App oder native ausführbare Datei erforderlich

Für die meisten Tests sind weder eine geräteseitige App noch eine native ausführbare Datei erforderlich.

Wenn Ihr Test keine Funktion umfasst, löschen Sie die nicht benötigten gradle-Unterprojektverzeichnisse.

Mein Proof-of-Concept-Angriff umfasst eine zweite App/einen zweiten Dienst

Fügen Sie beliebig viele Gradle-Unterprojekte mit AutoRepro-Plug-ins hinzu.

AutoRepro-Test einreichen

So fügen Sie Testergebnisse von Ihrem Gerät in die Einreichung ein:

Optional können Sie die Gradle-Aufgabe clean ausführen, um alle alten Testläufe zu löschen.
Führen Sie die entsprechende AutoRepro-Ausführungskonfiguration aus, um Tradefed für Ihren Test aufzurufen und Protokolle und Ergebnisse zu erfassen.
Führen Sie die Aufgabe copyInvocationResultsToSubmission aus, um die Protokolle und Ergebnisse in das Verzeichnis „Submission Sources“ zu kopieren.

Führen Sie assembleSubmissionZip aus, um die Datei submission/build/autorepro-submission.zip zu erstellen. Laden Sie diese Datei zusammen mit Ihrer Einreichung in das Android Vulnerability Reward Program hoch. Der Anhang muss dem Muster *autorepro-submission*.zip entsprechen und mit dem ursprünglichen Bericht hochgeladen werden. Wenn Sie Berichte zu spät hochladen, können wir sie nicht richtig prüfen.