Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork165
Python decompiler for 3.7-3.8 Stripped down from uncompyle6 so we can refactor and start to fix up some long-standing problems
License
rocky/python-decompile3
Folders and files
| Name | Name | Last commit message | Last commit date | |
|---|---|---|---|---|
Repository files navigation
A native Python cross-version decompiler and fragment decompiler.A reworking ofuncompyle6.
I gave a talk on this atBlackHat Asia 2024.
decompyle3 translates Python bytecode back into equivalent Pythonsource code. It accepts bytecodes from Python version 3.7 on.
For decompilation of older Python bytecode, seeuncompyle6.
Uncompyle6 is awesome, but it has a fundamental problem in the wayit handles control flow. In the early days of Python, when there waslittle optimization and code was generated in a very template-oriented way, figuring out control flow structures could be done by simply looking at code patterns.
Over the years, more code optimization, specifically around handling jumps, has made it harder to support detecting control flow strictlyfrom code patterns. This was noticed as far back as Python 2.4 (2004), but since this is a difficult problem, so far it hasn't been tackledin a satisfactory way.
The initial attempt to fix to this problem was to add markers in theinstruction stream, initially this was aCOME_FROM instruction, andthen use that in pattern detection.
Over the years, I've extended that to be more specific, soCOME_FROM_LOOP andCOME_FROM_WITH were added. And I added checksat grammar-reduce time to make try to make sure jumps match withsupposedCOME_FROM targets.
However, all of this is complicated, not robust, has greatly slowed down deparsing and is not really tenable.
In this project, we began rewriting and refactoring the grammar.
However, even this isn't enough. Control flow needsto be addressed by using dominators and reverse-dominators, which thepython-control-flow project can give.
This I amfinally slowly doing in yet another non-public project. Itis a lot of work. Funding in the form of sponsorship while greatlyappreciated isn't commensurate with the amount of effort, andcurrently I have a full-time job. So it may take time before it isavailable publicly, if at all.
The code here can be run on Python versions 3.7 or 3.8. The bytecodefiles it can read have been tested on Python bytecodes from versions3.7 and 3.8.
You can install from PyPI using the namedecompyle3:
pip install decompyle3
To install from source code, this project uses setup.py, so it follows the standard Python routine:
$ pip install -e . # set up to run from source tree
or:
$ python setup.py install # may need sudo
A GNU Makefile is also provided, somake install (possibly as root orsudo) will do the steps above.
make check
A GNU makefile has been added to smooth over setting up and running the rightcommand, and running tests from fastest to slowest.
If you haveremake installed, you can see the list of all tasksincluding tests viaremake --tasks
Run
$ decompyle3 *compiled-python-file-pyc-or-pyo*
For usage help:
$ decompyle3 -h
If you want Python syntax verification of the correctness of thedecompilation process, add the--syntax-verify option. However sincePython syntax changes. You should use this option if the bytecode isthe right bytecode for the Python interpreter that will be checkingthe syntax.
You can also cross-compare the results with another Python decompilerlikeunpyc37 . Since they work differently, bugs here often aren't inthat, and vice versa.
There is an interesting class of these programs that is readilyavailable to give stronger verification: those programs that, when run, test themselves. Our test suite includes these.
And Python comes with another set of programs like this: its testsuite for the standard library. We have some code intest/stdlib tofacilitate this kind of checking too.
We support only released versions, not candidate versions. Note howeverthat the magic of a released version is usually the same as thelast candidate version prior to release.
We also don't handlePJOrion or otherwise obfuscated code. ForPJOrion try: PJOrionDeobfuscator to unscramble the bytecode to getvalid bytecode before trying this tool;pydecipher might help with that.
This program can't decompile Microsoft Windows EXE files created byPy2EXE, although we can probably decompile the code after you extractthe bytecode properly.Pydeinstaller may help with unpacking Pyinstaller bundlers.
Handling pathologically long lists of expressions or statements is slow. We don't handleCython or MicroPython, which don't use bytecode.
There are numerous bugs in decompilation. And that's true for everyother CPython decompilers I have encountered, even the ones thatclaimed to be "perfect" on some particular version like 2.4.
As Python progresses, decompilation also gets harder because thecompilation is more sophisticated and the language itself is moresophisticated. I suspect that attempts there will be fewer ad-hocattempts likeunpyc37 (which is based on a 3.3 decompiler) simplybecause it is harder to do so. The good news, at least from mystandpoint, is that I think I understand what's needed to address theproblems in a more robust way. But right now, until such time asthe project is better funded, I do not intend to make any serious effortto support Python versions 3.8 or 3.9, including bugs that might comein. I imagine at some point I may be interested in it.
You can easily find bugs by running the tests against the standardtest suite that Python uses to check itself. At any given time, there aredozens of known problems that are pretty well isolated and that couldbe solved if one were to put in the time to do so. The problem is thatthere aren't that many people who have been working on bug fixing.
You may run across a bug, that you want to report. Please do so. Butbe aware that it might not get my attention for a while. If yousponsor or support the project in some way, I'll prioritize yourissues above the queue of other things I might be doing instead. Inrare situations, I can do a hand decompilation of bytecode for a fee.However, this is expensive, usually beyond what most people are willingto spend.
- https://github.com/andrew-tavera/unpyc37/ : indirect fork ofhttps://code.google.com/archive/p/unpyc3/ The above projects use a different decompiling technique than what is used here. Instructions are walked. Some instructions use the stack to generate strings, while others don't. Because control flow isn't dealt with directly, it too suffers the same problems as the various
uncompyleanddecompyleprograms. - https://github.com/rocky/python-xdis : Cross Python version disassembler
- https://github.com/rocky/python-xasm : Cross Python version assembler
- https://github.com/rocky/python-decompile3/wiki : Wiki Documents that describe the code and aspects of it in more detail
About
Python decompiler for 3.7-3.8 Stripped down from uncompyle6 so we can refactor and start to fix up some long-standing problems
Topics
Resources
License
Uh oh!
There was an error while loading.Please reload this page.
Stars
Watchers
Forks
Sponsor this project
Uh oh!
There was an error while loading.Please reload this page.