User Guide

1. Supported platforms & formats

1.1 Native binaries (upload and harden directly)

1.2 Cross-platform frameworks

1.3 Hardening modules (mix and match strength)

• DEX packing: the original DEX is extracted and encrypted; the shell ClassLoader decrypts and loads it at runtime.
• Anti-debug + anti-injection: detects debuggers, Frida, Xposed and similar dynamic-analysis tooling.
• Integrity check: verifies code / read-only segment hashes against repackaging (Windows reads the on-disk image to avoid false positives on the import table).
• Obfuscation: string encryption / control-flow flattening / symbol renaming / junk instructions / HTML·JS obfuscation.
• SO protection: native .so segment encryption + deep obfuscation.
• VMP virtualization: selected methods are converted to custom VM instructions, executed by a built-in interpreter at runtime.

Other security features: SSL Pinning (native implementation + public-key pinning, official CA), keys sunk into native (anti static-extraction), device fingerprinting (computed server-side), ban-and-force-exit.

2. Workflow

1. Create an app (Apps) → set name / package name.
2. Harden: drop in the file → the platform auto-detects → pick a hardening level (Basic / Standard / Max / Custom) → optionally enable device management and Live Key.
3. Sign: choose “auto debug signing” or upload your own platform certificate (Signing).
4. Submit → the job queues → live progress (unpack → obfuscate → pack → integrity → … → sign → upload).
5. Download / distribute: download the artifact when the job finishes, or generate an app-store-style distribution link (APK).

3. Device management / anti-piracy (optional)

With device management on, a hardened app auto-registers its device. From the console you can:

• See authorized devices (model / OS / runtime risk signals);
• Ban / kick a device: a banned device exits immediately on next launch;
• Push in-app notifications;
• Live Key derivation: the key is issued fresh at each launch — the server only sends intermediate material, and the real key is rebuilt on-device (on Android it's sunk into native, so decompilation reveals no key).

4. When a format isn't supported (important)

4.1 Windows installers (NSIS / Inno Setup / self-extracting EXE)

A compiled installer can't be repackaged losslessly (that needs the original packaging script). The right approach:

1. First upload your .exe / .dll (the app itself) to Anrix and harden it;
2. Download the hardened exe/dll;
3. Then use your NSIS / Inno / WiX script to build the installer from the hardened files.

4.2 MSI packages — supported

Upload the MSI → extract the installed EXE → harden it → replace in place and reseal → the embedded EXE carries the protection. If a complex custom-action / compressed MSI can't be resealed, that's labeled honestly (no false success); fall back to 4.1: harden the EXE, then rebuild the MSI with WiX or similar.

4.3 macOS DMG disk images — supported (resealing is fragile, with a fallback)

Upload the DMG → extract the .app → harden → reseal. Resealing a DMG on Linux is fragile; if it fails, the original is kept and you're notified (no fake hardening). Manual fallback:

1. Upload the .app (dragged out of the DMG) or its zip → download the hardened .app;
2. On macOS run hdiutil create -volname MyApp -srcfolder MyApp.app -ov MyApp.dmg.

4.4 macOS PKG packages — supported

Upload the PKG → extract the Payload → locate the .app and harden it (inject runtime protection) → repackage and reseal. Re-signing the whole package needs your certificate (on macOS, or upload a certificate for the platform to re-sign).

4.5 PyInstaller / py2exe (Python bundlers) — embedded bytecode encrypted

• The outer bootloader (exe/elf/mach-o) is hardened on upload (anti-debug / integrity).
• Python bytecode (.pyc) protection is implemented: the user .pyc inside the embedded archive and the whole bytecode region are encrypted (AES-256-GCM, key sunk into native to resist constant folding). Unpacking yields ciphertext, decompilation fails, embedded modules can't be restored, and a static search won't turn up the key.
• Fully transparent self-execution needs a bootloader patch (NEEDS_BOOTLOADER_PATCH): the pure-encryption layer already works (static anti-extraction), but for the encrypted program to self-decrypt and run, the bundler's bootstrap layer must be rebuilt / patched (a recipe ships alongside the artifact). For source-level hardening you can also layer a third-party Python source-hardening tool before bundling.

4.6 Other language bundlers

.NET single-file / R2R, GraalVM native-image, Nuitka, Go, Rust, deno/bun compile, Java fat-jar, Node pkg/SEA, PHP phar — we recognize 23 formats. Natively-compiled ones (Nuitka / Go / Rust / GraalVM) are already native binaries and harden on upload; self-extracting bundles (containing interpreted code) get the same depth as PyInstaller (native shell + code-asset encryption, transparent decryption needs runtime cooperation).

5. Known limits (always labeled honestly)

• The runtime protection library must ship in the same directory as the artifact: a hardened desktop artifact comes with a runtime protection library (Linux .so / Windows .dll / macOS .app Contents/Frameworks/*.dylib). It's a companion file auto-loaded when the artifact starts and must sit in the same directory as the executable (or in place inside the .app). If it's missing or moved, the hardened program won't open / fails at launch. Always include it when packaging for distribution (zip / installer).
• macOS re-signing disables Library Validation: after injecting a third-party protection library into a Hardened-Runtime app, re-signing automatically adds com.apple.security.cs.disable-library-validation to the entitlements (preserving the app's existing App Groups / Push / Keychain / Associated Domains / iCloud capabilities) so the loader allows the library. When you re-sign with your own certificate, those same entitlements are carried through.
• A signed Windows EXE loses its signature: injecting protection into an already-signed .exe invalidates the original signature. If you haven't uploaded a code-signing certificate (.pfx) in the signing settings, the artifact ships unsigned and the report says so honestly — re-sign with your certificate before distribution, or it triggers SmartScreen warnings or gets blocked by WDAC / AppLocker.
• macOS / iOS runtime behavior (force-exit, anti-debug, jailbreak detection, Gatekeeper) needs a real device; the static injection layer is verified, and Windows is tested on a compatibility layer.
• RN / Cordova / PyInstaller transparent code decryption needs the app's own native cooperation (NEEDS_APP_NATIVE).
• Browser upload of source packages >100 MB currently uses a size-limited channel; the artifact side already supports large-file direct upload.
• Compiled installers (NSIS / Inno) can't be resealed losslessly — use “harden before packaging” from section 4.