|packagestatus|

.. contents::

uncompyle6

네이티브 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 인터프리터를 실행하여 결과 프로그램이 구문적으로 올바른지 확인할 수 있습니다. 마지막으로, 프로그램에 자체 테스트가 있는 경우 디컴파일된 코드에 대해 검사를 실행할 수 있습니다.

우리는 자동화된 프로세스를 사용하여 버그를 찾습니다. 다른 디컴파일러의 이슈 트래커에서 우리가 발견한 여러 버그를 볼 수 있습니다. 그들 중 극소수만이 다른 디컴파일러에서 수정되었습니다.

요구 사항

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-문자열, 더 현대적인 관용구, 더 현대적인 Type 어노테이션 사용) 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.7보다 Python 2.6에 더 가까움) 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 Releases 섹션의 파일을 사용하여 설치하세요. 이전 Python은 easy_install <https://python101.pythonlibrary.org/chapter29_pip.html#using-easy-install>_ 을 사용했습니다. 그러나 이는 PyPi나 최신 Python 버전에서 더 이상 지원되지 않습니다. 반대로, poetry 나 pip (더 새로운 방식)는 이전 Python에서 지원되지 않습니다.

실행 중인 Python 버전이 Python 2.4에서 2.7 사이인 경우, uncompyle6_24-x.y.z.tar.gz라는 tarball을 사용하세요.

실행 중인 Python 버전이 Python 3.0에서 3.2 사이인 경우, uncompyle6_30-x.y.z.tar.gz라는 tarball을 사용하세요.

실행 중인 Python 버전이 Python 3.3에서 3.5 사이인 경우, uncompyle6_33-x.y.z.tar.gz라는 tarball을 사용하세요.

실행 중인 Python 버전이 Python 3.6에서 3.11 사이인 경우, uncompyle6_36-x.y.z.tar.gz라는 tarball을 사용하세요.

실행 중인 Python 버전이 3.11 이상인 경우, uncompyle6-x.y.z.tar.gz라는 tarball을 사용하세요.

동일한 버전 지정이 있는 egg나 wheel도 시도할 수 있습니다. 예를 들어 Python 3.9 설치의 경우 uncompyle6-x.y.z-py39-none-any.whl입니다. *그러나 지정자가 없는 버전은 Python 3.11 이상을 의미함을 유의하십시오.

마찬가지로 _xx가 없는 tarball은 Python 3.11 이상에서만 작동합니다.

Git 브랜치 사용 이유 ++++++++++++++++++++

현재로서는 이 정도 복잡성과 많은 기능을 가진 하나의 Python 소스 코드로 Python 2.7과 Python 3.13+를 모두 실행하는 것은 불가능합니다(비현실적이지 않다면). 언어가 너무 많이 달라졌고, 패키징도 크게 다릅니다. 실제로 Python 3.11+의 패키징 방식은 'easy_install'을 선호했던 Python 2.7(및 그 이전 Python 2.4까지)과 호환되지 않습니다.

소스 텍스트에서 설치 ++++++++++++++++++++

소스 코드에서 설치하려면 올바른 Git 브랜치가 있는지 확인하십시오. Git 브랜치 이름은 요구 사항 섹션을 참조하십시오.

올바른 브랜치를 설정한 후::

$ pip install -e .  # 소스 트리에서 실행하도록 설정

GNU Makefile도 제공되므로 :code:make install (루트 또는 sudo로 가능)을 실행하면 위 단계를 수행합니다.

테스트 실행

make check

올바른 명령을 설정하고 실행하며, 가장 빠른 것부터 느린 것까지 테스트를 실행하기 위해 GNU makefile이 추가되었습니다.

remake_가 설치되어 있으면 :code:remake --tasks를 통해 테스트를 포함한 모든 작업 목록을 볼 수 있습니다.

사용법

실행

$ uncompyle6 compiled-python-file-pyc-or-pyo

사용법 도움말:

$ uncompyle6 -h

검증

이전 Python 버전에서는 바이트코드를 디컴파일한 다음 해당 바이트코드 버전의 Python 인터프리터를 사용하여 컴파일함으로써 바이트코드를 검증할 수 있었습니다. 이렇게 하면 생성된 바이트코드를 원래 바이트코드와 비교할 수 있었습니다. 그러나 Python의 코드 생성이 향상됨에 따라 더 이상 실현 가능하지 않게 되었습니다.

디컴파일 과정의 정확성에 대한 Python 구문 검증을 원한다면 :code:--syntax-verify 옵션을 추가하십시오. 그러나 Python 구문은 변경됩니다. 바이트코드가 구문을 검사할 Python 인터프리터에 맞는 올바른 바이트코드인 경우 이 옵션을 사용해야 합니다.

특정 바이트코드 디컴파일에서 때때로 회귀가 발생할 수 있으므로 uncompyle6의 다른 버전과 결과를 교차 비교할 수도 있습니다. 전반적인 품질이 향상됨에 따라 발생합니다.

Python 3.7 및 3.8의 경우 decompyle3_의 코드가 일반적으로 더 좋습니다.

또는 uncompyle2_, unpyc37_ 또는 pycdc_와 같은 다른 특정 Python 디컴파일러를 시도해 보십시오. 후자의 두 가지는 다르게 작동하므로 여기의 버그가 그곳에는 없는 경우가 많고, 그 반대의 경우도 마찬가지입니다.

더 강력한 검증을 제공할 수 있는 흥미로운 종류의 프로그램이 있습니다: 실행 시 스스로를 테스트하는 프로그램입니다. 우리의 테스트 스위트에는 이러한 프로그램이 포함되어 있습니다.

또한 Python은 표준 라이브러리용 테스트 스위트와 같은 또 다른 프로그램 세트를 제공합니다. :code:test/stdlib에 이러한 종류의 검사를 용이하게 하는 코드가 있습니다.

알려진 버그/제한 사항

가장 크고 알려진 (그리고 수정 가능할 수도 있지만 어려운) 문제는 제어 흐름 처리와 관련이 있습니다. (Python은 아마도 제가 본 것 중 가장 다양하고 괴상한 복합문 집합을 가지고 있습니다; 루프와 try 블록에 'else' 절이 있는데 많은 프로그래머가 모를 것 같습니다.)

제가 살펴본 모든 Python 디컴파일러는 Python의 제어 흐름을 디컴파일하는 데 문제가 있습니다. 어떤 경우에는 잘못된 디컴파일을 감지하여 보고할 수 있습니다.

Python 2 지원은 꽤 좋습니다.

하위 Python 버전에서 디컴파일은 꽤 괜찮아 보이지만, Python 배포 테스트에 대한 자동화된 테스트는 마련되어 있지 않습니다. 또한 버전 1.6 및 2.0용 Python 인터프리터가 없습니다.

Python 3 시리즈에서는 3.4 또는 3.3 주변에서 지원이 가장 강력하며, 해당 버전에서 멀어질수록 지원이 약해집니다. Python 3.0은 어떤 면에서는 3.1이나 2.7보다 2.6에 더 가깝다는 점에서 이상합니다. Python 3.6은 바이트 코드 대신 워드 코드를 사용하여 상황을 극적으로 변화시킵니다. 결과적으로 점프 명령어 인수의 점프 오프셋 필드가 줄었습니다. 이로 인해 :code:EXTENDED_ARG 명령어가 점프 명령어에서 더 보편화되었습니다. 이전에는 드물었습니다. 아마도 추가된 :code:EXTENDED_ARG 명령어를 보완하기 위해 추가 점프 최적화가 추가되었습니다. 따라서 현재처럼 임시 방식으로 제어 흐름을 처리하는 것은 더 나쁩니다.

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_가 도움이 될 수 있습니다.

이 프로그램은 Py2EXE_로 생성된 Microsoft Windows EXE 파일을 디컴파일할 수 없습니다. 그러나 바이트코드를 적절히 추출한 후에는 코드를 디컴파일할 수 있습니다. Pydeinstaller <https://github.com/charles-dyfis-net/pydeinstaller>_ 가 Pyinstaller 번들러의 압축을 푸는 데 도움이 될 수 있습니다.

병적으로 긴 표현식 또는 문 목록을 처리하는 속도가 느립니다. 바이트코드를 사용하지 않는 Cython_ 또는 MicroPython은 처리하지 않습니다.

디컴파일에는 수많은 버그가 있습니다. 그리고 이는 제가 만난 모든 다른 CPython 디컴파일러에게도 해당됩니다. 2.4와 같은 특정 버전에서 '완벽하다'고 주장한 것들조차도 마찬가지입니다.

Python이 발전함에 따라 컴파일이 더 정교해지고 언어 자체도 더 정교해지면서 디컴파일도 더 어려워집니다. 그렇게 하기가 더 어렵기 때문에 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:uncompyle2는 가볍게 유지보수됩니다. 자세한 내용은 이슈 트래커 <https://github.com/wibiti/uncompyle2/issues>_를 참조하세요.

python-uncompyle6

인기