# Suze

## Introduction

Suze is a experimental security analysis framework developed by me to assist in Android security research. It performs both static analysis and fuzz testing on Android apps and the Android framework. Suze is currently capable of discovering convoluted and obscure types of vulnerabilities that would be extremely difficult for a human security researcher to detect. It can process individual APK files, most types of OTA files, and entire devices through ADB.

It’s also easily expandable; the core framework only handles fundamental features such as load balancing, CFG creation, CFG processing, and ADB communication. Additional features such as fuzzers, scanners, and OTA file parsers can be added to the framework as plugins.

## History

I started the project in 2016 as a simple program to extract system APK files and framework JAR files. To accomplish this, the initial project could either extract various OEM OTA files or use ADB to pull files from a device.
In 2017 when I was attempting to find a root exploit for the Amazon Fire HD 8 2017 tablet, I improved Suze to allow mass-decompilation of extracted APK files so I can grep for potential backdoors in the code such as RootAllow that affected the Amazon framework.
Through 2017 and 2018, I added simple variable and function analysis to Suze, so I can easily track usages/assignments/declarations of variables and function calls throughout decompiled code. This is a predecessor to the much more advanced control flow graph analysis used by Suze today.
In 2018 many general improvements to Suze were made as well, such as implementation of a more manageable CLI and support for multi-threaded APK decompiling.
The project developed rapidly in 2019. I wanted to implement a fuzzer that targets the system settings database, which is a relatively less-targeted area in Android from a security perspective. I could find many examples in Android OEM code where system settings were used needlessly; this is a dangerous coding practice because unprivileged apps can directly modify this database. Since the existing Suze project already provided many of the functionality that would be required for the system settings fuzzer, I decided to implement the fuzzer as an add-on to Suze.
Unfortunately my first attempt at the fuzzer failed completely. The initial fuzzer simply iterated over the decompiled code, looking for possible sensitive usages and exception triggers reachable from Settings.System API calls. Then it used the gathered data to generate large input test cases that were then fed into the system settings database entries. If the database write failed due to SystemSettingsValidators verification, it tried to use other input types such as integers/floats. This approach apparently failed due to the complexity of the decompiled Java code; the iterative parsing caused the fuzzer to miss many potential pathways and process some unreachable pathways.
So I started working on modifying the Suze framework to allow a much more accurate way of program representation: CFGs, or control flow graphs. Implementing it was a really difficult task that took around 9 months of work, ending in early 2020 and turning out to be a success. During the initial test run on extracted data from a Huawei Nova 3i device, Suze discovered an unpatched high-severity issue that was confirmed by Huawei. It was assigned CVE-2020-9245 and HWPSIRT-2020-02152.
After some bug fixes, Suze helped me discover another high-severity issue that turned out to affect AOSP itself. This issue was confirmed by Google and it was assigned CVE-2020-0443.
The bounties from these issues allowed me to allocate more resources to the development and execution of Suze. As such, many new plugins to Suze were added through 2020 to 2022 which in turn allowed me to discover more issues. The most important plugin developed during this time was the scanning plugin that identifies various vulnerable patterns in CFGs, by starting from entry nodes (accessible to unprivileged apps) and traversing inwards until a sensitive operation is detected. This plugin helped me discover CVE-2021-0952, HMS-VUL-2021-1, a bug in Google Contacts, a bug in Google Personal Safety, and many bugs affecting Huawei system apps and the Huawei framework. It also helped me find 5 other valid issues in AOSP, though Google informed me that they were already aware of those issues.

## Today

Current work on Suze is mostly focused on cleaning up and documenting the core framework code. I didn’t realize the importance of using clean and understandable code for closed-source projects until late 2019. The majority of the framework code was written before that; especially the code I wrote in 2016-2017 as a 12 year old is very difficult to understand, maintain and debug.
In the future I may provide the app scanning feature of Suze as a subscription-based server-side service, including IDE plugins so a developer can easily trigger a scan of their app directly from the IDE. Also, there’s a testing version of the scanning plugin that’s capable of modifying the CFG in near real-time as the source code changes. If I successfully implement this feature, Suze would be able to scan app source code during the development process itself and highlight potential issues in real-time. It should be noted that this version is highly experimental and fails most of the time.
Another avenue of research is using shared memory for plugin-framework communication rather than pipes. This is fairly difficult to implement safely because how multi-threading works in Suze, but it’ll likely improve performance significantly.

## Features

• Framework
• Retrieving all Android binaries from a USB-connected device using ADB. Allows the user to specify which type(s) of binaries to retrieve: system apps, user apps, framework files. ODEX/VDEX/APEX files will be also extracted automatically when applicable.
• Converting sparse system images from OTA files into raw images and mounting them in order to extract Android system binaries.
• Extracting important metadata (e.g., model, version, S/N, security patch, build fingerprints) from devices/OTA files, saving them into .sz files, and displaying them when requested.
• Perform batch operations on extracted app binaries using a filtering system. Supports filtering based on:
• Package name
• Package domain
• System/user app
• Origin (OTA/Device)
• SDK version
• Permissions requested
• Manufacturer (for system apps)
• Security patch (for system apps)
• Generating control flow graphs from app binaries, storing them in a memory-efficient format, processing and extracting information about graphs quickly, and sending information about graphs to plugins when requested.
• Supports plugins. Plugins are separate processes that communicate with the framework through pipes. A pre-processing step in framework compilation allows plugins to invoke any C++ function in the framework when needed, and read/write many global variable types. Plugins can also communicate with other plugins using the framework as an intermediary.
• Load balancing. While processing plugin requests, the framework distributes them over worker processes so that plugins don’t have to handle multi-threading by themselves. A plugin can have a priority level that determines how much resources the framework allocates for requests from that plugin.