Envuscator mobile security

Build-specific obfuscation without creating another secrets boundary.

Envuscator is being built as a runner-local security layer for Android and iOS pipelines. The target v1 architecture keeps source, protected configuration, generated artifacts, and build logs inside customer-controlled CI while adding randomized native output and independently verifiable build evidence.

The current web demo is a product concept surface; it does not yet demonstrate the complete runner-local v1 architecture described below.

Current foundation Native generation

Existing Android and iOS generation paths provide the implementation base.

In progress Provider-neutral engine

Stable requests, categorized results, cleanup guarantees, and manifests are converging.

Target v1 Runner-local execution

GitHub and GitLab adapters will keep sensitive build material in customer CI.

Available now

A working implementation base with a narrower production contract under construction.

Envuscator already has native mobile generation and build-time configuration concepts. Current work is hardening those foundations into a reproducible, provider-neutral v1 rather than presenting roadmap guarantees as completed product behavior.

Existing foundation

Android and iOS generation

Platform-specific tooling produces native mobile artifacts from build configuration.

Existing foundation

Build-time integration

The project is designed around inserting generated configuration during the build rather than maintaining it manually in application code.

Explicit limitation

Defense in depth only

Obfuscation raises extraction cost but does not turn shipped client values into durable secrets.

Target v1 architecture

The service licenses the engine. The runner performs the build.

The intended architecture separates commercial entitlement from sensitive execution. Provider adapters will authenticate a workload, acquire a bounded engine grant, verify an immutable release, and invoke one provider-neutral local engine contract.

  1. 01

    Provider identity

    GitHub OIDC or GitLab job identity proves repository, namespace, workflow, ref, and environment claims.

  2. 02

    Entitlement exchange

    A minimal service validates licensing and returns a short-lived grant for an immutable engine release.

  3. 03

    Local engine

    The runner verifies the release, reads protected local configuration, and invokes the Android or iOS path.

  4. 04

    Artifact and evidence

    The runner receives an AAR or XCFramework plus deterministic provenance metadata and a normalized result.

Customer-controlled boundary

What must stay in the runner

  • Application source and protected configuration
  • Plaintext temporary material and platform toolchains
  • Generated artifacts, application binaries, and build logs
  • Cleanup, retention, signing, and release policy

Envuscator service boundary

What the target service may know

  • Verified workload identity and licensed namespace
  • Entitlement state and privacy-minimized audit events
  • Requested engine version and short-lived grant metadata
  • No customer configuration, source, artifacts, or build logs

Delivery roadmap

Converging on a small, reproducible contract before commercial expansion.

In progress

Engine contract

Versioned requests, categorized failures, deterministic manifests, cleanup guarantees, and real Android/iOS smoke builds.

In progress

Provider adapters

GitHub Action and GitLab CI component parity using local configuration paths and one conformance suite.

Planned

Signed distribution

Reproducible releases, checksums, signatures, SBOMs, provenance, compatibility policy, and rollback-tested publication.

Planned

Commercial entitlement

Provider-neutral licensing for GitHub, GitLab-compatible workloads, and an explicit offline enterprise boundary.

Planned

Rust orchestration

An incremental migration from mixed shell and Python orchestration behind conformance fixtures and real-build parity tests.

Planned

Public verification

Examples, release verification instructions, threat-model documentation, and a single authoritative public deployment.

Security scope

Obfuscation is friction, not confidentiality.

Values embedded in a shipped client can eventually be recovered by a capable adversary. Envuscator does not replace server-side authorization, secret rotation, hardware-backed key storage, platform attestation, runtime integrity, or a secure SDLC. Use it as defense in depth for values that must exist in the client, and keep true secrets off the client entirely.