Python cross-version byte-code deparser
A native Python cross-version Decompiler and Fragment Decompiler. Follows in the tradition of decompyle, uncompyle, and uncompyle2.
uncompyle6 translates Python bytecode back into equivalent Python source code. It accepts bytecodes from Python version 2.1 to 3.6 or so, including PyPy bytecode and Dropbox’s Python 2.5 bytecode.
There were a number of decompyle, uncompile, uncompyle2, uncompyle3 forks around. All of them came basically from the same code base, and almost all of them no were no longer actively maintained. Only one handled Python 3, and even there, only 3.2 or 3.3 depending on which code is used. This code pulls these together and moves forward. It also addresses a number of open issues in the previous forks.
What makes this different from other CPython bytecode decompilers?: its ability to deparse just fragments and give source-code information around a given bytecode offset.
I use this to deparse fragments of code inside my trepan debuggers. For that, I need to record text fragments for all bytecode offsets (of interest). This purpose although largely compatible with the original intention is yet a little bit different. See this for more information.
The idea of Python fragment deparsing given an instruction offset can be used in showing stack traces or any program that wants to show a location in more detail than just a line number. It can be also used when source-code information does not exist and there is just bytecode information.
This project requires Python 2.6 or later, PyPy 3-2.4, or PyPy-5.0.1. The bytecode files it can read has been tested on Python bytecodes from versions 2.1-2.7, and 3.2-3.6 and the above-mentioned PyPy versions.
This uses setup.py, so it follows the standard Python routine:
pip install -r requirements.txt pip install -r requirements-dev.txt python setup.py install # may need sudo # or if you have pyenv: python setup.py develop
A GNU makefile is also provided so
make install (possibly as root or
sudo) will do the steps above.
A GNU makefile has been added to smooth over setting running the right command, and running tests from fastest to slowest.
If you have remake installed, you can see the list of all tasks
including tests via
$ uncompyle6 *compiled-python-file-pyc-or-pyo*
For usage help:
$ uncompyle6 -h
The biggest known and possibly fixable (but hard) problem has to do with handling control flow. In some cases we can detect an erroneous decompilation and report that.
About 90% of the decompilation of Python standard library packages in Python 2.7.12 verifies correctly. Over 99% of Python 2.7 and 3.3-3.5 “weakly” verify. Python 2.6 drops down to 96% weakly verifying. Other versions drop off in quality too.
Verification is the process of decompiling bytecode, compiling with a Python for that bytecode version, and then comparing the bytecode produced by the decompiled/compiled program. Some allowance is made for inessential differences. But other semantically equivalent differences are not caught. For example if x: foo() is equivalent to x and foo() and decompilation may turn one into the other. Weak Verification on the other hand doesn’t check bytecode for equivalence but does check to see if the resulting decompiled source is a valid Python program by running the Python interpreter. Because the Python language has changed so much, for best results you should use the same Python Version in checking as used in the bytecode.
Later distributions average about 200 files. There is some work to do on the lower end Python versions which is more difficult for us to handle since we don’t have a Python interpreter for versions 1.5, 1.6, and 2.0.
Python 3.0 support is weak; Python 3.5 largely works, but still has some bugs in it. Python 3.6 changes things drastically by using word codes rather than byte codes. That has been addressed, but then it also changes function call opcodes and its semantics.
Currently not all Python magic numbers are supported. Specifically in some versions of Python, notably Python 3.6, the magic number has changes several times within a version. We support only the released magic. There are also customized Python interpreters, notably Dropbox, which use their own magic and encrypt bytcode. With the exception of the Dropbox’s old Python 2.5 interpreter this kind of thing is not handled.
There is lots to do, so please dig in and help.
- https://github.com/zrax/pycdc : supports all versions of Python and is written in C++
- https://code.google.com/archive/p/unpyc3/ : supports Python 3.2 only. The above projects use a different decompiling technique what is used here.
- https://github.com/figment/unpyc3/ : fork of above, but supports Python 3.3 only. Include some fixes like supporting function annotations
- The HISTORY file.
Release history Release notifications | RSS feed
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
|Filename, size||File type||Python version||Upload date||Hashes|
|Filename, size uncompyle6-2.9.6-py2.6.egg (315.5 kB)||File type Egg||Python version 2.6||Upload date||Hashes View|
|Filename, size uncompyle6-2.9.6-py2.py3-none-any.whl (146.9 kB)||File type Wheel||Python version 3.4||Upload date||Hashes View|
|Filename, size uncompyle6-2.9.6-py3.3.egg (325.0 kB)||File type Egg||Python version 3.3||Upload date||Hashes View|
|Filename, size uncompyle6-2.9.6-py3.4.egg (321.2 kB)||File type Egg||Python version 3.4||Upload date||Hashes View|
|Filename, size uncompyle6-2.9.6-py3.5.egg (319.7 kB)||File type Egg||Python version 3.5||Upload date||Hashes View|
|Filename, size uncompyle6-2.9.6.tar.gz (866.0 kB)||File type Source||Python version None||Upload date||Hashes View|
Hashes for uncompyle6-2.9.6-py2.py3-none-any.whl