VR-Themis: A Scalable Framework for Virtual Reality Application Clone Detection

VR-Themis: A Scalable Framework for Virtual Reality Application Clone Detection Gengyang Xu1,4 , Hanyang Guo2 , Hong-Ning Dai1⋆ , and Weizhi Meng3 Hong Kong Baptist University, Hong Kong, China henrydai@comp.hkbu.edu.hk 2 Sun Yat-Sen University, Guangdong, China 3 Lancaster University, Lancaster, UK 4 Hong Kong University of Science and Technology, Hong Kong, China gxuah@cse.ust.hk

arXiv:2608.13290v1 [cs.CR] 13 Aug 2026

1

Abstract. Repackaging of mobile applications (aka app cloning) not only threatens the security and privacy of mobile users but also infringes upon the copyright of the original app developers. However, existing detection methods that primarily focus on mobile platforms (such as Android) fail to capture the essential features of virtual reality (VR). Consequently, they are inadequate for effectively detecting cloned VR apps, which have often been targeted by illegal users in the VR market. Considering the unique features of VR apps, this paper proposes a two-stage app clone detection framework, namely VR-Themis, based on Hierarchy-Object-Behaviour (HOB). Firstly, VR-Themis exploits the coarse-grained stage to cluster apps based on their retrievable statistical features, making this tool scalable to large-scale VR app datasets. Then, in the fine-grained stage, VR-Themis performs in-depth analysis of the suspicious apps (identified in the first stage) by calculating similarity using our defined HOB metrics. Our extensive experiments indicate that VR-Themis successfully detects 307 suspected clone apps from the collected 4,277 VR apps without false positives, demonstrating its effectiveness and scalability. Keywords: Software Clone · Mobile Security · Virtual Reality.

1

Introduction

Repackaged VR apps pose a significant threat to VR ecosystems. They undermine the interests of original developers, increase the maintenance burden on app markets, and threaten user privacy. For instance, Commuter Games reported that their VR racing game, Downtown Club, has about five times more players than the copies sold. Similarly, Realcast’s Just Hoops has nearly six times as many users as copies sold [6]. This phenomenon is largely due to the presence of pirated versions repackaged [6]. Furthermore, repackaged VR apps significantly ⋆

Corresponding author.

2

G. Xu et al.

increase users’ vulnerability to security and privacy attacks (e.g., inception attacks [53]). Although some VR headset companies have released solutions (e.g., Meta Quest Attestation API [26]), their reliance on online connectivity makes them vulnerable to crafty circumvention. As of this writing, active VR piracy communities continue to thrive, disseminating sources for repackaged pirated app downloads and methods for installing unauthorized apps on VR headsets, posing a lasting challenge to the industry [31,30,29,48]. In fact, the VR ecosystem is not the first mobile ecosystem to face the threat of app cloning. The ease of repackaging on mobile platforms has made them hotspots for illegal users. For example, Android apps are easily repackaged using reverse engineering tools, such as Apktool [3], dex2jar [10], and JADX [40]. These tools enable users to decompile apps, modify intrinsic contents, and then repackage them for distribution. Existing state-of-the-art clone detectors for mobile apps rely on various features for similarity comparison, including code-centric similarity [9,58], layout similarity of User Interface (UI) [41], resource metadata comparison [56], and combinations of them [55,37]. Despite the numerous existing clone detection approaches for mobile apps, VR platforms introduce novel development features that render conventional methods entirely ineffective for detecting clones in VR applications. Traditional mobile app development primarily relies on tools like Android Studio [12], focusing on 2D interface design and application logic. As a result, existing mobile app clone detectors typically use code, UI layouts, and resource metadata as the main features in their similarity metrics. In contrast, the development of VR apps emphasizes immersive 3D scene design. According to a breakdown of VR development costs, primary budget allocations include 30% for digital assets (e.g., 3D modeling and animation), 25% for code development, and 15% for 3D user interaction design [49]. This allocation reflects the increased importance of non-code asset creation and 3D scene design in VR, highlighting the limitations of mobile-oriented clone detection methods. In summary, existing state-of-the-art mobile app clone detection approaches are inherently infeasible for VR apps due to three key reasons: (1) The 3D scene structures of VR apps cannot be represented by the 2D UI layouts used in mobile applications; (2) VR apps heavily rely on non-code assets (e.g., 3D models and animations) that are not considered in mobile-oriented detection methods; and (3) 3D development engines (e.g., Unity) typically provide protection mechanisms (e.g., IL2CPP in Unity), which invalidate code-centric similarity metrics. These disparities necessitate a novel detection approach tailored specifically for VR ecosystems, rather than incremental improvements over existing mobile-oriented methods. To bridge this research gap, this paper proposes a novel clone detection approach specifically designed for VR apps, named VR-Themis5 . This detection approach adopts a two-stage framework and is specifically designed to address three critical challenges in VR app clone detection: 5

The name VR-Themis is inspired by the Greek goddess Themis, who can distinguish faked/cloned objects.

VR-Themis: VR Application Clone Detection

3

(1) Complexity of Pairwise Comparison. Directly comparing all possible pairs of VR apps becomes computationally prohibitive with large datasets. VRThemis addresses this challenge through a coarse-grained stage that groups VR apps based on retrievable statistical features, thereby significantly reducing the complexity of comparisons. (2) Limitations of Conventional Clone Detection Characteristics and Metrics. Existing mobile app clone detection methods rely on features such as code, UI layouts, and resource metadata, which are ineffective for the unique complexities of VR apps. Unlike mobile apps, VR apps involve intricate 3D scene hierarchies with interconnected GameObjects, immersive visual elements, dynamic interaction components, and customized script Behaviours. To characterize these unique features of VR apps, we propose the Hierarchy-Object-Behaviour (HOB) model, a structured representation tailored for VR. Additionally, conventional similarity metrics fall short in capturing the multi-dimensional complexities of VR apps. To overcome this challenge, VR-Themis introduces HOB metrics, a three-tiered similarity metric suite based on the HOB model by integrating Hierarchy Edit Distance for structural differences, GameObject Node Distance for visual and functional variations, and Script Behaviour Similarity for Behavioural consistency. This synergy allows VR-Themis to perform fine-grained and multidimensional comparisons of suspicious cloned apps. (3) Scarcity of Benchmark Datasets for VR Clone Detection: Unlike the mobile app ecosystem, the VR domain lacks publicly available datasets specifically designed for proprietary VR app clone detection. To the best of our knowledge, there is currently no benchmark tailored for proprietary VR app clones with the provision of reliable ground truths. Additionally, existing VRrelated datasets from other research do not meet the scale requirement for our study. Consequently, we constructed our own dataset consisting of 4,277 VR apps from multiple sources (more details in §5.1). For our experiments, we also utilize a smaller, carefully curated subset of this dataset, with manually verified clone truths, to determine thresholds and report accuracy. In summary, the main contributions of this work are highlighted as follows: – We construct a VR app dataset collected from diverse sources, including side-loading channels that have not been considered in previous research. – We propose an automatic app clone detection approach. As far as we know, this is the first study on proprietary VR app clone detection. Our two-stage method incorporates a coarse-grained clustering to reduce comparison space, followed by fine-grained in-depth comparisons. – We introduce HOB metrics, a VR similarity metric suite based on our HOB model. This metric suite is specifically designed to compare the unique characteristics of VR apps, including intricate 3D scene hierarchies, object-level visual and functional components, and script-driven Behaviours. – We conduct extensive experiments on 4,277 Unity-based VR apps. Results show that VR-Themis effectively and efficiently detects cloned VR apps with high accuracy. Our artifact is available at [51].

4

G. Xu et al.

2

Background and Threat Model

2.1

Mobile Application Clone

App cloning has become a significant concern in the mobile app industry, as it often facilitates various cybercrimes. Common motivations include: inserting malicious code into popular apps [21], hijacking advertising revenue [58], distributing cracked versions that bypass paid features [29], creating unauthorized localizations [47], and plagiarizing proprietary 3D assets with minimal effort [61]. The last motivation is particularly disruptive in VR, where high-quality 3D models and animations require substantial development resources. 2.2

VR Application Development

VR operating systems (OSs) (e.g., Meta Horizon OS [25] and PICO OS [28]) are custom-developed on top of Android OS. However, VR application development differs significantly from conventional mobile app development (e.g., Android SDK) due to the unique requirements of VR platforms. VR development emphasizes immersion that enables users to engage naturally with their surroundings. Unlike traditional mobile app development, where coding plays a predominant role, VR development places significant importance on creating high-quality 3D assets and designing immersive 3D scenes. A VR app typically consists of several scenes, where a scene is defined as an asset that contains all or part of an app [45]. The VR scene representation serves as the structural foundation for organizing the visual, functional, and interactive elements within 3D virtual environments. In most VR development engines, this representation adopts a tree structure, commonly referred to as the hierarchy. The hierarchy represents the grouping and parent-child relationships among GameObjects [42]. Each node in the scene’s hierarchy tree corresponds to a GameObject, where the parent GameObject may contain other child GameObjects inheriting the parent’s properties. GameObjects are the fundamental elements in the VR engine to represent real objects like balls, lights, cameras, and so on [45]. Nevertheless, GameObjects cannot perform any functions themselves; they only serve as containers. To enable a GameObject to possess a specific object’s necessary properties, one or more components must be attached to it. In Unity, various built-in components are provided, though developers can also create their own components using the Unity Scripting API [42]. 2.3

Threat Model

We define the threat model from the following perspectives. Goal: The goal of VR-Themis is to accurately identify cloned VR apps, which are defined as two (or more) apps exhibiting substantial similarity in architecture and fundamental assets but are distributed under distinct ownership without explicit authorization. This focus distinguishes VR app clone detection from

VR-Themis: VR Application Clone Detection

5

code reuse detection, as the latter does not emphasize scene hierarchies and digital assets. Adversary capabilities: An adversary possesses the following capabilities: – Decompilation: The adversary can use tools like AssetStudio [5] to decompile VR APKs and extract scene hierarchies, assets (e.g., meshes, textures, and animations), and C# scripts. – Modification: The adversary can obfuscate or minify scripts (e.g., renaming methods and variables in C#), modify 3D models (e.g., squashing, stretching, and vertex perturbation), and alter scene hierarchies. – Distribution: The adversary can distribute cloned apps through unofficial channels (e.g., sideloading platforms) or masquerade as developers. Assumptions: First, we assume that most VR apps store their scene hierarchies and assets statically within the VR APK. This assumption is supported by the fact that the majority of VR apps are designed to function in an offline way. Apps that dynamically load resources at runtime or retrieve assets from remote servers are outside the scope of this work. Second, we assume that the adversary is capable of performing minor modifications to cloned VR apps to circumvent detection. These modifications may include code obfuscation, asset perturbation, and alterations to the scene hierarchy. However, the adversary is unlikely to fully redesign the app or make significant architectural changes due to resource and time constraints.

3

Hierarchy-Object-Behaviour Similarity Metric for VR App Clone Detection

This section introduces a modeling framework for VR app clone detection by combining a representation with its similarity metrics. We first present the Hierarchy-Object-Behaviour (HOB) model, which encodes a VR app as scene hierarchies of GameObjects, comprising objects with components and script-driven Behaviours. Building on this representation, we define HOB metrics, a multidimensional suite of similarity measures. Together, the HOB model and HOB metrics capture VR-specific characteristics that extend beyond mobile-oriented features. We depict the HOB model, formalize HOB metrics, and explain their integration into VR-Themis’s fine-grained comparison as follows. 3.1

Hierarchy-Object-Behaviour Model

To overcome the limitations of conventional mobile-oriented app clone detectors in capturing VR-specific characteristics, we propose a HOB model. This model provides a structured representation of VR apps by analyzing their scene hierarchy (Hierarchy), 3D objects (Object), and script-driven components (Behaviour). Fig. 1 illustrates an example of a VR application represented by the HOB model. By comprehensively capturing the characteristics of VR apps from

6

G. Xu et al. root level1

level0 Court Wall ···

Hoop

Floor ··· Rim Pole ··· ···

Ball

... ...

...

AudioSource BoxCollider

··· Base ···

Hierarchy Object (GameObject) Behavior (Component)

Fig. 1. An example of a VR app represented by the HOB model

high-level structural representations to detailed functional Behaviours, it effectively overcomes the shortcomings of mobile app clone detection methods in handling 3D scenes and non-code assets. Hierarchy. VR apps typically consist of multiple scenes (levels), each represented as a hierarchy tree. This structure describes the parent-child relationships and organization of all objects (i.e., GameObject) within a scene. The HOB model parses and extracts this hierarchical information from VR APK, organizing the VR app as a tree structure, in which each scene is represented as a sub-tree. Each node of a tree corresponds to a GameObject containing the following information: Components are multiple attachments defining the properties and Behaviours of the GameObject; and Transform includes 3D coordinates, rotation, and scale. In this way, the HOB model comprehensively reflects the architecture of a VR app. Object. In the HOB model, the definition of an object is based on the GameObject concept. GameObject’s functionality is enabled through the attachment of components. However, game engines lack an effective mechanism to classify GameObjects based on their functionality. This limitation introduces significant challenges when comparing GameObjects across different VR apps, as it requires examining all their components individually. Such an approach is both computationally expensive and inefficient, especially given the diversity and complexity of components. To address this issue, we introduce a classification mechanism that assigns a type to each GameObject based on its major components. This mechanism groups GameObjects with similar functionalities under the same type. For instance, when an AudioSource6 component is attached to a GameObject, we classify this GameObject as an Audio type. Our proposed GameObject type classification mechanism adheres to three criteria: 1) Comprehensiveness requires defining as many GameObject types as possible to ensure broad coverage; 2) Accuracy ensures that the assigned type accurately represents the GameObject’s functionality; and 3) No overlapping of type definitions guarantees that a GameObject cannot belong to multiple types simultaneously. To ensure accurate classification, we implement a priority mechanism that assigns each GameObject a unique type based on its highest-priority component, avoiding overlaps. 6

The AudioSource component endows the GameObject with the ability to play sounds in a 3D environment.

VR-Themis: VR Application Clone Detection

7

Behaviour. In VR apps, Behaviours are the core components that determine the interactivity and functionality, and their definition is based on the concept of Component. Behaviours are typically implemented through C# scripts, which extend the MonoBehaviour base class to define the functionality of GameObject. For example, Behaviours can trigger events, modify component properties, or respond to user inputs. Unlike built-in components provided by game engines, Behaviours consist of custom code written by developers, often using tools like the Unity Scripting API [42]. Illegal cloners frequently make minor modifications to Behaviour scripts, such as renaming variables, to evade detection. However, since Behaviour scripts directly control the functionality of GameObjects, their core logic is difficult to alter. Therefore, by extracting the key features of Behaviours, it is possible to identify Behavioural similarities for VR clone detection. 3.2

HOB Metrics: Multi-Dimensional VR App Similarity Measures

Effectively detecting VR app clones requires a reliable similarity metric that can comprehensively capture the structural, object-level (visual and functional), and Behavioural characteristics of VR applications. To this end, we propose a threetiered HOB metrics suite specifically tailored for VR applications based on our HOB model. HOB metrics include three core components: Hierarchy Edit Distance (HED) evaluates the structural differences between two VR scene hierarchy trees; GameObject Node Distance (GND) quantifies object-level visual and functional differences; and Script Behaviour Similarity (SBS) assesses the similarity of script-driven Behaviours within GameObjects. Together, these metrics provide a comprehensive framework for capturing high-level structural transformations, detailed object-level variations, and subtle Behaviour-level modifications. HED measures differences between two VR scene hierarchy trees. HED is defined as the minimum cost of transforming one scene hierarchy tree into another through a series of operations. Let T denote the collection of VR app scene hierarchy trees, represented as T = {T1 , T2 , . . . , Tn }, where n indicates the total number of apps within the collection. Each tree Ti (i ∈ [1, 2, . . . , n]) consists of a collection of nodes, denoted by set Ni , where each node is indexed as ni,j ∈ Ni for j ∈ [1, 2, . . . , m], with m being the total number of nodes in tree Ti . We mainly consider the following operations involved in transforming a scene hierarchy tree: insertion, deletion, substitution, and modification on a GameObject. The difference between substitution and modification lies in the former replacing a GameObject with a different type, while the latter modifies the components of a GameObject without changing its type. The cost of each operation is within the range [0, 1]. Specifically, the costs for node deletion, insertion, and substitution operations are all equal to 1 while the cost of node modification is equal to the distance between two GameObjects, to be measured by GND (see below). GND denoted by δGND quantifies the cost of modifying a GameObject by analyzing its components. Each GameObject is characterized by a set of various components, such as MeshRenderer, AudioSource, and MonoBehaviour. For most GameObject types, GND reflects functional differences by evaluating the Jaccard distance between two GameObjects’ component sets. Let Gk and Gl de-

8

G. Xu et al.

Algorithm 1: GameObject Node Distance (GND) calculation Input: Two GameObjects Gk and Gl . Output: Node distance δGND . Function GNDCalculation(Gk , Gl ) if Gk .type ̸= Gl .type then return 1 end if Gk .type = “3DObject” then if Gk .getMeshHash() ̸= Gl .getMeshHash() then return 1 end end intersectionSet ← ∅ unionSet ← ∅ foreach ck ∈ Gk .components do unionSet.add(ck .type) foreach cl ∈ Gl .components do if ck .type = cl .type then if ck .type = “MonoBehaviour” then similarity ← ComputeSBS(ck , cl ) if similarity > 0.8 then intersectionSet.add(ck .type) end else intersectionSet.add(ck .type) end end end end unionSet.add(Gl .components) | intersectionSet | δGND ← 1 − | unionSet | return δGND

note two GameObjects being compared. Their component sets are represented as Ck = Gk .components and Cl = Gl .components, respectively. Then, δGND is expressed as: |Ck ∩ Cl | δGND (Gk , Gl ) = J(Ck , Cl ) = 1 − , (1) |Ck ∪ Cl | where J(·, ·) denotes the Jaccard distance. However, an exception occurs when two GameObjects of type “ 3DObject” have different meshes. For 3DObject nodes, whose primary feature is their visual representation rather than functional differences, GND adopts a specialized mesh comparison method (to be elaborated in §4.3). If the meshes are different, their GameObject node distance is directly assigned to 1 without further comparison. This is because different meshes result in completely different visual information, making them incomparable even if all

node<GameObject>

*node: GameObject GameObject G_3 { name: "basketball", type: "3DObject", components:[c1, c2, ..., cn] }

VR-Themis: VR Application Clone Detection

9

(a) Scene hierarchy tree node<GameObject>

*node: GameObject GameObject G_3 { name: "basketball", type: "3DObject", components:[c1, c2, ..., cn] }

Substitution of G4 to G10

(a) Scene hierarchy tree

(a) Scene hierarchy tree T1 .

Modification of G8 to G'8

Insertion of G9

: Scene hierarchy tree : Node : GameObject

(b) Scene (b) hierarchy Scenetree hierarchy tree T2 .

Fig. 2. Examples of two scene hierarchy trees and their HED

: Scene hierarchy tree other components are identical. Algorithm 1 outlines the process for calculating : Node Insertion Substitution Modification : GameObject of G of G to G of G to G' the GND. Fig. 2 depicts an example of measuring two trees, T1 and T2 by HED. Scene hierarchy tree Each(b)node is linked to a corresponding GameObject. For example, node n2,3 corresponds to GameObject G3 in Fig. 2, in which node insertion and deletion only have a cost of 1, while the cost of modification is determined by Eq. (1). SBS measures similarity between scripts. When comparing two components, it is often sufficient to simply compare their types (built-in by the game engine), as this approach adequately reflects their functionality. However, for customdefined script components, it is necessary to compare the corresponding scripts to assess their Behaviours. To address this issue, we define SBS, which employs cosine similarity to evaluate the feature vectors extracted from scripts (details in §4.3). For two MonoBehaviour components ck and cl , we denote their script feature vectors by fk = fingerprint(ck ) and fl = fingerprint(cl ), respectively. The cosine similarity, denoted by γ, is defined as follows: 4

10

8

8

9

fk · f l γ = cos(α) = = qP ∥fk ∥∥fl ∥ d

Pd

u=1 fku · flu

2 u=1 fku ×

qP d

,

(2)

2 u=1 flu

where α denotes the angle between two vectors, and d is the dimension of the script feature vectors. When their cosine similarity is greater than or equal to 0.8, the components can be deemed identical. This threshold is chosen based on the common practice in mobile app repackaging detection, where sharing 80% of the code serves as a typical indicator [20].

4

Design of VR-Themis

This section elaborates on the design of VR-Themis, illustrated in Fig. 3, covering its scope and two-stage workflow: coarse-grained and fine-grained processing. 4.1

Scope

VR-Themis is specifically designed to detect cloned VR apps. This study primarily focuses on VR apps developed for Meta Quest series headsets due to

10

G. Xu et al.

Coarse-grained Processing

Fine-grained Processing Hierarchy Extraction

2

1

3

…

1

Hierarchy-level Features Object-level Features Behavior-level Features VR APK Clustering

Scene Hierarchy Processing

Camera Eyes

Assets Scene Hierarchy

Mesh Decimation

GameObject Type Identification

Cluster i

GameObject Component GameObject Type

5 Pair-wise Similarity

Calculation

Mesh Indexing 4 Script Processing

…

Cluster n

Cluster 2

3DObject Surface

Scene Hierarchy AssetStudio.Fine

Noise

3 Mesh Processing

Level0

…

Cluster 1

2

…

1 Asset and Scene

Statistical Feature Extraction

Hierarchy Tree 1

Hierarchy Tree 2

Script Preprocessing

Hierarchy Edit Distance

Metadata Vectorization

Script Behavior Similarity

HOB-Metrics GameObject Node Distance

Fig. 3. Overview of VR-Themis

two key reasons: 1) Investigating other Android-based VR platforms may introduce complications due to the same app being distributed across multiple device stores. Verifying whether detected suspected clones arise from legitimate cross-platform distribution or unauthorized cloning requires substantial additional effort, incurring unnecessary complexity. 2) Meta Quest series dominates the VR headset market [4], providing a large and diverse dataset for our investigation. Nonetheless, our detection framework is flexible and can be seamlessly adapted to other Android-based VR platforms, such as Pico [28] and Vive [15]. Furthermore, this study concentrates on VR apps developed by the Unity engine for the following two reasons: 1) Over 70% of top-selling Quest games have been developed on top of Unity [46], making it a natural and significant focus for our study; 2) To extract VR assets, we utilize existing GUI-based, engine-specific asset extraction tools (e.g., AssetStudio [5] for Unity apps and UE Viewer for Unreal Engine) and adapt them for automated asset extraction. 4.2

Coarse-grained Processing

The primary goal of the coarse-grained stage is to reduce the comparison complexity (space) since directly comparing all possible pairs of VR apps becomes computationally intensive with large datasets. In this stage, VR-Themis clusters collected VR apps based on statistical features specifically designed for VR. Grounded in our HOB model, we selected ten key features covering structural, object-level (visual and functional), and Behavioural aspects of VR applications. The feature selection process was based on an in-depth analysis of VR development practices. It was validated by three experienced VR developers, each with more than three years of industry expertise. This process ensures the features are both representative and comprehensive in characterizing VR apps. Specifically, the selected features are elaborated at three different levels. The hierarchy level includes (1) the number of levels (scenes). At the object level, features encompass (2) the number of GameObject nodes, (3) AnimationClips, (4) Animators, (5) Materials, (6) Sprites, (7) Texture2Ds, (8) AudioClips, and (9) meshes. The Behaviour level includes (10) the number of MonoBehaviours. The imbalanced number of features across different levels is explained as follows.

VR-Themis: VR Application Clone Detection

11

The object level is designed to capture the visual and functional characteristics of VR. Each type of object, such as meshes and animations, provides distinct information, necessitating multiple features for accurate clustering. In contrast, the hierarchy level and Behaviour-level scripts are difficult to distinguish using statistical features alone. Therefore, they need more detailed analysis at the finegrained stage, using HED for structural comparisons and SBS for Behaviour assessments. To automate feature extraction, we modified the original AssetStudio [5] and developed a console-based version to automatically extract and statistically analyze asset features. After extracting the key features of VR apps, we apply a grouping process to categorize VR apps with similar attributes into the same group based on their feature fingerprints (details in §5.2). 4.3

Fine-grained Processing

After clustering VR apps with similar features, we proceed to the fine-grained stage, where a detailed comparison of VR apps is conducted based on our HOB model. This stage comprehensively evaluates VR apps by analyzing their structural, object-level, and Behavioural similarities using the HOB metrics framework. In Step 1 , we extract the VR scene hierarchy and corresponding VR assets. In Step 2 , we organize a scene hierarchy tree for each VR application, which serves as the basis for calculating the HED. Nodes containing meshes and scripts undergo further analysis in Step 3 (Mesh Processing) and Step 4 (Script Processing). At the object level, GND quantifies visual and functional variations by comparing the components of GameObjects. At the Behavioural level, SBS evaluates the consistency of custom scripts by analyzing their extracted feature vectors. Finally, in Step 5 , we calculate pairwise similarity scores for VR apps by integrating HED, GND, and SBS into HOB metrics. Asset and Scene Hierarchy Extraction. To extract the VR scene hierarchy and corresponding VR assets (e.g., meshes), we implement a custom tool based on AssetStudio [5]. While AssetStudio offers general asset extraction capabilities, it does not sufficiently support the extraction of scene hierarchies and VR-specific assets (e.g., environment and navigation elements). To address these limitations, we developed a specialized tool called AssetStudio.Fine, which is tailored to account for the unique characteristics of Unity-developed VR apps. Scene Hierarchy Processing. To facilitate the pairwise comparison of VR apps, we first organize the scene hierarchy tree of each app into a structured format, which serves as the foundation for calculating the HED. In a VR app, the GameObjects within the scene hierarchy serve as containers that aggregate various functional components. As discussed in §3.1, instead of exhaustively comparing all components within two GameObjects to calculate GND, which is computationally prohibitive, VR-Themis streamlines this process by categorizing GameObjects into predefined types based on their key components. Further component-level comparisons are conducted only when two GameObjects belong to the same type. To identify the components within GameObjects, VR-Themis leverages Unity’s YAML Class ID Reference [44], which provides a detailed mapping of built-in

12

G. Xu et al. Mesh Decimation (or Simplification) Ex: decimate ratio = 0.4 Edge collapse

Half edge collapse

# of Faces: 968 # of Vertices: 2904

......

Static 3D Model Indexing Algorithm 01 02 03 04 05

# of Faces:  386 # of Vertices:  1158

88 89 90 91

g monkey_high v 0.82 0.16 0.76 # v1 v 0.34 0.16 0.76 # v2 v 0.56 0.09 0.68 # v3 v 0.50 0.09 0.68 # v4 …… f 132 # v1 v3 v2 f 143 # v1 v4 v3 f 124 # v1 v2 v4 f 234 # v2 v3 v4 ……

01 02 03 04 05 88 89 90 91

g monkey_high v 0.34 0.16 0.76 # u1 v 0.50 0.09 0.68 # u2 v 0.56 0.09 0.68 # u3 v 0.82 0.16 0.76 # u4 …… f 431 # u4 u3 u1 f 423 # u4 u2 u3 f 412 # u4 u1 u2 f 132 # u1 u3 u2 ……

Hashing

Fig. 4. Mesh processing pipeline

Unity components to their respective class IDs. This enables VR-Themis to efficiently parse Unity asset files and accurately determine component types. In summary, we implement a new tool (i.e., AssetStudio.Fine) based on AssetStudio to address the above challenges. This tool can extract both the scene hierarchy and assets, with each GameObject node in the hierarchy tree containing the GameObject type and corresponding components. Representative GameObject types include 3DObject, Lighting, Environment, and so on. For GameObjects containing specific components, such as MeshFilter and MonoBehaviour, further comparisons of meshes and scripts are conducted in Step 3 and Step 4 , respectively. Mesh Processing. As defined in GND, after identifying the GameObject node in the scene hierarchy tree in Step 2 , we proceed to compare whether the identified node of 3DObject type shares the same mesh. The primary goal of this step is to efficiently compare meshes (i.e., MeshFilter) contained by two GameObjects. As far as we know, only one recent study, 3DScan [61], meets our requirements. In a nutshell, 3DScan first transforms 3D objects into a number of faces, each of which is represented by vertices and edges. It then normalizes the 3D objects by de-duplication and sorting faces. Thereafter, 3DScan compares two 3D objects by calculating their hash values of faces to represent meshes. Despite the advent of 3DScan, it cannot efficiently handle our large experimental scale, as it takes a considerable amount of time to process complex 3D objects with a high number of faces and vertices. To tackle this challenge, we propose a novel method by adopting the mesh decimation approach into the mesh processing algorithm. As shown in Fig. 4, mesh decimation can reduce the number of vertices and faces of a mesh while minimizing shape changes [19]. We implement this new design by using Blender [7], which is an open-source 3D graphics software. §5.3 will present the experimental results, highlighting the effectiveness of our approach and its improvements over 3DScan. Script Processing. During the Unity-based VR application development, the C# scripts can be used to trigger events, modify component properties, and respond to user input. To simplify development, all scripts created by developers in Unity are derived from the MonoBehaviour base class by default [45]. The MonoBehaviour class provides a skeleton to attach scripts to GameObjects and offers hooks for common events, such as Start() and Update(). When using AssetStudio.Fine to identify the component as MonoBehaviour, we can deter-

VR-Themis: VR Application Clone Detection

13

dnSpy classes.dex

AssemblyCSharp.dll Managed

assets

...

...

Metadata

...

2

.cs files globalmetadata.dat

libmain.so lib

...

arm64-v8a

...

libil2cpp.so

1

3

…

1

Mono-based Script fingerprint

Il2CppDumper

dump.cs

...

il2cpp.h

0

0

1

…

3

Il2Cpp-based Script fingerprint

Fig. 5. C# script decompilation under the two Unity scripting backends

mine that it is a custom-defined component, thereby enabling us to retrieve the corresponding C# class (script) from the associated MonoScript. When comparing the MonoBehaviour components of two GameObjects, a thorough comparison of the corresponding C# scripts is necessary to ascertain whether they are indeed the same component. Therefore, we extract and decompile the code from the VR APK by reverse engineering, though the completeness of source code decompilation largely depends on the scripting backend used. Currently, Unity provides two scripting backends: 1) Mono-based decompilation, 2) Intermediate Language to C++ (IL2CPP). Compared with the former one, it is more difficult to decompile IL2CPP-based APKs to source code. To ensure compatibility across different Unity scripting backends and address the challenges of decompiling source code from IL2CPP-based APKs, VRThemis utilizes the SBS metric to evaluate script Behavioural similarity. SBS calculates the cosine similarity between feature vectors extracted from scripts, with each feature vector constructed based on key script metadata such as declarations of methods (signatures) and data attributes. This allows VR-Themis to identify Behavioural similarities even when scripts have undergone lightweight modifications, such as variable renaming or minor structural changes. First, we need to extract the script metadata by decompilation. With regard to two different scripting backends, we have two different processing methods: 1) for Monobased VR apps, we extract the compiled logic code file Assembly-CSharp.dll and utilize the reverse engineering tool dnSpy [11] to retrieve the C# source code; 2) for IL2CPP-based VR apps, we first extract the compiled binary files libil2cpp.so as well as the function mapping file global-metadata.dat from the VR APK. We then employ the reverse engineering tool Il2CppDumper [17] to perform the DLL restoration, consequently obtaining the script metadata. To prevent attackers from obfuscating method (function) names, we compare the modifiers, parameters, and data types (e.g., private List<EventTrigger.Entry>, public Coroutine (IEnumerator routine)) by removing names. We then order these features and count their quantities to construct a feature vector, which represents the script fingerprint. Fig. 5 depicts how the above process works. Pairwise Similarity Calculation. To evaluate the similarity between two VR apps, we analyze their scene hierarchies, which are fundamentally determined by their GameObject nodes and associated components. Leveraging our proposed HOB metrics, tailored for VR scene hierarchy similarity, we comprehensively

14

G. Xu et al.

Original Scene Hierarchy Tree

GameObject Deletion

Screen

Base

level0 Court Wall ···

level0

Ball

Hoop

Floor ··· Rim Pole ··· ···

GameObject Substitution / Modification

GameObject Insertion

AudioSource BoxCollider

··· Base ···

Hierarchy Tree

...

Court Wall ···

level0 Ball

Hoop

Floor ··· Rim Pole ··· ···

AudioSource BoxCollider

··· Base ···

Hierarchy Tree

...

Court

Wall Floor ··· ··· Rim Pole Screen ··· ··· ···

AudioSource is removed

level0 Ball

Hoop

AudioSource BoxCollider

··· Base ···

Hierarchy Tree

...

Wall ···

Ball

Hoop

Court

Floor ··· Rim Pole ··· ···

...

AudioSource BoxCollider

··· Base ···

Hierarchy Tree

* To better match the objects in screenshot with the hierarchy tree nodes, the node's name is set to the GameObject name instead of the GameObject type.

GameObject Component

Fig. 6. Scene hierarchy tree transformation operations in an example VR scene

capture structural, object-level (functional and visual), and Behavioural differences. These metrics seamlessly integrate HED, GND, and SBS to provide a robust multi-dimensional similarity assessment. In the following, we present an example to demonstrate how HOB metrics are calculated on a real VR scene. Fig. 6 illustrates the transformation operations occurring in a real VR scene (excerpted from a real VR app). For example, a deletion operation removes the “Base” GameObject node from Hierarchy Tree TA , resulting in Hierarchy Tree TB , as shown in the screenshot (highlighted in a red box). In another example, an insertion operation adds the “Screen” GameObject node (highlighted in a red box) to Hierarchy Tree TA , producing Hierarchy Tree TC . Moreover, modifying the “Ball” GameObject node in Hierarchy Tree TA by removing the “ AudioSource” component results in Hierarchy Tree TD . As shown in examples of Fig. 6, the HED value between Hierarchy Trees TA and TB (or TC ) is 1, while the HED value between Hierarchy Trees TA and TD is 0.25 according to Eq. (1) since the original “Ball” GameObject contains four components.

5

Implementation and Evaluation

We evaluate VR-Themis on 4,277 VR apps. All experiments are conducted on a workstation with an Intel i7-13700 CPU and 32.0 GB of memory. 5.1

Dataset

We have collected a total of 4,277 Unity-based Meta Quest VR APK files from five distinct sources: 1) the official Meta app store [24], 2) the SideQuest platform [39], 3) the itch.io website [18], 4) Gaming forums, and 5) Source R (i.e., a sideloading platform)7 (the complete app list is available in our repository). Due to the close collaboration between the Meta app store and SideQuest [36], 7

We have chosen not to disclose sideloading sources’ names to prevent attracting more people to these non-compliant websites that offer unlicensed apps.

455

3500

4, 277

506 Downl oadSour c e Gami ngf or um i t c h. i o

1500

Sour c eR( Si del oad)

500

Sour c eType( 颜色) 和 Sour c e Type计数 ( 大小) 。

Fig. 7. Distribution of APK sources

60

2000

1000

2, 180

80

2500

Si dequest / Met a

15 100

3, 315

3000 Count

1, 136

VR-Themis: VR Application Clone Detection

40 684

20 247

0-400

400-800 800-1200

13

14

4

12001600

16002000

20002400

0

Cumul at i vePr opor t i on( %)

Downl oad Sour c e

Fig. 8. Distribution of APK sizes (MB)

the two platforms share a significant number of VR apps. Therefore, we do not explicitly differentiate between them to avoid confusion over app ownership. We analyze the distribution of collected apps, shown in Fig. 7. For a detailed analysis, Fig. 8 presents the size distribution of the APKs, which range from 18.26 MB to 2305.95 MB, with most being <400 MB. To the best of our knowledge, this is the largest VR APK dataset constructed for clone detection to date. In comparison, existing VR APK datasets include 1,096 VR apps [54], 408 VR/AR apps [2], 500 Oculus Quest apps [14], and 900 Meta Quest apps [13]. We collect the VR APKs through two distinct approaches. For those sources that only support the direct installation of apps onto VR headsets, we installed VR apps onto a Meta Quest 2 VR headset and extracted the corresponding APK files from the device. For others, we implement a web crawler to download the collected VR APK files. 5.2

Coarse-grained Detection

Direct pairwise comparisons of all possible VR app pairs in a large dataset are computationally prohibitive. To address this issue, we adopt a coarse-grained clustering stage that significantly reduces the comparison space by grouping apps with similar features. As discussed in §4.2, each VR APK is represented by a feature fingerprint comprising ten statistical characteristics grounded in our HOB model. In the coarse-grained stage, we employ the Density-Based Spatial Clustering of Applications with Noise (DBSCAN) algorithm [35] for clustering, as it is particularly well-suited to our task for several reasons. First, unlike K-means, DBSCAN does not require specifying the number of clusters (k) a priori, which is advantageous given the unknown distribution of the dataset. Second, DBSCAN is robust to noise (e.g., non-cloned apps) and capable of discovering clusters with arbitrary shape (i.e., capturing diverse cloning strategies). Finally, DBSCAN’s computational complexity ensures scalability to large datasets, whereas hierarchical clustering and spectral clustering are computationally intensive. To determine DBSCAN’s parameters, we set minPts = 2 based on domain knowledge, as clone detection inherently involves at least two apps forming a potential clone relationship. For the ϵ parameter (neighborhood radius), we used a k-distance graph to identify the “elbow” point, narrowing ϵ to the range (0, 1.0]. We then randomly select 100 samples from the 4,277 apps and manually install

Fig. 9. Distributions of cluster sizes and of app sources within clusters

0.10 0.05

(0.

.8] 8,1 ] (1, 2] (2, 3] (3, 4] (4, 5]

0.00

.6]

156 4 4 50 75 100 125 150 175 200 Number of Clusters

3

6,0

0-2 0

25

10

(0.

39

10 8 6 4 2 0

0.15

.4]

3-20

0.20

4,0

2

Large-size meshes Decimate ratio = 0.2

After Decimation Before Decimation

2,0

103

Medium-size meshes Decimate ratio = 0.4

0.25

(0.

21-100 1

0 1

(0.

Number of Clusters 100 50 81

Average Processing Time (seconds)

150

Number of Source Types in Cluster

200 101-600 2

Average Processing Time (seconds)

G. Xu et al.

Number of Apps in Cluster

16

Mesh Size (MB)

Fig. 10. Average mesh processing time before and after mesh decimation

and execute them to determine the clone truths. Validation experiments on this subset of 100 VR apps with known clone truths confirmed that ϵ = 0.1 maximized recall (100%) while maintaining high precision (80.65%). Feature extraction for all 4,277 VR apps required 5,810.44 seconds (approximately 1.36 seconds per app), and DBSCAN clustering completed in just 0.1024 seconds, producing 198 clusters. The distribution of cluster sizes and app sources in clusters is shown in Fig. 9, in which most clusters contain fewer than 20 apps. Furthermore, most apps within a cluster originate from one or two different sources. Finally, we reduced the initial 9,144,226 app pairs to 416,385 (about 4.55%) suspected clone pairs, substantially lowering the computational burden for the fine-grained stage. 5.3

Fine-grained Detection

Mesh Decimation Strategy. As mentioned in §4.3, we enhance 3DScan [61] by applying the mesh decimation approach. To evaluate the effectiveness of our improvement, we extracted 8,000 mesh files from 500 randomly selected VR APK files. As shown in Fig. 10, the results indicate that mesh decimation reduces average processing time by 53.54%, with decimation ratios of 0.4 for medium-size meshes (0.2 MB < file size ≤ 1.0 MB) and 0.2 for large-size meshes (file size > 1.0 MB). This substantial reduction in processing time highlights the efficiency gains introduced by the mesh decimation strategy. The performance improvement stems from the simplified geometric complexity of the models by mesh decimation while preserving their essential structure. 1.0

252

0.8

506

438 207

0.6

CDF

1.0

CDF

0.4

2180

0.5

0.2

0.0 0

0.0 0

1500

5000

10000

15000

20000

25000

500

1000

1500

30000

35000

40000

Scene Hierarchy Node Count per App

Fig. 11. Distribution of node counts in app scene hierarchy trees

Sidequest&Meta

14

2 11

10

Source R

itch.io

1136

21

455

5

Gaming forum

17

Fig. 12. Cloning within and across app sources (node: source; edge: cloning)

VR-Themis: VR Application Clone Detection

17

Table 1. Evaluation results of our two-stage approach (SQ denotes SideQuest) Source

# of Apps Coarse (Results) Coarse (%) Fine (Results) Fine (%)

Forum itch.io SQ & Meta Source R Total

455 506 2,180 1,136 4,277

108 197 617 126 1,048

23.74% 38.93% 28.30% 11.09% 24.50%

47 96 115 49 307

10.33% 18.97% 5.28% 4.31% 7.18%

App pairs

9,144,226

416,385

4.5535%

977

0.0107%

Importantly, two identical meshes remain identical even after the decimation process, ensuring that the technique does not introduce false negatives. To evaluate the potential for false positives (i.e., a large-sized mesh file can potentially be the same as an unsimplified smaller mesh after mesh decimation), we processed 3,000 mesh files and computed their hash values. No false positives were observed during this evaluation. This is primarily because the mesh decimation process distorts (even overlaps) the model’s geometric details, which would not occur in unsimplified meshes. As a result, they can effectively be distinguished. Determining Threshold. To determine the threshold for pairwise similarity calculation in the fine-grained stage, we use the subset of 100 VR APKs with known clone truths again (as described in §5.2). After calculating pairwise similarities, we evaluate accuracy across a range of similarity thresholds. By analyzing the false positive and false negative rates at different thresholds, we identify 80% as the optimal threshold. A detailed accuracy analysis is in §5.4. Fig. 11 illustrates the distribution of node counts in VR app scene hierarchy trees, where the majority of trees contain fewer than 1,500 nodes. For trees with exceptionally large sizes, we apply a tree pruning strategy to enhance comparison efficiency. Specifically, we remove non-contributory nodes, such as GameObject nodes with zero components, since they do not affect the functional characteristics of the scene. This approach reduces the computational overhead and ensures the comparison process remains efficient for large and complex trees. Fine-grained Detection Results. After the coarse-grained stage, we identify 416,385 suspected clone pairs. The fine-grained stage ultimately yields 977 suspicious app clone pairs involving 307 distinct apps, representing 7.18% of the dataset, as detailed in Table 1. The fine-grained stage requires a total processing time of 30,957.52 seconds. As shown in Fig. 12, cloning is observed not only within specific sources but also across different sources. The analysis of the motivations behind the discovered suspicious cloned applications will be discussed in §6. 5.4

Cloning Verification and Accuracy Analysis

Cloning Verification. The cloning verification process is an essential step to confirm the validity of detected potential clone VR apps and determine the

18

G. Xu et al. Different Color Schemes and Lighting

English text

Chinese text

Reduce one game mode

Fig. 13. Case 1 for likely unauthorized clones (original on the left, suspected on the right)

Fig. 14. Case 2 for likely unauthorized clones (original on the left, suspected on the right)

accuracy of our VR-Themis. First, we analyze the APK signature information of the identified suspicious clones. Apps signed by the same developer are excluded from being classified as clones, as they may represent different versions released by the same author. After filtering, we proceed to verify the clones by installing, executing, and experiencing these VR apps. By evaluating the app’s visual design and game mechanics, we ultimately confirm whether they are indeed clone apps. Notably, a few VR apps crash upon startup. Since the authors do not release a fix, we review them by checking previous gameplay videos. Accuracy Analysis. Unlike Android app clone detection, where datasets and standardized benchmarks (e.g., RePack [20]) are widely adopted, the VR domain lacks both labeled datasets and reference methods. This absence of established baselines precludes direct numerical comparisons. To overcome this limitation, we evaluate VR-Themis through two complementary strategies: (i) We created a labeled dataset of 200 apps, comprising 100 VR apps with manually identified clone truths (not used for threshold/parameter determination to avoid data leakage) and 100 apps with our artificially generated clones. To generate cloned apps, we refer to methods published in the game communities [33,34,43], including packaging apps with different script backends, using Ghidra [27] to decompile and modify assembly code, and translating the apps into different languages. The generated cloned apps are solely for internal research purposes and are not disseminated to the public. Then, we use VR-Themis to detect these 200 labeled apps. The results indicate that we successfully identified all cloned pairs with no false positives or false negatives among them. (ii) For the VR-Themis detection results of 4,277 apps, we manually reviewed all identified clones and found zero false positives. The examination of false negatives is more challenging. First, we define 10 keywords representing themes (e.g., soccer and museum) and randomly collect 10 APKs for each keyword. After manually reviewing each theme of apps, we did not identify any instances of clones that were undetected, suggesting that false negatives are unlikely. 5.5

Case Studies

We conduct a detailed analysis of cloning behaviours in two cases. We clarify that our intention is not to act as “cyber police”. Therefore, we anonymize the app names when presenting them as follows.

VR-Themis: VR Application Clone Detection

19

Case 1. Cluster 10—the largest cluster identified—contains clone apps suspected to originate from a popular app in the Meta app store (store ID prefix: 49790~). These clones are distributed across the SideQuest and itch.io platforms, featuring varied levels of modification to the original app, such as adding 3D models, altering textures, and introducing new levels. Many of the clones show a similarity of over 80%, with some exceeding 95%. An example is illustrated in Fig. 13. Case 2. App A (MD5 prefix: ca23d~) and App B (MD5 prefix: 4e59e~) are different language versions of the same game. Since the original game provides limited language options, attackers repackaged it into an additional language version. Beyond the language change, the clone version also shows evidence of decompilation and adjustments to the hierarchy tree structure during repackaging. Fig. 14 shows a screenshot of this cloned case.

6

Discussion

Handling Shared Assets and Templates. To handle cases where different VR apps share common 3D models, animations, and interaction templates, VR-Themis goes beyond visual similarity by incorporating structural similarity (i.e., HED) and Behavioural similarity (i.e., SBS). This mechanism ensures that apps sharing common assets and templates are not mistakenly flagged as clones under normal circumstances. However, in some edge cases—particularly with lightweight VR applications that rely heavily on publicly available assets or templates—the boundaries between legitimate reuse and cloning may become less clear. Although such cases were not observed in our experiments, future improvements could compare assets in VR apps against publicly available asset libraries (e.g., the Unity Asset Store) to further refine VR-Themis. Motivations Behind Apps Susceptible to Cloning. We analyzed all 307 detected cloned apps and identified three common motivations. (1) Popular gaming applications: High-profile paid games are prime targets due to their popularity and high-quality 3D assets. For example, Gorilla Tag was cloned across multiple platforms with modified models and scenes. (2) Language-specific applications: Apps with limited language support are frequently cloned and localized; several English apps were repackaged into Chinese versions distributed through unofficial channels. (3) Freemium applications: Apps offering free trials are commonly cloned into pirated versions with all paid features unlocked. Limitations. The main limitation lies in clone traceability: determining which app is the original among detected pairs is challenging, and heuristic solutions such as examining submission times and download counts are susceptible to attacks. Additionally, runtime-loaded assets and Unity Asset Bundles may result in a partially captured scene hierarchy, though the latter has minimal impact since most VR apps operate offline. Moreover, some applications use code obfuscation for anti-cheating purposes, which can prevent full decompilation. Nevertheless, we find only two such instances among our evaluations, indicating that it has a minimal impact. In terms of the range of app collections, we are unable to collect paid-download apps and those with broken download links. Additionally,

20

G. Xu et al.

VR apps may be developed by game engines other than Unity, such as Unreal and libGDX. Moreover, they may be deployed on other VR devices like HTC VIVE Pro 2, Sony PlayStation VR 2, and Pico 4, though many of them also use Android-based operating systems (which are also supported by our tool). In the future, we plan to conduct clone detection research on VR apps developed on more platforms and other engines.

7

Related Work

Mobile App Clone Detection. Research on repackaged mobile apps primarily focused on the Android platform. For instance, DNADroid [9] compares code dependence graphs, while DroidMOSS [58] employs fuzzy hashing. FSquaDRA [56] utilizes resources to perform similarity comparisons, and DroidEagle [41] focuses on UI layout comparisons. Additionally, methods such as ResDroid [37] and ViewDroid [55] integrate both resource and layout comparisons. PiggyApp [57], another notable approach, constructs vectors using normalized values derived from extracted features. To the best of our knowledge, there has been a lack of studies specifically addressing the detection of black-box VR apps. Existing works, such as those by Chen et al. [8] and Huang et al. [16], have primarily focused on code clone detection in open-source VR software. However, these approaches are not applicable to closed-source VR applications, where access to the source code is unavailable. In contrast, our work emphasizes clone detection in closed-source VR APKs, extending the scope beyond code to include a comprehensive Hierarchy-Object-Behaviour structure of VR applications. Studies on VR/AR Apps. Previous works have conducted several studies to understand VR/AR (XR) apps from different perspectives. Rodriguez and Wang [32] conducted an empirical study on 1,156 open-source VR projects, noting their steady growth, game focus, and frequent mis-committing of autogenerated files. Li et al. [22] conducted an empirical study on 368 real bugs from 33 GitHub-hosted WebXR projects, establishing a bug taxonomy based on symptoms and root causes. Adams et al. [1] focused on VR security and privacy perceptions, conducting a mixed-methods study including semi-structured interviews with 20 VR users and developers, a survey of VR privacy policies, and an ethics co-design study with VR developers. Guo et al. [14] conducted a combination of app analysis, taint analysis, and privacy-policy analysis methods on VR apps to assess security vulnerabilities, privacy data leaks, and contradictory statements in privacy policies. Li et al. [23] presented Orienter, a zero-shot context-sensitive framework for detecting interactable GUI elements in VR apps. Zhu et al. [59] proposed VRExplorer, a model-based approach for semi-automated testing of VR scenes. Wu et al. [50] explored the use of large language models to repair performance bugs in extended reality applications. Xu et al. [52] synthesized batch-editing programs of collision meshes in 3D software from user-provided examples, targeting the same category of non-code assets that dominates VR development.

VR-Themis: VR Application Clone Detection

21

Unity-based Application. Unity game engine is one of the most popular VR application development frameworks. We review related studies on Unity. Shim et al. [38] performed reverse engineering on Unity-based apps by combining static and dynamic analysis methods to detect malicious apps. Zuo et al. [60] designed and implemented a static tool called PaymentScope to automatically identify vulnerabilities in in-app purchasing (IAP) within Unity-based mobile games. Additionally, Zuo et al. [61] proposed a 3D model clone detection tool named 3DScan in mobile games developed with Unity.

8

Conclusion

VR app cloning threatens developer interests and user security, yet existing mobile clone detectors fail to capture VR-specific features. In this paper, we presented VR-Themis, a two-stage Hierarchy-Object-Behaviour -driven framework that clusters apps via coarse-grained statistical features and performs finegrained HOB metric comparisons. Experiments on 4,277 VR apps detected 307 clone apps with no false positives, demonstrating its effectiveness and scalability. Acknowledgments. This work was supported in part by Hong Kong RGC Project (with Grant No. 12200426) and Grant Seed Funding for Collaborative Research Grants of HKBU (with Grant No. RC-SFCRG/23-24/R2/SCI/06). We thank the anonymous reviewers for their valuable comments and constructive suggestions. Disclosure of Interests. The authors have no competing interests to declare that are relevant to the content of this article.

References 1. Adams, D., Bah, A., Barwulor, C., Musabay, N., Pitkin, K., Redmiles, E.M.: Ethics emerging: the story of privacy and security perceptions in virtual reality. In: Proceedings of the Fourteenth USENIX Conference on Usable Privacy and Security. pp. 443–458. USENIX Association (2018) 2. Alghamdi, A., Kinoon, A.A., Alghuried, A., Mohaisen, D.: XR-Droid: A Benchmark Dataset for AR/VR and Security Applications. IEEE Transactions on Dependable and Secure Computing 22(2), 1418–1430 (2025), online available: https: //doi.org/10.1109/TDSC.2024.3440662 3. Apktool: A Tool for Reverse Engineering Android Apk Files (2016), online available: https://ibotpeaches.github.io/Apktool/ 4. Armstrong, M.: Meta Leads the Way in VR Headsets. Statista Infographic (2023), online available: https://www.statista.com/chart/29398/vr-headset-kpis/ 5. AssetStudio: A tool for exploring, extracting and exporting assets and assetbundles. GitHub Project (2022), online available: https://github.com/Perfare/ AssetStudio 6. Bezmalinovic, T.: Meta Quest’s Piracy Issue is Back in the Spotlight. Mixed News (2024), online available: https://mixed-news.com/en/meta-quest-piracy/ 7. Blender Foundation: Blender - Home of the Blender project - Free and Open 3D Creation Software (1995), online available: https://www.blender.org/

22

G. Xu et al.

8. Chen, H., Huang, Z., Xu, Y., Huang, W., Wang, X., Chen, J., Li, H., Peng, K., Liu, F., He, S.: Unveiling code clone patterns in open source vr software: an empirical study. Automated Software Engineering 32(2), 72 (2025) 9. Crussell, J., Gibler, C., Chen, H.: Attack of the Clones: Detecting Cloned Applications on Android Markets. In: Computer Security - ESORICS 2012. pp. 37–54. Springer (2012), online available: https://doi.org/10.1007/978-3-642-33167-1_3 10. dex2jar: Tools to work with android .dex and java .class files. GitHub Project (2011), online available: https://github.com/pxb1988/dex2jar 11. dnSpy: dnSpy: reverse engineering tool (2020), online available: https://github. com/dnSpy/dnSpy 12. Google: Android Studio (2023), online available: https://developer.android.com/ studio 13. Guo, H., Dai, H.N., Luo, X., Xu, G., He, F., Zheng, Z.: An Empirical Study on Meta Virtual Reality Applications: Security and Privacy Perspectives. IEEE Transactions on Software Engineering (2025), online available: https://doi.org/10.1109/ TSE.2025.3553283 14. Guo, H., Dai, H.N., Luo, X., Zheng, Z., Xu, G., He, F.: An Empirical Study on Oculus Virtual Reality Applications: Security and Privacy Perspectives. In: Proc. of the 46th IEEE/ACM International Conference on Software Engineering (ICSE 2024). ACM, New York, NY (2024), online available: https://doi.org/10.1145/3597503. 3639082 15. HTC Corporation: HTC VIVE (2016), online available: https://www.vive.com/ 16. Huang, W., Chen, J., Chen, H., Qi, Z., Yang, X., Peng, K., He, S.: A Study of Code Clone on Open Source VR Software. In: Proc. of the 39th IEEE/ACM International Conference on Automated Software Engineering Workshops (ASE Workshops). pp. 239–244 (2024) 17. Il2CppDumper tool: Il2CppDumper (2017), online available: https://github.com/ Perfare/Il2CppDumper 18. itch.io: Independent Game Hosting Platform (2013), online available: https://itch. io 19. Kobbelt, L., Campagna, S., Seidel, H.P.: A General Framework for Mesh Decimation. In: Proc. of Graphics Interface 1998. pp. 43–50. Canadian Human-Computer Communications Society (1998) 20. Li, L., Bissyandé, T.F., Klein, J.: Rebooting Research on Detecting Repackaged Android Apps: Literature Review and Benchmark. IEEE Transactions on Software Engineering 47(4), 676–693 (2019), online available: https://doi.org/10.1109/TSE. 2019.2901679 21. Li, L., Bissyandé, T.F., Klein, J., Traon, Y.L.: Understanding Android App Piggybacking: A Systematic Study of Malicious Code Grafting. IEEE Transactions on Information Forensics and Security 12(6), 1269–1284 (2017), online available: https://doi.org/10.1109/TIFS.2017.2662219 22. Li, S., Li, B., Liu, Y., Gao, C., Zhang, J., Cheung, S.C., Lyu, M.R.: An Exploratory Study of Bugs in Extended Reality Applications on the Web. In: IEEE 31st International Symposium on Software Reliability Engineering (ISSRE). pp. 172–183 (2020). https://doi.org/10.1109/ISSRE5003.2020.00025 23. Li, S., Li, B., Liu, Y., Gao, C., Zhang, J., Cheung, S.C., Lyu, M.R.: Grounded GUI Understanding for Vision Based Spatial Intelligent Agent: Exemplified by Virtual Reality Apps (2024), arXiv:2409.10811. Available online: https://arxiv.org/abs/ 2409.10811 24. Meta: Meta Store: Shop Meta Quest VR Games, Apps, Deals and More (2023), online available: https://www.meta.com/experiences/

VR-Themis: VR Application Clone Detection

23

25. Meta: Meta Horizon OS (2024), online available: https://developers.meta.com/ horizon 26. Meta Developers: Attestation API. Meta Developers Documentation (2024), online available: https://developers.meta.com/horizon/documentation/unity/psattestation-api/ 27. National Security Agency (NSA) Research Directorate: Ghidra. Software Reverse Engineering Framework (2019), online available: https://ghidra-sre.org/ 28. PICO: PICO OS (2024), online available: https://www.picoxr.com/global/ software/pico-os 29. QuestPiracy: Cracked Beat Saber and Mods. Reddit (2023), available online: https://www.reddit.com/r/QuestPiracy/comments/191hzm4/cracked_beat_ saber_and_mods/ 30. Reddit: Quest Piracy. Reddit r/QuestPiracy (2025), online available: https://www. reddit.com/r/QuestPiracy/ 31. Reddit: The 2025 Guide to Quest Piracy (PCVR). Reddit r/QuestPiracy (2025), online available: https://www.reddit.com/r/QuestPiracy/comments/1i11h5d/ the_2025_guide_to_quest_piracy_pcvr/ 32. Rodriguez, I., Wang, X.: An Empirical Study of Open Source Virtual Reality Software Projects. In: ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). pp. 474–475 (2017). https://doi.org/10. 1109/ESEM.2017.65 33. Roldan, B.: Hacking and Reverse Engineering IL2CPP Games with Ghidra. Medium Blog (2022), online available: https://noob3xploiter.medium.com/ hacking-and-reverse-engineering-il2cpp-games-with-ghidra-5cee894024f2 34. Roldan, B.: Hacking .NET Games with dnSpy. Medium Blog (2022), online available: https://noob3xploiter.medium.com/hacking-net-games-with-dnspy73e1441f81c1 35. Schubert, E., Sander, J., Ester, M., Kriegel, H.P., Xu, X.: DBSCAN Revisited, Revisited: Why and How You Should (Still) Use DBSCAN. ACM Trans. Database Syst. 42(3) (Jul 2017). https://doi.org/10.1145/3068335, https://doi.org/10.1145/ 3068335 36. Shane: SideQuest x Piracy Games. SideQuestVR Forum (2024), online available: https://sidequestvr.com/space/142/p/156130/sidequest-x-piracy-games 37. Shao, Y., Holt, J., Yang, R.: Towards a scalable resource-driven approach for detecting repackaged android applications. In: Proceedings of the 30th Annual Computer Security Applications Conference. pp. 56–65 (2014) 38. Shim, J., Lee, S., Jang, C., Han, S., Shin, S.: Static and Dynamic Analysis of Android Malware and Goodware Written with Unity Framework. Security and Communication Networks 2018 (2018), online available: https://doi.org/10.1155/ 2018/6280768 39. SideQuest VR Ltd: SideQuest: The Early Access Platform for VR (2021), online available: https://sidequestvr.com 40. Skylot: jadx: Dex to Java decompiler. GitHub Project (2013), online available: https://github.com/skylot/jadx 41. Sun, M., Li, M., Lui, J.C.S.: DroidEagle: Seamless Detection of Visually Similar Android Apps. In: Proc. of the WiSec 2015. ACM (2015), online available: https: //doi.org/10.1145/2766498.2766503 42. Takoordyal, K.: Beginning Unity Android Game Development. Apress, Berkeley, CA (2020), online available: https://doi.org/10.1007/978-1-4842-6002-9 43. Thume, T.: Writing a Beat Saber Patcher. Personal Blog (2019), online available: https://thume.ca/2019/07/26/writing-a-beat-saber-patcher/

24

G. Xu et al.

44. Unity: Unity YAML Class ID Reference. Unity Documentation (2022), online available: https://docs.unity3d.com/2022.3/Documentation/Manual/ ClassIDReference.html 45. Unity Documentation: Unity Documentation (2022), online available: https://docs. unity3d.com/Manual/index.html 46. Unity Technologies: VR Game Development Software & Engine (2024), online available: https://unity.com/solutions/vr 47. VR MOO: Providing a vast array of free VR games and Chinese localization resources for download (2025), available online: https://www.vrmoo.net/ 48. VRPirates Community: VRPirates Wiki. VRPirates Community (2023), online available: https://www.vrpirates.wiki/ 49. Wrexa Technologies: AR/VR Development Costs: Bringing Immersive Experiences to Life (Detailed Breakdown) (2024), online available: https://www.wrexa.com/post/ar-vr-development-costs-bringing-immersiveexperiences-to-life-detailed-breakdown 50. Wu, J., Guo, H., Dai, H.N., Luo, X.: XRFix: Exploring Performance Bug Repair of Extended Reality Applications with Large Language Models. In: Proceedings of the 48th International Conference on Software Engineering (ICSE) (2026) 51. Xu, G., Guo, H., Dai, H.N., Meng, W.: VR-Themis (2026), online available: https: //github.com/gengyang-xu/VR-Themis 52. Xu, G., Xiao, D., Zhu, H., Peng, Y., Meng, W., Wang, S., Cheung, S.C.: Programming-by-Example for Batch-Editing Collision Meshes in 3D Software. arXiv preprint arXiv:2607.08804 (2026) 53. Yang, Z., Li, C.Y., Bhalla, A., Zhao, B.Y., Zheng, H.: Inception Attacks: Immersive Hijacking in Virtual Reality Systems. arXiv preprint arXiv:2403.05721 (2024), online available: https://arxiv.org/abs/2403.05721 54. Zhan, Y., Meng, Y., Zhou, L., Xiong, Y., Zhang, X., Ma, L., Chen, G., Pei, Q., Zhu, H.: VPVet: Vetting Privacy Policies of Virtual Reality Apps. In: CCS 2024. pp. 1746–1760. ACM (2024), online available: https://doi.org/10.1145/3658644. 3690321 55. Zhang, F., Huang, H., Zhu, S., Wu, D., Liu, P.: ViewDroid: Towards ObfuscationResilient Mobile Application Repackaging Detection. In: Proc. of the 7th ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec 2014). pp. 25–36. ACM (2014), online available: https://doi.org/10.1145/2627393.2627397 56. Zhauniarovich, Y., Gadyatskaya, O., Crispo, B., Spina, F.L., Battista, E.: FSquaDRA: Fast Detection of Repackaged Applications. In: Data and Applications Security and Privacy XXVIII. Lecture Notes in Computer Science, vol. 8566, pp. 130–145. Springer, Cham (2014), online available: https://doi.org/10.1007/978-3319-08509-8_9 57. Zhou, W., Zhou, Y., Grace, M., Jiang, X.: Fast, scalable detection of "piggybacked" mobile applications. In: Proceedings of the third ACM conference on Data and application security and privacy. pp. 185–196 (2013) 58. Zhou, W., Zhou, Y., Jiang, X., Ning, P.: Detecting Repackaged Smartphone Applications in Third-Party Android Marketplaces. In: Proc. of the 2nd ACM Conference on Data and Application Security and Privacy (CODASPY 2012). pp. 317–326. ACM (2012), online available: https://doi.org/10.1145/2133601.2133640 59. Zhu, Z., Dai, H.N., Guo, H., Liao, Z., Zheng, Z.: VRExplorer: A Model-based Approach for Semi-Automated Testing of Virtual Reality Scenes. In: 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). pp. 482–494. IEEE (2025)

VR-Themis: VR Application Clone Detection

25

60. Zuo, C., Lin, Z.: Playing Without Paying: Detecting Vulnerable Payment Verification in Native Binaries of Unity Mobile Games. In: Proc. of the 31st USENIX Security Symposium (USENIX Security 2022). pp. 3093–3110. USENIX Association (2022), online available: https://www.usenix.org/conference/ usenixsecurity22/presentation/zuo 61. Zuo, C., Wang, C., Lin, Z.: A Peek into the Metaverse: Detecting 3D Model Clones in Mobile Games. In: Proc. of the 32nd USENIX Security Symposium (USENIX Security 2023). pp. 3925–3942. USENIX Association (2023)

Related documents

• VR-Themis: A Scalable Framework for Virtual Reality Application Clone Detection#684583
• ARC-Loc: Leveraging Azimuthal Ray Convergence as a Geometric Cue for Direct Cross-View Localization#971928
• Fast-BEV++: Fast by Algorithm, Deployable by Design#925872
• Blind Stereoscopic Omnidirectional Image Quality Assessment Using Predictive Coding Hierarchy#793036
• Blind Stereoscopic Omnidirectional Image Quality Assessment Using Predictive Coding Hierarchy#789032