Adversarial Repackaging: Techniques and Defenses

Updated 4 July 2026

Adversarial repackaging is a technique that alters presentation-level features (e.g., code layout, metadata, narrative) while keeping the core functionality or evidence unchanged.
It is employed in domains like Android malware and packed executables to bypass detection by modifying non-semantic cues such as signatures, API features, and control flow.
Beyond malware, the approach challenges static detection in software supply chains and AI peer review, necessitating robust defenses that anchor evaluation to immutable evidence.

Adversarial repackaging denotes a class of attacks in which an existing artifact is modified so that its observable surface changes while a core invariant is preserved. In Android and PE malware, the preserved invariant is typically malicious functionality, whereas the modified surface includes code layout, resources, signatures, packer stubs, metadata, or API-level feature realizations. In software package ecosystems, the preserved invariant is malicious package behavior under semantics-preserving source transformations. In AI peer review, the preserved invariant is scientific evidence—methods, experiments, figures, equations, proofs, and numerical results—while the modified surface is presentation-level content such as framing, related work, discussion, and narrative structure (Li et al., 2018, Kim et al., 2022, Montaruli et al., 3 Dec 2025, Yang et al., 11 Jun 2026). This suggests a common attack surface: mutable representation under fixed semantics.

1. Definitions and problem scope

Across the Android repackaging literature, repackaging is the process of unpacking an APK, modifying code and/or resources, repackaging and re-signing it with a different certificate, and redistributing the altered app. A repackaged pair is defined when code similarity exceeds 80% and signatures differ. Within this space, piggybacking denotes repackaging a benign app with a malicious payload, and camouflage denotes repackaging popular apps while keeping the UI intact but altering the code (Li et al., 2018). In malware packing research, packing transforms a binary once with a packer, whereas repackaging repeatedly applies packers and/or variants to alter the observable surface without changing malicious semantics (Kim et al., 2022).

Domain	Mutable surface	Fixed core
Android malware	Code/resources, signatures, triggers, static and dynamic features	Malicious or benign app functionality
Packed executables	Entropy, sections, metadata, unpacking stubs, overlays	Runtime malware behavior
Python packages	Strings, imports, control scaffolding, source structure	Package semantics and installability
AI peer review	Abstract, framing, related work, discussion, narrative structure	Methods, experiments, figures, equations, proofs, numerical results

The peer-review literature sharpens the notion of permissible change by partitioning a paper into a free zone, a limited zone, and a fixed zone. The free zone comprises abstract, introduction, related work, discussion, and conclusion; the limited zone comprises method descriptions and results analysis; the fixed zone comprises experiments, tables, figures, equations, proofs, and numerical results. The optimization objective is to maximize the expected reviewer score over content-preserving presentation edits while holding scientific evidence fixed (Yang et al., 11 Jun 2026).

2. Android repackaging as evasive malware transformation

Android repackaging is adversarial because the injected segments are designed to remain hidden and evade static signatures, and triggers can guard execution until specific conditions are met. The malicious payload may implement premium SMS abuse, credential theft, dynamic code loading, or a logic bomb, while triggers range from null conditions to environment-dependent checks such as time, GPS, intents including android.intent.action.BOOT_COMPLETED, and server-provided values. A central difficulty is the absence of ground truth that pinpoints the precise malicious segments or paths in repackaged apps: labels are at app level, not path level, so a single execution that exercises only benign paths yields a benign-looking feature vector for a malicious label (Salem, 2018).

Aion addresses this ambiguity by connecting stimulation and detection in an active-learning feedback loop. Dynamic execution occurs on an Android Virtual Device using Droidutan, which launches the app’s main activity, enumerates UI elements, interacts randomly, and broadcasts app-declared intents; droidmon hooks security-relevant API calls and logs traces represented as strings of the form [package.module.class].[method]. In the reported implementation, acquisition is simplified to misclassification, selecting misclassified training apps for re-stimulation until training F1 fails to improve beyond $E = 1\%$ or $t_{\max} = 10$ is reached. On the Piggybacking dataset, active learning reaches test $F1 \approx 72\%$ , combining static and dynamic features boosts dynamic-only performance by about 7%, and most gains occur by iteration 2–5, with an average of about 5 iterations to reach maximal training performance (Salem, 2018).

Adversarial repackaging can also be formulated as direct feature-space attack. “Android HIV” injects perturbations into Dalvik bytecode rather than only into AndroidManifest.xml, thereby altering semantic features such as control-flow-graph-derived abstractions. The reported attack reduced detection rates from 96% to 0% in MaMaDroid and from 97% to 0% in Drebin, with just a small number of codes inserted into the APK (Chen et al., 2018). DECEIT takes the opposite perspective and uses metamorphic testing on feature vectors: given $x \in \{0,1\}^d$ , it constructs $x' = x \odot (1-m)$ by removing top- $k$ benign-prevalent features and flags suspected repackaging when $p_m(x) < \delta$ but $p_m(x') \ge \delta$ . With $k=6$ , accuracy on repackaged malware rises from 87.82% to 94.56%, benign accuracy remains 97.77%, and overall performance reaches Accuracy 96.17%, Precision 0.98, Recall 0.95, and F1 0.96 (Singh et al., 2021).

The benchmark problem is substantial. RePack contains 15,297 repackaging pairs built from AndroZoo, with 2,776 original apps and many originals repackaged multiple times; 5,960 repackaged malicious apps are labeled into 45 families by AVClass. Manual dynamic validation of 100 sampled pairs confirmed 89 as clear repackaging. In replications on RePack, Androguard achieved recall of about 86% at an 80% similarity threshold, FSQuaDRA about 11%, and SimiDroid about 100% over 11,255 runs, illustrating the brittleness of resource-only methods under adversarial resource changes (Li et al., 2018).

3. Packing, wrappers, and artifact-driven static detection

Packing is a canonical form of adversarial repackaging in PE malware because it compresses or encrypts sections, adds an unpacking stub, perturbs entry-point bytes, alters section flags, and changes import and metadata structure. A multi-step framework for classifying packed samples uses pseudo-optimal feature selection with CART and permutation importance, then trains a three-class classifier for Not Packed, Custom Packed, and Well-known Packed. On 214,001 PE malware samples, XGBoost trained on the 20 features selected by XGBoost with permutation importance achieved Accuracy $\approx 99.67\%$ , F1-score $t_{\max} = 10$ 0, and AUC $t_{\max} = 10$ 1, and the framework identifies packers for samples classified as Well-known Packed using a PEiD signature database with about 4,200 signatures (Kim et al., 2022).

Yet interpretability studies show that high accuracy does not imply semantic robustness. TRUSTEE-based analysis of static malware classifiers finds that the top-ranked features across controlled dataset compositions are predominantly packing artifacts, PE metadata, and string-level n-grams rather than malicious semantics. Across all settings, 85–90% of top-ranked features were artifacts and only 10–15% plausibly reflected malicious semantics. In biased settings, sectionsMaxEntropy and the string feature QQSV dominated; as packed benign samples increased, certificate-related ASN.1 n-grams and UTF-16 substrings became the strongest benign indicators. The reported behavior is highly sensitive to the ratio of Unpacked Benign, Packed Benign, Unpacked Malware, and Packed Malware, indicating that the classifier reweights non-semantic cues as dataset composition changes (Mohammed et al., 7 May 2026).

Pack-ALM reframes packed-data detection as a linguistic discrimination problem between “real instructions” and “pseudo instructions.” It applies linear sweep disassembly to all raw bytes outside the program header, normalizes operands into placeholders such as [const], [mem_abnormal], and [pad_abnormal], and trains a RoBERTa-style Transformer with structured-instruction masked language modeling. On region-level packed-data identification, Pack-ALM reports F1 97.73% for real-vs-pseudo instruction discrimination and F1 89.11% for native-vs-packed data discrimination. On low-entropy adversarial packing, it reports Accuracy 92.45% for transposition, 94.85% for encoding, 96.00% for mono-alphabetic substitution, and 96.40% for poly-alphabetic substitution, whereas pure entropy detection reports 0% for all four techniques (Li et al., 19 Sep 2025). This suggests that operand-level and compositional structure can be more robust than entropy-only heuristics under repackaging pressure.

4. Anti-repackaging defenses and their limits

Client-side anti-repackaging schemes attempt to make repackaging fail at runtime by inserting integrity checks, logic bombs, or self-decrypting code. A survey of Self-Protection through Dex Encryption, SSN, AppIS, SDC, BombDroid, and NRP shows a recurrent weakness: keys, hashes, expected certificate digests, and integrity references are embedded client-side and are therefore observable, hookable, or patchable. The survey also reports that 86% of Android malware resides in repackaged apps and that 77% of the top 50 free apps have plagiarized clones in alternative stores. An end-to-end attack on NRP, performed on the Antimine app, neutralized all 315 bombs by recovering Java and native keys with Frida hooks, dumping decrypted code, and patching the tamper check (Merlo et al., 2020).

ARMAND generalizes the logic-bomb approach by inserting heterogeneous detection nodes at compile time and relying heavily on native code. It uses six bomb types—Java bomb, Native-key bomb, Native AT bomb, Java AT + Native-key bomb, Java + Native AT bomb, and Honeypot bomb—together with standalone Java anti-tampering checks. On 30,000 real-world Android apps, ARMANDroid protected 27,656 apps, or 92.2%, with an average of 173 logic bombs, 355 Java AT checks, and average nesting level 2.3. On 220 apps used for runtime performance, 191 protected apps ran correctly, average CPU overhead was about +3%, and average memory overhead about +0.1% (Merlo et al., 2020).

PARIOT transfers the anti-repackaging idea to IoT firmware by injecting anti-tampering controls inside Cryptographically Obfuscated Logic Bombs derived from qualified conditions of the form $t_{\max} = 10$ 2. The firmware prototype PARIOTIC protected 45 of 50 real-world firmware samples, or 90%, with average instrumentation time 64.2 s per firmware. Code size overhead averaged 3.52% on iotlab-m3 and 11.3% on the native target; under automated adversarial modifications of 45 protected images, 69% were detected, with 23 detections at startup and 8 during operation, and no false positives were observed in normal runs (Verderame et al., 2021).

A complementary strategy is to make reverse engineering itself structurally unreliable. Obfuscated integration combines code layout randomization, interprocedurally coupled opaque predicates, and code factoring with intraprocedural control-flow idioms in post link-time rewriting. In the reported evaluation, IDA Pro on protected binaries exhibited GUI false positive rates of about 74–76% and GUI false negative rates of about 53–56%; after attacker-improved repartitioning, GUI false positive rates remained about 77–79%, database false positive rates about 95–96%, and about 85–88% of factored fragment pairs remained split across functions (Broeck et al., 2019). This suggests that repackaging can be resisted not only by integrity checks but also by collapsing the modular cues on which static comprehension depends.

5. Source-package repackaging in software supply chains

In Python package ecosystems, adversarial repackaging means transforming the source of an existing malicious package into a functionally equivalent but syntactically valid variant that evades static detectors. The transformations are semantics-preserving and include Base64, Base32, Base16, Base85, hexadecimal, binary arrays, data reordering, identifier renaming, useless code injection, and API obfuscation through constructs such as __import__, getattr, __getattribute__, __dict__, and __call__ (Montaruli et al., 3 Dec 2025).

A production-oriented detector for this setting combines structural features, counts of 215 security-sensitive APIs, five behavior categories, 12 obfuscation regex families, and string/entropy features, and uses XGBoost as the primary model. Without adversarial training, XGBoost reaches 95.27% TPR on the standard MalwareBench test set at 1% FPR but only 24.30% on the adversarial test set. With adversarial training using the top 20% of generated adversarial variants, the same model reports 95.64% on the standard test set and 86.81% on the adversarial test set at the same 1% FPR; the authors summarize this as a 2.5× robustness improvement and note that adversarial packages bypass state-of-the-art detectors with an 87.42% success rate before adversarial training (Montaruli et al., 3 Dec 2025).

Threshold adaptation is central to deployment. In a PyPI-maintainer setting tuned at 0.1% FPR, the detector analyzed 91,949 releases collected over 37 days and achieved 2.48 malicious packages per day with only 2.18 false positives per day. In an enterprise setting tuned at 10% FPR over 1,596 packages, it reported only 1.24 false positives daily across the same 37-day window (Montaruli et al., 3 Dec 2025). The operational lesson is not merely that repackaging is feasible, but that robustness must be calibrated to the false-positive tolerances of different actors.

6. Presentation-only adversarial repackaging in AI peer review

In AI peer review, adversarial repackaging is a closed-loop, black-box attack that modifies only presentation-level content while keeping scientific evidence fixed. The permissible edit space consists of source-level revisions that preserve evidence within the free-zone and limited-zone constraints, and the objective is

$t_{\max} = 10$ 3

The attack iterates through six stages—Profile, Plan, Edit & Compile, Review, Evaluate, Update—and accepts a candidate only if it passes a direction gate based on $t_{\max} = 10$ 4, $t_{\max} = 10$ 5, and $t_{\max} = 10$ 6, with default thresholds $t_{\max} = 10$ 7, $t_{\max} = 10$ 8, $t_{\max} = 10$ 9, and SelectionScore $F1 \approx 72\%$ 0 using $F1 \approx 72\%$ 1 and $F1 \approx 72\%$ 2 (Yang et al., 11 Jun 2026).

The empirical results are unusually strong for an attack that leaves methods and results unchanged. Across three mainstream AI reviewers, adversarial repackaging reports a cross-model average $F1 \approx 72\%$ 3 and attack success rate 75.1%. By model, Sonnet 4 reports $F1 \approx 72\%$ 4 and ASR 87.0%, Sonnet 4.5 reports $F1 \approx 72\%$ 5 and ASR 79.8%, and GPT-5-mini reports $F1 \approx 72\%$ 6 and ASR 58.4%; all $F1 \approx 72\%$ 7 values are statistically significant with Wilcoxon signed-rank $F1 \approx 72\%$ 8 (Yang et al., 11 Jun 2026).

The mechanism is not ordinary prose polishing. Related-work repositioning and analytical discussion expansion show accepted exposure rates of about 49.3% and 44.9%, whereas surface edits such as local polishing, table formatting, and algorithm boxes fall around 26.5–29.8%. Per-round analysis shows strengths improved in 86.1% of rounds, weaknesses were alleviated in 68.4% of rounds, and 31.6% of rounds exhibited weakness “backfire,” leading to the characterization that AI reviewers are easier to impress than to convince. The paper also documents a second failure mode: unchanged evidence can be reinterpreted as stronger contribution when omissions are reframed as methodological decisions, scarcity is reframed as design intent, or proposition/remark wrappers soften the perception of insufficient rigor (Yang et al., 11 Jun 2026).

Mitigation proposals therefore focus on anchoring evaluation to immutable evidence. The proposed interventions include stricter rubrics that separate scientific soundness from writing and presentation, evidence-linked scoring requiring direct citation of figures, tables, and equations, counterfactual evaluation under randomized presentation variants, adversarial robustness testing with presentation-only perturbations, and hybrid human-in-the-loop review in which AI systems summarize and structure but humans arbitrate scientific judgment (Yang et al., 11 Jun 2026).

Across these literatures, adversarial repackaging repeatedly exploits the same asymmetry: the cost of altering representation is often lower than the cost of altering semantics, while many detectors, reviewers, and integrity mechanisms remain more sensitive to representation than to semantics. The accumulated evidence from Android malware, packed executables, firmware, source-package ecosystems, and AI peer review suggests that robust defenses require either semantics-aware features, repeated dynamic observation, or explicit anchoring to immutable evidence rather than to mutable surface form (Salem, 2018, Mohammed et al., 7 May 2026, Yang et al., 11 Jun 2026).