pycdc (Decompyle++) Guide: Install It, Use It, and What It Really Recovers

pycdc — short for Python C++ Decompiler, also called Decompyle++ — is an open-source project by Michael Hansen (zrax) on GitHub, licensed under the GPL-3.0. It reads the code objects inside a .pyc and rebuilds Python statements from the bytecode. It isn't on PyPI: there's no pip install pycdc, you compile it yourself.

The build gives you two programs. `pycdc` is the decompiler: it prints recovered source. `pycdas` is a disassembler: it prints every code object, its constants, names and raw instructions. When pycdc gets something wrong, pycdas is how you check what the bytecode really says.

I built it on Debian 12 (bookworm) from a clean container. You need Git, CMake and a C++ compiler; nothing else. On a 4-core machine the whole build took 63 seconds.

sudo apt install git cmake g++
git clone https://github.com/zrax/pycdc.git
cd pycdc
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j4
# -> build/pycdc and build/pycdas

On macOS the same CMake commands apply after installing CMake (brew install cmake) and Xcode's command-line tools. On Windows, install CMake and Visual Studio's C++ Build Tools, run the same two cmake commands, and you get pycdc.exe and pycdas.exe under build\Release. I verified the Linux build above; I didn't re-test the macOS and Windows paths for this article.

./build/pycdc module.pyc > recovered.py
./build/pycdas module.pyc > module.dis.txt

pycdc writes the source to standard output and its problems to standard error — so don't redirect stderr away. Lines like Unsupported opcode: … tell you exactly where the output stops being trustworthy. Here is the start of real pycdas output for one of my test files:

s-3.12.pyc (Python 3.12)
[Code]
    File Name: simple.py
    Object Name: <module>
    Qualified Name: <module>
    Arg Count: 0
    Pos Only Arg Count: 0
    KW Only Arg Count: 0
    Stack Size: 2
    Flags: 0x00000000

The first script is deliberately simple: a hard-coded key, a set of license codes and a while loop that retries — the kind of thing people ship as a .pyc hoping it hides the logic.

API_KEY = "sk-demo-7c1f2a"
VALID = {"PRO-2026-XYZ", "TRIAL-7788"}


def check(code, attempts=3):
    tries = 0
    while tries < attempts:
        if code in VALID:
            return "ok"
        tries += 1
        code = code.upper()
    return "denied"


def main():
    for code in ["pro-2026-xyz", "nope"]:
        print(code, "->", check(code))
    print("key suffix:", API_KEY[-4:])


if __name__ == "__main__":
    main()

The second is a realistic 60-line module: a @dataclass, a @contextmanager, JSON parsing with try/except, a list and a dict comprehension, a for … else, a sorted(key=lambda …) and formatted f-strings. Every recovered file was run on the same CPython version as the original and its output compared line by line.

This is what pycdc returned for the 3.8 file — note there's no warning anywhere, yet the function is broken:

API_KEY = 'sk-demo-7c1f2a'
VALID = {
    'PRO-2026-XYZ',
    'TRIAL-7788'}

def check(code, attempts = (3,)):
    tries = 0
    if tries < attempts:
        if code in VALID:
            return 'ok'
        None += 1
        code = code.upper()
        continue
    return 'denied'


def main():
    for code in ('pro-2026-xyz', 'nope'):
        print(code, '->', check(code))
    print('key suffix:', API_KEY[-4:])

if __name__ == '__main__':
    main()

None of the seven outputs ran. But pycdc isn't useless here — on 3.11 it correctly recovered the constants (TAX = 0.18 and the full JSON string), the function signatures, the json.loads call, the for … else in first_over, sorted(items, key=lambda i: -i.total()) and even the formatted f-string {it.name:<8}{it.total():>8.2f}. What it lost were the dataclass, the generator-based context manager and the dict comprehension, which came out as 'tags:'(<dictcomp>, sorted(by_tag.items())()).

That's the honest summary of pycdc today: very good at showing you what a file contains, unreliable at giving you a file that runs. For reading secrets and logic out of a .pyc, that's often enough — and it's a good reminder that shipping .pyc hides almost nothing.

The pure-Python decompilers are often recommended as the more accurate option for older bytecode, so I ran both (version 3.9.3, on Python 3.8) against the same files.

So on modern bytecode there isn't really a contest: uncompyle6 and decompyle3 stop at 3.8, and even there they stumbled on these files. pycdc is the only one of the three that reads 3.9–3.13 at all.

• `Bad MAGIC!` — the first four bytes of the file are a magic number pycdc doesn't know. Either the .pyc is from a Python version it doesn't support yet (3.14 today) or it isn't a plain .pyc at all (encrypted or packed). See how to read a .pyc's magic number.
• `Unsupported opcode: NAME (n)` — a bytecode instruction pycdc can't translate yet. Everything around it is suspect; check that area with pycdas.
• `Unsupported Node type: 12` / `<NODE:12>` in the output — a construct it couldn't rebuild. In my tests this was the @dataclass class.
• `# WARNING: Decompyle incomplete` inside the source — pycdc gave up on that block and left a stub (often just pass).
• `PycBuffer::getByte(): Unexpected end of stream` — it lost track of the bytecode and read past the end; the output is truncated.
• No message at all — not proof the output is right. Three of my seven simple-script outputs were wrong without any warning.

• Auditing what a `.pyc` or a PyInstaller build exposes — strings, names, imports and the rough logic come through well.
• Quick triage on 3.8–3.13 files before spending time on a deeper analysis.
• Pairing with `pycdas` or `dis` to verify the exact logic of the parts that matter.

If you want readable source without building anything — including Python 3.14 files — use our free online .pyc Decompiler. And if you're on the other side, trying to protect your own code, the results above are the argument: a .pyc gives away its strings and structure in seconds, so obfuscate the source before you ship it.