rocky/python-uncompyle6Ein versionsübergreifender Python-Bytecode-Dekompiler
|buildstatus| |Pypi Installs| |Latest Version| |Supported Python Versions|
|packagestatus|
.. contents::
Ein nativer Python-kreuzversionsfähiger Decompiler und Fragment-Decompiler. Der Nachfolger von decompyle, uncompyle und uncompyle2.
Ich habe darüber einen Vortrag auf der BlackHat Asia 2024 <https://youtu.be/H-7ZNrpsV50?si=nOaixgYHr7RbILVS>_ gehalten.
uncompyle6 übersetzt Python-Bytecode zurück in äquivalenten Python-Quellcode. Es akzeptiert Bytecode von Python-Version 1.0 bis Version 3.8, was über 24 Jahre Python-Veröffentlichungen abdeckt. Wir beinhalten Dropbox' Python 2.5 Bytecode und einige PyPy-Bytecodes.
Ok, ich sage es: Diese Software ist erstaunlich. Sie ist mehr als ein gewöhnlicher, hackiger Decompiler. Mithilfe der compiler_-Technologie erstellt das Programm einen Parse-Baum des Programms aus den Instruktionen; Knoten auf den oberen Ebenen, die ein wenig so aussehen, wie das, was von einem Python-AST kommen könnte. So können wir wirklich klassifizieren und verstehen, was in Abschnitten von Python-Bytecode vor sich geht.
Darauf aufbauend ist ein weiterer Unterschied zu anderen CPython-Bytecode-Decompilern, dass er nur Fragmente von Quellcode deparsen und Quellcode-Informationen um einen bestimmten Bytecode-Offset herum liefern kann.
Ich verwende die Baumfragmente, um Codefragmente zur Laufzeit in meinen trepan_-Debuggers_ zu deparsen. Dazu werden Bytecode-Offsets aufgezeichnet und mit Fragmenten des Quellcodes verknüpft. Dieser Zweck ist zwar mit der ursprünglichen Absicht vereinbar, aber dennoch etwas anders. Siehe this_ für weitere Informationen.
Python-Fragment-Deparsing, gegeben einen Instruktions-Offset, ist nützlich für die Anzeige von Stack-Traces und kann in jedes Programm integriert werden, das einen Ort detaillierter als nur eine Zeilennummer zur Laufzeit anzeigen möchte. Dieser Code kann auch verwendet werden, wenn keine Quellcode-Informationen existieren und nur Bytecode vorhanden ist. Auch hier nutzen meine Debugger dies.
Es gab (und gibt immer noch) mehrere Forks von decompyle, uncompyle, uncompyle2, uncompyle3. Viele von ihnen stammen im Grunde von derselben Codebasis, und (fast?) alle werden nicht mehr aktiv gepflegt. Einer war wirklich gut im Dekompilieren von Python 1.5-2.3, ein anderer ist wirklich gut für Python 2.7, aber nur das. Ein anderer handhabt nur Python 3.2; ein weiterer hat das gepatcht und handhabt nur 3.3. Du verstehst, worauf ich hinauswill. Dieser Code bringt all diese Forks zusammen und geht voran. Es gibt eine ernsthafte Refaktorisierung und Bereinigung in dieser Codebasis im Vergleich zu diesen alten Forks. Noch experimentellere Refaktorisierung findet in decompyle3_ statt.
Dieser Code macht nachweislich das Beste beim Dekompilieren von Python über alle Python-Versionen hinweg. Und selbst wenn es ein anderes Projekt gibt, das nur Dekompilierung für eine Teilmenge von Python-Versionen bietet, schneiden wir im Allgemeinen auch für diese nachweislich besser ab.
Wie können wir das feststellen? Indem wir Python-Bytecode nehmen, der mit dieser Python-Version ausgeliefert wird, und ihn dekompilieren. Unter den erfolgreich dekompilierten können wir dann sicherstellen, dass die resultierenden Programme syntaktisch korrekt sind, indem wir den Python-Interpreter für diese Bytecode-Version ausführen. Schließlich können wir in Fällen, in denen das Programm einen Selbsttest hat, die Prüfung am dekompilierten Code durchführen.
Wir verwenden automatisierte Prozesse, um Fehler zu finden. In den Issue-Trackern anderer Decompiler werden Sie mehrere Fehler finden, die wir im Laufe der Zeit gefunden haben. Sehr wenige davon sind in den anderen Decompilern behoben.
Der Code im Git-Repository kann von Python 2.4 bis zur neuesten Python-Version ausgeführt werden, mit Ausnahme von Python 3.0 bis 3.2. Freiwillige sind willkommen, diese Mängel zu beheben, falls der Wunsch dazu besteht.
Die Art und Weise, wie dies geschieht, ist die Aufteilung aufeinanderfolgender Python-Versionen in Git-Zweige:
master Python 3.11 und höher (verwendet poetry-Installation und neuere Python-Idiome) python-3.6-to-3.10 Python 3.6 bis 3.10 (verwendet neuere f-Strings, modernere Idiome und modernere Typannotationen) python-3.3-to-3.5 Python 3.3 bis 3.5 (Generisches Python 3) python-3.0-to-3.2 Python 3.0 bis 3.2 (Frühes Python 3; 3.0 war in einigen Bereichen näher an Python 2.6 als an Python 2.7) python-2.4-to-2.7 Python 2.4 bis 2.7 (Generisches Python 2)
PyPy ab Version 2.4 funktioniert ebenfalls.
Die Bytecode-Dateien, die es lesen kann, wurden auf Python-Bytecodes der Versionen 1.4, 2.1-2.7, 3.0-3.8 und späteren PyPy-Versionen getestet.
Für neuere Python-Veröffentlichungen (Python 3.11+) können Sie von PyPI mit dem Namen uncompyle6 installieren::
pip install uncompyle6
Für Python-Veröffentlichungen vor 3.11 installieren Sie nicht von PyPI, sondern verwenden Sie eine Datei aus dem GitHub Releases section. Älteres Python verwendete früher easy_install <https://python101.pythonlibrary.org/chapter29_pip.html#using-easy-install>_. Dies wird jedoch nicht mehr auf PyPi oder neueren Python-Versionen unterstützt. Und umgekehrt werden poetry noch pip (die neueren Methoden) auf älteren Pythons nicht unterstützt.
Wenn die Python-Version, auf der Sie uncompyle6 ausführen, zwischen Python 2.4 und 2.7 liegt, verwenden Sie ein Tarball namens uncompyle6_24-x.y.z.tar.gz.
Wenn die Python-Version, auf der Sie uncompyle6 ausführen, zwischen Python 3.0 und 3.2 liegt, verwenden Sie ein Tarball namens uncompyle6_30-x.y.z.tar.gz.
Wenn die Python-Version, auf der Sie uncompyle6 ausführen, zwischen Python 3.3 und 3.5 liegt, verwenden Sie ein Tarball namens uncompyle6_33-x.y.z.tar.gz.
Wenn die Python-Version, auf der Sie uncompyle6 ausführen, zwischen Python 3.6 und 3.11 liegt, verwenden Sie ein Tarball namens uncompyle6_36-x.y.z.tar.gz.
Wenn die Python-Version, auf der Sie uncompyle6 ausführen, 3.11 oder höher ist, verwenden Sie ein Tarball namens uncompyle6-x.y.z.tar.gz.
Sie können auch Eggs oder Wheels mit derselben Versionsbezeichnung ausprobieren, z.B. uncompyle6-x.y.z-py39-none-any.whl für eine Python 3.9-Installation. *Beachten Sie jedoch, dass die Version ohne die Bezeichnung Python 3.11 oder höher bedeutet.
Ebenso funktioniert ein Tarball ohne _xx nur ab Python 3.11 oder höher.
Begründung für die Verwendung von Git-Zweigen +++++++++++++++++++++++++++++++++++++++++++++
Es ist derzeit unmöglich (wenn nicht unpraktisch), einen Python-Quellcode dieser Komplexität und mit so vielen Funktionen zu haben, der sowohl Python 2.7 als auch Python 3.13+ ausführen kann. Die Sprachen haben sich so weit auseinanderentwickelt, und das Paketieren ist grundverschieden. Tatsächlich ist die Verpackungspraxis für Python 3.11+ inkompatibel mit Python 2.7 (und davor zurück bis Python 2.4), das "easy_install" bevorzugte.
Installation aus dem Quelltext ++++++++++++++++++++++++++++++
Um aus dem Quellcode zu installieren, stellen Sie sicher, dass Sie den richtigen Git-Zweig haben. Siehe den Abschnitt Anforderungen für die Git-Zweignamen.
Nach dem Setzen des richtigen Zweigs::
$ pip install -e . # set up to run from source tree
Ein GNU Makefile wird ebenfalls bereitgestellt, so dass :code:make install (möglicherweise als root oder sudo) die obigen Schritte ausführt.
::
make check
Ein GNU-Makefile wurde hinzugefügt, um das Einrichten und Ausführen des richtigen Befehls und das Ausführen von Tests vom schnellsten zum langsamsten zu erleichtern.
Wenn Sie remake_ installiert haben, können Sie die Liste aller Aufgaben einschließlich Tests über :code:remake --tasks sehen.
Führen Sie aus:
::
$ uncompyle6 compiled-python-file-pyc-or-pyo