|packagestatus|

.. contents::

uncompyle6

Нативный кросc-версионный декомпилятор и декомпилятор фрагментов Python. Преемник decompyle, uncompyle и uncompyle2.

Я выступал с докладом об этом на BlackHat Asia 2024 <https://youtu.be/H-7ZNrpsV50?si=nOaixgYHr7RbILVS>_.

Введение

uncompyle6 преобразует байткод Python обратно в эквивалентный исходный код Python. Он принимает байткоды от Python версии 1.0 до версии 3.8, охватывая более 24 лет релизов Python. Мы включаем байткод Dropbox Python 2.5 и некоторые байткоды PyPy.

Зачем это?

Хорошо, я скажу: это программное обеспечение потрясающее. Это больше, чем обычный хакерский декомпилятор. Используя технологию compiler_, программа создает дерево разбора программы из инструкций; узлы на верхних уровнях выглядят немного похожими на то, что может получиться из Python AST. Так что мы действительно можем классифицировать и понимать, что происходит в секциях байткода Python.

Основываясь на этом, другая вещь, которая отличает это от других декомпиляторов байткода CPython, — это возможность депарсировать только фрагменты исходного кода и предоставлять информацию об исходном коде вокруг заданного смещения байткода.

Я использую фрагменты дерева для депарсинга фрагментов кода во время выполнения внутри моих trepan_ отладчиков_. Для этой цели записываются смещения байткода и связываются с фрагментами исходного кода. Эта цель, хотя и совместима с первоначальным замыслом, всё же немного отличается. См. this_ для получения дополнительной информации.

Депарсинг фрагментов Python, заданный смещением инструкции, полезен при показе стек-трейсов и может быть встроен в любую программу, которая хочет отображать местоположение более подробно, чем просто номер строки во время выполнения. Этот код также может использоваться, когда информация об исходном коде не существует, а есть только байткод. Опять же, мои отладчики используют это.

Существовало (и до сих пор существует) несколько форков decompyle, uncompyle, uncompyle2, uncompyle3. Многие из них происходят в основном из одной кодовой базы, и (почти?) все они больше не поддерживаются активно. Один был действительно хорош в декомпиляции Python 1.5-2.3, другой действительно хорош в Python 2.7, но только этом. Другой обрабатывает Python 3.2 только; другой пропатчил его и обрабатывал только 3.3. Вы поняли идею. Этот код объединяет все эти форки вместе и движется вперед. В этой кодовой базе проведен серьезный рефакторинг и очистка по сравнению с теми старыми форками. Еще более экспериментальный рефакторинг происходит в decompyle3_.

Этот демонстративно показывает лучшие результаты при декомпиляции Python во всех версиях Python. И даже когда есть другой проект, который предоставляет декомпиляцию только для подмножества версий Python, мы обычно демонстративно лучше и для них.

Как мы можем это сказать? Взяв байткод Python, который поставляется с этой версией Python, и декомпилируя его. Среди тех, кто успешно декомпилирует, мы можем затем убедиться, что результирующие программы синтаксически корректны, запустив интерпретатор Python для этой версии байткода. Наконец, в случаях, когда программа имеет тест для самой себя, мы можем запустить проверку на декомпилированном коде.

Мы используем автоматизированные процессы для поиска ошибок. В трекерах проблем для других декомпиляторов вы найдете несколько ошибок, которые мы обнаружили по пути. Очень немногие из них исправлены в других декомпиляторах.

Требования

Код в git-репозитории может быть запущен от Python 2.4 до последней версии Python, за исключением Python 3.0 до 3.2. Добровольцы приветствуются для устранения этих недостатков, если есть желание это сделать.

Однако способ, которым это делается, заключается в разделении последовательных версий Python на ветки git:

master Python 3.11 и выше (использует установку через poetry и более новые идиомы Python) python-3.6-to-3.10 Python 3.6 до 3.10 (использует более новые f-строки, более современные идиомы и более современные аннотации типов) python-3.3-to-3.5 Python 3.3 до 3.5 (общий Python 3) python-3.0-to-3.2 Python 3.0 до 3.2 (ранний Python 3; 3.0 в некоторых областях был ближе к Python 2.6, чем к Python 2.7) python-2.4-to-2.7 Python 2.4 до 2.7 (общий Python 2)

PyPy, начиная с версии 2.4, также работает.

Файлы байткода, которые он может читать, были протестированы на байткодах Python версий 1.4, 2.1-2.7, 3.0-3.8 и более поздних версиях PyPy.

Установка

Для последних релизов Python (Python 3.11+) вы можете установить из PyPI, используя имя uncompyle6::

pip install uncompyle6

Для релизов Python до 3.11 не устанавливайте через PyPI, а вместо этого установите, используя файл из секции релизов GitHub. Для более старых Python использовался easy_install <https://python101.pythonlibrary.org/chapter29_pip.html#using-easy-install>_. Но это больше не поддерживается на PyPi или более новых версиях Python. И наоборот, poetry и pip (новые способы) не поддерживаются на старых Python.

Если версия Python, на которой вы запускаете uncompyle6, находится между Python 2.4 и 2.7, используйте tarball с именем uncompyle6_24-x.y.z.tar.gz.

Если версия Python, на которой вы запускаете uncompyle6, находится между Python 3.0 и 3.2, используйте tarball с именем uncompyle6_30-x.y.z.tar.gz.

Если версия Python, на которой вы запускаете uncompyle6, находится между Python 3.3 и 3.5, используйте tarball с именем uncompyle6_33-x.y.z.tar.gz.

Если версия Python, на которой вы запускаете uncompyle6, находится между Python 3.6 и 3.11, используйте tarball с именем uncompyle6_36-x.y.z.tar.gz.

Если версия Python, на которой вы запускаете uncompyle6, 3.11 или новее, используйте tarball с именем uncompyle6-x.y.z.tar.gz.

Вы также можете попробовать eggs или wheels, которые имеют то же обозначение версии, например, uncompyle6-x.y.z-py39-none-any.whl для установки Python 3.9. Однако обратите внимание, что версия без обозначения означает Python 3.11 или более новую.

Аналогично, tarball без _xx работает только с Python 3.11 или новее.

Обоснование использования веток Git ++++++++++++++++++++++++++++++++

В настоящее время невозможно (если не непрактично) иметь один исходный код Python такой сложности и с таким количеством возможностей, который может работать как на Python 2.7, так и на Python 3.13+. Языки разошлись настолько, и упаковка сильно различается. Фактически, практика упаковки для Python 3.11+ несовместима с Python 2.7 (и более ранними версиями, начиная с Python 2.4), который предпочитал "easy_install".

Установка из исходного текста ++++++++++++++++++++++++++++++

Чтобы установить из исходного кода, убедитесь, что у вас правильная ветка Git. См. раздел Требования для названий веток Git.

После установки правильной ветки::

$ pip install -e .  # настроить для запуска из дерева исходников

Также предоставляется GNU Makefile, так что :code:make install (возможно, от root или через sudo) выполнит указанные выше шаги.

Запуск тестов

make check

GNU makefile был добавлен, чтобы упростить настройку и запуск правильной команды, а также запуск тестов от самых быстрых до самых медленных.

Если у вас установлен remake_, вы можете увидеть список всех задач, включая тесты, через :code:remake --tasks

Использование

Запустите

$ uncompyle6 сжатый-python-файл-pyc-или-pyo

Для справки по использованию:

$ uncompyle6 -h

Верификация

В старых версиях Python было возможно проверить байткод, декомпилировав его, а затем скомпилировав с помощью интерпретатора Python для этой версии байткода. Сделав это, полученный байткод можно было сравнить с оригинальным. Однако, по мере улучшения генерации кода в Python, это стало невозможным.

Если вы хотите синтаксическую проверку корректности процесса декомпиляции, добавьте опцию :code:--syntax-verify. Однако, поскольку синтаксис Python меняется. Вам следует использовать эту опцию, если байткод соответствует версии Python интерпретатора, который будет проверять синтаксис.

Вы также можете сравнить результаты с другой версией uncompyle6, так как иногда возникают регрессии при декомпиляции определенного байткода, в то время как общее качество улучшается.

Для Python 3.7 и 3.8 код в decompyle3_ обычно лучше.

Или попробуйте другой конкретный декомпилятор Python, например uncompyle2_, unpyc37_, или pycdc_. Поскольку последние два работают по-другому, ошибки здесь часто отсутствуют в них, и наоборот.

Существует интересный класс этих программ, который легко доступен для более сильной проверки: те программы, которые при запуске тестируют сами себя. Наш набор тестов включает их.

И Python поставляется с другим набором таких программ: его тестовый набор для стандартной библиотеки. У нас есть некоторый код в :code:test/stdlib для облегчения такой проверки.

Известные ошибки/ограничения

Самая большая известная и, возможно, исправимая (но сложная) проблема связана с обработкой потока управления. (У Python, вероятно, самый разнообразный и запутанный набор составных операторов, который я когда-либо видел; есть предложения "else" в циклах и блоках try, о которых, подозреваю, многие программисты не знают.)

Все декомпиляторы Python, которые я видел, имеют проблемы с декомпиляцией потока управления Python. В некоторых случаях мы можем обнаружить ошибочную декомпиляцию и сообщить об этом.

Поддержка Python довольно хороша для Python 2

На нижнем уровне версий Python декомпиляция кажется довольно хорошей, хотя у нас нет автоматического тестирования для дистрибутивных тестов Python. Кроме того, у нас нет интерпретатора Python для версий 1.6 и 2.0.

В серии Python 3 поддержка Python наиболее сильна для 3.4 или 3.3 и снижается по мере удаления от этих версий. Python 3.0 странен тем, что в некоторых отношениях больше напоминает 2.6, чем 3.1 или 2.7. Python 3.6 кардинально меняет ситуацию, используя word-коды вместо byte-кодов. В результате поле смещения перехода в аргументе инструкции перехода было уменьшено. Это делает инструкции :code:EXTENDED_ARG теперь более распространенными в инструкциях перехода; ранее они были редки. Возможно, чтобы компенсировать дополнительные инструкции :code:EXTENDED_ARG, была добавлена дополнительная оптимизация переходов. Так что в целом обработка потока управления ad hoc методами, как это делается сейчас, становится хуже.

Между Python 3.5, 3.6 и 3.7 произошли серьезные изменения в инструкциях :code:MAKE_FUNCTION и :code:CALL_FUNCTION.

Python 3.8 удаляет инструкции :code:SETUP_LOOP, :code:SETUP_EXCEPT, :code:BREAK_LOOP и :code:CONTINUE_LOOP, что может усложнить обнаружение потока управления из-за отсутствия более сложного анализа потока управления, который планируется. Посмотрим.

В настоящее время поддерживаются не все магические номера Python. В частности, в некоторых версиях Python, особенно Python 3.6, магический номер менялся несколько раз в пределах одной версии.

Мы поддерживаем только релизные версии, не кандидатные. Однако обратите внимание, что магия релизной версии обычно совпадает с последней кандидатной версией перед релизом.

Существуют также кастомизированные интерпретаторы Python, в частности Dropbox, которые используют свою собственную магию и шифруют байткод. За исключением старого интерпретатора Dropbox Python 2.5, такие вещи не обрабатываются.

Мы также не обрабатываем PJOrion_ или иной обфусцированный код. Для PJOrion попробуйте: PJOrion Deobfuscator_ для деобфускации байткода, чтобы получить валидный байткод перед использованием этого инструмента; pydecipher_ может помочь с этим.

Эта программа не может декомпилировать исполняемые файлы Microsoft Windows, созданные Py2EXE_, хотя мы, вероятно, можем декомпилировать код после того, как вы извлечете байткод правильно. Pydeinstaller <https://github.com/charles-dyfis-net/pydeinstaller>_ может помочь с распаковкой бандлеров Pyinstaller.

Обработка патологически длинных списков выражений или операторов медленная. Мы не обрабатываем Cython_ или MicroPython, которые не используют байткод.

Существует множество ошибок в декомпиляции. И это верно для каждого другого декомпилятора CPython, который я встречал, даже для тех, которые утверждали, что "идеальны" для какой-то конкретной версии, например 2.4.

По мере развития Python декомпиляция также усложняется, потому что компиляция становится более сложной, а сам язык — более сложным. Я подозреваю, что попыток ad-hoc, подобных unpyc37_ (который основан на декомпиляторе 3.3), будет меньше просто потому, что это сложнее сделать. Хорошая новость, по крайней мере с моей точки зрения, заключается в том, что я думаю, что понимаю, что нужно для более надежного решения проблем. Но прямо сейчас, пока проект не получит лучшее финансирование, я не намерен прилагать серьезных усилий для поддержки версий Python 3.8 или 3.9, включая ошибки, которые могут возникнуть. Я предполагаю, что в какой-то момент мне это может стать интересно.

Вы легко можете найти ошибки, запустив тесты против стандартного набора тестов, который Python использует для самопроверки. В любой момент есть десятки известных проблем, которые довольно хорошо изолированы и могут быть решены, если уделить время. Проблема в том, что не так много людей работают над исправлением ошибок.

Некоторые ошибки в 3.7 и 3.8 — это просто вопрос обратного переноса исправлений из decompyle3. Есть добровольцы?

Вы можете столкнуться с ошибкой, о которой захотите сообщить. Пожалуйста, сделайте это после прочтения Как сообщить об ошибке <https://github.com/rocky/python-uncompyle6/blob/master/HOW-TO-REPORT-A-BUG.md>_ и следуйте инструкциям при открытии проблемы <https://github.com/rocky/python-uncompyle6/issues/new?assignees=&labels=&template=bug-report.md>_.

Имейте в виду, что это может не привлечь мое внимание в течение некоторого времени. Если вы спонсируете или поддерживаете проект каким-либо образом, я буду расставлять приоритеты для ваших проблем перед очередью других дел, которыми я мог бы заниматься. В редких случаях я могу выполнить ручную декомпиляцию байткода за плату. Однако это дорого и обычно выходит за пределы того, что большинство людей готовы потратить.

См. также

https://rocky.github.io/blackhat-asia-2024-additional/all-notes-print.html : Как читать и писать высокоуровневый декомпилятор байткода: uncompyle6 decompyle3 -- BlackHat 2024 Asia (видео <https://www.youtube.com/watch?v=NA77SFncppE>_). Большое спасибо организаторам и рецензентам за возможность выступить. Такие вещи побуждают меня работать над такими проектами.
https://github.com/rocky/python-decompile3 : Гораздо более компактный и современный код, ориентированный на 3.7 и 3.8. Изменения в нём будут перенесены сюда.
https://code.google.com/archive/p/unpyc3/ : поддерживает только Python 3.2. Вышеупомянутые проекты используют другую технику декомпиляции, отличную от используемой здесь. В настоящее время не поддерживается.
https://github.com/figment/unpyc3/ : форк вышеуказанного, но поддерживает только Python 3.3. Включает некоторые исправления, такие как поддержка аннотаций функций. В настоящее время не поддерживается.
https://github.com/wibiti/uncompyle2 : поддерживает только Python 2.7, но делает это довольно хорошо. Есть ситуации, когда результаты :code:uncompyle6 некорректны, а результаты :code:uncompyle2 — нет, но чаще uncompyle6 корректен, когда uncompyle2 — нет. Поскольку :code:uncompyle6 придерживается точности, а не идиоматичности Python, :code:uncompyle2 может выдавать более естественно выглядящий код, когда он корректен. В настоящее время :code: поддерживается слабо. См. его _ для получения более подробной информации.

python-uncompyle6

Популярное