EnvuscatorA Micrantha solution

Micrantha laboratory · mobile security

An extra build-specific security layer for mobile applications.

Envuscator applies randomized, layered obfuscation during your build pipeline to produce a unique protected build for every CI execution. The goal is not impossible client-side secrecy, but a practical increase in the cost of reverse engineering while keeping sensitive build operations inside your own infrastructure.

Discuss an integration View public project Open concept demo

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

Build-specific outputA unique protected build

Each CI execution can vary generated native output so one successful analysis is less reusable against the next build.

Layered techniquesRandomized obfuscation

Multiple complementary transformations increase effort beyond a single predictable obfuscation pass.

Customer controlledExecution stays in your CI

Source, protected configuration, artifacts, and build logs remain inside customer-managed infrastructure.

Provider neutralOne engine contract

GitHub Actions, GitLab CI/CD, and local execution converge on the same provider-neutral protection model.

Available now

A working implementation base for build-specific mobile protection.

Envuscator already has native Android and iOS generation and build-time configuration foundations. Current work is hardening those foundations into a reproducible, provider-neutral engine that can combine randomized techniques without overstating what client-side protection can guarantee.

Build-specific output

Unique native artifacts

Platform-specific generation makes it possible to vary protected Android and iOS output between CI executions.

Layered protection

Multiple randomized methods

The target engine combines complementary obfuscation techniques instead of relying on one predictable transformation.

Explicit limitation

Defense in depth only

No build-time client protection is perfect. Envuscator raises extraction cost but does not turn shipped values into durable secrets.

Target v1 architecture · how protection is delivered

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

The intended architecture supports the product promise without creating another sensitive build boundary. Provider adapters 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 applies the Android or iOS protection path.

  4. 04

    Artifact and evidence

    The runner receives a build-specific 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

Layered randomization

Composable build-specific techniques with explicit compatibility, reproducibility, and failure semantics.

Planned

Signed distribution

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

Planned

Commercial model

Perpetual one-time licensing alongside subscription updates, hosted services, support, and an 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.

Defense in depth

No client-side protection is perfect.

Given sufficient time and resources, a determined attacker can recover values and behavior from a shipped application. Envuscator does not promise permanent client-side secrecy. It increases reverse-engineering cost by producing a unique protected build for each CI execution and combining multiple randomized obfuscation techniques. It complements, rather than replaces, secure backend authorization, secret rotation, hardware-backed key storage, platform attestation, runtime integrity, and a secure SDLC.

Licensing philosophy

Simple, sustainable licensing without unnecessary lock-in.

The long-term pricing model is intended to always include a perpetual one-time purchase option alongside subscription tiers. Subscription plans may provide ongoing updates, hosted services, and enterprise support, while teams that prefer to own their tooling should retain a perpetual licensing path. These commercial options are planned and are not yet presented as generally available product tiers.