AutoRepro Gradle 플러그인은 Android Trade Federation 테스트 하네스를 기반으로 빌드되어 Android 보안 게시판의 취약점에 대한 보안 패치 테스트를 위해 모든 Android 기기를 테스트합니다.
이러한 테스트는 일반적인 취약점 및 노출 (CVE)과 연결되거나 연결될 예정인 수정사항에만 독점적으로 사용됩니다.
이 플러그인을 사용하면 Android 스튜디오 또는 표준 Android SDK를 사용하여 Android 소스 트리 외부에서 Tradefed 테스트를 개발할 수 있습니다. 여기에는 Tradefed 테스트를 빌드하고 실행하는 데 필요한 모든 유틸리티가 포함되어 있습니다.
예시 또는 템플릿을 추출한 후 Android 스튜디오에서 디렉터리를 기존 프로젝트로 열고 Gradle 동기화가 완료될 때까지 기다립니다. 사전 구성된 Android 스튜디오 실행 구성이 여러 개 있습니다.
Gradle 작업:
assembleSubmissionSources - 제출 zip의 소스 파일을 어셈블합니다.
assembleSubmissionZip - 업로드할 제출 zip을 어셈블합니다.
copyInvocationResultsToSubmission - 검토 프로세스를 지원하기 위해 이전 Tradefed 호출의 결과를 AutoRepro 제출 소스 디렉터리에 복사합니다. 여기에는 호스트와 기기의 로그가 모두 포함됩니다. 이를 실행하기 전후에 콘텐츠를 검토하세요.
AutoRepro 호출 Android 스튜디오 실행 구성:
autorepro_nonroot_arm64
autorepro_nonroot_x86_64
autorepro_root_arm64
autorepro_root_x86_64
런처 구성은 autorepro_{device_root}_{device_arch} 형식입니다. 일반적으로 루트가 필요하지 않은 것이 좋습니다. 루트가 필요한 취약성은 심각도가 낮기 때문입니다. 하지만 설정이나 정리 작업을 실행하기 위해 루트를 사용하는 것은 명확하게 문서화되고 일반적으로 유효한 비루트 상태로 허용되는 한 허용될 수 있습니다. 예를 들어 두 번째 기기와 여러 SIM 카드가 필요하지 않도록 루트를 사용하여 기기에 문자 메시지를 가짜로 전송하는 것은 허용됩니다.
그러면 테스트를 위해 Tradefed가 실행됩니다. Tradefed는 유효한 기기가 연결되기를 기다리므로 기기가 연결되어 있고 ADB 디버깅이 승인되었는지 확인하세요.
AutoRepro 테스트 작성
AutoRepro 테스트에는 세 부분이 있으며 이에 상응하는 Gradle 플러그인이 세 개 있습니다.
Gradle 플러그인 id("com.android.security.autorepro.javahosttest") ADB를 통해 기기와 상호작용하는 단일 호스트 측 Tradefed 테스트입니다. 이 예에서는 submission/hostTest/ 디렉터리에서 사용합니다.
Gradle 플러그인 id("com.android.security.autorepro.apptest")adb install을 통해 기기에 설치되고 호스트 측 테스트로 실행되는 앱 또는 서비스 APK. 앱 또는 서비스는 호스트 측 실행기에 보고되는 자체 JUnit 어설션 세트도 포함할 수 있습니다. 이 예에서는 submission/appTest/ 디렉터리에서 사용합니다.
Gradle 플러그인 id("com.android.security.autorepro.ndktest")adb push을 통해 기기로 푸시되고 호스트 측 테스트에 의해 실행되는 선택적 NDK 기반 개념 증명 공격 이 예시에서는 submission/ndkTest/ 디렉터리에서 사용합니다.
일반적인 AutoRepro 테스트 흐름은 대부분 다음 두 가지 패턴 중 하나를 따릅니다.
계측 테스트 앱:
호스트 측 테스트는 계측된 앱 또는 서비스로 구성된 APK를 기기에 푸시합니다.
호스트 측 테스트는 runDeviceTest()를 통해 APK와 함께 번들로 제공되는 기기 측 JUnit 테스트를 시작합니다.
기기 측 JUnit 테스트는 UIAutomator를 사용하여 버튼을 탭하고 앱을 보거나 보안 취약점을 드러내는 방식으로 Android API에 액세스합니다.
기기 측 JUnit 테스트의 성공 또는 실패는 호스트 측 테스트에 반환되며 이는 테스트를 통과했는지 확인하는 데 사용할 수 있습니다. 실패 메시지에는 어설션이 실패한 이유와 취약성의 증거로 사용되는 특정 객체, 값, 예외, 스택 트레이스 또는 기타 아티팩트에 관한 자세한 정보가 포함되어야 합니다.
NDK 개념 증명:
호스트 측 테스트는 기기에서 Linux 실행 파일을 푸시하고 실행합니다.
네이티브 프로그램이 다운되거나 특정 종료 코드를 반환합니다.
호스트 측 테스트가 비정상 종료를 확인하거나, Logcat 백트레이스를 살펴보거나, 특정 종료 코드를 찾아 공격이 성공했는지 확인합니다. 실패 메시지에는 어설션이 실패한 이유와 취약점의 증거로 사용되는 특정 구조체, 값, 스택 트레이스 또는 기타 아티팩트에 관한 자세한 정보가 포함되어야 합니다.
두 패턴의 조합(예: 기기 측 테스트와 함께 네이티브 프로그램을 실행)도 가능합니다. frida-inject와 같은 다른 계측 프레임워크도 사용할 수 있습니다. 자세한 내용은 보안 테스트 모음 참조 문서 및 Tradefed 참조 문서를 확인하세요.
개념 증명 공격에 테스트 앱 또는 네이티브 실행 파일이 필요하지 않음
대부분의 테스트에는 기기 측 앱과 네이티브 실행 파일이 모두 필요하지는 않습니다.
테스트에 기능이 사용되지 않는 경우 불필요한 Gradle 하위 프로젝트 디렉터리를 삭제합니다.
개념 증명 공격에 두 번째 앱/서비스가 사용됨
AutoRepro 플러그인이 있는 Gradle 하위 프로젝트를 원하는 만큼 추가합니다.
AutoRepro 테스트 제출
기기의 테스트 결과를 제출에 포함하려면 다음 단계를 따르세요.
선택적으로 Gradle clean 작업을 실행하여 이전 테스트 실행을 삭제합니다.
적절한 AutoRepro 실행 구성을 실행하여 테스트를 위해 Tradefed를 호출하고 로그와 결과를 수집합니다.
copyInvocationResultsToSubmission 작업을 실행하여 로그와 결과를 제출 소스 디렉터리에 복사합니다.
assembleSubmissionZip를 실행하여 submission/build/autorepro-submission.zip 파일을 만듭니다. Android 취약점 리워드 프로그램에 제출하는 동시에 이 파일을 업로드합니다. 첨부파일이 *autorepro-submission*.zip 패턴과 일치하고 초기 보고서와 함께 업로드되는지 확인합니다. 늦게 제출하면 신고를 제대로 검토할 수 없습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Android Security AutoRepro\n\nThe AutoRepro Gradle plugin is built on top of the\n[Android Trade Federation](/docs/core/tests/tradefed) test harness to test all\nAndroid devices for security patch tests against vulnerabilities in the\n[Android Security Bulletin](/docs/security/bulletin).\nThese tests are exclusively for fixes that are associated or will be associated\nwith a Common Vulnerabilities and Exposures (CVE).\n\nThe plugin allows development of Tradefed tests outside of the Android source\ntree using Android Studio or the standard Android SDK. It includes all utilities\nthat are needed to build and run a Tradefed test.\n\nIt is primarily used to submit automatically reproducible proof-of-concepts for\nthe\n[Android Vulnerability Rewards Program](https://bughunters.google.com/about/rules/android-friends/6171833274204160/android-and-google-devices-security-reward-program-rules).\n\n[Download AutoRepro Example download](https://android-security-tools.googlesource.com/autorepro/+archive/main/example.tar.gz)\n\nPrerequisites\n-------------\n\nInstructions are provided for a 64-bit Linux PC.\n\n- [Android Studio Ladybug or newer](https://developer.android.com/studio) - Can also be installed from your distro's package manager.\n- [Android SDK platform tools](https://developer.android.com/studio/releases/platform-tools) (`adb`, `fastboot`) - Need to be installed and be in your `$PATH` (That is, you should be able to run `adb` from the command line). The easiest way to install the platform tools is using your distro's package manager.\n - If using Android Studio's SDK manager instead of standalone platform tools, remember to add the SDK's `platform-tools` directory to your `$PATH` for command-line development.\n- [AAPT2](https://developer.android.com/tools/aapt2). - Can also be installed using your distro's package manager.\n- Java JDK 21 or newer - compatible with the Android SDK and Gradle.\n\n| **Note:** See [the CTS guide](/docs/compatibility/cts/setup#adb-aapt) for more details on setting up ADB and AAPT2.\n| **Caution:** AutoRepro only officially supports 64-bit Linux machines. While tests written with AutoRepro may build and run on Windows or macOS, they must also be compatible with Linux for submission.\n\nGet started using Android Studio\n--------------------------------\n\nAfter extracting the example or template, open the directory in Android Studio\nas an existing project and wait for Gradle sync to complete. There are several\npreconfigured Android Studio run configurations.\n\nGradle tasks:\n\n- `assembleSubmissionSources` - Assemble the source files for the submission zip.\n- `assembleSubmissionZip` - Assemble the submission zip for upload.\n- `copyInvocationResultsToSubmission` - Copy the results from previous Tradefed invocations into the AutoRepro submission sources directory to assist with the review process. Note that this contains logs from both the host and device; review the contents before or after running this.\n\n| **Tip:** Running `copyInvocationResultsToSubmission` can help your submission be reviewed faster by directly providing logs and results from your device and host.\n\nAutoRepro invocation Android Studio run configurations:\n\n- `autorepro_nonroot_arm64`\n- `autorepro_nonroot_x86_64`\n- `autorepro_root_arm64`\n- `autorepro_root_x86_64`\n\nThe launcher configurations are in the form\n`autorepro_{device_root}_{device_arch}`. It's generally preferable to use\nnonroot because vulnerabilities requiring root are less severe. However, using\nroot to perform setup or cleanup can be acceptable so long as it is clearly\ndocumented and is generally accepted as a valid nonroot state. For example, it's\nacceptable to use root to fake send text messages to the device to avoid\nrequiring a second device and multiple SIM cards.\n\nThese will launch Tradefed for your test. Tradefed waits for a valid device to\nbe connected so ensure one is connected and ADB debugging authorized.\n\nWrite an AutoRepro test\n-----------------------\n\n| **Note:** An AutoRepro test fails when the device is vulnerable and passes when the device is patched or otherwise not vulnerable. One major advantage of this approach is that the failure message should contain detailed information about the vulnerability and any artifacts generated by the PoC. The test should return an `ASSUMPTION_FAILURE` (for example, by using JUnit `Assume` instead of `Assert`) when it can't determine whether the device is vulnerable or not.\n\nThere are three parts to an AutoRepro test and three corresponding Gradle\nplugins:\n\n1. Gradle plugin `id(\"com.android.security.autorepro.javahosttest\")` The single host-side Tradefed test that interacts with the device through ADB. The example uses it in the `submission/hostTest/` directory.\n2. Gradle plugin `id(\"com.android.security.autorepro.apptest\")` An app or service APK that is installed onto the device through `adb install` and launched by the host-side test. The app or service can also contain its own set of JUnit assertions that is reported to the host-side runner. The example uses it in the `submission/appTest/` and directory.\n3. Gradle plugin `id(\"com.android.security.autorepro.ndktest\")` An optional NDK-based proof-of-concept attack that is pushed onto the device through `adb push` and executed by the host-side test. The example uses it in the `submission/ndkTest/` directory.\n\nA typical AutoRepro test flow usually follows one of two patterns:\n\n- Instrumented test app:\n\n 1. The host-side test pushes an APK consisting of an instrumented app or service onto the device.\n 2. The host-side test starts the device-side JUnit tests that is bundled with the APK through `runDeviceTest()`.\n 3. The device-side JUnit tests taps buttons and watches the app using UIAutomator, or otherwise accesses the Android APIs in ways that reveal security vulnerabilities.\n 4. The success or failure of the device-side JUnit tests is returned to the host-side test, which can be used to determine if the test passed or not. The failure message should contain detailed information on why the assertion failed and any specific objects, values, exceptions, stacktraces, or other artifacts as proof of vulnerability.\n- NDK proof-of-concept:\n\n 1. The host-side test pushes and launches a Linux executable on the device.\n 2. The native program crashes or returns a specific exit code.\n 3. The host-side test checks for crashes, looks at the logcat backtrace, or looks for the specific exit code to determine whether the attack succeeded. The failure message should contain detailed information on why the assertion failed and any specific structs, values, stacktraces, or other artifacts as proof of vulnerability.\n\nA combination of the two patterns (for example, running of a native program in\nconjunction with device-side tests) is also possible. Some other instrumentation\nframeworks, such as `frida-inject`, are also available. For details, see the\n[Security Test Suite reference docs](/reference/sts/packages) and the\n[Tradefed reference docs](/reference/tradefed/packages).\n\n### My proof-of-concept attack doesn't need a test app or native executable\n\nMost tests will not need both a device-side app and a native executable.\n\nIf your test does not involve the use a feature, delete the unnecessary gradle\nsubproject directories.\n\n### My proof-of-concept attack involves a second app/service\n\nAdd as many Gradle subprojects with AutoRepro plugins as you like.\n\nSubmit the AutoRepro test\n-------------------------\n\nTo include test results from your device as part of the submission:\n\n- Optionally run the Gradle `clean` task to delete any old test runs.\n- Run the appropriate AutoRepro run configuration to invoke Tradefed for your test and collect logs and results.\n- Run the `copyInvocationResultsToSubmission` task to copy the logs and results into the submission sources directory.\n\nRun the `assembleSubmissionZip` to create the\n`submission/build/autorepro-submission.zip` file. Upload that file along with\nyour submission to the Android Vulnerability Reward Program. Ensure that the\nattachment matches the pattern `*autorepro-submission*.zip` and that it is\nuploaded with the initial report. Uploading submissions late will impact our\nability to properly review your report."]]
