---
title: 'Purifire: Android Evasion Engine'
url: https://www.emergentmind.com/topics/purifire
type: topic
---

# Purifire: Android Evasion Engine

Purifire is an evasion engine for Android dynamic analysis that bypasses packers’ anti-analysis techniques without unpacking the protected application. It was proposed against a setting in which commercial Android packers embed anti-debugging, anti-hooking, anti-instrumentation, and related checks that defeat tools such as Frida and Xposed, while existing unpackers increasingly fail because of incomplete code exposure, dynamic and native code loading, and the continuing evolution of packers. Purifire instead enables analysis on the packed app itself, using eBPF in kernel space to enforce configurable evasion behavior while remaining outside the visibility scope of common userspace detection strategies [2509.16340].

## 1. Problem setting and conceptual position

Android packers are used to protect apps against tampering and analysis, and the reported motivation for Purifire is that these protections also obstruct legitimate dynamic inspection. In the study introducing the system, none of the examined unpackers remained effective on emerging commercial packers, and unpacked apps could no longer run. Purifire therefore adopts a different operational premise: it does not attempt to defeat the packer by reconstructing a clean application image, but instead “lives alongside it,” permitting runtime analysis directly on the packed app [2509.16340].

This positioning is central to the system’s scope. Purifire is designed to restore the usefulness of dynamic-analysis workflows that depend on runtime observability, particularly when packers crash or block instrumentation frameworks. The paper frames this as a practical alternative to unpacking in environments where code is released in multiple stages, native code is loaded on demand, and anti-analysis logic is intertwined with the app’s execution path. A common misconception is therefore that Purifire is an unpacker. It is not: its goal is dynamic analysis without unpacking, and it does not yield a fully reconstructed Dex for offline analysis [2509.16340].

## 2. System architecture

Purifire is composed of three main parts: a **Userland Controller**, an **eBPF Kernel-space Program**, and **Defined Evasion Rules (DERs)**. The controller loads and parses DER configuration and manages policy updates; the kernel component enforces those rules; and the DERs specify the triggers and responses used to neutralize anti-analysis behavior [2509.16340].

| Component | Role | Implementation detail |
|---|---|---|
| Userland Controller | Loads and parses DER configuration; manages policy updates | User space |
| eBPF Kernel-space Program | Enforces DERs; intercepts and manipulates app behavior | Kernel space |
| Defined Evasion Rules | Describe conditions and evasion responses | Config files |

The architectural choice of eBPF is deliberate. The paper describes eBPF as a modern Linux kernel feature for safe, event-driven, programmable inspection or manipulation at kernel level. In Purifire, that substrate provides both observability and invisibility to userspace applications. The engine hooks low-level execution events rather than injecting analysis code into the app’s process, and it is presented as lightweight and practical because it requires no OS or AOSP modification and operates on modern rooted devices [2509.16340].

The implementation targets ARM64 Android devices with kernels 5.10 and above, and portability is supported through CO-RE and Aya-Rust. Communication between the controller and kernel logic uses RingBuffers and Maps, while direct in-memory intervention relies on `bpf_probe_write_user()` and `bpf_probe_read_user()` helpers. This combination gives the system access to runtime state that is normally used by packers for anti-analysis checks, while keeping the intervention path below the userspace boundary from which those checks are usually performed [2509.16340].

## 3. DERs and intervention semantics

The rule system is the main abstraction by which Purifire operationalizes evasion. A DER contains a **condition** and an **evasion**. Conditions can filter on process name, thread, syscall type, syscall arguments, and specific data. Evasions specify how to patch memory, alter a syscall return, or otherwise modify app behavior at runtime [2509.16340].

The paper gives a concrete example based on `openat`: when a target attempts to open `/proc/self/task/`, a DER can redirect the operation to `/data/local/tmp/fake`. The example is significant because `/proc/self/task/` access is a known anti-Frida pattern in the paper’s terminology, and the rule shows that Purifire’s intervention model is not limited to logging or passive tracing. It can rewrite arguments and steer the app away from sensitive kernel- or procfs-visible state that would otherwise reveal instrumentation [2509.16340].

Purifire uses this mechanism in three principal ways. First, it intercepts file and memory probes and rewrites paths, arguments, or contents to hide Frida, debuggers, root, or other artifacts. Second, it performs in-place code or data patching after runtime decryption or loading, allowing detector functions or self-destruct logic to be neutralized even when packers expose code only transiently. Third, it manipulates memory or syscall behavior to prevent suspicious anti-analysis threads or processes from being created. These behaviors are presented as targeted and configurable rather than as a single hard-coded bypass strategy [2509.16340].

## 4. Execution model and assisted analysis

Purifire instruments syscalls such as `openat`, `mprotect`, `ptrace`, `prctl`, and `readlinkat` through eBPF kprobes and tracepoints. That syscall-centered model is paired with memory-aware intervention, permitting a rule author to connect kernel-observed behavior to concrete code or data regions inside the target process [2509.16340].

To support rule creation, the system includes assisted-analysis tooling. The paper describes **syscall–memory mapping** that correlates syscalls with memory regions and stack backtraces, and **stack trace integration** that reports offsets and call locations. The intended effect is to help analysts identify the minimum evasion point needed for a given packer behavior, which in turn supports more precise patching. A plausible implication is that Purifire is meant not only as a runtime bypass engine but also as a rule-authoring environment for repeated packer families; the paper makes this explicit by noting that DERs can be shared and reused among analysts as “community DERs” [2509.16340].

This workflow reflects the system’s broader design philosophy. Purifire is dynamic rather than static; it does not require rebuilding Android, modifying AOSP, or pre-transforming the application package. It is also intended to coexist with standard dynamic-analysis tooling. The paper emphasizes that existing Frida-based research tools, API tracing pipelines, memory-dump workflows, and network-inspection setups can become usable again once the relevant anti-analysis checks are bypassed [2509.16340].

## 5. Empirical evaluation

The paper reports a large-scale prevalence analysis over **12,341 apps**, comprising **7,913 Chinese** apps and **4,428 global** apps. Within that dataset, approximately **59% of Chinese apps** were packed, compared with **2% of global apps**. It further reports that **Frida and JDB-based dynamic tools were blocked or crashed in 28%+ of real-world apps**, especially in the Chinese subset [2509.16340].

Purifire’s direct evaluation focuses on previously blocked apps. On **2,340 apps** affected by anti-analysis protections, Purifire enabled Frida on **662 additional apps**, which the paper reports as **28% of them** and **5% of the whole dataset**. The paper explicitly notes that this outcome is contingent on existing DER coverage, implying that broader rule coverage could extend that number [2509.16340].

The study also evaluates downstream impact on prior research workflows. In a **device fingerprinting** case study associated with **Heid et al.**, the number of unique fingerprints detected increased from **79,260** to **131,173**, a reported **+65%**. In a **covert identifier collection** case study associated with **Dong et al.**, observation of external file accesses in sampled packed apps increased from **133 unique** to **3,355**, described as an approximately **24×** increase. These case studies are used to argue that Purifire improves not merely the ability to attach an instrumentation framework, but the effective code coverage and event visibility of dynamic-analysis pipelines that had previously been impaired by packers [2509.16340].

## 6. Scope, limitations, and technical significance

Purifire’s limitations are stated explicitly. DER creation is manual and requires packer-specific expertise, although the paper characterizes this as a one-time effort whose output can be shared. The system requires **kernel 5.10 or newer**, which constrains deployment to modern devices and emulators. **Java-only anti-analysis** implemented entirely within ART is less accessible to the eBPF-based approach because of stack-unwinding limitations. Memory patching is impossible when the relevant region is not writable, although the paper notes that many packers temporarily make regions writable during execution [2509.16340].

These constraints delimit the system’s domain. Purifire is not presented as a universal bypass for every anti-analysis strategy, nor as a replacement for offline reverse engineering. Instead, it is described as a practical mechanism for restoring dynamic observability on packed apps under modern Android kernels. The paper further characterizes it as **the first kernel-level, eBPF-based evasion engine** that enables dynamic-analysis tools to operate transparently on packed Android apps without unpacking them [2509.16340].

Its broader significance lies in the shift from unpacking-centric analysis to co-resident runtime evasion. Rather than treating packers as something that must be removed before inspection can begin, Purifire treats them as a persistent execution environment within which observability must be re-established. This suggests a different research and engineering program for Android analysis: one centered on low-level, event-driven intervention, reusable evasion rules, and compatibility with existing dynamic-analysis ecosystems rather than on complete recovery of a deprotected application image [2509.16340].

Source: https://www.emergentmind.com/topics/purifire