Skip to main content
All CollectionsAdvanced
Analysis Capabilities
Analysis Capabilities
Updated over 2 weeks ago

This document provides an overview of the techniques AppSweep uses to analyze apps. AppSweep employs static analysis (SAST) for Android and iOS, and interactive analysis (IAST) for Android.

Static Analysis (SAST) Capabilities

Code and Resource Loading

The first step in static analysis involves loading the app into an internal representation that facilitates a deeper inspection of the app's code and resources. This stage includes:

  • Code Transformation: The app’s code is loaded into an internal representation. For example, virtual method call targets are resolved and control flow graph (CFG) is built to analyze the order in which different code segments are executed.

  • Resource Parsing: App resources such as images, strings, and configuration files are parsed into specialized data structures, which lets AppSweep extract and analyze these resources efficiently.

Value Reconstruction

Once the app's internal structure is constructed, AppSweep performs value reconstruction across the control flow graph. This process determines the values that flow into method-call parameters and variables, providing a clear path of how data is propagated and manipulated. In essence, this process is similar to constant propagation techniques used in compilers.

Dataflow and Taint Analysis

Taint analysis is an integral part of AppSweep's analysis capabilities. It is a specialized form of data-flow analysis that allows for the tracking of potentially sensitive or critical data throughout the app. Here’s how it operates:

  • Detection of Sensitive Sources: Taint analysis identifies sources of sensitive, untrusted or potentially malicious values, for example:

    • API keys

    • Cryptographic secrets

    • User inputs

    • Authentication tokens

    • etc

  • Tracking Data Flows: After identifying the sources, AppSweep follows the flow of the data throughout the program and examines where and how it is being consumed. Specifically, it identifies functions or methods that interact with, transform, or transmit this data.

Taint analysis is important for identifying vulnerabilities that e.g., stem from improper handling of sensitive information or unsafe data flows across app components.

Generating Findings

Based on the results of the supporting analyses, AppSweep generates findings - indications of potential security risks or flaws within the app. This process uses as many details as possible from the preceding analysis stages, to minimize false positives as much as possible.

Interactive Analysis (IAST) for Android

Interactive Application Security Testing (IAST) in AppSweep is currently exclusive to Android. This mode of analysis extends the static capabilities by incorporating runtime data collection.

Code Instrumentation

Immediately after static analysis is complete and findings are generated, AppSweep identifies code locations which may benefit from additional runtime data. Areas where sensitive or critical data is processed, or where specific methods of interest are executed, are flagged. In these identified spots, AppSweep instruments the code by injecting data collection logic and reassembles the app as a new APK.

Runtime Data Collection

Once the instrumented app is running, information on function calls, their arguments, returned values, and observed runtime behaviors (e.g., which code paths are executed) is collected and transmitted back to AppSweep’s servers. The more extensively the app is used and features are explored, the more comprehensive the data collection becomes. This allows AppSweep to gain deeper insights into how the app operates in various usage scenarios.

Static Analysis with Collected Data

Once the runtime data collection phase is completed, the app undergoes a second round of static analysis. This time, the analysis process benefits from access to the previously recorded runtime data. This helps provide deeper insight into the app’s execution and functions, ensuring that findings more accurately reflect potential risks under real execution conditions.

Did this answer your question?