---
title: 'AUTOVR: Unity VR Testing and Privacy Auditing'
url: https://www.emergentmind.com/topics/autovr
type: topic
---

# AUTOVR: Unity VR Testing and Privacy Auditing

Searching arXiv for AUTOVR and closely related VR app analysis/testing papers.
arxiv_search.query({"search_query":"all:AUTOVR OR ti:AUTOVR OR abs:\"Unity\" AND abs:\"VR\" AND (abs:privacy OR abs:testing OR abs:fuzzing)", "start": 0, "max_results": 10, "sort_by": "submittedDate", "sort_order": "descending"})
Searching for the specific AUTOVR paper and related work on VR privacy analysis.
arxiv_search.search({"query":"2508.12187", "max_results": 5})
AUTOVR is a grey-box, binary-driven framework for automatically exploring and interacting with the user interface and in-game events of Unity-based Virtual Reality applications, with a particular focus on uncovering sensitive data exposures. It was introduced to address the lack of robust headless tools for UI exploration and user event testing in VR apps, especially on the Meta Quest platform, whose interaction model differs from that of conventional devices such as smartphones. Unlike conventional Android and GUI testers, AUTOVR analyzes the app’s internal binary to reveal hidden events, resolves generative event dependencies, and uses them for comprehensive exploration of VR apps [2508.12187].

## 1. Problem setting and scope

AUTOVR is situated at the intersection of VR application testing, dynamic binary analysis, and privacy auditing. The motivating problem is that Unity-based VR apps expose interaction surfaces that are not adequately covered by conventional headless Android GUI stress testing. In particular, VR applications combine standard UI callbacks with physics-mediated interactions, and both classes of events may be hidden behind prior state transitions, scene changes, or editor-bound callback assignments rather than explicit source-level code paths [2508.12187].

The framework therefore targets three specific gaps. First, it seeks to recover UI semantics from stripped IL2CPP binaries. Second, it models what the system describes as generative event dependencies, meaning that triggering one event may enable or disable others. Third, it uses sensitive data exposure as the evaluation objective, rather than generic event counts alone. This design choice ties exploration coverage to a concrete security outcome: the number of unique sensitive data-flow exposures triggered.

A key conceptual distinction in AUTOVR is between black-box fuzzing and binary-driven exploration. The system does not rely solely on external input generation. Instead, it reconstructs internal Unity event structure from runtime metadata and directly invokes recovered callbacks. This suggests a testing regime that is closer to semantic exploration than to random interaction replay.

## 2. Three-phase architecture

AUTOVR’s workflow is organized into three tightly integrated phases: UI Semantics Recovery, Generative Event Modeling, and Context-aware Event Execution [2508.12187].

| Phase | Mechanism | Output |
|---|---|---|
| UI Semantics Recovery | Frida-based instrumentation of `libil2cpp.so` and Unity introspection APIs | Global class/function tables and live object inventory |
| Generative Event Modeling | Recovery of UI and physics Event Function Callbacks (EFCs) | Scene-level event set with callback pointers and targets |
| Context-aware Event Execution | Depth-first execution with re-introspection and back-tracking | Exploration of enabled/disabled event branches |

In the first phase, AUTOVR instruments the IL2CPP game binary through Frida and calls Unity’s internal APIs to reconstruct metadata that is not directly available from stripped binaries. In the second phase, it extracts executable event callbacks from both UI components and physics objects. In the third phase, it executes those callbacks while continuously updating a dependency model that captures how one action changes the set of reachable actions.

This phase decomposition is important because the framework does not treat event discovery and event execution as separable tasks. Event execution can expose additional UI components, callbacks, or physics handlers that were not visible in the initial scene state. As a result, exploration is iterative and state-dependent rather than flat.

## 3. Binary analysis and event recovery

AUTOVR leverages a hybrid of static and dynamic binary analysis on IL2CPP-compiled VR apps. Unity’s IL2CPP AOT compiler emits a stripped native library, `libil2cpp.so`, together with an encrypted metadata blob, `global-metadata.dat`. At runtime, the IL2CPP VM decrypts `global-metadata.dat` into in-memory class and method tables. AUTOVR uses Frida to hook into and directly call internal IL2CPP APIs for class metadata extraction, method metadata extraction, and object enumeration [2508.12187].

The framework builds a global class table through `il2cpp_class_*` APIs such as `il2cpp_class_get_name` and `il2cpp_class_get_parent`, and a global function table through `il2cpp_method_*` APIs such as `il2cpp_method_get_name` and `il2cpp_method_get_pointer`. It then invokes `il2cpp_capture_memory_snapshot` to enumerate all live `GameObject` instances and their `Component` fields. UI components are identified by filtering loaded objects whose `Component` classes implement the `IEventSystemHandler` interface.

For UI events, AUTOVR inspects each relevant component, such as `Button`, and extracts `UnityEventBase` fields `m_Calls` and `m_PersistentCalls`. It traverses `InvokableCallList` and `PersistentCallGroup` containers through field introspection to recover every Event Function Callback, together with its method pointer and target object. This mechanism is specifically intended to recover callbacks assigned in the Unity Editor rather than bound by code, overcoming a limitation of pure static tools such as `Il2CppDumper` and black-box fuzzers.

For physics events, the system enumerates all `Collider` components and `Rigidbody` attachments. A `GameObject` is classified as triggerable if it has a `Collider` with `isTrigger=true` and implements `OnTriggerEnter`, `OnTriggerStay`, or `OnTriggerExit`. A `GameObject` is classified as collisionable if it has a `Collider` plus `Rigidbody`, `isTrigger=false`, and implements `OnCollisionEnter`, `OnCollisionStay`, or `OnCollisionExit`. Each physics EFC is recorded with its virtual address for later invocation.

## 4. Generative dependencies, state modeling, and exploration

A central claim of AUTOVR is that Unity UIs and physics interactions are generative: UI elements and objects can be enabled or disabled in response to prior events. A naive flat exploration would therefore miss deep execution paths. AUTOVR addresses this by constructing a per-scene dependency model in which each node represents a known set of enabled EFCs and each edge corresponds to invoking one EFC [2508.12187].

Execution proceeds in depth-first order. The framework selects an unexplored EFC, invokes it by calling its function pointer through Frida’s `NativeFunction`, and then re-scans the scene to discover newly enabled or disabled EFCs. Newly enabled EFCs are added as child nodes in the state tree. Disabled EFCs are remembered but cannot be executed until a back-track restores the appropriate state.

Back-tracking is implemented by reloading the current scene through Unity’s `LoadSceneAsyncNameIndexInternal` function. The same mechanism can also support re-invoking a parent EFC within the same scene. The purpose is to restore the initial state so that alternative event branches remain explorable. The framework states that this guarantees that for each scene the exploration terminates only after all branches have been exercised.

The paper gives the exploration procedure in the following form:

```text
DFS_Event_Explore(S₀):
  for each e ∈ E(S₀) not yet triggered do
    Invoke(e)
    Δ ← Re-introspect scene; update E and D
    DFS_Event_Explore(S₀’)  // S₀’ is the new state after e
    Backtrack()  // reload S₀ to restore disabled EFCs
```

Formally, with $E$ as the set of all discovered EFCs in a scene, $D$ as the dependency graph among $E$, and $S_0$ as the initial scene state, the framework explores the event space by recursive DFS over state transitions. Its worst-case running time per scene is approximated as

$$
O( |E| \cdot (|P_c| + |P_t| + (|C_t| + |C_f|)) + |D| )
$$

where $P_c$ and $P_t$ are the numbers of collisionable and triggerable objects, $C_t$ and $C_f$ are the numbers of class types and their fields for UnityEvent extraction, and $D$ is the number of dependency edges.

## 5. Sensitive-data flow detection

AUTOVR measures exploration quality through privacy-relevant outcomes rather than interaction counts alone. During dynamic exploration, it concurrently runs AntMonitor, adapted for non-rooted Quest 2 devices, to intercept TLS traffic. Because many targets employ certificate validation and related defenses, the framework includes explicit SSL-pinning bypasses at both the Android and Unity layers [2508.12187].

At the Android layer, AUTOVR hooks `okhttp3` and `javax.net.ssl` APIs using common bypass patterns. At the Unity layer, it hooks `mbedtls_x509_crt_verify_with_profile` and `x509_crt_verify_restartable_ca_cb` in `libunity.so`, returning success unconditionally. The intercepted traffic is then parsed for sensitive payloads, including PII, device fingerprinting, and VR-specific sensor data, using patterns from OVRSeen and PoliCheck.

The principal metric is Unique Sensitive Data Exposures (USDE), defined as the number of distinct data types exposed, with examples including `DEVICE_ID`, `USER_ID`, and `GPS_COORD`. The framework also reports an improvement ratio over Android Monkey:

$$
R = \frac{USDE_{\mathrm{AutoVR}}}{USDE_{\mathrm{Monkey}}}
$$

In the reported experiments, $R \approx 390 / 117 \simeq 3.33$ overall, and on average $2.2\times$ across all apps. Because the detection pipeline is tied to concrete traffic interception and content parsing, AUTOVR is positioned not merely as an interaction explorer but as a dynamic auditing system for sensitive-data flows.

The paper further states that this enables auditors and platform owners to quantify first-party versus third-party data exfiltration, detect undeclared PII collection buried behind nested UI submenus, and evaluate compliance with stated privacy policies through PoliCheck cross-comparison.

## 6. Empirical evaluation

AUTOVR was evaluated against Android Monkey on 366 Unity VR apps, comprising 263 free and 103 paid titles, with each app run under a 20 min time budget [2508.12187]. The comparison uses sensitive-data coverage as the main outcome.

| Evaluation item | AUTOVR | Android Monkey |
|---|---:|---:|
| Unique sensitive data flows | 390 | 117 |
| Average runtime per app | 222 s | 120 s |
| Custom 3-scene app branch coverage | 100 % of 28 EFC branches | Fewer than 10 % |

On the corpus of 366 apps, Monkey discovered 117 unique sensitive data flows, whereas AUTOVR discovered 390 unique sensitive data flows, approximately $3.3\times$ more. On a small custom VR app with three scenes—UI only, physics only, and mixed—AUTOVR exercised 100 % of all 28 EFC branches, whereas Monkey exercised fewer than 10 %.

The framework also analyzes runtime correlates. The correlation of runtime $T$ to scene count $S$ is reported as Pearson $r \approx 0.6721$ with $p < 0.01$, while the correlation of $T$ to object count $O$ is $r \approx 0.24$. This suggests that exploration cost is more strongly associated with the number of scenes than with raw object count.

Although AUTOVR’s average runtime per app, 222 s, exceeds Monkey’s 120 s, the paper presents this overhead as offset by substantially higher sensitive-data coverage. The evaluation therefore emphasizes coverage-efficiency tradeoffs rather than absolute execution speed alone.

## 7. Limitations, extensions, and significance

AUTOVR currently supports only Unity IL2CPP apps. The paper identifies several limitations. It does not provide symbolic resolution of EFC arguments, so parameterized events such as text input remain unexplored. Scene reload backtracking imposes overhead, and incremental checkpointing is proposed as a possible improvement. The framework also does not perform full taint-tracking inside the app, leaving sensitive data on local files or inter-component leaks out of scope [2508.12187].

The future-work agenda follows directly from those constraints. Proposed extensions include support for a Mono backend, integration with SMT solvers such as Z3 to solve event constraints, support for Unreal Engine binaries, and a crash-detection plugin leveraging AUTOVR’s state model.

In broader methodological terms, AUTOVR represents a shift from generic input fuzzing toward runtime reconstruction of the internal Unity event graph. Its combination of IL2CPP metadata recovery, scene-aware dependency modeling, and TLS-level data-flow auditing makes it a specialized framework for immersive application analysis rather than a simple adaptation of mobile GUI testing. A plausible implication is that privacy and security auditing for VR software requires event-semantic coverage that conventional Android tooling under-approximates, especially where interaction reachability depends on editor-defined callbacks, physics triggers, and scene-conditional state changes.

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