Android Security Test Suite Development Kit (STS SDK)

Security Test Suite Trade Federation (sts-tradefed) is built on top of the Android Trade Federation test harness to test all Android devices for security patch tests that don't fall into the Compatibility Test Suite. These tests are exclusively for fixes that are associated (or will be associated) with a Common Vulnerabilities and Exposures (CVE).

The SDK allows development of STS tests outside of the Android source tree using Android Studio or the standard Android SDK. It includes all utilities that are needed to build and run an STS test.

Get started using Android Studio

After extracting the archive, open the directory in Android Studio as an existing project. Run the assembleSTSARM or assembleSTSx86 build target to build the skeleton test, depending on the architecture of the target Android device. Run the runSTS build target to run the skeleton test on the connected device (ADB must be authorized).

Get started using Gradle

After extracting the archive, set the sdk.dir property in the local.properties file at the root of the Gradle project, then run the assembleSTSARM Gradle task to build the skeleton test. After the build is finished, the test can be run by navigating (cd) into build/android-sts/tools and executing the sts-tradefed wrapper.

$ echo 'sdk.dir=/home/<myusername>/Android/Sdk' > local.properties
$ ./gradlew assembleSTSARM
$ cd build/android-sts/tools
$ ./sts-tradefed run sts-dynamic-develop -m hostsidetest

Write an STS test

There are three parts to an STS test:

  1. A host-side Tradefed test that interacts with the device through adb, in the sts-test subdirectory.
  2. An optional native proof-of-concept attack that is pushed onto the device through adb push and executed by the host-side test in the native-poc subdirectory.
  3. An optional app or service APK that is installed onto the device through adb install and also 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. This is in the test-app subdirectory.

A typical STS test flow usually follows one of two patterns:

  • Native proof-of-concept:

    1. The host-side test pushes and launches a native executable on the device.
    2. The native program crashes or returns a specific exit code.
    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.
  • Instrumented test app:

    1. The host-side test pushes an APK consisting of an app or service onto the device.
    2. The host-side test starts the device-side JUnit tests that is bundled with the APK through runDeviceTest()
    3. The device-side JUnit tests taps buttons and watches the app using UIAutomator, or otherwise accesses the Android system in ways that reveal security vulnerabilities.
    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.

A combination of the two patterns (for example, running of a native program in conjunction with device-side tests) is also possible. Some other instrumentation frameworks, such as frida-inject, are also available. For details, see the Security Test Suite reference docs.