DroidBreaker: Practical and Functional Problem-Space Attacks on Machine-Learning Android Malware Detectors

Unknown

Conceptio › Archive › arXiv CS

arXiv CSopen access

DroidBreaker: Practical and Functional Problem-Space Attacks on Machine-Learning Android Malware Detectors

Unknown · 2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

Open Source ↗Direct PDF ↓

cryptography, security, privacy, cybersecurity

DroidBreaker: Practical and Functional Problem-Space Attacks on Machine-Learning Android Malware Detectors Christian Scano∗† , Diego Soi∗ , Angelo Sotgiu∗‡ , Luca Demetrio§ , Davide Maiorca∗ , Giorgio Giacinto∗‡ , Fabio Roli∗‡§ , and Battista Biggio∗‡ , ∗ University of Cagliari † Sapienza University of Rome ‡ CINI

arXiv:2606.26707v1 [cs.CR] 25 Jun 2026

§ University of Genova

{christian.scano, diego.soi, angelo.sotgiu, davide.maiorca, giorgio.giacinto, battista.biggio}@unica.it, {luca.demetrio, fabio.roli}@unige.it

Abstract—Adversarial APKs are Android applications modified in the problem space to evade machine-learning malware detectors. In this work, we first show that, despite claims, existing problem-space attacks remain largely impractical. Most techniques leverage software transplantation to inject entire benign modules, introducing many side-effect features and often causing build-time failures. Fine-grained methods that inject only a narrow subset of components exhibit limited effectiveness, while those that also use obfuscation rely on brittle bytecode rewriting, producing APKs that are syntactically valid but semantically unusable. Prior work further overestimates attack success rates by running smoke tests that only validate installation and basic execution, without assessing whether the modified APK still preserves its intended behavior. To overcome these limitations, we present D ROID B REAKER, a practical (build-safe) and functional (semantics-preserving) problem-space attack framework that provides: (i) query-efficient white- and black-box attacks by manipulating only the APK components most influential to the target model; (ii) a set of fine-grained, build-safe manipulations (including injection and obfuscation of API calls, app modules, permissions, and URLs) with minimal side effects; and (iii) a semantics-preserving functionality test that enforces runtime equivalence by comparing execution logs and API-level traces between the initial and the modified APK. Evaluated on a recent corpus of Android applications, D ROID B REAKER achieves high evasion rates with few queries and minimal side effects in both white-box and black-box settings, and drastically reduces detections by commercial malware scanners hosted on VirusTotal.

I. I NTRODUCTION Android is the most widely deployed mobile operating system, with billions of devices and millions of applications across both official and third-party app stores. This scale makes it a prime target for malicious APKs that infiltrate devices to steal data, credentials, or financial information. Malware detectors based on machine learning (ML) have been widely adopted to counter these threats, leveraging large training datasets collected from diverse sources [1]–[3] and exploring a variety of feature representations and models [2], [4], [5]. However, their effectiveness remains limited. Their performance decays quickly as malware evolves over time [6],

and they remain vulnerable to adversarial manipulation of the APK files [4], [7]–[13]. Early work demonstrated this vulnerability via feature-space attacks, i.e., by only changing a small subset of feature values among those provided as input to the classifier, without crafting the corresponding adversarial APKs [4], [7]. Subsequent research has thus questioned their practical applicability and shifted the focus towards problemspace attacks, i.e., attacks that produce functional adversarial APKs by manipulating components such as bytecode, resources, or manifest entries [8]–[10], [13]. In this work, we show that existing problem-space attacks for Android malware detection are far less practical than claimed: coarse-grained injection methods that rely on software transplantation [14] inject entire portions of benign APKs into malicious ones, introducing many unintended sideeffect features and often failing to repackage, causing buildtime failures [8], [10], [12], [13]; fine-grained methods that inject only a smaller subset of components, such as APIs and Permissions, exhibit limited effectiveness [11], [15]–[17], while those that also perform code obfuscation rely on brittle bytecode rewriting, frequently breaking app semantics [9]. Furthermore, we highlight another significant prior work limitation, related to how they test that attacks preserve the initial APK malicious behavior. In particular, prior evaluations validate that the app semantics are preserved using smoke tests that only check installation and basic execution [8], [10], [11], [15], [16], without really assessing whether the modified APK preserves its intended functionality, e.g., by looking at its execution traces when properly stimulated at runtime. We will show that this leads to significantly overestimating attack success rates. For these reasons, we argue that the problem of crafting practical (build-safe) and functional (semanticspreserving) problem-space attacks still represents an open challenge (Sect. II). By practical, we refer to attacks that can be reliably applied without failing to repackage, while by functional, we refer to attacks that avoid runtime crashes and preserve the app semantics. Finally, existing approaches

also lack scalability: unstable manipulations, manual validation, and insufficient functionality testing prevent the reliable generation of attacks and the preservation of behavior at scale. To overcome these issues, we present D ROID B REAKER (Sect. III), a framework for designing practical and functional problem-space attacks, providing the following contributions. (1) Query-efficient white-box and black-box attacks. D ROID B REAKER can be used to stage both white- and blackbox attacks that can drastically reduce the number of queries to the target model (i.e., forward and backward passes). To this end, we define an attack initialization phase whose goal is to retain only manipulations that (i) do not cause buildtime failures, and (ii) cause a significant impact on the target model. We also provide an additional contribution, introducing an encoding trick to show that problem-space attacks can be optimized end-to-end via gradient descent, while elegantly formalizing the presence of side effects [8]. (2) Practical APK manipulations, minimal side effects. Another significant advancement with respect to existing problem-space attacks is that D ROID B REAKER performs reliable fine-grained injection and obfuscation of API calls, app modules, Permissions, and URLs using bytecode-rewriting methods and manipulations that are fully compatible with the Android framework, avoid build-time repackaging failures, and introduce only minimal side effects. (3) Semantics-preserving functionality testing. To preserve semantics, we introduce new functionality tests enforcing runtime equivalence between initial and modified APKs by comparing execution logs and API-level traces, validating that our attacks are functional and do not cause runtime errors. Our experiments (Sect. IV) demonstrate the strong evasive capabilities of D ROID B REAKER against four detectors with distinct feature representations, consistently achieving high evasion rates within only a few queries and with minimal side effects. We further show that the adversarial APKs generated by D ROID B REAKER also impact commercial scanners, reducing detections by roughly half on VirusTotal (VT) [18]. This shows that, for the first time, practical and functional problem-space attacks against Android malware detectors are not only possible but effective at scale. We conclude the paper by summarizing our work, discussing its limitations, and providing future research directions in Sect. V.

(○), obfuscation (○), or both (). We also report: (i) whether the attack is practical, i.e., build safe (✓), or not (p), along with a qualitative assessment of (ii) the amount side-effect features (HIGH for coarse-grained injection methods, and LOW for fine-grained ones); and (iii) the expected effectiveness against diverse detectors (LOW for attacks manipulating few components, MED for coarse-grained injection attacks manipulating many components, and HIGH for attacks combining injection and obfuscation over a large set of components). 3 Functionality Testing. It characterizes the depth of APK functionality validation after manipulation (cf. Sect. II-B), ranging from smoke to runtime testing, and indicates whether validation is automated (✓) or manual (§). We also qualitatively report the functional rate after attack (LOW, MED, HIGH), defined as the fraction of adversarial APKs that preserve the intended behavior. For the attacks considered in our experiments, we report the exact values in Sect. IV. 4 Open Code. It highlights whether attack and corresponding functionality test code is publicly available (✓) or not (p), impacting its reproducibility and re-evaluation. Based on this analysis, we identify fundamental issues undermining current attacks. In particular, many of them fail to preserve the intended behavior and consequently overestimate attack success rates, as they rely on inconsistent or faulty manipulations (Sect. II-A) and incomplete functionality tests (Sect. II-B). We discuss these limitations in detail in Sect. II-C, highlighting that only a few attack implementations are opensource, thereby hindering reproducibility and re-evaluation. A. APK Manipulations We categorize here prior APK manipulations based on the affected components and the strategies used to modify the APK. Further details are provided in Appendix A-A and A-B. 1) APK Components: APKs are compressed archives consisting of: (i) the manifest, declaring the app structure and its required capabilities to the Android OS; (ii) the code (DEX bytecode, disassembled into smali code, and native libraries), implementing the functionalities referenced in the manifest; and (iii) the resources, including non-code app elements, such as User Interface (UI) layouts, images, strings, and styles. We report below six categories of APK components (C1 -C6 ) that are manipulated by current attacks, as detailed in Tab. I. Examples for each category are reported in Appendix A-C. C1 : Application Modules. They correspond to the class names of Activities, Services, Receivers, and Providers declared in the manifest and implemented inside the APK DEX bytecode. C2 : Hardware Features. They are declared in the manifest and grant permission to use specific hardware (e.g., mic, camera). C3 : Permissions. They are declared in the manifest and grant access to specific software capabilities (e.g., sending SMS). C4 : Intent Filters. They are reported in the manifest and describe the external behaviors of invoked app modules. C5 : APIs. They allow to interact with the Android OS. C6 : Strings. Strings (e.g., URLs, IPs) defined in the bytecode.

II. A DVERSARIAL APK S : A RE W E T HERE Y ET ? Previous work on problem-space attacks may give the impression that crafting functional adversarial APKs, i.e., malicious applications that evade detection while preserving runtime behavior, is a solved problem [8]–[13], [15]–[17], [19]. In this work, we demonstrate that ensuring semantic preservation under adversarial manipulation remains a challenging issue, far from being solved. To this end, we first categorize existing attacks in Tab. I along four main dimensions, detailed below. 1 Attack Setting. It captures whether the attack is staged in a white- (□) or black-box (□) setting, or in both (◨) settings. 2 APK Manipulations. This dimension reports the components C1 -C6 (cf. Sect. II-A) modified by the attack via injection

TABLE I: Problem-space attacks for adversarial APKs: 1 Attack Setting ( □ white-box, □ black-box, or ◨ both); 2 APK Manipulations (○ injection, ○ obfuscation, or both) and affected components (C1 -C6 ), with qualitative evaluation of practical (build-safe) manipulations (✓ yes, p no, - not verifiable), side effects and expected effectiveness on different detectors; 3 Functionality Testing (§ manual, ✓ automatic, - not applied), with details of smoke and runtime testing phases, and rate of functional (semantics-preserving) apps; and 4 Open Code availability of attack and functionality tests (✓ yes, p no). 2 APK Manipulations

3 Functionality Testing

4 Open Code

Attack

1 Attack Setting

C1 : App Modules

C2 : Hw. Features

C3 : Permissions

C4 : Intent Filters

C5 : APIs

C6 : Strings

Practical

Side Effects

Effectiveness

Repackaging

Install

Launch

Exec. Logs

Exec. Traces

Functional

Attack

Functionality Test

Runtime

Year (Preprint)

Fine

Coarse

Smoke

Yang et al. [10]

2017

□

○

HIGH

MED

✓

LOW

Pierazzi et al. [8]

2020

□

○

HIGH

MED

✓

LOW

✓

E VADE D ROID [13]

2021

□

○

HIGH

MED

✓

MED

✓

A DV D ROID Z ERO [12]

2023

□

○

MED

✓

MED

✓

A NDROID HIV [16]

2018

□

○

LOW

✓

HIGH

HRAT [19]

2021

□

LOW

✓

HIGH

✓

BAG A MMO [17]

2023

□

○

LOW

✓

HIGH

G EN D ROID [11]

2023

□

○

LOW

✓

HIGH

EAGLE [15]

2023

□

○

LOW

✓

HIGH

ADE [9]

2020

□

○

LOW

HIGH

✓

LOW

✓

◨

○

✓

LOW

HIGH

✓

HIGH

✓

D ROID B REAKER (ours)

effect components that uncontrollably increase the complexity of the resulting APKs. As a consequence, the manipulation process becomes highly unstable and unreliable, especially when many components need to be injected, often leading to malformed or non-functional applications. Our experimental evaluation in Sect. IV shows that these approaches are largely impractical, and achieve only a medium expected effectiveness against diverse detectors. The reason is that they generate significantly suboptimal adversarial APKs, as these manipulations introduce too many uncontrolled side-effect features. This in turn leads to overly optimistic evaluations, which only contribute to spreading a false sense of security [20].

2) Manipulation Strategies: We cover the main methods to craft adversarial APKs: coarse-grained injection via software transplantation and fine-grained injection and obfuscation. Coarse-grained Injection (Software Transplantation). The first set of attacks in Tab. I [8], [10], [12], [13] relies on software transplantation [14], a technique originally proposed to automatically migrate functionalities between software systems. It operates by identifying a target component from a donor, harvesting all its necessary dependencies, and injecting the resulting code slice into the host. In the context of adversarial APKs, software transplantation was first introduced in [10] to migrate components (e.g., API calls and App Modules) across malicious APKs, and extended in subsequent work [8], [12], [13] to inject components from benign APKs into malware samples. More specifically, Pierazzi et al. [8] targets Activities, Receivers, Providers, URLs, API calls, and Permissions; E VADE D ROID [13] only focuses on API calls; and A DV D ROID Z ERO [12] targets Services, Receivers, and Providers (while also injecting Hardware Features, Permissions, and Intent Filters in the manifest file). By construction, the process required to transplant Android components results in the implantation of large APK portions (typically the entire implementation of app modules and their associated dependencies and manifest entries), thus enabling the injection of all APK components listed in Tab. I (C1 -C6 ). These components are added without altering the execution path by injecting code that is not executed at runtime, claiming to preserve the APK semantics by design [8]. However, while effective in principle, this approach introduces a large number of unintended side-

Fine-grained Injection and Obfuscation. The second set of attacks in Tab. I [11], [15]–[17], [19] apply fine-grained manipulations on a restricted subset of APK components, i.e., Permissions, APIs, and Strings. Limiting modifications to a narrow set of components enables them to introduce fewer side-effect features, resulting in more controlled manipulations and a generally higher functional rate than coarse-grained injection attacks. However, their expected effectiveness remains low against detectors based on diverse or more comprehensive feature sets, limiting their practical impact. Among the methods with available code, we verified that HRAT [19] is not practical. It injects and obfuscates methods that are neither framework APIs nor lifecycle methods, and applies code transformations that may break the APK build, e.g., moving a method body into its caller. If register handling is incorrect or exceeds the declared limits, the resulting bytecode fails to compile. ADE [9] is the only attack in this category

that allows injecting and obfuscating multiple components in 1 .class public final Lcom/inmobi/ads/c; a fine-grained manner. However, its flawed implementation 2 .super Lcom/inmobi/commons/core/configs/a; 3 .method static constructor <clinit>()V frequently breaks APKs: its manipulations may (i) leave unre- 4 .registers 8 [...] solved references to obfuscated components, causing crashes 5 6 const-string v4, " https://sdktm.w.inmobi.com " when they are accessed; (ii) prevent retrieving or invoking the 7 [...] const-string v5, "GET" obfuscated elements; and (iii) inject transformed components 8 9 new-instance v0, Ljava/net/HttpURLConnection; whose integration accidentally results in runtime failures. 10 invoke-virtual {v0, v5}, ,→ Ljava/net/HttpURLConnection;-> A Paradigmatic Example. While we defer a detailed 11 setRequestMethod(Ljava/lang/String;)V technical analysis of all these issues to Sect. B-B, we report 12 [...] in Fig. 1 an example of a URL (string) injection via software 13 .end method 14 transplantation [8] (Fig. 1a), and via ADE [9] (Fig. 1b). In the 15 .class public Landroid/telephony/TelephonyManager; first case, the entire class containing the target URL is added, 16 .super Ljava/lang/Object; 17 .method public getDeviceId()Ljava/lang/String; introducing additional dependencies in the form of stub classes 18 .registers 3 new-instance v0, Ljava/lang/RuntimeException; (e.g., android.telephony.TelephonyManager) as 19 20 .local v0, "$r1":Ljava/lang/RuntimeException;, "" side effects to satisfy type references (via FlowDroid [21]) 21 const-string v1, "Stub!" invoke-direct {v0, v1}, Ljava/lang/RuntimeException; and unnecessary components for the attack (e.g., 22 ,→ -><init>(Ljava/lang/String;)V setRequestMethod). In the second case, the URL 23 throw v0 .end local v0 is injected within a register that cannot hold strings, resulting 24 25 .end method in invalid bytecode that breaks the APK during either building or verification. Our approach, instead, overcomes (a) String injection via software transplantation [8]. these limitations by minimizing uncontrolled side effects and 1 .method public static <init>()V .registers 1 providing practical (build-safe) and functional (semantics- 2 3 const-string p0, " https://sdktm.w.inmobi.com " preserving) manipulations (cf. Fig. 3, Sect. III-A). 4 iput-object p1,p0,Ldj;->a:Lcom/m_zxmlmnnew/image/ ,→ pc8aa4a7efb;

5 invoke-direct {p0}, Ljava/lang/Object;-><init>()V 6 return-void 7 .end method

B. Functionality Testing Adversarial APKs must fully preserve their intended malicious behavior after manipulation. We review here how prior work conducted functionality testing to validate that. As summarized in Tab. I, existing approaches can be broadly categorized into two families, i.e., smoke and runtime testing. Smoke Testing. This preliminary validation step checks whether basic structural integrity has been preserved. Typically, it verifies that adversarial APKs can be successfully repackaged and installed on emulators or real devices. As shown in Tab. I, this is often applied in a minimal and inconsistent manner throughout prior work. Some attacks only consider repackaging [11], [15], while most also verify that adversarial APKs can be installed without errors. However, installation tests are typically performed on a small number of samples and frequently rely on manual inspection, providing only weak evidence of the correctness and robustness of the manipulation process. While install failures may indicate severe corruption of the APK, smoke testing does not assess semantics preservation, as the app is never executed. Thus, it ignores runtime errors, crashes, and behavioral deviations that may only manifest during execution, providing no evidence that the intended functionality is actually preserved. Runtime Testing. It aims to assess functionality preservation by observing the execution of adversarial APKs in sandboxes [22] or emulators [9], [17]. In prior work, this is typically achieved by verifying that APKs can be launched and executed without crashing (Launch in Tab. I), and by also checking the presence of specific implanted messages in the Logcat output (Execution Logs in Tab. I).1 In both cases,

(b) String injection via ADE [9].

Fig. 1: Examples of URL (highlighted in blue) string injection. In (a), the entire class TelephonyManager and an API call (in red) are injected as a side effect; in (b), string injection breaks the APK build due to faulty register management.

execution may be stimulated using manual UI inspection [8], [12], [16], [17], [19], or automatic monkey testing [13], [19] simulating random interactions with the app UI. Despite being more informative than smoke testing, these checks still provide only limited guarantees of preserved semantics. While they can confirm that APKs can be executed,2 or that specific log messages are produced, they cannot verify that the initial malicious behavior is fully preserved. This limitation is critical given that malicious logic often executes as background services, without triggering UI interactions or producing observable log events. Moreover, most existing approaches rely on manual inspection, small-scale execution tests, or purely random APK interaction with the Android monkey tool [24], suffering from poor code coverage and limited reproducibility of UI events. This severely limits the ability to conduct systematic, reproducible assessments of semantic preservation at scale. C. What Is Missing? From our analysis, we identify two fundamental limitations preventing existing problem-space attacks from being both 2 The Android OS enforces compliance with the Android Verifier [23] which checks low-level bytecode correctness at class loading time.

1 Logcat is a utility recording runtime debugging and error messages.

practical (build-safe) and functional (semantics-preserving). L1: Ineffective/Unreliable Manipulations. Existing attacks rely on manipulation strategies that are either too coarse or too limited in scope. Coarse-grained approaches based on software transplantation [8], [10], [12], [13] inject entire components and their dependencies, resulting in an uncontrolled inclusion of side-effect features that often destabilize the manipulated APKs, resulting in suboptimal adversarial examples. Finegrained approaches typically support only injection and/or operate on a small subset of components [11], [15], [16], severely limiting their expected effectiveness against diverse detectors. While ADE [9] also attempts fine-grained obfuscations, its flawed implementation frequently breaks APK repackaging. For these reasons, existing attacks remain largely impractical. L2: Inadequate Functionality Testing. Despite claims of functionality preservation, none of the reviewed works employ functionality tests capable of reliably verifying that adversarial APKs preserve their original behavior. Smoke testing only validates repackaging and installation, while runtime testing typically checks execution without crashes and/or the presence of specific log messages, providing at best weak behavioral evidence for a few manually inspected apps. These checks fail to systematically capture deviations in malicious behavior, which often executes in background services without observable UI interactions or logs. As a result, prior work systematically overestimates attack success rates and lacks scalable, sound functionality tests for semantic validation. L3: Lack of Open Code. Only a limited number of works make their attack implementations publicly available, and even among these, reproducibility is often hampered by bugs and insufficient documentation [25]. Moreover, none of the existing approaches release the code used for functionality testing, hindering reproducibility and independent re-evaluation. To overcome these limitations, in Sect. III we introduce D ROID B REAKER, a novel framework that performs practical (build-safe) and functional (semantics-preserving) whiteand black-box attacks, outperforming competing methods. In particular, D ROID B REAKER exhibits an improved tradeoff between attack success rate and number of required manipulations, minimizing side-effect features while preserving the intended behavior of adversarial APKs.

space and make optimization significantly more efficient. The second phase is the attack optimization (Sect. III-B), performed either through a gradient-based (white-box) method or a genetic (black-box) algorithm. The third phase is the functionality testing (Sect. III-C), in which D ROID B REAKER evaluates the functionality of the initial and adversarial APKs using our novel testing procedure to verify that the two samples exhibit the same intended behavior. Problem Formulation. Given an input APK file z ∈ Z, the detector first extracts a feature vector representation x = ϕ(z) ∈ X ⊆ Rd . The detector then outputs f (x) ∈ R, i.e., a confidence value indicating how likely the input sample belongs to the malicious class. The prediction is obtained by thresholding this value: if f (x) > 0, the input sample is labeled as malicious, otherwise as legitimate.3 In this context, a problem-space attack aims to have an input malware sample misclassified as legitimate by manipulating its components, as defined in Sect. II-A1. The attack can thus be formulated as: t⋆ ∈ arg min f (ϕ(h(z, t))), ∥t∥0 ≤λ

(1)

where h is the manipulation function, parameterized by a set of k available transformations that inject/obfuscate components t ∈ T = {0, 1}k , while λ ∈ N upper bounds the number of applied transformations.4 The corresponding adversarial APK z ⋆ can then be obtained by applying the optimal transformations t⋆ to the initial malware APK z, as z ⋆ = h(z, t⋆ ). Threat Modeling. We consider attacks that aim to evade detection at test time by manipulating malware samples within the feasible transformation set T . In the white-box case, the attacker knows the feature mapping ϕ, the resulting feature vector x, and the scoring function f , enabling direct optimization of Problem (1). In the black-box case, the attacker lacks access to ϕ, x, and model parameters, and can only interact with the detector as an oracle by querying modified APKs and observing its output f . In both cases, the attack must satisfy the constraints defined in Section II-A1. A. Attack Initialization To be query-efficient, our attacks are initialized by defining the transformation set T as a subset of k transformations that are both (i) build-safe (preserving correct repackaging) and (ii) model-influential (maximizing impact on the target model). (1) Build-safe Transformations. We first construct a set of components by including those that can be injected from a set of benign APKs, and those that can be obfuscated from the malicious input APK z. We then exclude from this set the components that, when injected or obfuscated, make the APK build fail. To this end, we attempt to inject (or obfuscate) all the selected components into the APK according to the Android structure and context, and compile. If compilation/repackaging fails, we split the set into smaller groups and repeat the process until every single problematic component is identified.

III. D ROID B REAKER : P RACTICAL AND F UNCTIONAL P ROBLEM - SPACE ATTACKS FOR A DVERSARIAL APK S We present here D ROID B REAKER, our novel framework for query-efficient white- and black-box problem-space attacks. Thanks to robust, fine-grained manipulations, it supports both injecting components from benign APKs and obfuscating elements within the target APK, preserving semantics while minimizing failures and side effects. The D ROID B REAKER workflow, shown in Fig. 2, consists of three main phases. In the attack initialization phase (Sect. III-A), it selects a reduced set of APK components eligible for injection or obfuscation, retaining those that do not compromise app repackaging and are most relevant to the target model. This step is conducted in both white- and black-box attacks to reduce the component

3 We will use f (z) as shorthand for f (ϕ(z)) when clear from context. 4 While f is defined here as the confidence of the attacked detector, our formulation also holds if one alternatively defines f as a suitable loss function.

Attack Initialization

Functionality Testing

Attack Optimization

Hooking Extraction Phase APK Decoding

Component Injection and Obfuscation

Build-safe and Model-influential Transformations

Review Phase

Execution Phase

Orig data

Adv data

API trace

API Extraction

APK Building

= Malware Detector Top-k Transformations t ∈ T

Logs

App UI

Blocked

Evaded

Fig. 2: D ROID B REAKER workflow. (1) Attack Initialization selects the top-k transformations, discarding those that break repackaging or have negligible impact on the model. (2) Attack Optimization manipulates APK components via query-efficient white- and black-box attacks. (3) Functionality Testing uses dynamic analysis to ensure semantics preservation.

This step does not require querying the target detector and guarantees that only build-safe transformations are kept. (2) Model-influential Transformations. In the second part of the attack initialization phase, we identify which transformations have the largest impact on the detector f . In the whitebox setting, this requires determining how each transformation influences the features, as described in Sect. III-B1. In the black-box setting, we query the detector by applying all candidate transformations affecting the components in C1 -C6 independently, performing one query per set (q = 6 in total) to estimate their impact on f . We then retain only the top-ranked transformations, discarding those with no effect. As shown in Sect. IV-B4, this step reduces the transformations from tens to only a few thousand, yielding a compact set T of k transformations that improves the attack query efficiency. Practical Manipulations: We define here the practical, fine-grained manipulations implemented in D ROID B REAKER, along with the corresponding modified APK components. The proposed manipulations are divided into obfuscation and injection, and applied in a specific order to preserve functionality. Concrete examples are reported in Sect. B-C. (1) Component Obfuscation. These manipulations are used to obfuscate and increase the source code complexity by modifying class names, strings, and changing the API invocation chain to alter the Function Call Graph (FCG), i.e., the graph of the API calls within the program. The primary objective is to hide specific components from the target detector that may fail to recognize their presence within the code. App-Module Class Renaming. We replace occurrences of App Modules class identifiers (C1 ) in both the manifest and DEX files with meaningless names. To avoid build-time repackaging failures, we rename only the class names while preserving the original package and class directory structure,

without renaming other classes in the same package. This operation is feasible because Android resolves classes through internal identifiers rather than human-readable names, as long as references remain coherent. API Indirection and Reflection. These techniques operate on API calls (C5 ) to modify the FCG. First, indirection replaces the call to the original method γo with that to a wrapper method γw . Then, (Java) reflection is used to indirectly invoke γo , thereby hiding the API call from the source code. Unlike the other injection and obfuscation methods, indirection must be applied before reflection to prevent the original method from being hidden by a reflective call, which could cause the application to crash. Furthermore, to avoid runtime errors, reflection is applied only to declared Android and Java framework APIs, excluding interfaces and abstract methods. String Encryption. We encrypt constant strings (C6 ) containing URLs and IP addresses, making it more challenging to identify patterns or the presence of specific strings in the code. (2) Component Injection. We support injecting Strings (i.e., URLs and IP addresses), API calls, Application Modules, Permissions, and Hardware Features into the original APKs. These components are expected to affect the feature representations of static analysis–based detectors, even if they are not used at runtime. By operating at fine granularity, we inject only a minimal, targeted set of components rather than performing coarse-grained injections, minimizing side-effect features, build failures, and unintended behavioral changes. App-Module Injection. This technique involves inserting additional Activities, Services, Receivers, and Providers (C1 ) with the corresponding Intent Filters (C4 ) in the manifest. To keep the app functional, we decided to set the enabled attribute of newly added app modules to false, ensuring that the Android verifier at startup does not check for the existence

1 .method public static HdAqmYyilQzcHQlj()V 2 .registers 1 3 const-string v0, " https://sdktm.w.inmobi.com " 4 return-void 5 .end method

Fig. 3: D ROID B REAKER URL (string) injection (in blue).

-0.5

t2 0

URL: https://sdktm.w.inmobi.com/sdkpubreq

1.0

-1

API: Landroid/telephony/...;->getDeviceId

1.0

Side-effect: Ljava/.../reflect/Method;->invoke

∇tf=

-0.5

Fig. 4: Modeling side-effect features via encoding E. of the corresponding classes inside APKs’ DEX code. Hardware Feature and Permission Injection. We inject Hardware Features (C2 ) and Permissions (C3 ) by adding new entries in the manifest. These injections are inherently semantics-preserving because they do not introduce executable code or runtime behavior that could disrupt functionality. API Injection. We inject API calls (C5 ) into nonreachable code paths, ensuring they are never executed but remain visible to static detectors, by defining a new DEX class5 and a void wrapper method that, when called, does not affect the APK’s context (e.g., the original registers’ content). To prevent runtime failures due to Android Verifier checks, we inject only parameter-free APIs, keeping manipulations minimal and avoiding the need to manage parameter references. String Injection. We inject constant strings (C6 ) within a void wrapper method added to an existing class. As for API injection, this avoids disrupting the app context when called. Additionally, this enables the use of all 15 available registers within a method, preventing runtime syntax or register-allocation errors. This manipulation is inherently functionality-preserving, as constant string declarations do not imply code execution. Fig. 3 illustrates an example of string injection within its ad-hoc wrapper method, which manipulates the registers in accordance with the Android structure, and prevents errors caused by brittle approaches (cf. Fig. 1b). Key Improvements. D ROID B REAKER improves upon ADE by ensuring consistency and compliance with Android runtime constraints, thereby avoiding crashes and verification errors. Moreover, our transformations are semantically sound and complete, preserving app functionality while still providing effective obfuscation (cf. Sect. B-C). Additionally, our manipulations are lightweight compared to software transplantation attacks, as they introduce minimal code changes, improving efficiency while avoiding the injection of large code components or unnecessary dependencies. This also minimizes the risk of bugs and errors caused by third-party tools, affecting either the attacks or the functionality of the produced APKs.

with respect to t, the solution to Problem (1) could be approximated via gradient descent, by computing: ∇t f (ϕ(h(z, t))) =

∂f ∂ϕ ∂h(z, t) . ∂ϕ ∂h ∂t

(2)

However, while f is typically differentiable, the same does not hold for feature extraction ϕ and manipulation h functions, as both often involve non-differentiable operations, making it also difficult to keep track of side effects [8]. To address these issues, we introduce an encoding trick that renders the entire pipeline differentiable, enabling end-to-end gradient descent. Encoding Trick. Let E ∈ {−1, 0, 1}d×k be an encoding matrix specifying how each ti in t affects the feature values (−1 for obfuscation, 0 for no change, +1 for injection). The problem-space to feature-space mapping thus becomes: x′ = ϕ(h(z, t)) = x + ΠX (Et),

(3)

where the projection operator ΠX keeps the modified x′ within the feasible feature space. Although each transformation primarily aims to modify a single component, its application may introduce side-effect features, justifying the use of a non-linear projection.6 Under this setting, Eq. 1 becomes end-to-end differentiable, enabling gradient descent under an ℓ0 sparsity constraint on t. In particular, it holds ∂h(z,t) = E (assuming that the gradient of ΠX is that ∂ϕ ∂h ∂t approximated via straight-through estimation). Hence, for a linear detector f (x) = w⊤ x + b, one obtains ∇t f = w⊤ E. Under the ℓ0 constraint on t, this reduces to a closedform solution, i.e., selecting the top-λ entries of w⊤ E in magnitude. For a non-linear model, one can apply the same principle by iteratively selecting the η transformations with the largest absolute gradient components, applying them, and recomputing the gradient on the updated sample. This amounts to performing gradient descent over Boolean variables, with step size η. Our white-box attack procedure is given as Alg. 1. Modeling Side-effect Features. Fig. 4 reports an example in which we attack a linear model with three features, assuming that the input APK has a feature representation x = (0, 1, 0)⊤ . Under an ℓ0 constraint with λ = 1 (i.e., applying one transformation only), an attack that does not properly account for sideeffect features would apply a problem-space transformation

B. Attack Optimization We describe here how Problem (1) can be solved by developing our white-box and black-box attack strategies. 1) White-box Attack: Assuming white-box access to a detector whose decision function f is end-to-end differentiable

6 For example, considering Boolean features as in Drebin [2], where x ∈ {0, 1}d , it may happen that two distinct transformations ti and tj attempt to inject the same feature xi . Before projection, the mapping Et would yield x′i = 2, which lies outside the valid Boolean domain. The projection operator ΠX resolves this by clipping the value to x′i = 1, ensuring that x′ ∈ {0, 1}d .

5 A new DEX class is needed to overcome the 65,536 method reference limit which could raise Verifier Exceptions if not considered.

N transformation vectors ti , where ∥ti ∥0 ≤ λ for each i = 1, . . . , N . Each vector is constructed by sampling and combining up to λ transformations from the k candidates in T , prioritizing those that had the greatest impact on the detector during the initialization phase. The corresponding N modified APKs are evaluated using the scoring function f . The selection step then iteratively extracts from P the best candidate t′ , identified by the lowest value of f ((h(z, t′ ))). The mutation step randomly alters one or more entries of t′ , followed by the crossover step, which mixes some entries of t′ with others in P . This allows thoroughly exploring the solution space until the query budget Q is exhausted or the detector is evaded.

Algorithm 1: D ROID B REAKER White-box Attack Input : z, the input malware; B, the benign APKs; f , the detector; k, the number of transformations selected by the attack initialization; λ, the perturbation budget; η, the step size; Q, the number of iterations. Output: z ⋆ , the adversarial APK. T ← attack initialization(z, B, f, k); q ← 0; E ← build encoding(f, T ); ′ ⋆ 3 z , z ← z; t′ ← 0; s′ , s⋆ ← f (z); ′ 4 while q < Q or s ≥ 0 do ′ 5 t ← select transformations(∇t f (z ′ ), η, λ); 6 z ′ ← h(z, t′ ); s′ ← f (z ′ ); 7 if s′ < s⋆ then 8 z ⋆ ← z ′ ; s⋆ ← s′ ; 1 2

9 10

C. Functionality Testing To validate that our attacks preserve semantics, addressing the limitations discussed in Sect. II-B, we extend functionality testing beyond basic smoke testing. We use DroidBot [26] to install (Install), execute, and interact with the apps (Launch); Logcat to capture runtime crashes (Exec. Logs); and Frida [27] to collect API traces from both the initial and the modified (adversarial) APK (Exec. Traces). We (i) simulate users’ interaction following a depth-first strategy on UI elements, guaranteeing consistent evaluations over two different runs of the same app, (ii) cover the majority of the code at runtime, enabling the Android Verifier to check DEX classes, and (iii) dynamically instrument apps hooking APIs, rather than only relying on static instrumentation (e.g., Soot [28]), ensuring that the traces accurately reflect runtime behavior. We also use a physical device instead of Android Studio emulators for two main reasons: (i) many modern malware include anti-sandboxing techniques that detect and evade emulated environments [29]; and (ii) some apps in our dataset lack x86-compatible libraries, preventing installation on emulators. Fig. 2 provides an overview of the proposed semantics-preserving functionality testing, consisting of three main stages, while Alg. 3 formalizes the approach. (a) Hooking Extraction. This stage extracts the Android APIs to be monitored at runtime by Frida from the input APK (line 2). The same set of APIs is monitored for both original and adversarial APKs, ensuring consistency and fairness across multiple runs. Additionally, we restricted the scope to APIs belonging to packages that are potentially securitysensitive or relevant for behavioral profiling (e.g., data storage, networking, and inter-component communication APIs). (b) Execution. This stage installs and automatically interacts with both original (line 3) and adversarial (line 5) APKs, generating Android runtime logs, which include messages from the Android Verifier and the APK’s code, and API-call traces characterizing the behavioral profile of each APK. (c) Review. The final stage involves comparing the behavior of the original and adversarial APKs. Specifically, we check (i) the absence of fatal exceptions in the Logcat logs (line 7), (ii) the absence of log entries incorporated within the API injection wrapper function (line 9), and (iii) whether the functions hooked in the original APK are also present in the adversarial APK (line 11). This ensures that obfuscated APIs are correctly

q ←q+1 ; return z ⋆ ;

that obfuscates feature 2, to maximally decrease f . While obfuscating feature 2 alone would be optimal, applying this manipulation also unexpectedly injects feature 3 as a side effect, whose positive weight cancels the intended decrease, yielding no net benefit in f . By contrast, our encoding trick makes such interactions explicit by backpropagating gradients through E. In fact, ∇t f = w⊤ E = (−0.5, 0) indicates that only the first transformation is useful, despite feature 2 having a higher weight in isolation. Hence, by automatically accounting for side effects, our attack can find better transformations and more effective adversarial examples.7 Let us finally remark that this approach is useful when the encoding matrix E can be reliably estimated from the available transformations and the feature representation. Although prior work has argued that this is generally infeasible, even for Drebin [8], we demonstrate that it can, in fact, be constructed efficiently, enabling end-to-end, gradient-based attacks in the problem space. In particular, for Drebin, a simple string-matching procedure is sufficient to identify which features are injected or obfuscated by each transformation, as validated in our experiments (Sect. IV). 2) Black-box Attack: Problem (1) can also be solved in a black-box setting, querying the detector with different input APKs and observing its output, without exploiting any knowledge of its internal parameters. To this end, we leverage the genetic algorithm given as Alg. 2. Our attack is initialized by building the set T of k candidate transformations as described in Sect. III-A. It then generates an initial population P of 7 While the greedy optimization strategy by Pierazzi et al. [8] accounts for the side-effect features present in the organs to be transplanted, we will show that it completely ignores those introduced when importing required dependencies via FlowDroid, as these cannot be feasibly estimated a priori. This leads to a substantial underestimation of the total number of side effects, resulting in many uncontrolled injections. Our fine-grained attack overcomes this limitation by requiring significantly fewer injections while exhibiting almost no side-effect features, as shown in our experiments in Sect. IV.

Algorithm 2: D ROID B REAKER Black-box Attack Input : z, the input malware; B, the benign APKs; f , the detector; k, the number of transformations selected during initialization; λ, the perturbation budget; N , the population size; Q, the number of iterations. Output: z ⋆ , the adversarial APK.

Algorithm 3: Functionality Check Input : List of (AP K O , AP K A ) Output: Functional or non-functional APK foreach (AP K O , AP K A ) ∈ Input List do APIsO ← extract APIs(AP K O ); 3 logO , logHookO ← instrument(AP K O , APIsO );

T ← attack initialization(z, B, f, k); q ← 6; S ← ∅; 2 P ← initialize population(N, k, λ); ⋆ 3 z ← z; s⋆ ← f (z) ; 4 for i = 1 : N do 5 zi ← h(z, ti ); s′ ← f (zi ); S ← S ∪ s′ ; q = q + 1; 6 if s′ < 0 then 7 z ⋆ ← zi ; 8 return z ⋆ ;

reset environment();

logA , logHookA ← instrument(AP K A , APIsO );

if ∃e ∈ logA : F atal(e) then return AP K A non-functional;

7 8 9

while q < Q or s′ ≥ 0 do 10 t′ ← selection(P , S); 11 t′ ← mutate(t′ ) and crossover(t′ , P ); 12 P ← P ∪ t′ ; 13 z ′ ← h(z, t′ ); s′ ← f (z ′ ); S ← S ∪ s′ ; 14 if s′ < s⋆ then 15 z ⋆ ← z ′ ; s⋆ ← s′ ; 16 17

if logHookO ̸⊂ logHookA then return AP K A non-functional;

return AP K A functional;

if ∃e ∈ logA : Instr(e) then return AP K A non-functional;

Fatal(e) evaluates whether log entry e corresponds to a fatal exception. Instr (e) evaluates whether e corresponds to a log inserted by API injection.

part SecSVM [4], selecting the top 10,000 features. In the black-box setting, to assess our attacks against diverse feature representations and models, we consider four distinct detectors: Drebin and SecSVM (implementation from [32] with full feature set), APIGraph [33] (original implementation), and MaMaDroid [5] (implementation from [12]). We provide their complete performance metrics, in Tab. VI. As MaMaDroid performs poorly on the ELSA dataset, we omit it from the corresponding results. We also consider commercial scanners from VT to evaluate the real-world impact of our attacks. Evaluation Metrics. The evaluation of attack performance considers four main aspects: (i) attack success rate (ASR), (ii) attack cost (for black-box setting only), i.e., the number of queries to the target model, (iii) number of modified components, including both injections and obfuscations, and (iv) final app size. We perform automated static inspection using Androguard to quantify the effectively altered components. Additionally, we compute the Functional Rate, i.e., the fraction of apps that successfully pass the functionality testing. Baselines. In the white-box setting, we compare D ROID B REAKER with Pierazzi et al. [8] and ADE [9]. Their original implementations present several issues that prevent the generation of functional APKs or result in complete failure of the attack process [25], as detailed in Sect. B-A and B-B. For this reason, we apply two fixes to Pierazzi et al. [8] and report results for the original and patched versions, while for ADE we evaluate its functional rate using the adversarial APKs provided by the authors, as fixing it would have required a substantial rewrite of its implementation. We also consider the feature-space attack by Demontis et al. [4], which simulates the injection and obfuscation of individual features without side effects, serving as a worst-case baseline that evades detection with the minimum number of modifications. In the black-box setting, we compare our method with the

q ← q + 1; return z ⋆ ;

reached following the same execution flow of the original variant, and the injected APIs are not invoked. To summarize, our methodology goes beyond smoke testing or incomplete analysis by dynamically executing apps on a real device, checking not only Android execution logs for runtime crashes but also the runtime API traces, thereby enabling a consistent comparison between original and adversarial APKs. IV. E XPERIMENTAL E VALUATION We describe below the experimental setup used to evaluate D ROID B REAKER in both white- and black-box attack settings. Datasets. We conduct experiments using APG [8] and ELSA [30] datasets. Both consist of APKs sampled from AndroZoo [3] and labeled based on the number of detections p reported by VT. A sample is considered as benign if p = 0 and malicious if p ≥ 4 for APG and p ≥ 10 for ELSA. APG consists of 89,335 training samples (2014-2017) and 62,302 test samples (2018), while ELSA contains 75,000 training apps (2017-2019) and 6,250 test APKs (2020-2022). We use APG dataset for the white-box setting as in [8], and both datasets in the black-box setting. We randomly select 100 true positive APKs from each setting-dataset pair, using APKiD to exclude packers and reduce unrelated crashes, and annotate them with malware families via the AVClass tool [31]. Moreover, as no valid APKs are generated by ADE, we only test the functionality of the publicly available adversarial APKs. Detectors. Following [8], in the white-box setting, we evaluate our attack on Drebin [2] and its adversarially robust counter-

Drebin (APG)

Attack Success Rate

1.0

0.8

0.6

0.4

0.2

0.2 0

3 FS

9 12 15 18 21

0.0

Modified features DB

SecSVM (APG)

1.0

0.8

0.0

0 3 6 9 12 15 18 21 24 27

Modified features

Pierazzi et al. (estimated)

Pierazzi et al. (actual)

Fig. 5: White-box ASR vs. number of modified features on APG dataset for feature-space attack (FS), D ROID B REAKER (DB), and Pierazzi et al. For the latter, we report both the manipulations estimated prior to (dashed curve) and those applied after (solid curve) software transplantation.

104

Modified Components

state-of-the-art black-box attack A DV D ROID Z ERO [12], which assumes the target detector is unknown and achieves strong performance across various detection models. We use the original implementation provided by the authors for evaluation. Attack Configurations. In the white-box setting, we set an ℓ0 constraint of 50, representing the maximum number of features that the attack is allowed to modify. For Pierazzi et al. [8], we consider 500 features and 5 benign donors per feature for organ harvesting and run it in the low-confidence setting. In the black-box setting, we evaluate D ROID B REAKER with a perturbation budget λ = 300, allowing the application of 300 transformations. As in [12], the number of queries to the target detector is limited to Q = 40. We extract the candidate components for injection from a sample B of 100 benign APKs from each dataset; A DV D ROID Z ERO uses all of them, while D ROID B REAKER uses only 30. Up to 6 queries are reserved for the attack initialization, one for each APK component. D ROID B REAKER Implementation. We use Androguard 4.1.3 [34] to extract information from manifest and bytecode (i.e., Application Modules, Permissions, Hardware Features, Strings, and APIs). We inject and obfuscate only public APIs from Android and Java frameworks, excluding interfaces and abstract methods. We obfuscate only suspicious APIs as identified by Backes et al. [35]. We design and implement all fine-grained manipulations from scratch, relying on ObfuscAPK [36], ApkTool 2.10, and the official Android apksigner for APK smali-processing, rebuilding and resigning, respectively. For the white-box attack, we build the encoding matrix E by matching each feature with the related transformations. If we need to obfuscate several components to change a feature value from 1 to 0, we aggregate them into a single transformation if there are up to 5; otherwise, we discard them. If it is not possible to exactly determine the encoding matrix, it can be approximated to run the attack. In this case, if unexpected side effects are found, we use a greedy coordinate descent approach by iteratively applying one transformation at a time, discarding those that do not improve the solution. Functionality Testing Implementation. We evaluate functionality preservation after the attack through dynamic analysis, using Droidbot 1.0.2 for interaction, preferred for its reliability over Monkey [24], and Frida 16.6.6 for dynamic instrumentation and monitoring8 . All experiments are conducted on a OnePlus 6 running Android 11 (API level 30, Google APIs) with 8GB RAM. We select apps targeting API level between 26 and 30 by checking the min_sdk_level, max_sdk_level, and compile_sdk fields in the APK manifest. To compare our framework against prior methods [12], [16], we also conduct an ablation study using (i) smoke testing and (ii) post-execution logcat comparison. For smoke testing, for each attack and setting (i.e., whiteand black-box), we randomly sample 100 adversarial APKs from those generated against all detectors, ensuring that the corresponding original APKs are the same across settings. Due

DroidBreaker (APG)

104

103

102

101

100

100 Drebin

SecSVM

Pierazzi et al. (APG)

Drebin

SecSVM

Fig. 6: Boxplots of the distribution of the number of modified components by D ROID B REAKER and Pierazzi et al.’s attack [8] against Drebin and SecSVM on the APG dataset.

to the cost of dynamic analysis, we randomly sample 50 of them and execute each original–adversarial pair for 4 minutes, following previous work [37]. For comparison with ADE, we select an equivalent number of adversarial APKs released by the authors, pairing each with its original version. A. Results for White-Box Attacks 1) Attack Success Rate: Our results in Fig. 5 show that both the feature-space attack [4] and D ROID B REAKER always evade Drebin and SecSVM by manipulating, on average, 1.0 and 6.2 features, respectively. Despite operating in problem space, D ROID B REAKER can be as effective as worst-case feature-space attacks, modifying the same number of features without side effects. The original implementation of Pierazzi et al. [8] successfully builds only 4/100 APKs on Drebin and none on SecSVM. As explained in Sect. B-A, we trace this back to an incompatibility between the opaque predicate used to inject the code snippets and the instrumentation tool used to perform the transplantation. After fixing it, the attack always succeeds but requires modifying a larger number of features: on average, 20.7 and 26.6 on Drebin and SecSVM, respectively. Let us remark that Pierazzi et al.’s attack only accounts for side-effect features present in the organs before transplan-

8 A rooted device is required for API hooking and UI interaction. This onetime setup does not affect app behavior since root checks can be bypassed.

TABLE II: Average Functional Rate on the APG dataset (white-box). Smoke testing is verified for all applications, whereas runtime testing is verified only on a random subset.

framework classes added by FlowDroid include an incorrect synchronized access flag, not supported by the Android DEX specification. We thus apply a second fix to the attack implementation by automatically identifying and removing all unnecessary framework classes added by FlowDroid. After that, all APKs are successfully executed and tested without DEX verification failures, but only 38 passed the Execution Trace. In fact, even if the original code is not directly modified, the injection still influences execution through the added opaque predicates that protect only the injected class. Some API calls may thus not be triggered at runtime, as in the original APKs, leading to differences in observed behavior. ADE. As no APK from our datasets was correctly repackaged by ADE, we evaluate it on their dataset. Among the 50 APKs tested, only 8 remain functional due to the significant implementation flaws. These issues disrupt the APK execution and structure, leading to runtime crashes in 30 apps, as detailed in Appendix B-B. Specifically, when injecting strings (e.g., URLs), ADE sometimes places them in inappropriate registers, causing type and runtime errors. Additionally, incorrect module-level obfuscation results in class renaming errors, preventing reflective calls from finding the necessary classes. These results clearly demonstrate that our fine-grained manipulations preserve the functionality of nearly all samples. As detailed in Sect. III-A, this is achieved because our perturbations are carefully designed to leave the APK’s execution context intact, ensuring that no injected or obfuscated components interfere with the original app behavior.

Functionality Test Attack

Smoke

Exec. Logs

Exec. Traces

D ROID B REAKER Pierazzi et al. [8] (original) Pierazzi et al. [8] (opaque pred. fix) Pierazzi et al. [8] (FlowDroid fix) ADE [9]

100/100 4/4 100/100 100/100 100/100

50/50 0/4 0/50 50/50 20/50

46/50 0/4 0/50 32/50 8/50

tation (on average, 5.0 and 13.3 on Drebin and SecSVM, respectively), while ignoring all the additional ones injected by FlowDroid when importing the required dependencies. Finally, despite our efforts to address their implementation issues, ADE [9] fails to produce any APK. 2) Analysis of Adversarial APKs: To assess how the feature-space modifications are reflected in the problem-space, we quantify the increase in size and the number of components modified in the generated adversarial APKs. On average, D ROID B REAKER increases the adversarial APKs size by only 0.17% (approximately 0.01 MB) compared to their original counterparts, modifying 8.6 components. The small difference between the average number of manipulated features and components by D ROID B REAKER is due to additional modifications that are sometimes required to preserve app functionality, as discussed in Sect. III-A. Conversely, Pierazzi et al. [8] produces a size increase of 23.87% (approximately 1 MB), modifying 913.5 components on average. These results, reported in Fig. 6, confirm that the side effects of D ROID B REAKER manipulations are negligible in both feature- and problemspace. On the other hand, transplantation-based attacks require modifying hundreds of components by injecting large amounts of code, even to manipulate a single feature. 3) Functionality Check: Results in Tab. II show a large difference across the considered testing levels, indicating that testing without API trace analysis may misclassify APKs as functional despite behavioral deviations. D ROID B REAKER. Our analysis reveals that 46/50 apps from the APG dataset remain operational. Among the nonfunctional cases, 2 APKs fail due to ApkTool decompilation issues, leading to the loss of essential files due to antirepackaging mechanisms. Manual decompilation and recompilation of these APKs (without any changes) also result in faults, indicating the issue is unrelated to our attack framework. For the other 2 apps, Frida cannot fully reconstruct the API call trace as some classes were absent during instrumentation (a known limitation of dynamic hooking frameworks). Pierazzi et al. We first test the APKs produced by the original version and those obtained after fixing the opaque predicate code (see Appendix B-A for more details). All of them fail to execute at runtime despite being successfully installed. As specified in Appendix B-A, this occurs during app startup, when the Android OS cannot verify all DEX files added by FlowDroid during software transplantation (including both organs and their dependencies). In particular, the Android

B. Results for Black-Box Attacks 1) Attack Success Rate: Tab. III reports our attack’s success rates compared to A DV D ROID Z ERO [12], for different query budgets and datasets. D ROID B REAKER achieves an average ASR of 96% on APG dataset and 85.33% on ELSA within just 10 queries. For the same number of queries, A DV D ROID Z ERO shows only modest effectiveness (on average, 68.5% on APG and 11.33% on ELSA), while achieving maximum average ASR of 84% on APG and 31.33% on ELSA when using Q = 40 queries. While APIGraph proves to be the most resilient model for both datasets, D ROID B REAKER effectively evades it on both APG and ELSA, reporting 95% and 85% ASR, respectively, compared to 70% and 30% ASR of A DVD ROID Z ERO. These results underscore D ROID B REAKER ’s effectiveness across different datasets and detectors, attributed to its model-agnostic design and strategic manipulation choices. 2) Analysis of Adversarial APKs: We compare the APKs produced by our attack with those generated by A DVD ROID Z ERO in terms of app size and number of modified components. On average, D ROID B REAKER increases the app size by only 0.65% (≈0.04 MB), compared to about 12% (≈1 MB) for A DV D ROID Z ERO, consistently across datasets. Fig. 7 reports boxplots of the distribution of modified components, including side effects, introduced by D ROID B REAKER and A DV D ROID Z ERO across the given models. Our attack results in an average of 337 and 328 modifications on the APG and ELSA datasets, respectively, corresponding to an order-

TABLE III: Black-box ASR per query budget (Q) for D ROID B REAKER and A DV D ROID Z ERO on 100 APKs. The main ASR values report the raw attack success rate, while the values in parentheses account for functionality and are estimated by multiplying the raw ASR by the average functional rate reported in Tab. IV for each attack. APG DS

ELSA DS

Attack

Drebin

SecSVM

APIGraph

MaMaDroid

Drebin

SecSVM

APIGraph

D ROID B REAKER (ours)

10 20 30 40

94% (86%) 94% (86%) 94% (86%) 94% (86%)

96% (88%) 96% (88%) 96% (88%) 96% (88%)

94% (86%) 95% (87%) 95% (87%) 95% (87%)

100% (92%) 100% (92%) 100% (92%) 100% (92%)

95% (87%) 96% (88%) 96% (88%) 96% (88%)

95% (87%) 95% (87%) 95% (87%) 95% (87%)

66% (61%) 77% (71%) 82% (75%) 85% (78%)

A DV D ROID Z ERO [12]

10 20 30 40

65% (37%) 80% (46%) 82% (47%) 84% (48%)

76% (43%) 85% (48%) 88% (50%) 89% (51%)

45% (26%) 64% (36%) 70% (40%) 70% (40%)

88% (50%) 91% (52%) 92% (53%) 93% (53%)

10% (6%) 16% (9%) 27% (15%) 31% (18%)

15% (8%) 29% (16%) 31% (18%) 33% (19%)

9% (5%) 18% (10%) 27% (15%) 30% (17%)

DroidBreaker (APG)

Modified Components

105

AdvDroidZero (APG)

DroidBreaker (ELSA)

AdvDroidZero (ELSA)

104 103 102 101 100

Dre

bin

SVM IGraph aDroid Sec AP MaM

bin

Dre

SVM

Sec

rap

APIG

bin

id Dro

Dre

a MaM

SVM

Sec

bin

rap

APIG

SVM

Dre

Sec

h rap

APIG

Fig. 7: Boxplots of the distribution of the number of modified components by D ROID B REAKER and A DV D ROID Z ERO for APG (left) and ELSA (right), highlighting how D ROID B REAKER requires 10-30× fewer changes to APKs to evade detection. TABLE IV: Average Functional Rate over APG and ELSA datasets (black-box). Smoke testing is verified for all applications, while runtime testing is verified on a random subset. D ROID B REAKER successfully passes runtime validation on 92% of the cases, while A DV D ROID Z ERO stops at 56%.

it injects benign code blocks, often introducing incompatible logic and violating Android Verifier’s structural constraints. Such insertions can cause runtime errors, like java.lang.NoClassDefFoundError from missing classes and java.lang.IllegalAccessException from unauthorized access, and disrupt interactions among original components, affecting runtime behavior.

Functionality Test Smoke

Exec. Logs

Exec. Traces

D ROID B REAKER A DV D ROID Z ERO [12]

100/100 66/100

50/50 42/50

46/50 (92%) 28/50 (56%)

1.0

Attack Success Rate

Attack

of-magnitude reduction (between 10× and 30×) compared to A DV D ROID Z ERO, which produces substantially more modifications, averaging 3,817 and 9,317 on the same datasets. 3) Functionality Check: We apply here the same evaluation as in Sect. IV-A3. The results are reported in Tab. IV. D ROID B REAKER. When functionality is evaluated via smoke tests and execution logs, D ROID B REAKER causes no crash. When execution traces are also considered, on average 46 out of 50 apps across both datasets preserve their behavior. As in the white-box case, the remaining apps fail during execution for reasons unrelated to our attack, as detailed in Sect. IV-A3. A DV D ROID Z ERO. On average, A DV D ROID Z ERO produces 66 APKs out of 100 across both datasets, but only 28 remain functional. This is mainly due to how

0.8 0.6 0.4 0.2 0.0

APIGraph - BS APIGraph - BS + MI Transformations

Number of Queries

Fig. 8: ASR of D ROID B REAKER against APIGraph with ELSA dataset, using build-safe (green line) and build-safe + model-influential transformations (orange line). 4) Ablation Study on Model-influential Transformations: We conduct an ablation study to quantify the impact of modelinfluential transformations on the attack efficacy. Specifically,

TABLE V: Detection Rate of D ROID B REAKER against 70 VT detectors in terms of average AV detection per family. Family

Original

Re-signing

D ROID B REAKER

dnotua zdtad joker firead blacklister gappusin

19/70 22/70 23/70 17/70 17/70 18/70

14/70 21/70 14/70 15/70 13/70 16/70

6/70 15/70 8/70 8/70 9/70 12/70

Average

27%

22%

13%

spite claims, they remain largely ineffective. Coarse-grained transplantation methods introduce excessive side effects and frequently fail to rebuild, while fine-grained techniques either lack impact or break semantics. Moreover, prior work overestimates attack success, due to insufficient functionality testing that cannot properly assess the preservation of the manipulated APK behavior. To address these limitations, we introduced D ROID B REAKER, a framework for crafting adversarial APKs that are both practical (build-safe) and functional (semantics-preserving), providing the following contributions: (i) query-efficient white- and black-box attacks based on model-influential transformations; (ii) fine-grained, build-safe manipulation of APIs, modules, Permissions, and URLs with minimal side effects; and (iii) a semantics-preserving functionality test enforcing runtime equivalence via execution logs and API-level traces. Our empirical results confirm the practical impact of D ROID B REAKER: (i) it achieves high evasion rates against multiple detectors in both white- and black-box settings with only a few tens of queries and negligible side effects; (ii) the resulting adversarial APKs remain functional at runtime; and (iii) when evaluated against commercial scanners on VT, it significantly reduces detections, demonstrating that practical and semantics-preserving problem-space attacks are feasible at scale. D ROID B REAKER enables several promising directions for future work. First, thanks to its query efficiency, it can serve as a foundation for developing adaptive attacks against stateful-protection and rate-limiting defenses [38], [39]. Another natural extension is to broaden its manipulation set to target detectors that rely on dynamic features, modifying execution-level behaviors beyond those considered by existing problem-space attacks.

we evaluate D ROID B REAKER against APIGraph on the ELSA dataset with a perturbation budget of 300, with and without the influential step. As reported in Fig. 8, the difference in success rates is striking: with initialization enabled, D ROID B REAKER attains a 70% success rate within just 10 queries; without it, the attack’s effectiveness degrades markedly, plateauing and showing little improvement over the final 15 queries. In numerical terms, this step shrinks the average component search space from 14,418 to 3,080. This result underscores its central role: it both guides the genetic optimizer toward a compact, high-quality subset of components and provides an accurate surrogate of the target detector’s decision boundary, even in the context of learning-based defenses. C. D ROID B REAKER against Real-world AVs We report here the evaluation of D ROID B REAKER on realworld AntiVirus (AV) engines hosted on VT. VT aggregates results from around 70 AV vendors, including major companies like Avast and Microsoft. This represents a fully blackbox evaluation whose objective f (z) is defined as the number of detectors that flag the input APK z as malicious. We use the VT APIs to upload both the initial and the modified APKs, analyzing the results after imposing a very low query budget of 10. The analysis required an average of 1 minute per APK, a duration dictated by VT’s internal processing overhead. For comparison, we use a baseline approach that only re-signs all the 100 initial APKs with a different certificate, altering their hashes without changing the source code, isolating the effects of hash alteration on detection by signature-based antimalware. The results in Tab. V show that D ROID B REAKER reduces the detection rate by approximately 50%, compared to an 18% reduction from re-signing. The majority of re-signed samples are still detected by at least five AVs, indicating that our structural transformations are crucial for evasion; e.g., re-signing zdtad only results in a 4% reduction, while D ROID B REAKER achieves an average reduction of 28.57%. Further analysis of VT reports reveals that major engines, like SymantecMobileInsight and Avast-Mobile, fail to detect the majority of modified APKs, confirming the effectiveness of our attack against prominent enterprise AVs in the mobile malware space with an extremely low query budget.

VI. E THICAL C ONSIDERATIONS D ROID B REAKER aims to improve the robustness evaluation of machine-learning Android malware detectors. Our goal is to highlight existing vulnerabilities and encourage the development of more robust and secure detection systems. For this reason, we have chosen to publicly release our attack implementation to foster reproducibility, fair benchmarking, and the design of improved countermeasures. This approach follows established practices in the security and machine learning communities, where openness and responsible disclosure are key to strengthening defenses (cf. [9], [40]). However, we acknowledge the dual-use nature of this work. Adversarial techniques designed for research can also be misused to evade real-world detection systems. To mitigate this risk, we decided to (i) document the intended purpose of the tool—enhancing robustness, not enabling malicious activity; (ii) include explicit disclaimers and responsible usage guidelines; and (iii) release the code under a restrictive license prohibiting unethical or harmful applications. These measures, combined with transparency and community oversight, aim to maximize the scientific and defensive value of our contribution while minimizing potential misuse.

V. C ONCLUSIONS AND F UTURE W ORK In this work, we evaluated existing problem-space attacks for Android malware detection and showed that, de-

ACKNOWLEDGMENT

[16] X. Chen, C. Li, D. Wang, S. Wen, J. Zhang, S. Nepal, Y. Xiang, and K. Ren, “Android HIV: A study of repackaging malware for evading machine-learning detection,” IEEE Transactions on Information Forensics and Security, vol. 15, pp. 987–1001, 2019. [17] H. Li, Z. Cheng, B. Wu, L. Yuan, C. Gao, W. Yuan, and X. Luo, “Black-box adversarial example attack towards fcg based android malware detection under incomplete feature information,” in Proceedings of the 32nd USENIX Conference on Security Symposium, ser. SEC ’23. USA: USENIX Association, 2023. [Online]. Available: https://www.usenix.org/system/files/sec23fall-prepub-2-li-heng.pdf [18] “Virustotal,” https://www.virustotal.com/, accessed on May 2025. [19] K. Zhao, H. Zhou, Y. Zhu, X. Zhan, K. Zhou, J. Li, L. Yu, W. Yuan, and X. Luo, “Structural attack against graph based android malware detection,” in Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’21. New York, NY, USA: Association for Computing Machinery, 2021, p. 3218–3235. [20] N. Carlini, A. Athalye, N. Papernot, W. Brendel, J. Rauber, D. Tsipras, I. Goodfellow, A. Madry, and A. Kurakin, “On evaluating adversarial robustness,” arXiv preprint arXiv:1902.06705, 2019. [21] S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A. Bartel, J. Klein, Y. Le Traon, D. Octeau, and P. McDaniel, “Flowdroid: precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps,” SIGPLAN Not., vol. 49, no. 6, p. 259–269, Jun. 2014. [Online]. Available: https://doi.org/10.1145/2666356.2594299 [22] “Cuckoodroid,” https://github.com/idanr1986/cuckoo-droid, accessed on August 2025. [23] Google, “Android runtime and dalvik,” https://source.android.com/docs/ core/runtime?hl=en, accessed on December 2025. [24] “Monkey,” https://developer.android.com/studio/test/other-testing-tools/ monkey, accessed on May 2025. [25] D. Olszewski, A. Lu, C. Stillman, K. Warren, C. Kitroser, A. Pascual, D. Ukirde, K. Butler, and P. Traynor, “”get in researchers; we’re measuring reproducibility”: A reproducibility study of machine learning papers in tier 1 security conferences,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’23. New York, NY, USA: Association for Computing Machinery, 2023, p. 3433–3459. [Online]. Available: https://doi.org/10.1145/3576915.3623130 [26] Y. Li, Z. Yang, Y. Guo, and X. Chen, “Droidbot: a lightweight ui-guided test input generator for android,” in 2017 IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE-C), 2017, pp. 23–26. [27] “Frida,” https://frida.re/, accessed on May 2025. [28] “Soot,” https://soot-oss.github.io/soot/, accessed on December 2025. [29] T. Vidas and N. Christin, “Evading android runtime analysis via sandbox detection,” in Proceedings of the 9th ACM Symposium on Information, Computer and Communications Security, ser. ASIA CCS ’14. New York, NY, USA: Association for Computing Machinery, 2014, p. 447–458. [30] “Robust android malware detection competition,” https: //ramd-competition.github.io/, accessed on May 2025. [31] “Avclass,” https://github.com/malicialab/avclass, accessed on May 2025. [32] “Android malware detectors,” https://github.com/pralab/ android-detectors, accessed on May 2025. [33] X. Zhang, Y. Zhang, M. Zhong, D. Ding, Y. Cao, Y. Zhang, M. Zhang, and M. Yang, “Enhancing state-of-the-art classifiers with api semantics to detect evolved android malware,” in Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, 2020, pp. 757–770. [34] Androguard Project, “Androguard,” version 4.1.3. Accessed: May 2025. [Online]. Available: https://github.com/androguard/androguard [35] M. Backes, S. Bugiel, E. Derr, P. McDaniel, D. Octeau, and S. Weisgerber, “On demystifying the android application framework: Re-visiting android permission specification analysis,” 2016, Conference paper, p. 1101 – 1116. [Online]. Available: https://www.usenix.org/system/files/ conference/usenixsecurity16/sec16 paper backes-android.pdf [36] S. Aonzo, G. C. Georgiu, L. Verderame, and A. Merlo, “Obfuscapk: An open-source black-box obfuscation tool for android apps,” SoftwareX, vol. 11, p. 100403, 2020. [37] T. Sutter, T. Kehrer, M. Rennhard, B. Tellenbach, and J. Klein, “Dynamic security analysis on android: A systematic literature review,” IEEE Access, vol. 12, pp. 57 261–57 287, 2024. [38] S. Chen, N. Carlini, and D. Wagner, “Stateful detection of blackbox adversarial attacks,” in Proceedings of the 1st ACM Workshop on

This work has been partly supported by the EU-funded Horizon Europe projects ELSA (GA no. 101070617) and CoEvolution (GA no. 101168560); and by the projects SERICS (PE00000014) and FAIR (PE00000013) under the MUR National Recovery and Resilience Plan funded by the European Union - NextGenerationEU. This work was carried out while C. Scano was enrolled in the Italian National Doctorate on AI run by the Sapienza University of Rome in collaboration with the University of Cagliari. R EFERENCES [1] A. Ruggia, D. Nisi, S. Dambra, A. Merlo, D. Balzarotti, and S. Aonzo, “Unmasking the veiled: A comprehensive analysis of android evasive malware,” in Proceedings of the 19th ACM Asia Conference on Computer and Communications Security, 2024, pp. 383–398. [2] D. Arp, M. Spreitzenbarth, M. Hubner, H. Gascon, K. Rieck, and C. Siemens, “Drebin: Effective and explainable detection of android malware in your pocket.” in Ndss, vol. 14, 2014, pp. 23–26. [3] K. Allix, T. F. Bissyandé, J. Klein, and Y. Le Traon, “Androzoo: Collecting millions of android apps for the research community,” in Proceedings of the 13th international conference on mining software repositories, 2016, pp. 468–471. [4] A. Demontis, M. Melis, B. Biggio, D. Maiorca, D. Arp, K. Rieck, I. Corona, G. Giacinto, and F. Roli, “Yes, machine learning can be more secure! a case study on android malware detection,” IEEE Transactions on Dependable and Secure Computing, vol. 16, no. 4, pp. 711–724, 2017. [5] E. Mariconti, L. Onwuzurike, P. Andriotis, E. De Cristofaro, G. Ross, and G. Stringhini, “Mamadroid: Detecting android malware by building markov chains of behavioral models,” 2017. [6] F. Pendlebury, F. Pierazzi, R. Jordaney, J. Kinder, and L. Cavallaro, “TESSERACT: Eliminating experimental bias in malware classification across space and time,” in 28th USENIX Security Symposium (USENIX Security 19). Santa Clara, CA: USENIX Association, Aug. 2019, pp. 729–746. [Online]. Available: https://www.usenix.org/system/files/ sec19-pendlebury.pdf [7] K. Grosse, N. Papernot, P. Manoharan, M. Backes, and P. McDaniel, “Adversarial examples for malware detection,” in Computer Security– ESORICS 2017: 22nd European Symposium on Research in Computer Security, Oslo, Norway, September 11-15, 2017, Proceedings, Part II 22. Springer, 2017, pp. 62–79. [8] F. Pierazzi, F. Pendlebury, J. Cortellazzi, and L. Cavallaro, “Intriguing properties of adversarial ml attacks in the problem space,” in 2020 IEEE symposium on security and privacy (SP). IEEE, 2020, pp. 1332–1349. [9] D. Li and Q. Li, “Adversarial deep ensemble: Evasion attacks and defenses for malware detection,” IEEE Transactions on Information Forensics and Security, vol. 15, pp. 3886–3900, 2020. [10] W. Yang, D. Kong, T. Xie, and C. A. Gunter, “Malware detection in adversarial settings: Exploiting feature evolutions and confusions in android apps,” in Proceedings of the 33rd Annual Computer Security Applications Conference, 2017, pp. 288–302. [11] G. Xu, H. Shao, J. Cui, H. Bai, J. Li, G. Bai, S. Liu, W. Meng, and X. Zheng, “Gendroid: A query-efficient black-box android adversarial attack framework,” Computers & Security, vol. 132, p. 103359, 2023. [12] P. He, Y. Xia, X. Zhang, and S. Ji, “Efficient query-based attack against ml-based android malware detection under zero knowledge setting,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, 2023, pp. 90–104. [13] H. Bostani and V. Moonsamy, “Evadedroid: A practical evasion attack on machine learning for black-box android malware detection,” Computers & Security, vol. 139, p. 103676, 2024. [14] E. T. Barr, M. Harman, Y. Jia, A. Marginean, and J. Petke, “Automated software transplantation,” in Proceedings of the 2015 International Symposium on Software Testing and Analysis, 2015, pp. 257–269. [15] Z. Shu and G. Yan, “Eagle: Evasion attacks guided by local explanations against android malware classification,” IEEE Transactions on Dependable and Secure Computing, vol. 21, no. 4, pp. 3165–3182, 2024.

a human.9 Similarly, manipulated APKs may only need to bypass the detector, without necessarily appearing inconspicuous to malware analysts—which is indeed a different goal. Furthermore, the notion of plausibility in prior work has never been empirically validated. Pierazzi et al. [8] claimed that techniques such as opaque predicates and software transplantation inherently satisfy this requirement, whereas obfuscation does not. Beyond the fact that opaque predicates themselves introduce obfuscation (e.g., hiding false if clauses to inject dead code), this claim has not been subjected to human studies or user evaluations to verify whether the resulting APKs would indeed appear inconspicuous to analysts. The plausibility requirement remains thus largely theoretical, and we decided not to enforce it as a strict requirement.

Security and Privacy on Artificial Intelligence, ser. SPAI ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 30–39. [39] E. Debenedetti, N. Carlini, and F. Tramer, “ Evading Black-box Classifiers Without Breaking Eggs ,” in 2024 IEEE Conference on Secure and Trustworthy Machine Learning (SaTML), 2024, pp. 408–424. [40] L. Demetrio, B. Biggio, G. Lagorio, F. Roli, and A. Armando, “Functionality-preserving black-box optimization of adversarial windows malware,” IEEE Transactions on Information Forensics and Security, vol. 16, pp. 3469–3478, 2021. [41] J. Gilmer, R. P. Adams, I. J. Goodfellow, D. Andersen, and G. E. Dahl, “Motivating the rules of the game for adversarial example research,” CoRR, vol. abs/1807.06732, 2018. [42] A. Ruggia, A. Possemato, S. Dambra, A. Merlo, S. Aonzo, and D. Balzarotti, “The dark side of native code on android,” ACM Trans. Priv. Secur., vol. 28, no. 2, Feb. 2025. [43] “Jadx,” https://github.com/skylot/jadx, accessed on May 2025. [44] “Apktool,” https://apktool.org/, accessed on May 2025. [45] “Smali code,” https://sallam.gitbook.io/sec-88/android-appsec/smali/ smali-cheat-sheet, accessed on July 2025. [46] Android Developers, “Apksigner,” Android developer documentation, accessed: May 2025. [Online]. Available: https://developer.android.com/ tools/apksigner?hl=en

B. Manipulation Types Prior work on Android malware typically categorizes APK manipulations by the program representation they affect, ranging from high-level declarative metadata to low-level code. Manifest-level Manipulations. These manipulations target the Android manifest, including injection or modification of App Modules (i.e., Activities, Services, Receivers, Providers), Permissions, Hardware Features, and Intent Filters [9], and directly affect high-level static features but are tightly constrained by Android’s consistency and validation rules. DEX bytecode–level Manipulations. They target Dalvik bytecode by injecting or modifying classes, methods, API calls, and embedded constants (e.g., URLs, IP addresses), with changes ranging from coarse-grained (e.g., transplanting entire classes or modules) [8], [10] or fine-grained (e.g., inserting individual API calls or rewriting specific instructions) [9]. Control-Flow Graph (CFG) Manipulations. CFG-level manipulations alter execution structure without necessarily adding or removing semantic components. Typical examples include basic-block reordering, opaque predicates, function inlining or duplication, and control-flow flattening. Prior work (e.g., HRAT [19]) leverages such transformations to perturb structural features or increase code complexity; however, these operations usually preserve all original components, providing only partial obfuscation or no removal of malicious capability. Native-code (JNI) Manipulations. They affect compiled native libraries (ELF binaries) accessed through Java Native Interface (JNI), and include injecting benign native libraries, modifying native call patterns, and renaming symbols [42]. Even if native code is a relevant attack surface, such manipulations are less explored due to architectural dependencies, limited tooling, and a higher risk of breaking functionality. Resource-level Manipulations. They modify APK assets such as layout files, images, and resource string tables without altering app semantics, but they may still influence detectors that rely on metadata, resource statistics, and strings. Overall, existing attacks differ both in which representations they manipulate and in the granularity of the ma-

A PPENDIX A P ROBLEM - SPACE ATTACKS D ETAILS A. Requirements for Problem-space Attacks Pierazzi et al. [8] formalized four key requirements for problem-space attacks: (i) practical manipulations, i.e., the APK changes must be feasible under Android’s structural and syntactic constraints, even if they may introduce unintended side-effect features; (ii) semantics preservation, i.e., the modified APK continues to exhibit its intended (malicious) behavior; (iii) robustness to preprocessing, i.e., the manipulations cannot be easily removed or neutralized by trivial preprocessing mitigation measures; and (iv) plausibility, i.e., the modified APK remains inconspicuous to both users and analysts. Robustness to Preprocessing. While we agree that problem-space attacks should rely on practical manipulations and preserve app semantics, we argue that implementing robust preprocessing mechanisms may not be as trivial as often claimed and, thus, it should not be considered a strict requirement. While prior work claims that “trivial” preprocessing steps may neutralize certain types of manipulation, no machine-learning malware detector to date implements them [2], [5]. As the complexity of identifying unreachable code, callbacks, or reflection instructions via static analysis makes their removal non-trivial and prone to error, in practice, such manipulations remain effective, making this requirement poorly specified and rarely supported. Nevertheless, while our manipulations are mainly designed to be practical (build-safe), they can be hardened with similar tricks from previous work to demonstrate their robustness to preprocessing. Plausibility. As for robustness to preprocessing, we argue that plausibility should not be considered a strict requirement, too. In the context of adversarial images, Gilmer et al. [41] observed that “no compelling example where imperceptibility is required” could be found, showing that the goal of evading a classifier is fundamentally different from that of also fooling

9 It is important to distinguish imperceptibility from semantics preservation. An attack can introduce visible perturbations to an image without altering its semantics, so a human observer can still correctly recognize its content.

TABLE VI: Performance metrics for considered detectors, on both APG and ELSA datasets. APG DS

Metric F1-score Precision Recall

ELSA DS

Drebin

Drebin-10k

SecSVM

SecSVM-10k

APIGraph

MaMaDroid

Drebin

SecSVM

APIGraph

MaMaDroid

78.2% 72.5% 84.86%

79.63% 72.89% 87.74%

76.98% 72.03% 82.66%

75.85% 73.19% 78.71%

79.76% 72.81% 88.17%

78.34% 76.31% 80.49%

86.48% 97.72% 77.28%

85.09% 94% 75.36%

85.89% 96.79% 77.2%

51.86% 91.68% 36.16%

resources can then be modified and repackaged, producing patched versions of the original APKs that can be redistributed and installed, provided the applied changes do not compromise the app’s integrity. Finally, the repackaged APKs must be re-signed using apksigner [46], as Android requires each APK to include a valid digital certificate to verify its integrity and allow installation on a device.

nipulation: coarse-grained approaches simultaneously affect manifest, bytecode, FCG, resources, and sometimes native code, while fine-grained approaches restrict themselves to a narrow subset to reduce side effects and preserve functionality. C. APK Component Examples We report concrete examples of APK components that are manipulated by problem-space attacks to evade Android malware detectors, organized by the categories in Sect. II-A1. C1 : Application Modules. They correspond to the class names of APK entry points (Activities, Services, Receivers, and Providers), declared within the manifest with specific tags, i.e.,<activity>, <service>, <receiver>, <provider>, and implemented inside the DEX bytecode. C2 : Hardware Features. They are declared within the manifest with the tag <uses-features> and declare the permission to use specific hardware (e.g., microphone, camera). C3 : Permissions. They are declared within the manifest with the tag <uses-permission> and identify the app software capabilities (e.g., sending SMS, or accessing storage). C4 : Intent Filters. They are reported within the manifest and describe the external behaviors of app modules invoked at runtime. They are identified by the XML tag <intent-filter>, and the <action> name that identifies the behavior, declared within an Application Module. C5 : API calls. They are used by the DEX bytecode to interact with the Android OS and implement APK functionality. They are invoked in the smali code with instructions like invoke-*. In our case, we consider only framework’s APIs. C6 : Strings. They include Strings (e.g., URLs, IPs) initialized within the DEX bytecode. They are declared with the instruction const-string that pushes a constant string into a register. In our attack, we consider only IP addresses and URLs as strings to be modified.

A PPENDIX B R EPRODUCIBILITY AND I MPLEMENTATION I SSUES A. Pierazzi et al. Implementation Issues We outline here the issues we found with the approach by Pierazzi et al. [8] that hinder the APKs from being built or functioning correctly. First, as also shown in previous work [25], reproducibility issues mainly due to incomplete documentation and configuration details, prevent the attack from working out of the box. In particular, we observed that the attack’s operational stability is significantly influenced by the interplay between the versions of the manipulated APK SDK, FlowDroid, Android Build Tools, and Platform Tools. After contacting the authors and trying several settings, we achieved optimal results using Build Tools 23.0.1 and Platform Tools 23. Second, the original opaque predicate within which the benign code is injected was compiled into a control flow structure that Soot could not recognize as a valid injection point, preventing transplantation from working correctly. A minor modification to the conditional expression resolved the issue without affecting the predicate’s runtime behavior. Third, after selecting all organs to inject, FlowDroid identifies their dependencies, which are subsequently added to the app as stub classes, even when a filtering step is supposed to remove unnecessary components. However, this is not effective, and the approach also fails to discard malformed dependency classes with invalid access flags, e.g., 0x20601, which incorrectly assigns the synchronized modifier to those classes. To verify this, we recompiled the APKs without the faulty classes and, as specified in Sect. IV-A3, launched them without fatal errors from the Android Verifier. Overall, these issues highlight the approach’s lack of robustness, which fails to adequately handle edge cases or ensure the correctness of injected components, ultimately leading to unstable, unreliable APK builds.

D. Repackaging Repackaging enables the extraction and manipulation of an app’s manifest, code, and resources. Most manipulation operators are applicable only to APKs that can be safely repackaged without introducing artifacts that invalidate the DEX code or are unrelated to the intended modifications; consequently, apps protected by packing or advanced obfuscation techniques are typically excluded from adversarial manipulation. In practice, tools such as Jadx [43] and ApkTool [44] are used to decompile DEX files, recovering the original Java code when possible or lifting it to smali [45], an assembly-like language for the Android Virtual Machine. The resulting code and

1 <?xml version="1.0" encoding="utf-8"?> 2 <manifest package="com.nd.android.pandah" [...]> 3 [...] 4 <application android:label="@string/application_name

1 <?xml version="1.0" encoding="utf-8"?> 2 <manifest package="com.android.pandahome2" [...]> 3 [...] 4 <application android:label="@string/application_name

,→ " android:name="com.nd.hilaunch.LauncherApp2">

5 [...] 6 <activity android:name="com.nd.hilaunc.Launcher"/> 7 <acvitity android:name=" R345678shgd " 8 android:label=""> 9 <activity android:name=" A2b6bdaa4 "> 10 <intent-filter> 11 <action android:name= 12 "android.intent.action.VIEW"/> 13 </intent-filter> 14 </activity> 15 [...] 16 </application> 17 </manifest>

5 6 7 8 9

,→ " android:name="com.hilauncherdev.launcher. ,→ LauncherTinkerApplication"> [...] <activity android:name=" com.pc3ef4.p75645.p72b28 "/> [...] </application> </manifest>

Fig. 10: App Module (C1 ) renaming in the manifest (line 6) without encoding the tokens that are also within the package name.

Fig. 9: ADE App-Module Injection. Injected App Modules components are highlighted in blue (C1 ).

to reject the app with a fatal error invalidating its functionality. C. D ROID B REAKER Manipulation Details We outline here the implementation details of the manipulations presented in Sect. III-A, explaining how they preserve functionality and differ from prior work. Component Obfuscation. App-Module Class Renaming. Unlike ADE, to avoid inconsistent and partial renaming, we encode only the class identifiers within the manifest (Fig. 10), while preserving the app package tokens. After encoding the Activity class name in the manifest (com.pc3ef4.p75645.p72b28 in line 6), we consistently rename every occurrence of the same class within the smali code, without partial renaming of other classes even though it contains similar tokens (i.e., com). API Indirection. Unlike ADE, we also propose API indirection to obfuscate APIs. As shown in Fig. 11, we obfuscate the original call to getDrawable (Fig. 11a), with wrapper method (Fig. 11b) invoking the API (line 4), altering the FCG with an additional node. To maintain the app’s functionality, the new method accepts the same parameters as the obfuscated one and the corresponding object to correctly invoke it. API Reflection. Fig. 12 shows an example of API Reflection. We leverage an additional class ApiReflection (Fig. 12b), and its obfuscate method, which takes in input an integer (i.e., the identifier of the call in the array), and the parameters passed to the target method to invoke (line 27). As in the case of ADE, we employ getMethod (line 14) from Ljava/lang/reflect/Method class, but differently from it, we employ only public methods from public classes, not to raise errors of inaccessibility. String Encryption. D ROID B REAKER encrypts strings to hide the URL inside the method body. In particular, we leverage a DecryptString classes that have all necessary methods to descript the method name to dynamically reconstruct the original value at runtime. This transformation preserves the original semantics, while preventing static analyzers from directly observing sensitive string literals. Component Injection. App-Module Injection. Fig. 13 depicts an example of Activity injection by D ROID B REAKER. To overcome the implementation limitations of ADE, we first inject only the Activity name without adding any additional attribute from the benign manifest that may raise build errors

B. ADE Manipulation Issues We outline here the ADE implementations that are brittle, causing the perturbed apps to crash due to Android Verifier errors or runtime exceptions. Component Obfuscation. App-Module Class Renaming. The approach encodes the class identifier and tokens into the package name and propagates this transformation to all matching string occurrences in both manifest and smali. As a result, class names are only partially modified in the smali code, and the renamed identifier appears in the method body. However, the corresponding .class definitions are left unchanged, yielding to ClassNotFoundException as the referenced classes are not actually defined. API Indirection and Reflection. ADE implements API Reflection only, without considering other techniques like Indirection. To do so, it enforces the usage of getMethod whichever the API to be reflected is. While being syntactically correct, it raises problems when the attack chooses inaccessible methods, i.e., private, which cannot be resolved using getMethod as it can be used only with public APIs. As a result, the reflective lookup fails at runtime, raising a NoSuchMethodException, invalidating functionality. Component Injection. App-Module Injection. Fig. 9 outlines two examples of Activity injections by ADE that suffer from implementation issues. First, when injecting manifest components ADE does not detect that it is faulty and inserts it into the manifest, leading to compilation errors (e.g., in line 8 label attribute is empty, but it should contain a valid value). Second, since the Activities are injected only at the manifest level, there is no corresponding code within the DEX. As a result, when such an Activity is launched (e.g., when an app issues the corresponding Intent), the app may fail since the Activity class is missing, raising errors. String Injection. The major problem with this kind of manipulation is that ADE employs inaccessible registers, e.g.,p0 that holds the Java this and cannot store string objects, or registers that are not previosly declared in the method register’s set. As a result, the string injection cause the Android Verifier

1 .method public a(I)Landroid/graphics/drawable/Drawable; 2 .registers 6 3 [...] 4 move-result v0 5 invoke-virtual {v1, v0}, ,→ Landroid/content/res/Resources;->getDrawable(I)

6 Landroid/graphics/drawable/Drawable; 7 move-result v0 8 [...] 9 .end method

(a) Plain version of the a function. 1 .method public static uQtOtnIMMiVSwoJq(Landroid/content/ 2 3

,→ res/Resources;I)Landroid/graphics/drawable/ ,→ Drawable; .locals 1 invoke-virtual {p0, p1}, ,→ Landroid/content/res/Resources;->getDrawable(I) Landroid/graphics/drawable/Drawable; move-result v0 return v0 .end method

4 5 6 7 8 9 .method public a(I)Landroid/graphics/drawable/Drawable; 10 .registers 6 11 [...] 12 move-result v0 13 invoke-static {v1, v0}, Lcom/google/android/gms/plus ,→ /e;->uQtOtnIMMiVSwoJq(Landroid/content/res/ ,→ Resources;I)Landroid/graphics/drawable/Drawable;

14 move-result v0 15 [...] 16 .end method

(b) Obfuscated version of the a function through Call Indirection.

Fig. 11: Obfuscation through Call Indirection. (a) shows the smali code of the original function a with the call to the target API in blue (C5 ), while (b) shows the obfuscated counterpart.

1 .method public b(Landroid/os/Parcel;)Lcom/google/android ,→ /gms/wallet/NotifyTransactionStatusRequest; .registers 9 [...] invoke-virtual {v1, v2}, ,→ Landroid/webkit/WebSettings;->setSupportZoom(Z)V 5 [...] 6 .end method

2 3 4

(a) Plain version of the b function. 1 .method public b(Landroid/os/Parcel;)Lcom/google/android ,→ /gms/wallet/NotifyTransactionStatusRequest; .registers 9 [...] invoke-static {v8, v0, v6}, Lcom/reflect/ ,→ ApiReflection;->obfuscate(ILjava/lang/Object;[ ,→ Ljava/lang/Object;)Ljava/lang/Object; 5 .end method

2 3 4

6 7 .class public Lcom/reflect/ApiReflection; 8 .super Ljava/lang/Object; 9 10 .method static constructor <clinit>()V 11 [...] 12 const-class v2, Landroid/webkit/WebSettings; 13 const-string v3, " setSupportZoom " 14 invoke-virtual {v2, v3, v1}, Ljava/lang/Class;-> 15 16

,→ getMethod(Ljava/lang/String;[Ljava/lang/Class;) ,→ Ljava/lang/reflect/Method; move-result-object v1 sget-object v2, Lcom/reflect/ApiReflection;-> ,→ obfuscatedMethods:Ljava/util/List; invoke-interface {v2, v1}, Ljava/util/List;->add( ,→ Ljava/lang/Object;)Z .end method

(line 11), then we set the enable attribute to false so that 17 the Android system treats the Activity as disabled at runtime; 18 therefore, the Intents are not resolved, and the injected Activ- 19 20 .method public static obfuscate(ILjava/lang/Object;[ ity, i.e., without corresponding code, cannot be launched. ,→ Ljava/lang/Object;)Ljava/lang/Object; sget-object v0, Lcom/reflect/ApiReflection;-> Hardware Features and Permission Injection. Fig. 13 shows 21 ,→ obfuscatedMethods:Ljava/util/List; an example of injection of hardware feature (line 7) and per- 22 invoke-interface {v0, p0}, Ljava/util/List;->get(I) ,→ Ljava/lang/Object; mission (line 5). In particular, our implementation takes into 23 move-result-object p0 account only components from the Android framework starting 24 check-cast p0, Ljava/lang/reflect/Method; invoke-virtual {p0, p1, p2}, with android.permission and android.hardware, 25 ,→ Ljava/lang/reflect/Method;-> so that apps does not need the corresponding declaration. 26 invoke(Ljava/lang/Object;[Ljava/lang/Object;) Ljava/lang/Object; API Injection. Fig. 14 depicts an example of API injection. 27 28 [...] New APIs are injected by introducing a new class whose void 29 .end method inject method contains the invocations of additional APIs (b) Obfuscated version of the b function through Reflection. within dead code. To preserve the functionality, (i) we inject not only the target API (line 10) and (ii) we employ a void Fig. 12: D ROID B REAKER API Reflection. (a) shows the smali method not to interfere with the app context when called. code of the original function b with the call to the target API String Injection. Rather than injecting string constants into an in blue (C5 ), while (b) shows the obfuscated counterpart with existing app method, violating register allocation constraints the corresponding side-effect in red. as done by ADE, we introduce a dedicated void method that (i) safely allocates fresh registers and stores the injected strings locally, and (ii) does not return any value, so as not to interfere with the original app context when called. As a result, our implementation preserves the bytecode correctness and avoids Android Verifier errors.

1 <?xml version="1.0" encoding="utf-8"?> 2 <manifest package="com.nd.android.pandah" [...]> 3 [...] 4 <uses-permission android:name=" android.permission. 5 SEND_SMS "/> 6 <uses-feature android:name= 7 " android.hardware.audio "/> 8 <application android:label="@string/application_name" ,→ android:name="com.nd.hilauncherdev.Launch">

9 [...] 10 <acvitity android:name=" R345678shgd " 11 android:enable="false" 12 <activity android:name=" A2b6bdaa4 " 13 android:enable="false"> 14 <intent-filter> 15 <action android:name=" android.intent.action.SEND "/> 16 </intent-filter> 17 </activity> 18 [...] 19 </application> 20 </manifest>

Fig. 13: D ROID B REAKER manifest components Injection, i.e., Permissions (C3 ), Hardware Features (C2 ), App Modules (C1 ), and Intent Filers (C4 ).

1 .class public Lcom/apiinjectionmanager/ApiInjection; 2 .super Ljava/lang/Object; 3 4 .method public static inject()V 5 .registers 6 6 const/4 v0, 0x1 7 const/4 v1, 0x0 8 /* Logging */ 9 if-nez v0, :impossible 10 invoke-static {v2}, ,→ Landroid/os/Binder;->getCallingPid()I

11 :impossible 12 return-void 13 .end method

Fig. 14: D ROID B REAKER API Injection. inject holds the injected API (C5 ).

Record · ID 310749 · SHA-256 d40d46c740249e42
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.