Convert Figma logo to code with AI

AndroidVTS logoandroid-vts

Android Vulnerability Test Suite - In the spirit of open data collection, and with the help of the community, let's take a pulse on the state of Android security. NowSecure presents an on-device app to test for recent device vulnerabilities.

1,014
272
1,014
24

Top Related Projects

Android Vulnerability Test Suite - In the spirit of open data collection, and with the help of the community, let's take a pulse on the state of Android security. NowSecure presents an on-device app to test for recent device vulnerabilities.

An on-path blackbox network traffic security testing tool

3,180

Tool to look for several security related Android application vulnerabilities

Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis.

The Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes the technical processes for verifying the controls listed in the OWASP Mobile Application Security Verification Standard (MASVS).

Quick Overview

AndroidVTS (Android Vulnerability Test Suite) is an open-source project that provides a mobile application to detect vulnerabilities on Android devices. It allows users to test their devices for known security issues and provides information about potential risks.

Pros

  • Easy-to-use interface for non-technical users
  • Regularly updated with new vulnerability tests
  • Provides detailed explanations of detected vulnerabilities
  • Open-source, allowing for community contributions and transparency

Cons

  • May not detect all possible vulnerabilities
  • Some tests may require root access, limiting functionality on non-rooted devices
  • Results may be difficult to interpret for average users
  • Potential for false positives or negatives in certain scenarios

Getting Started

To use AndroidVTS:

  1. Download the APK from the releases page or build from source.
  2. Install the APK on your Android device.
  3. Open the app and grant necessary permissions.
  4. Tap "Run Tests" to begin vulnerability scanning.
  5. Review the results and follow any recommended actions to improve device security.

Note: Some tests may require root access for full functionality. Always exercise caution when granting root access to applications.

Competitor Comparisons

Android Vulnerability Test Suite - In the spirit of open data collection, and with the help of the community, let's take a pulse on the state of Android security. NowSecure presents an on-device app to test for recent device vulnerabilities.

Pros of android-vts

  • More active development and recent updates
  • Larger community and contributor base
  • Better documentation and usage instructions

Cons of android-vts

  • Potentially more complex setup due to additional features
  • May require more system resources to run

Code Comparison

android-vts:

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }
}

android-vts>:

public class MainActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }
}

The code comparison shows minor differences in class inheritance and method signatures. android-vts uses AppCompatActivity and follows more recent Android development practices, while android-vts> uses the older Activity class.

Both repositories aim to provide Android vulnerability testing solutions, but android-vts appears to be the more actively maintained and feature-rich option. It likely offers better support and a wider range of vulnerability tests. However, android-vts> might be simpler to set up and use for basic testing needs.

When choosing between the two, consider factors such as project requirements, desired features, and the level of community support needed for your specific use case.

An on-path blackbox network traffic security testing tool

Pros of nogotofail

  • Broader scope: Tests network security across various platforms, not limited to Android
  • Active development: More recent commits and updates
  • Flexible deployment: Can be used as a client, server, or on-path network testing tool

Cons of nogotofail

  • Steeper learning curve: Requires more setup and configuration
  • Less focused: Not specifically tailored for Android vulnerability testing
  • Requires root access for some features, which may not be available on all devices

Code Comparison

android-vts:

public class VulnerabilityTest extends AsyncTask<Void, Void, Void> {
    @Override
    protected Void doInBackground(Void... params) {
        vulnerabilityResult = vulnerable();
        return null;
    }
}

nogotofail:

class Attack(object):
    def on_request(self, request):
        raise NotImplementedError()

    def on_response(self, response):
        raise NotImplementedError()

The android-vts code snippet shows a vulnerability test implementation using AsyncTask in Java, while the nogotofail code demonstrates a Python-based attack class structure for network testing. This reflects the different focus areas and implementation languages of the two projects.

3,180

Tool to look for several security related Android application vulnerabilities

Pros of QARK

  • More comprehensive static analysis tool, covering a wider range of Android security issues
  • Actively maintained with regular updates and contributions
  • Provides detailed reports and recommendations for fixing identified vulnerabilities

Cons of QARK

  • Slower analysis process compared to android-vts
  • May produce more false positives, requiring manual verification
  • Steeper learning curve for new users due to its extensive feature set

Code Comparison

QARK (Python):

def __init__(self):
    self.vulnerabilities = []
    self.issues = []
    self.manifest_path = None
    self.source_directory = None

android-vts (Java):

public class VulnerabilityTest {
    private String testName;
    private String cveName;
    private String description;
    private boolean isVulnerable;
}

Both projects aim to improve Android security, but QARK focuses on static analysis of source code and APKs, while android-vts primarily tests for known vulnerabilities on devices. QARK offers a more comprehensive approach to identifying potential security issues, while android-vts provides quick vulnerability checks for specific CVEs.

Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis.

Pros of Mobile-Security-Framework-MobSF

  • Supports both Android and iOS platforms, providing a more comprehensive mobile security testing solution
  • Offers a web-based interface, making it more user-friendly and accessible
  • Provides detailed reports and vulnerability assessments, including OWASP Mobile Top 10 checks

Cons of Mobile-Security-Framework-MobSF

  • Requires more setup and dependencies compared to android-vts
  • May have a steeper learning curve due to its broader feature set
  • Can be resource-intensive, especially when analyzing large applications

Code Comparison

Mobile-Security-Framework-MobSF (Python):

def scan_file(app_path):
    # Perform static analysis
    static_analysis = StaticAnalyzer(app_path)
    static_results = static_analysis.analyze()
    
    # Perform dynamic analysis
    dynamic_analysis = DynamicAnalyzer(app_path)
    dynamic_results = dynamic_analysis.analyze()

android-vts (Java):

public void runTest(String testName) {
    Test test = TestLoader.loadTest(testName);
    TestResult result = test.execute();
    reportManager.addResult(result);
}

The code snippets illustrate the different approaches:

  • MobSF uses separate static and dynamic analysis modules
  • android-vts focuses on individual vulnerability tests

Both projects aim to improve mobile security, but MobSF offers a more comprehensive solution at the cost of complexity, while android-vts provides a simpler, Android-specific approach.

The Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes the technical processes for verifying the controls listed in the OWASP Mobile Application Security Verification Standard (MASVS).

Pros of owasp-mastg

  • Comprehensive mobile application security testing guide covering both Android and iOS
  • Regularly updated with the latest security best practices and vulnerabilities
  • Extensive community support and contributions from security experts worldwide

Cons of owasp-mastg

  • Larger and more complex project, potentially overwhelming for beginners
  • Requires more time to navigate and find specific information
  • Less focused on automated testing compared to android-vts

Code Comparison

android-vts example (Java):

public class VulnerabilityTest extends Test {
    @Override
    public void execute(Context context) {
        // Vulnerability test implementation
    }
}

owasp-mastg example (Python):

def test_insecure_data_storage(app_path):
    # Analyze app for insecure data storage
    result = analyze_storage(app_path)
    assert result.is_secure, "Insecure data storage detected"

While android-vts focuses on Java-based vulnerability tests specific to Android, owasp-mastg provides a broader range of testing methodologies and examples in various languages, including Python, for both Android and iOS platforms.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

#Android Vulnerability Test Suite

Download from Github

UPDATE 2015/12/15: AndroidVTS is currently not available in the Google Play™ store app, more info here.

Overview

This tool was meant to show the end user the attack surface that a given device is susceptible to. In implementing these checks we attempt to minimize or eliminate both false positives/false negatives without negatively affecting system stability.

Rationale for necessity

When a vulnerability is discovered, Google receives word and applies a patch to Android. The Nexus devices are usually the devices that receive these patches quickest as they deviate the least (read: not at all) from AOSP (Android Open Source Project - The core of Android, where Google commits to). The lag time between learning about a bug and the time when a patch is applied to a device can still be significant (for OEMs, it can be > 1 year or never). For example, the futex bug (CVE-2014-3153/Towelroot) was known about in late May, early June. This bug took multiple months to get patched on the flagship (at the time) Nexus 5. This leaves users extremely vulnerable to attack from applications. Users mostly do not know that their devices are vulnerable and this tool is meant to give visibility into the vulnerabilities a given device is susceptible to.

Lifecycle of a patch

Samsung, HTC, and every other OEM keep heavily customized versions of Android. The patch deployment infrastructure from OEMS -> carriers -> users is in disarray. The OEMs receive the patches from Google and spend weeks or months applying these to some devices and testing. Then they ship off the device updates to the carrier who is responsible for pushing them to the end user. They then go through another QA cycle from the carrier.

Implementation

Vulnerabilities in a device can exist at many layers inside of Android. For example, a bug can exist in the kernel (Towelroot, for example) or it can exist in the Android specific framework (Android Masterkeys/FakeID). Some of the kernel bugs can sometimes be difficult to check for without potentially causing system instability. This implementation takes care to not include checks that could cause instability problems for the end user and therefore may omit checks that could cause these types of issues. The framework is very thin at the current time and consists of a vector of vulnerability checks. Their concrete implementations vary wildly depending on the bug.

A list of current bug checks:

Previous work

There have been attempts before to solve this issue. xray.io Xray works by actually attempting the exploit which doesn't satisfy our system stability constraint. There also exist other applications which attempt to determine a devices attack surface by simply using a lookup based on Android verison/build information. This causes both false negatives and false positives. Imagine the case where an OEM has back ported a fix to a device, but the check solely relies on an Android device; false positive. The case where an OEM upgrades to an Android version/kernel version which includes patches, but manages to break them causes the case of a false negative.

Device Vulnerability Screencast

Contributions

See CONTRIBUTING.md

Building

You can import this project into AndroidStudio or use gradle from the CLI. You need the Android SDK and NDK installed to properly build this project. The gradle build files look for a local.properties:

cat local.properties

## This file is automatically generated by Android Studio.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
#
# This file must *NOT* be checked into Version Control Systems,
# as it contains information specific to your local configuration.
#
# Location of the SDK. This is only used by Gradle.
# For customization when using a Version Control System, please read the
# header note.
#Tue Aug 18 12:32:42 EDT 2015
sdk.dir=/Users/fuzion24/bin/android_sdk_home
ndk.dir=/Users/fuzion24/bin/android_ndk

To build a debug APK with test signing keys:

./gradlew assembleDebug

Build and install a debug build:

./gradlew installDebug

Build a release (unsigned):

./gradlew assembleRelease