Android’s vast ecosystem and expansive API surfaces pose a serious challenge to static application security testing (SAST) tools. Mainstream tools such as MobSF, APKHunt, and AUSERA mainly rely on manually crafted rules. Crafting these rules demands considerable effort, yet they still cannot cover every security issue. When Android introduces new APIs, changes its permission model, or revises other security policies, the rules soon fall behind. Without constant maintenance, false positives grow, and true vulnerabilities slip through. Recently released LLM-based detectors are easy to use and potentially support a wide range of vulnerability types, but their findings often lack clear explanations and suffer from high false-positive rates.In this paper, we present RULEDROID, a new framework that leverages LLMs to automatically generate Semgrep-compatible static detection rules from up-to-date official Android security documentation. RULEDROIDtackles the limits of pure LLM detection by combining (i) Retrieval-Augmented Generation (RAG), which grounds model outputs in trusted documents, and (ii) a modular workflow that decomposes rule synthesis into welldefined stages. The resulting rules are then applied with proven static-analysis techniques, ensuring consistent and explainable results. We evaluated RULEDROID on three public benchmark datasets. Based on its large and precise rule set, RULEDROIDachieved higher coverage and accuracy than traditional SAST tools, and sharply reduced false positives compared with direct LLM scanning. When applied to real-world apps, RULEDROIDdiscovered multiple new vulnerabilities, resulting in 57 CVE IDs being assigned. These results show that RULEDROIDcombines the broad vulnerability coverage of LLMs with the precision of static analysis, delivering a fully automated docs-to-rules solution for Android security testing.

The rapid growth of the Internet of Things (IoT) has led to the widespread use of companion apps for device management. However, these apps expose a critical vulnerability in the IoT ecosystem: insufficient verification procedures during device firmware updates (DFU), often resulting in firmware leakage. Once leaked, the firmware reveals sensitive design details, creating a straightforward path for attackers to reverse-engineer devices. To address this issue, we designed an automated analysis tool called FirmProj. It systematically evaluates firmware leakage risks by examining IoT companion apps. FirmProj combines advanced static analysis techniques with large language models to identify DFU modules, extract firmware files, and detect security vulnerabilities. In a large-scale study involving 10,047 IoT companion apps, FirmProj successfully retrieved 3,434 firmware files, uncovering severe flaws in DFU implementations that can lead to firmware leakage. These findings resulted in the assignment of 35 CVE IDs. Our results highlight the urgent need to strengthen firmware protection mechanisms throughout the IoT ecosystem.

Abstract To facilitate collaboration across multiple devices and benefit from larger screens and better user experiences, many users choose to mirror their screen content of smartphones to personal computers. The implementation of the Android screen mirroring feature varies across different manufacturers, resulting in significant security differences among screen mirroring apps. Moreover, actual incidents of screen content leakage have exacerbated users’ concerns about the security of the Android screen mirroring feature. In this work, we systematically analyzed the system architecture of the Android screen mirroring feature and the security risks it faces. Specifically, we identified four critical security risks in the communication process between the mobile and PC sides of screen mirroring apps, including arbitrary access to screen content, MITM (Man-in-the-Middle) attacks, malicious commands injection, and data sniffing attacks. Attackers can exploit these identified security risks to arbitrarily access screen content or manipulate user’s phone to perform malicious operations. To evaluate the security risks of the Android mirroring feature in real-world deployments, we conducted a security evaluation on over 20 popular screen mirroring apps from multiple sources. The results indicate that all of these apps are facing at least one of the aforementioned security risks. Finally, we provide the corresponding recommendations to mitigate the identified security risks.

The Android OS, known for its openness and flexibility, dominates the global smartphone market, enabling the creation and distribution of a vast array of apps. However, this openness also attracts malicious apps that threaten user security. To counter these threats, static and dynamic analysis techniques are employed. Despite these efforts, evasion techniques such as code obfuscation and anti-debugging are increasingly used to bypass these analyses.In this study, we conduct a comprehensive review of current evasion and anti-evasion techniques and assess their real-world impact by analyzing 108,099 benign apps, 11,730 malicious apps, and 11 online dynamic analysis platforms. Our findings reveal that 68.1% of apps employ evasion techniques, with benign apps using them more frequently than malicious ones. Malicious apps, however, demonstrate more cautious behaviors when evading dynamic analysis. Additionally, our evaluation of dynamic analysis platforms shows that most evasion techniques, including simple methods like checking fields in the Build class, successfully evade detection, indicating a significant gap in current anti-evasion capabilities. Our research provides critical insights into the ongoing battle between Android app security and evasion techniques, underscoring the need for improved countermeasures to enhance user security.

Multi-channel distribution of Android apps offers convenience to users, yet simultaneously introduces security concerns. Although apps published on Google Play and third-party markets share the same version code, differences in app content may still arise. Notably, a recent incident involving the third-party market version of Pinduoduo app containing malicious code highlights the intentionally-differentiated implementations of app functionalities by developers between Google Play and third-party markets. The case of Pinduoduo may be just the tip of the iceberg, underscoring the need for a comprehensive investigation of the disparities between Google Play and third-party market versions of apps.In this work, we systematically analyze the differences in security and privacy of cross-market apps that claim to share the same version code. Specifically, we propose three research questions that cover differences in app protection, security threats, and permission usage. To answer these questions, we constructed a dataset containing 17,218 app pairs (filtered from 236,731 apps) and permission mappings (27,046 SDK mappings, 1,656 ContentProvider mappings, and 309 Intent mappings) for API levels 16 - 33. This dataset enables us to perform a comprehensive differential analysis. Consequently, our investigation unveiled a series of captivating and insightful findings. Approximately 29.02% of apps show differences in one or all three aspects. For example, the third-party market versions of apps often request more permissions compared to their Google Play counterparts, particularly among apps in the game category. Our work can help developers and app store operators improve cross-market app consistency, enhancing the quality of the Android app ecosystem and user experience.

The update of Android OS constantly brings users various new features and enhances system security. On the other hand, the system and API modifications with the update may introduce the app compatibility issue. The app's SDK version may not align with the Android OS version, making apps not work adequately. This condition will inevitably damage the Android ecosystem. Thus, while developing Android OS, Google considered and deployed compatibility support. The software engineering research community also noticed the Android compatibility issue and conducted some investigations. However, most previous studies focus on apps' performance and solutions on compatibility (apps running on multiple OS versions). Rare work considers the Android OS side's forward compatibility implementations (supporting legacy apps running on the latest OS). This work systematically studied how Android OS implements forward compatibility for the apps developed with outdated SDKs, primarily focusing on the targetSdkVersion-based fine-grained control. Specifically, we propose three research questions, covering: 1) the forward compatibility support approaches; 2) the stability of foforward compatibility support in third-party market apps. To address these questions, we conducted comprehensive measurements on Android's forward compatibility support, including its implementation, implications, and evolution. Our measurements were based on large-scale datasets covering the source code of Android 8.0~ 13 and 130,461 apps. Finally, we provide rich data support and analysis to answer these questions. This study offers new insights into Android's forward compatibility support, helping the research community understand the evolution of Android's API design.

Private browsing is a common feature of web browsers on desktop platforms. This feature protects the privacy of users browsing the Internet and, therefore, is widely welcomed by users. In recent years, with the popularity of smartphones, the private browsing mode has been introduced into mobile browsers. However, its deployment on mobile platforms has not been well evaluated. To bridge the gap, in this work, we systemically studied the private browsing modes of Android browser apps. Specifically, we proposed six private rules for mobile browsers to follow by combining the mobile browsing features with the previous research on private browsing. Furthermore, we designed an automated analysis framework, BroDroid, to detect whether mobile browsers violate these rules. Also, with BroDroid, we evaluated 49 popular browser apps crawled from Google Play. Finally, BroDroid successfully identified 58 violations, some of which come from the promised capabilities of the browser. We reported our discovered issues to the corresponding developers, and four of them (Yandex Browser, Mint Browser, Web Explorer, and Net Fast Web Browser) have acknowledged our findings. Our observation may be the tip of the iceberg, and more efforts should be put into improving the privacy protections of mobile browsers.

The popularity of Android OS is largely credited to massive apps, and many app developers are involved in this ecosystem. On the other hand, various vulnerabilities are introduced into apps by developers carelessly, bringing security issues to users. To facilitate secure development and avoid common API misuses, Google provides a series of security guidelines and development practices for developers on the official developer community websites. However, the deployments of these guidelines in the wild have not been systematically evaluated. In this work, through large-scale app measurement (251,749 apps from 10 markets) and analysis, we investigated whether app developers follow the official Android security guidelines and the possible reasons behind it. In practice, we selected five guidelines related to app data security as representatives, covering: (1) secure file creation modes; (2) sensitive data storage; (3) validation check for file paths; (4) hardware ID usage; (5) custom permission protection. We also designed the corresponding detection strategies to check violations of the guidelines. The results show that most developers (> 90 %) can comply with Guidelines 1 and 2. However, some guidelines have not been followed properly. For Guidelines 3, 4, and 5, less than 60 % of developers followed the Google security suggestions.

During the Android app development, the SDK is essential, which provides rich APIs to facilitate the implementations of functionalities. However, in the Android framework, there still exist plenty of non-SDK APIs that are not well documented. These non-SDK APIs can be invoked through unconventional ways, such as Java reflection. On the other hand, these APIs are not stable and may be changed or even removed in future Android versions, providing no guarantee for compatibility. From Android 9 (API level 28), Google began to strictly restrict the use of non-SDK APIs, and the corresponding checking mechanism has been integrated into the Android OS.

The casting service on SmartTV has been increasingly used for home entertainment and business, given the convenience offered in media broadcast and screen sharing. Among the underlying protocols that support TV cast, DLNA (Digital Living Networking Alliance) – established by a group of tech giants – has become a prevailing standard in the consumer market. Although DLNA has launched the market for years, concerns may arise about whether its real-world deployment has been clearly understood.In this work, we systematically evaluate the security of DLNA deployments in the SmartTV ecosystem. Specifically, we identify a series of critical security issues in the interactions between SmartTVs and casting apps on the smartphone, ranging from non-mandatory encryption to unauthorized file access. The identified security risks can be exploited by a malicious app on the victim’s phone, without requesting sensitive permissions, to launch multiple attacks, including arbitrary command execution, data theft, MITM (man-in-the-middle) attack, and DoS (denial-of-service) attack. To measure the impact of the identified security issues, we designed semi-automated analysis solutions to facilitate the measurements and conducted real-world experiments on 10 on-shelf TV boxes. The results show that most DLNA implementations of products and apps in the wild are insecure. In the end, we provide immediate improvement solutions to mitigate the identified security issues.

Permission is the fundamental security mechanism for protecting user data and privacy on Android. Given its importance, security researchers have studied the design and usage of permissions from various aspects. However, most of the previous research focused on the security issues ofsystem permissions. Overlooked by many researchers, an app can usecustom permissionsto share its resources and capabilities with other apps. However, the security implications of using custom permissions have not been fully understood. In this paper, we systematically evaluate the design and implementation of Android custom permissions. Notably, we built an automatic fuzzing tool, calledCuPerFuzzer+, to detect custom permission related vulnerabilities existing in the Android OS.CuPerFuzzer+treats the operations of the permission mechanism as a black-box and executes massive targeted test cases to trigger privilege escalation. In the experiments,CuPerFuzzer+discovered 5,932 effective cases with 47 critical paths successfully. Through investigating these vulnerable cases and analyzing the source code of Android OS, we further identified a series of severe design shortcomings lying in the Android permission framework, includingdangling custom permission,inconsistent permission-group mapping,custom permission elevating,inconsistent permission definition,dormant permission group, andinconsistent permission type. Exploiting these shortcomings, a malicious app can access unauthorized platform resources. On top of these observations, we propose three general design guidelines to secure custom permissions. Our findings have been acknowledged by the Android security team and assignedCVE-2020-0418,CVE-2021-0306,CVE-2021-0307, andCVE-2021-0317.