Protecting Python Applications
You can protect Python applications using Sentinel LDK Script Envelope on Windows or Linux machines. Through built-in automation, Script Envelope provides the simplest and preferred method for applying Sentinel Envelope protection to your applications.
Sentinel LDK Script Envelope protects Python applications so that you can distribute software without exposing proprietary source code. Script Envelope provides the following protection capabilities:
•Encryption (Classic): Encrypts each Python file as a whole. The runtime decrypts code into memory on demand. Encryption (Classic) also protects non-Python data files and machine learning models. This protection method is included with Sentinel LDK Script Envelope.
•Native Compilation: Compiles Python source code into native machine-code extension modules (.pyd on Windows and .so on Linux). The resulting modules contain machine code instead of Python bytecode. This protection method is included with Sentinel LDK Script Envelope.
•Machine Code Hardening: Applies configurable obfuscation, anti-tamper, and anti-trace protection to natively compiled machine code. Machine Code Hardening requires the Script Envelope Plus add-on.
You can select Encryption (Classic) or Native Compilation for each group of files and combine both protection methods within the same project.
Sentinel LDK Script Envelope provides automated native compilation for Python and typed Cython scripts (.py and .pyx files). The automated workflow translates source code to C, compiles the generated code into native machine-code binaries (.pyd on Windows and .so on Linux), and binds each protected module to a Sentinel LDK Feature ID without requiring a local Microsoft Visual Studio or CPython installation on the vendor machine.
Script Envelope Plus is an add-on that extends Script Envelope with Machine Code Hardening for natively compiled modules. Script Envelope Plus applies configurable protection mechanisms (obfuscation, anti-tamper, and anti-trace) directly to the compiled machine code.
You can configure general protection settings in the Script Envelope project file (.sprjx, in YAML format) at the project and file-group levels. Script Envelope Plus also supports more granular Machine Code Hardening settings for modules and functions. For details, see the Sentinel LDK Envelope for Windows or the Sentinel LDK Envelope for Linux.
Licensing Model and Workflow for Python Applications
Protected Python applications operate under a two-part licensing architecture:
>Protection-time developer key licensing: Controls the protection features available on the build machine.
>Run-time end-user application licensing: Controls how the protected application runs on the target machine.
Script Envelope and Script Envelope Plus Capabilities
The following table lists the capabilities available in Script Envelope and the capabilities that require the Script Envelope Plus entitlement (Feature 302):
| Included with Script Envelope | Script Envelope Plus (Feature 302) |
|---|---|
|
>Bytecode encryption of Python scripts and data files >Module and package folder name obfuscation (Encryption method) >Native compilation of >Docstring stripping in natively compiled modules >Traceback frame information stripping in natively compiled modules >Module bundling ( >Multi-architecture packaging ( >Per-unit licensing via Feature ID >Customizable runtime error messages and multi-language fallback >Customizable startup and runtime licensing failure policies |
>Instruction and control-flow obfuscation of compiled code >Anti-tamper binary integrity checking >Anti-trace debugger and tracer detection >Granular protection levels via the |
Developer Key Entitlement (Feature 302)
Script Envelope Plus hardening is licensed by a dedicated feature on the developer key connected to your build machine. You use this entitlement at protection time, not as the end user. To opt a project in to hardening passes, set plus: true in the project file.
To enable Script Envelope Plus protection, configure plus: true in the project file. The developer key used during protection must contain the Script Envelope Plus entitlement (Feature 302). If you protect with demo vendor code (DEMOMA), the build succeeds with standard native compilation without code hardening passes under warning C0057. If you specify plus: true with your vendor code but Feature 302 is absent from your developer key, the build stops with error C0062.
NOTE Feature 302 applies only to Script Envelope Plus for Python. Verify that your developer key holds Feature 302 for Python hardening.
Evaluation Entitlement
You can request a temporary evaluation entitlement (for example, a 30-day evaluation) for Script Envelope Plus. Thales provides the entitlement as a remote license update to your existing developer key.
To activate the evaluation entitlement:
1.Generate a machine fingerprint (C2V file) from your developer key.
2.Send the C2V file to Thales support.
3.Apply the returned V2C license update to activate the evaluation entitlement on your developer key.
The evaluation entitlement produces fully hardened native extension modules. Each module includes the trial expiration date. At run time, the module displays a warning that indicates the number of trial days remaining and stops running after the trial expires.
Use evaluation builds only for evaluation. The trial expiration prevents you from distributing these builds to end users.
End-User Application Licensing
Sentinel LDK Script Envelope binds each natively compiled Python script or Cython module to a specific Feature ID. This Feature ID governs the run-time licensing terms of the application on the target machine where you deploy the application.
You can define different versions of your application in Sentinel LDK-EMS by applying different license terms to your Feature ID:
>Evaluation Version: You can configure a time-limited or execution-limited license term for your Feature ID, which allows you to distribute a trial version of your natively protected application.
>Purchased Version: When a user purchases your software, you can provision a perpetual (unlimited) license or a subscription-based license for that Feature ID in Sentinel EMS.
Obtaining First Licenses and Applying Updates
Natively compiled applications use standard Sentinel LDK remote update procedures to activate and update licensing containers on target systems.
>Obtaining the First License: The end user generates a machine fingerprint (C2V file) using the Sentinel Remote Update System (RUS) utility or Admin Control Center, and transmits the C2V file to you. You import this C2V file into Sentinel LDK-EMS to generate a license file (V2C file) for your Feature ID. The end user then applies this V2C file to activate the application.
>Performing License Updates: When you need to upgrade an end user from an evaluation license to a permanent purchased license, you generate an update order in Sentinel LDK-EMS and send a new V2C file to the end user. The user applies the V2C file using RUS, which updates the licensing parameters on the Feature ID without requiring modifications to your compiled Python binaries.