Quality & Robustness
Tests & Benchmarks
Rigorous evaluation of the full 2026 SOTA protection stack under realistic attacker models, including LLM-powered deobfuscators.
ADVERSARIAL DIFFICULTY
~6
Overall attacker score (lower = stronger)
NAME RECOVERY
0.00
No original identifiers extracted
CROSS-REFERENCE
0.00
Call graph & dataflow links unrecoverable
Evaluation Philosophy
The goal is not merely “does it look obfuscated”. Every change is measured against a 12-axis matrix that captures correctness, performance, integrity, surface quality, and — most critically — resistance to modern automated reverse engineering under strict blind conditions.
Adversarial Robustness
ISOLATED BLIND RECONSTRUCTIONTests use a dedicated internal harness with strict static surface only — no execution, no logic guessing, no source hints. This simulates a strong CASCADE-style LLM+IR attacker given only the protected artifact.
Overall attacker score
~6
Lower is better — measures difficulty of blind reconstruction
40% effective against the model
nameRecovery
0.00
Zero original identifiers recovered by the attacker model
100% effective against the model
crossRefScore
0.00
No cross-file references or call graph reconstructed
100% effective against the model
Graded benchmark series
The files isolation_test.js → complex_license.js → test_h.js form an increasing-difficulty ladder. They exercise realistic licensing, cross-module calls, heavy computation, environment binding, and audit side-effects — exactly the patterns that trigger receipts, obligations, P0 entanglement, D-oracles, and PCET rolling proofs.
Current consistent result on maximum + full A–H: overall ~6 with perfect 0.00 on name and cross-reference recovery.
Size & Performance Characteristics
Full A–H stack, maximum preset, on realistic modules exercising licensing, feature gating, heavy arithmetic, cross-calls and data-dependent control flow.
Size Expansion Factor
Protected size relative to original source
14 KB original
10–14×
protected 150–197 KB
50 KB original
6–7×
protected 310–374 KB
100 KB original
≈5×
protected 496–529 KB
Larger sources achieve better relative density; the fixed cost of the rich runtime + oracles + receipt machinery is amortized.
Encode Time (full maximum)
Typical dev machine, all layers + poison + A–H primitives active
14 KB2.8–3.7 s
50 KB5.9–6.7 s
100 KB13–18 s
Time is dominated by VM virtualisation, oracle planting, receipt chain synthesis, and per-build polymorphic emission.
| Original | Protected Output | Expansion | Encode Time |
|---|---|---|---|
| 14 KB | 150–197 KB | 10–14× | 2.8–3.7 s |
| 50 KB | 310–374 KB | 6–7× | 5.9–6.7 s |
| 100 KB | 496–529 KB | ≈5× | 13–18 s |
Protected execution overhead on robust Stage-0 variants is typically 5–15× in hot loops (receipt density after calls/assignments, obligations, oblivious decisions). Exotic Stage-0 choices can be significantly more expensive or may fail to emit loadable artifacts for very large payloads.
The 12-Axis Evaluation Framework
12 EVALUATION AXES| # | Test | What it validates |
|---|---|---|
| 01 | Correctness / usability | Run the exact same workload on original and (when it loads) protected. Outputs must match (or be within defined tolerance). We verified stable main() results across 5+ runs and 10k iterations. |
| 02 | Cold-start / loading overhead | Time require() (or process spawn + first work). Break down Stage-0 assembly vs VM init vs oracle evaluation vs first receipt/proof setup when possible. |
| 03 | Warm execution performance | Micro-benchmark representative hot paths (the 2k / 10k main() loops, 3k-iteration bench on the size files). Report avg time or ops/sec. |
| 04 | Memory footprint | process.memoryUsage() before/after require, after workload. Record RSS and heapUsed deltas (load + work). |
| 05 | Environmental sensitivity (D oracles) | Run under mocked "bad" env (no node signals, instant time, etc.). Record whether behavior diverges, validation fails, or traps are hit. (Design intent: oracles are load-bearing for receipt keys.) |
| 06 | Receipt / proof chain integrity (design + spot) | The architecture (receipt re-keys xk + folds P0 + lastReceipt into proofRoot via rolling FNV-style mul/xor at every receipt point; PCET at terminal; obligations that poison on invariant failure) is intended to make partial replay or out-of-order simulation produce garbage or traps. |
| 07 | Size & surface / obfuscation metrics | Original total bytes/LOC vs protected bundle(s). Quick surface checks (no internal engine names, "receipt point", "P0 entanglement", "living trap", "PCET", "ADTI-LHB", "ADTI" etc. self-names remain in emitted code — verified on protected artifacts). Per-build polymorphism (different line numbers in errors, different protected sizes across rebuilds). |
| 08 | Long-running stability | Run workloads 5–10× longer than the baseline (10k iterations). Watch for crashes, accumulating state growth, or non-deterministic drift in audit hashes / results. |
| 09 | Encoder regression gates | TypeScript compilation and the full JsGuardianVM regression suite (16/16 cases) are enforced and must remain green after any change to the protector engine. |
| 10 | Cross-build polymorphism & "protected artifact usability rate" | Re-encode the same sources multiple times (different seeds / Stage-0 choices). Count how many of N rebuilds produce a loadable artifact that passes the workload with correct output. (Current full A–H + cross-flatten on >tiny apps: low success rate on exotic Stage-0; robust variants higher but still expensive.) |
| 11 | Adversarial regression (when artifacts are loadable) | Internal isolated blind reconstruction harness on the graded benchmark series. Current results on maximum + full A–H stack: overall ~6, nameRecovery 0.00, crossRefScore 0.00. |
| 12 | Branding / self-description | Grep protected output for technique names. Must be clean (no engine codenames such as JsGuardianVM or internal technique markers may leak into artifacts). |
Correctness & Reliability
01 · 08 · 09 · 10
Correctness / usabilityRun the exact same workload on original and (when it loads) protected. Outputs must match (or be within defined tolerance). We verified stable main() results across 5+ runs and 10k iterations.
Long-running stabilityRun workloads 5–10× longer than the baseline (10k iterations). Watch for crashes, accumulating state growth, or non-deterministic drift in audit hashes / results.
Encoder regression gatesTypeScript compilation and the full JsGuardianVM regression suite (16/16 cases) are enforced and must remain green after any change to the protector engine.
Cross-build polymorphism & "protected artifact usability rate"Re-encode the same sources multiple times (different seeds / Stage-0 choices). Count how many of N rebuilds produce a loadable artifact that passes the workload with correct output. (Current full A–H + cross-flatten on >tiny apps: low success rate on exotic Stage-0; robust variants higher but still expensive.)
Core requirement: protected code must behave identically. Long workloads and cross-build repeatability are validated to ensure no drift or fragility in the emitted artifacts.
Performance & Resource Impact
02 · 03 · 04
Cold-start / loading overheadTime require() (or process spawn + first work). Break down Stage-0 assembly vs VM init vs oracle evaluation vs first receipt/proof setup when possible.
Warm execution performanceMicro-benchmark representative hot paths (the 2k / 10k main() loops, 3k-iteration bench on the size files). Report avg time or ops/sec.
Memory footprintprocess.memoryUsage() before/after require, after workload. Record RSS and heapUsed deltas (load + work).
Loading, hot-path execution, and memory deltas are measured because real-world deployment cares about startup latency and footprint as much as security.
Protection Integrity
05 · 06
Environmental sensitivity (D oracles)Run under mocked "bad" env (no node signals, instant time, etc.). Record whether behavior diverges, validation fails, or traps are hit. (Design intent: oracles are load-bearing for receipt keys.)
Receipt / proof chain integrity (design + spot)The architecture (receipt re-keys xk + folds P0 + lastReceipt into proofRoot via rolling FNV-style mul/xor at every receipt point; PCET at terminal; obligations that poison on invariant failure) is intended to make partial replay or out-of-order simulation produce garbage or traps.
D-oracles and receipt/PCET chains are load-bearing. Environmental deviation or any attempt at replay/partial simulation must be detected and punished.
Obfuscation Quality & Stealth
07 · 12
Size & surface / obfuscation metricsOriginal total bytes/LOC vs protected bundle(s). Quick surface checks (no internal engine names, "receipt point", "P0 entanglement", "living trap", "PCET", "ADTI-LHB", "ADTI" etc. self-names remain in emitted code — verified on protected artifacts). Per-build polymorphism (different line numbers in errors, different protected sizes across rebuilds).
Branding / self-descriptionGrep protected output for technique names. Must be clean (no engine codenames such as JsGuardianVM or internal technique markers may leak into artifacts).
Surface area and branding are aggressively minimized. No self-referential strings or technique names are allowed to remain in the final output.
Adversarial Resistance
11
Adversarial regression (when artifacts are loadable)Internal isolated blind reconstruction harness on the graded benchmark series. Current results on maximum + full A–H stack: overall ~6, nameRecovery 0.00, crossRefScore 0.00.
The decisive modern test: resistance to LLM+IR pipelines under strict isolated blind conditions (no source logic hints, no execution).
Key engineering takeaway
The full A–H stack delivers very strong properties when the protected artifact loads. The dominant remaining constraint is Stage-0 emission reliability for payloads beyond small single files under cross-flatten at maximum. Larger combined images still occasionally land on fragile loaders. Future iterations prioritize robust Stage-0 bias for complex apps while preserving the deliberate diversity of the eight heterogeneous outer loaders.
All measurements were performed with internal encoder gates passing (TypeScript clean + 16/16 JsGuardianVM regression tests).