Is Python Obfuscation Secure? I Tried to Break 5 Common Methods

Same script for every test. It has the two things people obfuscate to hide: a hard-coded credential and a license comparison.

API_KEY = "sk-live-4a91f7c2e8d0"

def check_license(key):
    if key == "PRO-2026-ZQX":
        return "unlocked"
    return "locked"

print(check_license("PRO-2026-ZQX"))

For each method I checked two things: did I recover byte-identical source, and are the secret strings (sk-live-4a91f7c2e8d0, PRO-2026-ZQX) sitting there in plaintext once I do?

The single most-recommended "obfuscation" is to base64-encode the source and exec it. It *looks* unreadable, which is the whole appeal:

import base64
exec(base64.b64decode('QVBJX0tFWSA9ICJzay1saXZlLTRhOTFmN2MyZThkMCIK...'))

But base64 isn't a cipher — there's no key. It's a reversible alphabet. The exact same call that runs it, decodes it. The reversal *is* one line:

>>> import base64
>>> print(base64.b64decode('QVBJX0tFWSA9...').decode())
API_KEY = "sk-live-4a91f7c2e8d0"

def check_license(key):
    if key == "PRO-2026-ZQX":
        ...

# byte-identical to the original — measured at 0.004 ms

The common upgrade is to zlib.compress first, then base64. Now the blob is shorter and looks even more random. Same fatal flaw: compression is not encryption, and the decompress key is, again, nothing.

import base64,zlib
exec(zlib.decompress(base64.b64decode('eJxzDPCM93aNVLBVUCrO1s3JLEvVNUm0...')))

>>> zlib.decompress(base64.b64decode(blob)).decode()
# byte-identical original source, measured at 0.010 ms

0.010 ms. You read the decompress call in the payload; you *are* the decompress call. Adding a second reversible transform just means pressing undo twice.

Some online obfuscators lean into the illusion by encoding over and over — base64 of base64 of base64, dozens of times. The output is a genuinely huge wall of noise, which *feels* like security. It isn't; it's the same undo, in a loop.

I encoded the source 50 times. The payload ballooned to 313,469,352 bytes — nearly 300 MB — to hide seven lines. Then I peeled it with a five-line loop that just keeps decoding until it sees Python:

data = payload
while True:
    try:
        data = base64.b64decode(data, validate=True)
    except Exception:
        break

# stripped all 50 layers in 50 rounds, ~3.5 s
# (almost all of that is just shuffling 300 MB of bytes)
# result: byte-identical original source, secrets in plaintext

This one *feels* more serious because the payload is real binary: a compiled code object, marshaled to bytes. No readable text in sight. But the code object is exactly what the interpreter runs, and Python ships the tools to read it in the standard library.

import marshal
exec(marshal.loads(b'\xe3\x00\x00\x00...'))   # 357 opaque bytes

Two standard-library calls undo it. marshal.loads gives back the code object; dis disassembles it. And every string constant is readable straight off the object — no decompiler needed:

>>> co = marshal.loads(blob)
>>> [c for c in walk_consts(co) if isinstance(c, str)]
'sk-live-4a91f7c2e8d0'
'PRO-2026-ZQX'
'unlocked'
'locked'

LOAD_CONST     2 ('PRO-2026-ZQX')
COMPARE_OP    88 (bool(==))
LOAD_CONST     1 ('unlocked')

Total time from opaque binary to "here is the key and here is the exact comparison": 0.417 ms. If you want full .py source rather than bytecode, a decompiler like pycdc rebuilds it — that's the same engine behind our free .pyc Decompiler. But as with a raw .pyc, I never needed it; the constants and the disassembly already told me everything. (More on why in Python `marshal` explained.)

The encoding tricks all share one flaw — they're reversible with no key — so let's test the other popular approach: an actual minifier that renames identifiers. I ran the script through python-minifier with global and local renaming turned on. This is the real, unedited output:

A='PRO-2026-ZQX'
C='sk-live-4a91f7c2e8d0'
def B(key):
	if key==A:return'unlocked'
	return'locked'
print(B(A))

Renaming did something real — check_license became B, API_KEY became C. But look at what it *didn't* touch: the API key is right there as 'sk-live-4a91f7c2e8d0'. The license code is right there as 'PRO-2026-ZQX'. The control flow is intact and trivially readable. No reversal step at all — I just *read* it.

*The 3.5 seconds for 50 layers is almost entirely the cost of moving a needlessly-created 300 MB file around — not any actual difficulty. Every method returned working, byte-accurate source, and every method left the API key and license string in the clear.

Python is compiled and run on the user's machine, so the code — in *some* form — has to be present for the interpreter to execute it. That means no obfuscation is truly unbreakable; a determined attacker with enough time can always recover behavior. Anyone who tells you otherwise is selling something.

But that's not the same as "obfuscation is pointless." The realistic goal isn't *impossible*, it's *not worth it* — raising the cost of reversing your code far above the value of doing so. The five methods above fail because they raise the cost by roughly zero. What actually moves the needle:

1. Encrypt the string literals, don't just encode the file. The reason every test above leaked its secrets is that the strings were never protected. Real obfuscation transforms literals so a text search and a dis dump turn up nothing usable.
2. Rename at the AST level, together with that encryption — so the disassembly is both anonymous *and* stripped of readable constants, not just short-named. Renaming alone (Method 5) is the trap.
3. Keep true secrets off the client entirely. An API key or license authority that lives on your server can't be extracted from a download, no matter how it's wrapped. Validate licenses server-side.
4. For the strongest bar, compile to a native module — a Cython .pyd/.so or a Nuitka binary — so there's no bytecode to marshal.loads or dis in the first place.

Our free Python Obfuscator does the first two — AST-level renaming *with* string encryption — so a decompile or disassembly of the result doesn't hand over your logic and keys the way every method on this page did. It's the difference between "looks scrambled" and "is actually scrambled." Pair it with server-side secrets and, for critical code, compiling to a binary, and you've moved from "cracked in 0.004 ms" to "not worth anyone's afternoon."