Python source code recovery

What can be assessed?

The first distinction is packaging versus protection. PyInstaller collects an application, its Python runtime and dependencies into a distribution. Python bytecode may be present in its archives. PyArmor applies protection to Python code and introduces a runtime component. The same application can combine both, so identifying a PyInstaller executable does not establish how easy its protected modules are to recover.

The catalogue covers PyArmor 7, 8 and 9, plus PyInstaller, py2exe and cx_Freeze packages. Availability of a compatible runtime, Python bytecode version, custom loaders and missing dependencies changes what can be examined. A version label alone is not enough to quote a complete recovery.

• Identify the executable, interpreter version and packaging format.
• Separate ordinary dependencies from protected application modules.
• Evaluate bytecode, resources and observable runtime behaviour.
• Document recoverable components and unresolved limitations.

Agree the deliverable before recovery

An extracted archive, decompiled Python module and reconstructed project are different deliverables. Extraction can restore files without making their code readable. Decompilation can produce readable statements while losing comments, formatting and some names. Reconstructing a runnable project may also require dependency versions, configuration files and external services that were never embedded in the executable.

For a suitable sample, the agreed handover can include recovered modules, extracted resources, a directory map and an analysis report. The report should distinguish directly extracted material from reconstructed code and list components that could not be validated. If running the recovered project is part of the engagement, agree a reproducible acceptance check using your own test data.

Why full original source cannot be guaranteed

Compilation and protection can discard information. Original comments, local names and build instructions may not exist in the shipped artifact. Bytecode decompiler support also varies by Python release. Native extensions require a different approach from Python bytecode, even when both are shipped in one application.

A useful result can therefore be partial: a recovered data file, an identified module boundary or a documented execution path. Ask for the feasible scope after initial inspection. Avoid treating a demonstration on one build as evidence that every protection mode or release will behave the same way.

What to send for an initial assessment

Start with the file type, platform, Python or packager version if known, and the outcome you need. Explain whether you need to restore your project, investigate a defect or understand a particular module. A small representative sample and a description of its normal behaviour are often more useful than an unexplained archive.

Contact TNKRE before transferring sensitive binaries. Agree the transfer method, execution restrictions, retention and deletion expectations, and any confidentiality terms for the engagement. Do not send production credentials, private customer records or a live service token with an initial inquiry. Work should be limited to software you own or are authorized to have assessed.

How are price and turnaround determined?

There is no published fixed price for an unknown sample. Packaging format, protection mode, target environment, sample size and the required validation all affect effort. An individual scope and delivery schedule must be confirmed after inspection.

If your application was compiled with Nuitka, or includes Go or Rust components, review the native binary security audit service instead. The comparison guide explains why a readable source reconstruction and a native analysis report answer different questions.