| JavaScript / TypeScript: CLI, services and SDKs |
Source profile available One compiled JavaScript ESM source bundle. Compile TypeScript before packing. |
Build integration required Integrate the emitted module into the application build; qualify the complete service or package separately. |
Recorded artifact checks Selected ESM bundles have recorded Node.js checks. Marked matched four Markdown cases; the earlier SDK benchmark matched four scenarios. Node.js 24.19.0 JavaScript bundle measurements Four public artifact measurements |
- Export names alone do not prove behavior for every export.
- Live bindings, dependency behavior and module initialization require scenario-specific qualification.
- Bun, Deno, live service deployments and complete application behavior require their own qualification.
|
| CommonJS applications |
ESM conversion required Convert CommonJS to an ESM bundle first. Direct .cjs input and node-cjs output are unavailable. |
Build integration required Conversion belongs in the application build before the ESM source profile. |
Runtime not qualified No direct CommonJS output qualification is claimed. |
- Renaming an extension does not convert module semantics.
- A valid CommonJS generation and parity workflow remains to be delivered.
|
| Browser applications and PWAs |
Source profile available One JavaScript source bundle through the browser profile. |
Build integration required HTML, assets, routing, service workers and the final web deployment remain part of the application build. |
Recorded artifact checks One owned ESM fixture matched 12 of 12 scenarios before and after protection, retained five export names, and passed observed CSP enforcement controls in Chromium. Chromium 156.0.8078.4 on Linux x64 in BoxFleet E2B Chromium fixture before and after Verified browser fixture report (JSON) |
- Only the owned fixture is verified; frameworks, PWAs, service workers, extensions and arbitrary browser applications remain unqualified.
- This compatibility run does not measure resistance to reverse engineering or autonomous agents.
|
| Browser extensions |
Source profile available An extracted JavaScript module can use the browser source profile; extension integration is unqualified. |
Not available No CRX/XPI packaging or extension manifest workflow. |
Runtime not qualified No extension runtime, permission or background-worker qualification. |
- Content scripts, isolated contexts, messaging and store packaging require a dedicated corpus.
|
| React Native and Hermes applications |
Source profile available The dedicated mobile:precompile hook transforms one JavaScript source script before the matching Hermes compiler. |
Build integration required A source build hook is available. APK, AAB and IPA construction, signing and deployment remain unqualified. |
Recorded artifact checks An owned Metro-style fixture with Day.js 1.11.13 matched 19 scenarios in each of four variants: source and compiled bytecode, before and after transformation. Hermes 451d60a2 on Linux x64 in BoxFleet E2B Hermes and Electron before and after |
- Compiled Hermes bytecode is not accepted as protection input.
- Standalone Hermes evidence does not qualify React Native UI, native modules, JNI, Swift/Objective-C, Android or iOS applications.
- Use the Hermes compiler version required by the application build.
|
| Capacitor and Tauri applications |
Source profile available JavaScript source components can use a source profile; framework integration remains to be qualified. |
Not available No complete mobile or desktop framework packaging workflow. |
Runtime not qualified No WebView, plugin bridge or native host qualification. |
- A transformed JavaScript component does not qualify the native host, Rust code, plugins or final package.
|
| Android Java / Kotlin and JNI |
Not available No APK, AAB, DEX or Android native-library protection input. |
Not available No Android application transformation, signing or installation workflow. |
Runtime not qualified Toolchain prerequisite checks exist; no Android application benchmark is established. |
- Manifest, resources, R8/ProGuard, JNI and signature validation require separate work.
- Linux ARM64 does not establish Android compatibility.
|
| iOS Swift / Objective-C applications |
Not available No IPA, iOS Mach-O or Swift/Objective-C protection input. |
Not available No iOS application transformation, provisioning or signing workflow. |
Runtime not qualified No device or simulator qualification. |
- Desktop macOS artifact checks do not establish iOS compatibility.
|
| Flutter and Dart applications |
Not available No Dart source, snapshot or AOT artifact protection workflow. |
Not available No Flutter mobile, desktop or web package integration. |
Runtime not qualified No Flutter runtime qualification. |
- Dart code, assets, plugins and native integration need a dedicated corpus.
|
| Unity applications and games |
Not available No Unity Mono or IL2CPP protection workflow. |
Not available No Unity player, asset-bundle or application package integration. |
Runtime not qualified No Unity player qualification. |
- Managed scripts, generated native code, assets and engine behavior require separate validation.
|
| .NET MAUI and Xamarin applications |
Not available No MAUI/Xamarin assembly or AOT application protection workflow. |
Not available No framework-specific mobile or desktop package integration. |
Runtime not qualified No MAUI/Xamarin application qualification. |
- The historical .NET laboratory fixture does not qualify these frameworks.
|
| Electron desktop applications |
Selected application files The dedicated electron:pack command transforms explicitly selected main, preload and renderer JavaScript files in an application directory or ASAR. |
Selected application packaging New directory or fully packed ASAR output; unselected files, dependencies and package metadata are preserved. |
Recorded artifact checks One owned application matched 11 scenarios in each of four directory/ASAR variants before and after transformation, with IPC, resources, live bindings, preload isolation and enforcing CSP observed. Electron 44.5.0 on Linux x64 in BoxFleet E2B Electron before and after Electron runtime report (JSON) |
- Linux fixture evidence does not qualify arbitrary Electron applications, Windows or macOS.
- Native addons, unpacked ASAR sidecars, installers, signing, notarization and updates remain unqualified.
- Chromium operating-system sandbox disabled in E2B; preload JavaScript sandbox and context isolation measured separately.
|
| Native desktop: Go, Rust and C/C++ |
Selected artifact experiments Separate experiments on selected native artifacts. The source-module packer does not accept executables or libraries. |
Not available No general executable, library, installer or signed application pipeline. |
Recorded artifact checks Recorded fzf and ripgrep Windows checks matched two CLI controls each. Linux/macOS observations were static only. Windows x64 Four public artifact measurements |
- Two CLI controls do not establish complete binary parity.
- General C/C++, Linux, macOS, ABI compatibility and signature preservation remain unqualified.
|
| Managed .NET and NativeAOT applications |
Not available No general managed-assembly or NativeAOT input in the source-module packer. |
Laboratory fixture only Historical laboratory builds cover a specific .NET fixture only. |
Historical fixture record Historical fixture checks do not establish qualification of arbitrary .NET applications. Windows .NET Framework laboratory fixture |
- Assemblies, metadata, runtime versions, native dependencies and NativeAOT need a representative corpus.
|
| JVM Java / Kotlin applications |
Selected application packaging The dedicated jvm:pack command accepts Java 17 classpath application and library JARs with explicit API and reflection contracts. |
Selected application packaging A new JAR preserves declared contracts, resources and resource directories. Keep build diagnostics outside the distributed package. |
Recorded artifact checks An owned application and a library with an unchanged external consumer matched 17 scenarios each before and after transformation: 68 outcomes, including reflection, annotations, ServiceLoader and resources. OpenJDK 17.0.20.1 on Linux x64 in BoxFleet E2B Java application and library before and after Java runtime report (JSON) |
- Kotlin metadata, external dependencies, signed, modular and multi-release JARs are refused, along with recognized native formats and nested ZIP/JAR components.
- Opaque resources are preserved without execution or runtime qualification.
- UTF-8 output was explicitly configured in each tested JVM process.
- This fixture does not qualify arbitrary JVM applications, server deployments, desktop GUI, Windows, macOS or Android.
|
| WebAssembly modules and components |
Not available No standalone .wasm module or component protection input. |
Not available No WebAssembly component or WASI packaging workflow. |
Runtime not qualified No external WebAssembly artifact qualification. |
- Browser, WASI and host integration require independent tests.
|
| Python applications and distributions |
Source profile available One Python source module. Wheel archives and frozen executables are not accepted. |
Build integration required Integrate transformed modules into the package build; wheels and frozen applications require separate validation. |
Recorded artifact checks One Click module was replaced inside a copied package; four CLI scenarios matched. CPython 3.12.10 Four public artifact measurements |
- This does not qualify all modules, C extensions, wheels, PyInstaller or Nuitka outputs.
|
| Other interpreted runtimes: PHP, Ruby, Lua and more |
Not available No source or bytecode protection workflow for these interpreted runtimes. |
Not available No language-specific application or dependency packaging workflow. |
Runtime not qualified No PHP, Ruby, Lua or other interpreted-runtime qualification. |
- Each language, interpreter version and extension model requires its own corpus and qualification.
|
| Containers and serverless deployment packages |
Not available No OCI image, container layer or serverless function-package transformation. |
Not available No qualified container or serverless packaging and deployment integration. |
Runtime not qualified No deployed container or serverless function qualification. |
- Deployment packaging does not qualify the contained runtime.
- Assess each contained application component under its own family; package assembly, permissions and deployment behavior require separate validation.
|
| Firmware and embedded applications |
Not available No firmware image, bootloader or embedded application protection workflow. |
Not available No device-image construction, signing or update workflow. |
Runtime not qualified No hardware or emulator qualification. |
- CPU, memory, boot, update and device-specific constraints require a separate assessment.
|
| EVM smart-contract bytecode |
Not available No EVM bytecode or smart-contract protection workflow. |
Not available No contract build or deployment integration. |
Runtime not qualified No EVM execution or contract-equivalence qualification. |
- Contract semantics, gas behavior and deployment constraints require a separate assessment.
|