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

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

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.

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. This phenomenon is largely due to the presence of pirated versions repackaged. Furthermore, repackaged VR apps significantly increase users’ vulnerability to security and privacy attacks (e.g., inception attacks). Although some VR headset companies have released solutions (e.g., Meta Quest Attestation API), 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.

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, dex2jar, and JADX. 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, layout similarity of User Interface (UI), resource metadata comparison, and combinations of them.

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, 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. 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-Themis. This detection approach adopts a two-stage framework and is specifically designed to address three critical challenges in VR app clone detection:

(1) Complexity of Pairwise Comparison. Directly comparing all possible pairs of VR apps becomes computationally prohibitive with large datasets. VR-Themis 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 multi-dimensional 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 VR-related 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. 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.

Background and Threat Model. 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, hijacking advertising revenue, distributing cracked versions that bypass paid features, creating unauthorized localizations, and plagiarizing proprietary 3D assets with minimal effort. The last motivation is particularly disruptive in VR, where high-quality 3D models and animations require substantial development resources.

VR operating systems (OSs) (e.g., Meta Horizon OS and PICO OS) 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. 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. 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. 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.

The threat model is defined 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 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 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.

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.

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). By comprehensively capturing the characteristics of VR apps from 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 AudioSource 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.

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. 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.

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 three-tiered 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.

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 denote two GameObjects being compared. Their component sets are represented as Ck = Gk.components and Cl = Gl.components, respectively. Then, δGND is expressed as: δGND(Gk, Gl) = J(Ck, Cl) = 1 − (Ck ∩ Cl / 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. 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 other components are identical.

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 custom-defined 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. 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: γ = cos(α) = (fk · fl) / (∥fk∥∥fl∥) = (Σ u=1 d fku · flu) / (√(Σ u=1 d fku2) × √(Σ u=1 d flu2)), 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.

Design of VR-Themis. 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 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, 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 and Vive. 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, 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 for Unity apps and UE Viewer for Unreal Engine) and adapt them for automated asset extraction.

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. 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 fine-grained stage, using HED for structural comparisons and SBS for Behaviour assessments. To automate feature extraction, we modified the original AssetStudio 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.

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.

To extract the VR scene hierarchy and corresponding VR assets (e.g., meshes), we implement a custom tool based on AssetStudio. 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. 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, which provides a detailed mapping of built-in 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.

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, 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. We implement this new design by using Blender, which is an open-source 3D graphics software.

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. 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 determine 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, VR-Themis 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 Mono-based VR apps, we extract the compiled logic code file Assembly-CSharp.dll and utilize the reverse engineering tool dnSpy 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 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, 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.

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 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.

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. 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, 2) the SideQuest platform, 3) the itch.io website, 4) Gaming forums, and 5) Source R (i.e., a sideloading platform) (the complete app list is available in our repository). Due to the close collaboration between the Meta app store and SideQuest, 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, 408 VR/AR apps, 500 Oculus Quest apps, and 900 Meta Quest apps. 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.

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 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 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.

As mentioned in §4.3, we enhance 3DScan 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 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. 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.

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. 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.

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 cloning verification process is an essential step to confirm the validity of detected potential clone VR apps and determine the 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.

Unlike Android app clone detection, where datasets and standardized benchmarks (e.g., RePack) 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, including packaging apps with different script backends, using Ghidra 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.

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. 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.

Discussion. 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. 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. 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, 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.

Related Work. Research on repackaged mobile apps primarily focused on the Android platform. For instance, DNADroid compares code dependence graphs, while DroidMOSS employs fuzzy hashing. FSquaDRA utilizes resources to perform similarity comparisons, and DroidEagle focuses on UI layout comparisons. Additionally, methods such as ResDroid and ViewDroid integrate both resource and layout comparisons. PiggyApp, 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. and Huang et al., 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. Previous works have conducted several studies to understand VR/AR (XR) apps from different perspectives. Rodriguez and Wang conducted an empirical study on 1,156 open-source VR projects, noting their steady growth, game focus, and frequent mis-committing of auto-generated files. Li et al. 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. 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. 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. presented Orienter, a zero-shot context-sensitive framework for detecting interactable GUI elements in VR apps. Zhu et al. proposed VRExplorer, a model-based approach for semi-automated testing of VR scenes. Wu et al. explored the use of large language models to repair performance bugs in extended reality applications. Xu et al. 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. Unity game engine is one of the most popular VR application development frameworks. We review related studies on Unity. Shim et al. performed reverse engineering on Unity-based apps by combining static and dynamic analysis methods to detect malicious apps. Zuo et al. 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. proposed a 3D model clone detection tool named 3DScan in mobile games developed with Unity.

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 fine-grained HOB metric comparisons. Experiments on 4,277 VR apps detected 307 clone apps with no false positives, demonstrating its effectiveness and scalability.

Based on the paper, here are the specific improvements you can make to AI systems and what the improved systems can do:

---

1. VR-Specific Clone Detection System

• Improvement: Build an AI system that uses the HOB model (Hierarchy-Object-Behaviour) to represent VR apps as structured trees of GameObjects, components, and script behaviours, rather than relying on 2D UI or code-centric features.

• Capability: The system can automatically detect repackaged or cloned VR apps (e.g., on Meta Quest, Pico) by comparing 3D scene hierarchies, object-level components (meshes, animations, textures), and script behaviour fingerprints, even when code is obfuscated or IL2CPP-compiled.

2. Scalable Two-Stage Detection Pipeline

• Improvement: Implement a coarse-to-fine detection approach: first cluster apps using statistical features (e.g., number of scenes, GameObjects, meshes, MonoBehaviours) with DBSCAN, then perform fine-grained pairwise similarity using HED, GND, and SBS metrics.

• Capability: The system can efficiently handle large VR app datasets (e.g., 4,277 apps) by reducing pairwise comparisons from millions to 4.5% of the original space, enabling real-time or near-real-time screening of app stores or sideloading platforms.

3. Robust Similarity Metrics for 3D Assets

• Improvement: Use the paper’s metrics: Hierarchy Edit Distance (HED) for structural differences, GameObject Node Distance (GND) with Jaccard distance for component sets and mesh decimation for 3D model comparison, and Script Behaviour Similarity (SBS) using cosine similarity on script metadata (method signatures, data types) after stripping names.

• Capability: The system can detect clones even when attackers modify 3D models (e.g., squashing, vertex perturbation), rename variables, or change scene hierarchies, while avoiding false positives from shared assets or templates.

4. Cross-Platform and Cross-Engine Adaptation

• Improvement: Adapt the framework to other Android-based VR platforms (Pico, Vive) and engines (Unreal, libGDX) by modifying asset extraction tools (e.g., UE Viewer for Unreal) and adjusting the HOB model to engine-specific component types.

• Capability: The system can be deployed across diverse VR ecosystems, providing a unified clone detection solution for multiple headset brands and development engines.

5. Automated Asset Extraction and Preprocessing

• Improvement: Integrate the custom tools (AssetStudio.Fine for Unity) and mesh decimation (via Blender) to automatically extract scene hierarchies, assets, and script metadata from APKs, and to reduce mesh complexity for faster comparison without losing accuracy.

• Capability: The system can process large volumes of VR APKs automatically, extracting structured data and computing similarity scores in a fully automated pipeline, reducing manual effort and enabling continuous monitoring.

6. Threshold Tuning and False-Positive Reduction

• Improvement: Use the paper’s empirical findings (e.g., 80% similarity threshold, DBSCAN with ϵ=0.1, minPts=2) to calibrate detection sensitivity, and incorporate APK signature verification to exclude legitimate multi-version apps.

• Capability: The system achieves zero false positives on real-world datasets (as demonstrated) and can be fine-tuned for different app markets or threat models, balancing recall and precision.

7. Clone Motivation Analysis and Traceability

• Improvement: Extend the system to classify detected clones by motivation (e.g., pirated paid games, localized language versions, freemium unlocks) using metadata and behavioural patterns, and to heuristically infer the original app via submission timestamps or download counts.

• Capability: The system can provide actionable intelligence to app store moderators and developers, identifying not only clones but also the likely original and the type of infringement, aiding in takedown decisions.

8. Benchmark Dataset Creation for Future Research

• Improvement: Use the paper’s dataset (4,277 VR apps, 307 confirmed clones) and methodology to create a public benchmark for VR clone detection, including ground-truth labels and feature extraction pipelines.

• Capability: The system can serve as a reference for training and evaluating new AI models, enabling reproducible research and fostering the development of more advanced detection techniques.

Summary of Improved AI System Capabilities:

The improved AI system can automatically detect cloned VR apps across multiple platforms and engines, scale to large app stores, resist common evasion techniques (code obfuscation, asset modification, hierarchy changes), and provide high accuracy with zero false positives, while also enabling continuous monitoring and forensic analysis of VR piracy.