JSProtect: JavaScript Obfuscation & Bug Detection

• JSProtect is a dual-purpose JavaScript protection method that includes a scalable obfuscation framework for WeChat mini-games and a two-phase bug detector for property access errors.
• It employs techniques like Parallel-Aware Scope Analysis and performance-aware optimizations to preserve semantics, control code bloat, and maintain near-native runtime speeds.
• Evaluations show JSProtect significantly improves scalability, reduces runtime overhead, and enhances resistance to reverse-engineering compared to traditional tools.

JSProtect is a name used in the JavaScript research literature for distinct systems with different objectives. Most prominently, it denotes a scalable JavaScript obfuscation framework for the WeChat mini-game ecosystem, designed to address IP theft through code porting and secondary development while preserving semantics, controlling code size inflation, and maintaining near-native runtime performance (Li et al., 29 Sep 2025). The same name has also been used for a two-phase bug-finding technique for incorrect JavaScript property accesses, which combines statistical mining of anomalous access patterns with local data-flow filtering (Arteca et al., 2023). More broadly, the term appears alongside a larger body of JavaScript protection research concerned with sandboxing, provenance validation, privilege reduction, runtime rewriting, and security analysis.

1. Terminological scope

In the arXiv literature, the name JSProtect refers to two different systems.

Usage of the name	Core objective	Representative paper
JSProtect as an obfuscation framework	Protect large WeChat mini-games from IP theft while preserving semantics and scalability	(Li et al., 29 Sep 2025)
JSProtect as a bug-finding technique	Detect incorrect JavaScript property accesses by combining statistical anomaly detection with local analysis	(Arteca et al., 2023)

The first system is explicitly framed as an industrial-scale JavaScript protection method. Its threat model includes code pirates, cheat developers, algorithm thieves, and reverse engineers, and its practical target is JavaScript shipped to clients in the WeChat mini-game ecosystem. The second system addresses a different problem: JavaScript property-access mistakes that remain latent because reading a nonexistent property yields undefined rather than a runtime error. The shared name therefore does not identify a single canonical architecture; instead, it labels different protection-oriented interventions at different layers of the JavaScript toolchain.

A common source of confusion is to treat JSProtect as synonymous with JavaScript sandboxing. The literature does not support that equivalence. The 2025 system is an obfuscation framework, whereas the 2023 system is a bug detector. Neither is, in itself, a transactional sandbox or a hermetic worker-based isolation system.

2. Obfuscation for the WeChat mini-game ecosystem

JSProtect, in the sense of the 2025 paper, is a parallel, scope-aware JavaScript obfuscation framework built specifically for the WeChat mini-game ecosystem. The paper argues that developers face a serious threat of IP theft through code porting and secondary development: attackers can copy the source, replace WeChat-specific APIs, make minor edits, and redeploy the game on other platforms. The core practical constraint is that traditional JavaScript obfuscators are too slow, too memory-hungry, and too aggressive about code bloat, especially for industrial-scale mini-games with codebases up to 20 MB (Li et al., 29 Sep 2025).

The paper identifies three major limitations of existing obfuscation tools. First is a scalability crisis: for a 20 MB codebase, JS-Obfuscator takes over 13 hours and uses up to 22 GB memory. Second is runtime performance degradation: transforms such as control-flow flattening, dead code insertion, and repeated string/property decoding can reduce frame rate dramatically, even from 60 FPS to 1 FPS in severe cases. Third is severe code size inflation: existing tools often inflate output size by 10–20×, partly because they eventually run out of short identifiers and fall back to long hexadecimal names.

The paper formalizes obfuscation as a transformation

$\Omega: \mathcal{P} \rightarrow \mathcal{P}'$

subject to Semantic Preservation, Security Enhancement, and a Performance Constraint

$$\text{RT}(\mathcal{P}') \leq (1+\epsilon) \cdot \text{RT}(\mathcal{P})$$

for small $\epsilon$. The stated challenge is therefore not merely to hide code, but to do so while preserving semantics and controlling processing time, code size, and runtime overhead. This places JSProtect in the class of protection systems that must balance reverse-engineering resistance against deployment realism.

3. PASA, scope analysis, and performance-aware obfuscation

The central technical contribution of the obfuscation framework is Parallel-Aware Scope Analysis (PASA). JSProtect’s architecture has three components: PASA, PASA-enabled optimizations consisting of independent namespace management and independent code partitioning, and performance-aware obfuscation techniques consisting of single-variable property access and memoization via guard variables (Li et al., 29 Sep 2025).

PASA models scope as a tree,

$\mathcal{S} = (V_S, E_S, \text{root}),$

where each scope node carries Declarations, References, Type, and IsDynamic. Identifier resolution is defined by the function $\rho$, which recursively resolves a name through lexical parents until either a declaration is found or the global scope is reached. This resolution model is the basis for semantics-preserving renaming. PASA itself operates in three stages: parsing and dependency extraction, graph partitioning, and cross-file coordination. It builds a file dependency graph

$G_D = (F, D),$

then partitions files and scopes to minimize cross-partition edges, and finally resolves the small set of global bindings that cross partitions.

The output of PASA is twofold: a Scope Independence Map, which identifies scopes that can be processed independently, and Dependency Boundary Markers, which identify minimal coordination points for safe partitioning. These artifacts support two optimizations simultaneously: parallel obfuscation across multiple cores and aggressive identifier reuse across disjoint scopes. The safe-renaming condition is stated as Definition 3.3 (Safe Renaming): $$\forall s_1, s_2 \in V_S, \forall x, y \in \text{Identifier}: \rho(x, s_1) \neq \rho(y, s_2) \Rightarrow R(s_1, x) \text{ may equal } R(s_2, y).$$ This permits reuse of short names such as $a, b, c, \ldots$ across scopes whose bindings do not interfere.

The renaming procedure, given as Algorithm 1, iterates over independent partitions in parallel, processes scopes in topological order, computes forbidden names from ancestors, assigns the shortest available names from the pool $N = \{a,b,c,\ldots,z,aa,ab,\ldots\}$, and conservatively preserves names in dynamic scopes. The paper states Theorem 3.1 (Algorithm Correctness) and Theorem 3.2 (Space Optimality). The latter uses the cost function

$$\text{Cost}(R) = \sum_{s \in V_S} \sum_{x \in \text{Declarations}(s)} |R(s,x)| \cdot \text{Usage}(s,x).$$

The intended result is simultaneous correctness and minimization of expected identifier length under a uniform usage distribution.

JSProtect’s runtime-oriented transforms are deliberately narrower than many classic obfuscation passes. Instead of rewriting obj.prop into expensive computed expressions such as obj[calc_a()], it uses single-variable property access, rewriting to forms such as obj[a], where a stores the precomputed property name. Repeated computations in hot paths are cached using guard variables. The paper attributes near-native runtime behavior to scope-aware transformations that avoid unnecessary global coordination, direct lookups instead of indirect expensive expressions, caching repeated obfuscated computations, and preserving natural code structure as much as possible.

4. Evaluation, security metrics, and deployment claims

The empirical evaluation is organized around four research questions: semantic equivalence, scalability, runtime overhead and code size inflation, and security against static analysis and LLMs. The datasets include the Test262 official ECMAScript test suite, five mainstream WeChat mini-game engines, 100 real-world mini-games, 15 popular JavaScript libraries such as jQuery, Vue, and React, 50 real-world mini-games for runtime testing, and Livecodebench-JS for security evaluation. Baselines are JS-Obfuscator, JsJiaMi, VirBox Protector, and JScrambler (Li et al., 29 Sep 2025).

On semantic equivalence, the reported result is 100% on Test262, Engines, Mini-Games, and Libs. For scalability, the headline result at 20 MB is 141 s for JSProtect versus 47,445 s for JS-Obfuscator, with memory usage of 7,162 MB versus 22,035 MB. For code size inflation at the same input size, JSProtect produces 23.9 MB total output, corresponding to 20% inflation, whereas JS-Obfuscator produces 239.5 MB, corresponding to 1098% inflation; other commercial baselines are reported in the range 230%–1748%. These numbers are presented as one of JSProtect’s strongest results.

Representative runtime results are similarly concrete. For PixiJS, the original configuration is 9 MB, 1 ms frame time, and 60 FPS; the JSProtect version is 15 MB, 5 ms frame time, and 60 FPS, whereas baselines degrade much more severely. For JSZip, the original runtime is 7.9 s and the JSProtect runtime is 8.1 s, compared with 322.5 s to 664.5 s for baselines. For mini-games, the original configuration is 798 MB, 45 FPS; the JSProtect configuration is 804 MB, 41 FPS; baselines range from 820–924 MB and 1–16 FPS.

Security evaluation uses Cyclomatic complexity, Maintainability index, Normalized Information Distance (NID), ExpoSE, and LLM-based output prediction. The NID formula is

$$\text{RT}(\mathcal{P}') \leq (1+\epsilon) \cdot \text{RT}(\mathcal{P})$$0

JSProtect reports Cyclomatic complexity: 24.0×, Maintainability index: 42.6, and NID: 0.99. Under ExpoSE, it reports 56.3 s analysis time, 21% coverage, and 145 modeled calls. In LLM-based reverse engineering, output-prediction accuracy falls to 1.7% for GPT-4o, 9.8% for DeepSeek-V3, and 15.2% for DeepSeek-R1. The unified evaluation table is summarized as showing the highest cyclomatic complexity increase, the lowest maintainability score, the highest NID, the strongest resistance to ExpoSE, and the lowest LLM output-prediction accuracy among compared tools.

The paper also states deployment and impact claims: the framework has been deployed in production on approximately 10,000 active mini-games and 100 million user devices; the engineering effort took about five years, involved 20+ developers, and produced a codebase of over 6 MB; and after deployment, game plagiarism decreased by 91% over the past year. At the same time, the paper is explicit about assumptions and limits: dynamic JavaScript features are handled conservatively, PASA assumes accurate dependency and scope analysis, and the evaluation is centered on WeChat mini-games.

5. JSProtect as a detector for incorrect property accesses

A separate paper uses the name JSProtect for a two-phase bug-finding technique for incorrect JavaScript property accesses. Its target problem is distinct from obfuscation. JavaScript objects are dynamically shaped; properties can be added, overwritten, or deleted; methods are properties; and reading a nonexistent property simply yields undefined. As a result, an error such as using size instead of length may not fail at the point of access and can manifest much later. The technique therefore treats rare property-access patterns as suspicious, then filters them using a local analysis of the surrounding code (Arteca et al., 2023).

Phase 1 mines property-access patterns from a large corpus and represents each access as an access-path / property pair

$$\text{RT}(\mathcal{P}') \leq (1+\epsilon) \cdot \text{RT}(\mathcal{P})$$1

The access-path grammar is

$$\text{RT}(\mathcal{P}') \leq (1+\epsilon) \cdot \text{RT}(\mathcal{P})$$2

Pairs are classified as expected, anomalous, or unknown using thresholds and a binomial cumulative distribution function (BCDF). The anomaly criterion is

$$\text{RT}(\mathcal{P}') \leq (1+\epsilon) \cdot \text{RT}(\mathcal{P})$$3

Intuitively, a property access is anomalous only if the property is rare for the access path and the access path is rare for the property, with sufficient confidence.

Phase 2 performs local data-flow filtering to classify concrete instances of anomalous accesses as safe or unsafe. The five heuristics are: H1. Explicit assignment exists; H2. Access is in a conditional; H3. Dominated by another access to same property; H4. Same expression maps to another access path where the pair is not anomalous; and H5. Reassignment to an unmodeled value before the access. These heuristics are intentionally conservative and accept some false negatives to reduce false positives.

The mining stage uses 131,133 JavaScript/TypeScript GitHub projects and finds 40,717,178 access-path/property pairs from 201,282 packages. For the focused study, the paper uses 10 popular packages/libraries and reports 5,229,843 mined property-access expressions and 394,146 unique $$\text{RT}(\mathcal{P}') \leq (1+\epsilon) \cdot \text{RT}(\mathcal{P})$$4 pairs. It exhaustively searches 4096 parameter configurations. Under the reported precision-oriented configuration, Phase 1 yields Precision: 77.1%, Recall: 3.2%, and 148 anomalous pairs. In 10-fold cross-validation, the mean results are Precision: 67.57% and Recall: 4.80%.

Phase 2 evaluates the 645 concrete property-access expressions corresponding to those anomalous pairs across 266 code bases. It classifies 427 as safe and 218 as unsafe. On a manually checked sample of 100 instances, the ground truth contains 80 correct and 20 incorrect cases. The technique reports 78 safe and 22 unsafe; among the safe cases, 76 are correct and 2 are false negatives; among the unsafe cases, 18 are incorrect and 4 are false positives. The resulting Phase 2 metrics are Precision: 82% and Recall: 90%. The paper also compares against VSCode IntelliSense, which achieves precision 100% but recall 22.5% on the same sample, and therefore does not replace JSProtect’s anomaly-detection objective.

The paper is explicit about limitations. Phase 1 alone has very low recall. The approach depends on TypeScript declaration files for validation and some analysis steps. It only handles property accesses with constant property names. Access-path modeling is context-insensitive and flow-insensitive, and false positives can arise from analysis limitations around async/promise flows or module resolution. This version of JSProtect is therefore best understood as a statistically guided bug detector rather than a general-purpose security confinement mechanism.

6. Relation to the broader JavaScript protection landscape

JSProtect sits within a broader family of JavaScript protection techniques, but the neighboring systems operate under different security models. DecentJS is a language-embedded sandbox for full JavaScript that provides controlled visibility and controlled side effects through a membrane based on JavaScript proxies and a transactional effect log; effects can later be committed or rolled back, and the central security goal is noninterference (Keil et al., 2016). SafeJS offers hermetic sandboxing using web workers, a virtual DOM, and string-only message channels checked by policies, so that a foreign component cannot modify the main DOM unexpectedly (Cassou et al., 2013). JSSignature is instead a client-side pure JavaScript framework that validates third-party scripts by digital signature, providing integrity, authentication, and non-repudiation before execution, but it does not restrict script behavior after verification (Pinto et al., 2018). Mir introduces a fine-grained read-write-execute (RWX) permission model at library boundaries, infers 99.33% of required permissions, reduces privilege by 15.6× to 706× with an average of 224.5×, and reports 1.93% runtime overhead (Vasilakis et al., 2020). URR performs runtime detection and rewriting of privacy-harming code inside JavaScript bundles, replacing harmful AST subtrees with benign equivalents and reporting Precision: 1.00, Recall: 0.95, and Speed: 0.43s per script (Ali et al., 2024).

Other adjacent work further clarifies the space. Dasty is not a direct protection system; it is a semi-automated pipeline for identifying prototype-pollution gadgets using dynamic taint analysis and AST-level instrumentation, and it confirms proof-of-concept exploits for 49 NPM packages (Shcherbakov et al., 2023). OBsmith tests whether JavaScript obfuscators preserve semantics, finding 11 previously unknown correctness bugs in popular obfuscators and thereby addressing a precondition for trustworthy obfuscation-based protection (Jiang et al., 11 Oct 2025). Research on JavaScript semantics emphasizes why protection is difficult in the first place: global exposure, dynamic this binding, prototype-based inheritance, runtime evaluation, hoisting, and with all complicate confinement and auditability (Ducasse et al., 2012). Formal work on staged metaprogramming extends this line by proving soundness for static information-flow analysis aimed at properties such as noninterference in JavaScript-like languages (Lester et al., 2013).

Taken together, these systems show that JSProtect does not denote a single doctrine of JavaScript defense. In one usage it is an industrial obfuscation framework; in another it is a statistical detector for property-access bugs; and in related usage it names or evokes a wider class of techniques for sandboxing, validation, privilege reduction, rewriting, and security analysis. A plausible implication is that the term is best understood through the specific paper and threat model in which it appears rather than as a fixed, universally standardized architecture.