Security Model¶

This topic covers PyLocket's security architecture at a high level, describing the multiple layers of protection applied to every build.

Defense in Depth¶

PyLocket employs multiple independent security layers. Each layer operates independently, so defeating one layer does not compromise the others:

Encryption: Every Python function is individually encrypted with military-grade authenticated encryption. Without a valid license token, no function can be decrypted.
Integrity Verification: A cryptographically signed manifest ensures that any tampering with the protected artifact, encrypted data, or manifest is detected and causes immediate termination.
Anti-Reverse-Engineering: Multiple runtime detection mechanisms identify debugging, analysis, and instrumentation tools across all supported platforms. Detection triggers immediate application termination with no diagnostic output.
Memory Protection: Decrypted bytecode is held in secure memory regions with strict access controls. When no longer needed, decrypted data is securely erased to minimize exposure.
Binary Hardening: The native runtime is compiled with advanced obfuscation and hardening techniques that resist static analysis, disassembly, and binary patching.
License Binding: Runtime tokens are cryptographically bound to a specific device, application, and build. Tokens cannot be transferred or replayed on a different device.

Encryption¶

Every Python function body is encrypted individually with its own unique key. PyLocket uses authenticated encryption, which provides both confidentiality (the data cannot be read without the key) and integrity (any modification to the ciphertext is detected and rejected).

Keys are derived through a secure hierarchical key management system. The master key material is managed by a cloud-based hardware security module and never leaves the secure boundary. Per-function keys are derived deterministically, ensuring that each function has a unique key while enabling efficient on-demand decryption.

Integrity Verification¶

The protection manifest is cryptographically signed at build time. At runtime, the signature is verified before any decryption occurs. If the manifest has been modified in any way, the application terminates immediately.

Each encrypted function blob is also independently verified for integrity before decryption. This two-layer approach catches tampering whether it targets the manifest metadata or the encrypted function data itself.

Anti-Reverse-Engineering¶

PyLocket's native runtime includes multiple detection mechanisms that run on every supported platform:

Debugger detection: Identifies when a debugger is attached to the process
Environment detection: Identifies virtualized and sandboxed execution environments commonly used for analysis
Tool detection: Identifies known reverse-engineering and instrumentation tools without storing plaintext tool names in the binary
Timing verification: Detects execution anomalies caused by single-stepping or breakpoint-based debugging
Memory dump prevention: Disables core dumps and process memory dumps on supported platforms
Continuous monitoring: Key detection checks are repeated on every protected function call, not just at startup

When any detection check fails, the application terminates immediately without providing diagnostic information that could help an attacker understand which check was triggered.

Memory Protection¶

Decrypted bytecode is stored in protected memory regions with strict permission controls:

When idle, memory regions are marked as inaccessible — any unauthorized read attempt causes an immediate fault
Permissions are elevated only during active execution
Decrypted functions are cached briefly and then securely erased using compiler-safe techniques that cannot be optimized away
The cache is small and time-limited to minimize the window of exposure

Binary Hardening¶

The native runtime binary is hardened against static and dynamic analysis:

Control-flow protection: The binary's control flow is transformed to resist disassembly and decompilation
API concealment: Security-sensitive operating system calls are resolved dynamically at runtime rather than being visible in import tables
Symbol stripping: All debug information and symbols are removed from production binaries
Crash hardening: The runtime is configured to abort on errors rather than unwind, preventing stack trace analysis

Tamper Detection¶

PyLocket detects multiple forms of tampering:

Manifest tampering: Any modification to the manifest causes signature verification to fail, terminating the application before any decryption occurs
Ciphertext tampering: Any modification to an encrypted function blob is detected by integrity verification during decryption
Function swapping: Attempting to swap encrypted blobs between functions fails because each function has a unique key
Runtime binary tampering: Modifications to the native runtime produce incorrect behavior, triggering crashes or false-positive security detections

What PyLocket Does Not Protect Against¶

No protection system is unbreakable. PyLocket significantly raises the cost of reverse engineering but cannot prevent:

Kernel-level debuggers: Ring-0 debuggers can bypass user-space detection
Hardware debuggers: JTAG/SWD interfaces operate below the OS level
Custom VM/emulator: A purpose-built emulator can sandbox the application
Memory forensics with physical access: Cold boot attacks, DMA attacks
Social engineering: Extracting license keys from legitimate users

PyLocket is designed to make reverse engineering economically impractical — the cost of breaking the protection exceeds the value of the protected code for the vast majority of threat actors.