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.

Key Management Principles¶

Master keys are NEVER embedded in the distributed artifact. The bootstrap contains no key material of any kind.
Key material comes exclusively from the license activation service. At runtime, the bootstrap contacts the activation service and receives encrypted key material that was decrypted server-side using cloud-based key management.
Even with full access to the artifact, decryption is impossible without a valid license key and matching device fingerprint. The artifact contains only encrypted function blobs, stubs, and the manifest -- none of which are sufficient for decryption on their own.
Master keys are managed by a cloud-based hardware security module. Key material never leaves the secure boundary. Automatic key rotation is enabled.

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 runtime integrity checks that run on every supported platform. These checks detect a wide range of analysis and instrumentation techniques across all supported operating systems.

Checks run continuously throughout execution, not just at startup. When any 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

Security Philosophy¶

No software protection system is unbreakable. PyLocket is designed to make reverse engineering economically impractical — the cost of breaking the protection far exceeds the value of the protected code for the vast majority of threat actors. Multiple independent security layers ensure that defeating any single layer does not compromise the overall protection.