AUTOVR: Unity VR Testing and Privacy Auditing

• AUTOVR is a grey-box, binary-driven framework for Unity-based VR apps that recovers UI semantics and systematically uncovers sensitive data exposures.
• It employs a three-phase architecture combining UI semantics recovery, generative event modeling, and context-aware event execution.
• The framework improves sensitive data flow detection, achieving up to 3.3x better coverage than conventional Android GUI testers.

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":"(Kim et al., 17 Aug 2025)", "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 (Kim et al., 17 Aug 2025).

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 (Kim et al., 17 Aug 2025).

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 (Kim et al., 17 Aug 2025).

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 (Kim et al., 17 Aug 2025).

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 (Kim et al., 17 Aug 2025).

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:

$E$1

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 (Kim et al., 17 Aug 2025).

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:

$D$0

In the reported experiments, $D$1 overall, and on average $D$2 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 (Kim et al., 17 Aug 2025). 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 $D$3 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 $D$4 to scene count $D$5 is reported as Pearson $D$6 with $D$7, while the correlation of $D$8 to object count $D$9 is $E$0. 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 (Kim et al., 17 Aug 2025).

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.