rocky/python-uncompyle6Un decompilatore di bytecode Python cross-version
|buildstatus| |Pypi Installs| |Latest Version| |Supported Python Versions|
|packagestatus|
.. contents::
Un decompilatore Python nativo cross-version e decompilatore di frammenti. Il successore di decompyle, uncompyle e uncompyle2.
Ho tenuto un intervento su questo a BlackHat Asia 2024 <https://youtu.be/H-7ZNrpsV50?si=nOaixgYHr7RbILVS>_.
uncompyle6 traduce il bytecode Python in codice sorgente Python equivalente. Accetta bytecode dalla versione 1.0 alla versione 3.8 di Python, coprendo oltre 24 anni di rilasci Python. Includiamo il bytecode Python 2.5 di Dropbox e alcuni bytecode PyPy.
Ok, lo dico: questo software è fantastico. È più di un normale decompilatore hackerato. Utilizzando la tecnologia compiler_, il programma crea un albero sintattico del programma a partire dalle istruzioni; nodi ai livelli superiori che assomigliano un po' a ciò che potrebbe provenire da un AST Python. Quindi possiamo davvero classificare e capire cosa sta succedendo in sezioni di bytecode Python.
Basandosi su questo, un'altra cosa che rende questo diverso da altri decompilatori di bytecode CPython è la capacità di deparsare solo frammenti di codice sorgente e fornire informazioni sul codice sorgente attorno a un dato offset del bytecode.
Uso i frammenti di albero per deparsare frammenti di codice in esecuzione all'interno dei miei trepan_ debuggers_. Per questo, gli offset dei bytecode vengono registrati e associati a frammenti del codice sorgente. Questo scopo, sebbene compatibile con l'intenzione originale, è comunque un po' diverso. Vedi this_ per maggiori informazioni.
La deparsazione di frammenti Python, dato un offset di istruzione, è utile per mostrare stack trace e può essere incorporata in qualsiasi programma che voglia mostrare una posizione in modo più dettagliato rispetto a un semplice numero di riga a runtime. Questo codice può anche essere usato quando non esistono informazioni sul codice sorgente e c'è solo bytecode. Ancora una volta, i miei debugger ne fanno uso.
C'erano (e ci sono ancora) diversi fork di decompyle, uncompyle, uncompyle2, uncompyle3. Molti di essi provengono fondamentalmente dalla stessa base di codice, e (quasi?) tutti non sono più attivamente mantenuti. Uno era molto bravo a decompilare Python 1.5-2.3, un altro è molto bravo con Python 2.7, ma solo quello. Un altro gestisce solo Python 3.2; un altro l'ha patchato e gestiva solo 3.3. Capisci il concetto. Questo codice unisce tutti questi fork e va avanti. C'è un serio refactoring e pulizia in questa base di codice rispetto a quei vecchi fork. Un refactoring ancora più sperimentale è in corso in decompyle3_.
Questo fa dimostrabilmente il miglior lavoro nel decompilare Python su tutte le versioni di Python. E anche quando c'è un altro progetto che fornisce decompilazione solo per un sottoinsieme di versioni Python, generalmente facciamo dimostrabilmente meglio anche per quelle.
Come possiamo dirlo? Prendendo il bytecode Python distribuito con quella versione di Python e decompilandolo. Tra quelli che decompilano con successo, possiamo poi assicurarci che i programmi risultanti siano sintatticamente corretti eseguendo l'interprete Python per quella versione di bytecode. Infine, nei casi in cui il programma ha un test per se stesso, possiamo eseguire il controllo sul codice decompilato.
Usiamo processi automatizzati per trovare bug. Nei tracker dei problemi di altri decompilatori, troverai diversi bug che abbiamo scoperto lungo la strada. Molti di essi non sono stati corretti negli altri decompilatori.
Il codice nel repository git può essere eseguito da Python 2.4 fino all'ultima versione di Python, eccetto Python 3.0 fino a 3.2. I volontari sono benvenuti per affrontare queste carenze se c'è il desiderio di farlo.
Il modo in cui lo fa, comunque, è segregando versioni consecutive di Python in rami git:
master Python 3.11 e superiori (usa installazione poetry e idiomi Python più recenti) python-3.6-to-3.10 Python 3.6 fino a 3.10 (usa f-string più recenti, idiomi più moderni e annotazioni di tipo più moderne) python-3.3-to-3.5 Python 3.3 fino a 3.5 (Python 3 generico) python-3.0-to-3.2 Python 3.0 fino a 3.2 (Python 3 iniziale; 3.0 era in alcune aree più vicino a Python 2.6 che a Python 2.7) python-2.4-to-2.7 Python 2.4 fino a 2.7 (Python 2 generico)
PyPy dalla versione 2.4 in su funziona anche.
I file di bytecode che può leggere sono stati testati su bytecode Python delle versioni 1.4, 2.1-2.7, 3.0-3.8 e successive versioni PyPy.
Per i rilasci recenti di Python (Python 3.11+), puoi installare da PyPI usando il nome uncompyle6::
pip install uncompyle6
Per i rilasci di Python precedenti alla 3.11, non installare usando PyPI, ma installa usando un file nella sezione Rilasci GitHub. Il vecchio Python usava easy_install <https://python101.pythonlibrary.org/chapter29_pip.html#using-easy-install>_. Ma questo non è più supportato su PyPi o versioni più recenti di Python. E viceversa, poetry né pip (i modi più recenti) non sono supportati su Python più vecchi.
Se la versione di Python su cui stai eseguendo uncompyle6 è tra Python 2.4 e 2.7, usa un tarball chiamato uncompyle6_24-x.y.z.tar.gz.
Se la versione di Python su cui stai eseguendo uncompyle6 è tra Python 3.0 e 3.2, usa un tarball chiamato uncompyle6_30-x.y.z.tar.gz.
Se la versione di Python su cui stai eseguendo uncompyle6 è tra Python 3.3 e 3.5, usa un tarball chiamato uncompyle6_33-x.y.z.tar.gz.
Se la versione di Python su cui stai eseguendo uncompyle6 è tra Python 3.6 e 3.11, usa un tarball chiamato uncompyle6_36-x.y.z.tar.gz.
Se la versione di Python su cui stai eseguendo uncompyle6 è 3.11 o successiva, usa un tarball chiamato uncompyle6-x.y.z.tar.gz.
Puoi anche provare egg o wheel che hanno la stessa designazione di versione, ad esempio uncompyle6-x.y.z-py39-none-any.whl per un'installazione Python 3.9. Tuttavia, nota che la versione senza designazione significa Python 3.11 o superiore.
Allo stesso modo, un tarball senza _xx funziona solo da Python 3.11 o superiore.
Motivazione per l'uso dei rami Git +++++++++++++++++++++++++++++++++++
Al momento è impossibile (se non impraticabile) avere un unico codice sorgente Python di questa complessità e con così tante funzionalità che possa funzionare sia su Python 2.7 che su Python 3.13+. I linguaggi si sono allontanati così tanto, e il packaging è completamente diverso. Infatti, la pratica di packaging per Python 3.11+ è incompatibile con Python 2.7 (e prima fino a Python 2.4), che preferiva "easy_install".
Installazione dal codice sorgente ++++++++++++++++++++++++++++++++++
Per installare dal codice sorgente, assicurati di avere il ramo Git giusto. Vedi la sezione Requisiti per i nomi dei rami Git.
Dopo aver impostato il ramo giusto::
$ pip install -e . # configura per l'esecuzione dall'albero dei sorgenti
È anche fornito un GNU Makefile, quindi :code:make install (possibilmente come root o sudo) eseguirà i passaggi sopra.
::
make check
Un makefile GNU è stato aggiunto per agevolare la configurazione e l'esecuzione del comando giusto, e per eseguire i test dal più veloce al più lento.
Se hai remake_ installato, puoi vedere l'elenco di tutte le attività inclusi i test tramite :code:remake --tasks
Esegui
::
$ uncompyle6 file-python-compilato-pyc-o-pyo
Per l'aiuto sull'uso:
::
$ uncompyle6 -h