디컴파일러

Decompiler

디컴파일러는 실행 파일을 개략적인 소스 파일로 변환하는 컴퓨터 프로그램입니다.이 파일은 정상적으로 재컴파일 할 수 있습니다.따라서 이는 고급 언어를 하위 언어로 변환하는 일반적인 컴파일러와는 반대입니다.디컴파일러는 보통 원래의 소스 코드를 완벽하게 재구성할 수 없기 때문에 난독화된 코드를 자주 생성합니다.그럼에도 불구하고 디컴파일러는 여전히 컴퓨터 소프트웨어의 리버스 엔지니어링에서 중요한 도구입니다.

서론

디컴파일러라는 용어는 실행 가능한 프로그램(컴파일러로부터의 출력)을 (상대적인) 고급 언어로 소스 코드로 변환하는 프로그램에 가장 일반적으로 적용되며, 컴파일되면 원래 실행 가능한 프로그램과 동일한 동작의 실행 파일이 생성됩니다.이에 비해 디스어셈블러는 실행 가능한 프로그램을 어셈블리 언어로 변환합니다(어셈블러는 실행 가능한 프로그램으로 다시 어셈블하기 위해 사용될 수 있습니다).

디컴파일은 디컴파일러를 사용하는 동작이지만 디컴파일러의 출력을 나타내는 용어일 수도 있습니다.손실된 소스 코드를 복구하는 데 사용할 수 있으며, 경우에 따라서는 컴퓨터 보안, 상호 운용성 및 [1]오류 수정에도 유용합니다.디컴파일의 성공 여부는 디컴파일되는 코드에 존재하는 정보의 양과 그에 대해 수행되는 분석의 정교함에 따라 결정됩니다.많은 가상 머신(Java Virtual Machine 또는 등)에서 사용되는 바이트 코드 형식입니다.NET Framework Common Language Runtime)에는 광범위한 메타데이터 및 고급 기능이 포함되어 있어 컴파일이 상당히 가능합니다.디버깅 데이터(debug-symbols 등)를 적용하면 변수와 구조체의 원래 이름, 심지어 회선 번호까지 복제할 수 있습니다.이러한 메타데이터나 디버깅 데이터가 없는 기계어는 [2]디컴파일이 훨씬 어렵습니다.

일부 컴파일러 및 컴파일 후 툴은 난독화된 코드를 생성합니다(즉, 디컴파일하기 매우 어렵거나 혼란스러운 출력으로 디컴파일되는 출력을 생성하려고 시도합니다).이는 실행 파일의 리버스 엔지니어링을 더욱 어렵게 하기 위해 수행됩니다.

디컴파일러는 보통 바이너리 실행 파일에서 소스 코드를 만드는 데 사용되지만 특정 바이너리 데이터 파일을 사람이 읽을 수 있고 편집 가능한 [3][4]소스로 변환하는 디컴파일러도 있습니다.

설계.

디컴파일러는 각각이 전체 디컴파일 프로세스의 특정 측면에 기여하는 일련의 단계로 구성된다고 생각할 수 있습니다.

로더

첫 번째 디컴파일 단계는 입력 기계 코드 또는 중간 언어 프로그램의 바이너리 파일 형식을 로드하고 구문 분석합니다.아키텍처(Pentium, PowerPC 등)나 엔트리 포인트 등 입력 프로그램에 관한 기본적인 사실을 검출할 수 있을 것입니다.많은 경우, 이 경우, 이 경우, 다음과 같은 값을 찾을 수 있어야 합니다.main사용자가 작성한 코드의 시작인 C 프로그램의 기능.런타임 초기화 코드는 제외됩니다.이 코드는 가능하면 디컴파일하지 마십시오.사용 가능한 경우 기호 테이블 및 디버그 데이터도 로드됩니다.프론트 엔드는 사용되는 라이브러리가 코드에 링크되어 있어도 식별할 수 있습니다.이것에 의해, 라이브러리 인터페이스가 제공됩니다.사용하고 있는 컴파일러 또는 컴파일러를 판별할 수 있는 경우는,[5] 코드 이디어나 식별에 도움이 되는 정보를 얻을 수 있습니다.

분해

다음 논리적 단계는 기계 코드 명령을 기계 독립 중간 표현(IR)으로 분해하는 것입니다.예를 들어 Pentium 기계 명령어

움직이다    이액스, [ebx+0x04]

IR로 변환될 수 있습니다.

이액스  := m[ebx+4];

이디옴

관용적인 기계 코드 시퀀스는 명령어의 개별 의미론에서 결합된 의미론이 즉시 명확하지 않은 코드 시퀀스입니다.분해 단계의 일부 또는 이후 분석의 일부로서 이러한 관용적 시퀀스를 알려진 등가 IR로 변환해야 한다.예를 들어 x86 어셈블리 코드는 다음과 같습니다.

    CDQ    이액스             ; edx는 기호-edi, edi +(tex)로 설정됩니다.     xor    이액스, 엣지     후보선수    이액스, 엣지

로 번역될 수 있다

eax : = 복근(eax);

일부 관용적 시퀀스는 기계에 의존하지 않으며 일부 시퀀스는 하나의 명령만 수반합니다.예를들면,xor eax, eax를 클리어 합니다.eaxregister(제로 설정)이는 다음과 같은 머신에 의존하지 않는 심플화 규칙을 사용하여 구현할 수 있습니다.a = 0.

일반적으로 명령 순서의 영향을 덜 받는 후속 단계로 가능한 한 관용적 시퀀스의 검출을 지연시키는 것이 좋습니다.예를 들어 컴파일러의 명령 스케줄링 단계는 관용적인 시퀀스에 다른 명령을 삽입하거나 시퀀스의 명령 순서를 변경할 수 있습니다.분해 단계의 패턴 일치 프로세스에서는 변경된 패턴을 인식하지 못할 수 있습니다.이후 단계에서는 명령 표현식을 보다 복잡한 표현식으로 그룹화하고 정규(표준화) 형식으로 수정하여 변경된 관용구도 나중에 상위 수준 패턴과 일치할 가능성이 높아집니다.

서브루틴 콜, 예외 처리 및 스위치 문에 대한 컴파일러의 관용구를 인식하는 것이 특히 중요합니다.일부 언어에서는 문자열이나 긴 정수를 광범위하게 지원합니다.

프로그램 분석

다양한 프로그램 분석을 IR에 적용할 수 있습니다.특히, 표현 전파는 여러 명령어의 의미를 보다 복잡한 표현으로 결합합니다.예를들면,

    움직이다   이액스,[ebx+0x04]     더하다   이액스,[ebx+0x08]     후보선수   [ebx+0x0C],이액스

표현 전파 후 다음과 같은 IR이 발생할 수 있습니다.

m[ebx+12] : = m[ebx+12] - (m[ebx+4] + m[ebx+8]);

결과 표현은 고급 언어에 가깝고 기계 레지스터의 사용을 제거했습니다.eax.나중에 분석을 실시하면,ebx등록하세요.

데이터 흐름 분석

레지스터 내용이 정의되고 사용되는 장소는 데이터 흐름 분석을 사용하여 추적해야 합니다.임시 및 로컬 데이터에 사용되는 위치에도 동일한 분석을 적용할 수 있습니다.그런 다음 연결된 값 정의 및 용도별로 서로 다른 이름을 생성할 수 있습니다.원래 프로그램의 다른 부분에 있는 여러 변수에 동일한 로컬 변수 위치가 사용되었을 수 있습니다.더 나쁜 것은 데이터 흐름 분석이 실제로 발생하거나 실제로 문제가 되지는 않더라도 이러한 두 사용 사이에 값이 흐를 수 있는 경로를 식별하는 것입니다.이로 인해 나쁜 경우 로케이션을 여러 유형의 조합으로 정의해야 할 수 있습니다.디컴파일러를 사용하면 사용자가 이러한 부자연스러운 의존관계를 명시적으로 끊을 수 있기 때문에 코드가 명확해집니다.이는 변수가 초기화되지 않고 잠재적으로 사용됨을 의미하므로 원래 [citation needed]프로그램에 문제가 있음을 나타냅니다.

유형 분석

양호한 머신 코드 디컴파일러는 타입 분석을 실행합니다.여기서 레지스터 또는 메모리 로케이션을 사용하는 방법은 로케이션의 가능한 유형에 제약을 가합니다.예를 들어,and명령어는 피연산자가 정수임을 나타냅니다.프로그램은 부동소수점 값(특수 라이브러리 코드 제외)이나 포인터에서는 이러한 연산을 사용하지 않습니다.안add명령어는 오퍼랜드가 정수 또는 1개의 정수 및 1개의 포인터(각각 정수 및 포인터 결과 포함), 세 번째 제약은 유형이 다를 [6]때 두 오퍼랜드의 순서에서 발생합니다.

구조 또는 배열의 인식을 트리거하는 다양한 고급 표현을 인식할 수 있습니다.그러나 기계 코드나 심지어 C와 같은 고급 언어가 캐스트와 포인터 산술로 허용하는 자유로움 때문에 많은 가능성을 구별하는 것은 어렵습니다.

이전 섹션의 예에서는 다음과 같은 고레벨 코드가 발생할 수 있습니다.

구조 T1 *ebx;     구조 T1 {         인트 v0004;         인트 v0008;         인트 V000C;     }; ebx->V000C -= ebx->v0004 + ebx->v0008;

구조화

두 번째 디컴파일 단계에서는 IR을 다음과 같은 상위 레벨의 구조로 구성합니다.while루프와if/then/else조건문예를 들어 기계 코드

    xor 이액스, 이액스 l0002:     또는  ebx, ebx     쟈게 l0003     더하다 이액스,[ebx]     움직이다 ebx,[ebx+0x4]     jmp l0002 l0003:     움직이다 [0x10040000],이액스

다음과 같이 변환할 수 있습니다.

이액스 = 0; 하는 동안에 (ebx < > 0) {     이액스 += ebx->v0000;     ebx = ebx->v0004; } v10040000 = 이액스;

비구조화 코드는 이미 구조화된 코드보다 구조화된 코드로 변환하기가 더 어렵습니다.해결책으로는 일부 코드 복제 또는 부울 [7]변수 추가가 있습니다.

코드 생성

마지막 단계는 디컴파일러 백엔드에서 상위 레벨코드를 생성하는 것입니다.컴파일러가 다른 아키텍처의 머신 코드를 생성하기 위한 백엔드를 여러 개 가지고 있는 것처럼 디컴파일러는 다른 고급 언어로 높은 수준의 코드를 생성하기 위한 백엔드를 여러 개 가지고 있을 수 있습니다.

코드 생성 직전에 IR을 대화식으로 편집할 수 있도록 하는 것이 바람직할 수 있습니다.아마도 그래픽 사용자 인터페이스를 사용할 수 있습니다.이를 통해 사용자는 코멘트, 일반적이지 않은 변수 및 함수 이름을 입력할 수 있습니다.그러나 이러한 정보는 거의 디컴파일 후 편집에서도 쉽게 입력할 수 있습니다.사용자는 다음과 같은 구조적 측면을 변경할 수 있습니다.while에 루프하다.for이 과정은 소스 코드 리팩터링 도구가 도움이 되지만 단순한 텍스트 편집기로 쉽게 수정되지 않습니다.사용자는 유형 분석 단계에서 식별되지 않은 정보를 입력해야 할 수 있습니다. 예를 들어 메모리 식을 배열 또는 구조식으로 수정해야 합니다.마지막으로 잘못된 IR을 수정하거나 출력 코드를 읽기 쉽게 변경해야 할 수 있습니다.

합법성

대부분의 컴퓨터 프로그램은 저작권법의 적용을 받는다.저작권의 대상이 되는 것의 정확한 범위는 지역에 따라 다르지만, 일반적으로 저작권법은 작성자(프로그래머 [8]또는 고용주)에게 프로그램에 대한 배타적 권리를 제공합니다.이러한 권한에는 컴퓨터의 RAM에 복사된 복사본을 포함하여 복사본을 만들 수 있는 권리도 포함됩니다(프로그램 [9]사용에 필수적이지 않은 경우).디컴파일 처리에는 복수의 복사가 수반되기 때문에 저작권자의 허가 없이는 일반적으로 금지된다.그러나 디컴파일은 소프트웨어 상호운용성을 달성하기 위해 필요한 단계인 경우가 많기 때문에 미국과 유럽의 저작권법은 제한된 범위 내에서 디컴파일을 허용합니다.

미국에서는 디컴파일 사례에서 저작권 공정 사용 방어가 성공적으로 적용되었습니다.예를 들어, 세가 v. 법원은 Collade가 Sega의 [10]게임기에서 사용되는 소프트웨어 잠금 메커니즘을 피하기 위해 Collade가 법적으로 디컴파일에 관여할 수 있다고 판결했습니다.또한 디지털 밀레니엄 저작권법(PUBLIC LAW 105~304)은[11] §1201(i)의 보안 테스트와 평가 및 §1201(f)[12]의 리버스 엔지니어링에 대해 적절한 면제를 실시하고 있습니다.

유럽에서는 1991년 소프트웨어 지령이 상호 운용성을 달성하기 위해 디컴파일할 권리를 명시적으로 규정하고 있습니다.한편에서는 소프트웨어 보호론자, 다른 한편에서는 학계 및 독립 소프트웨어 개발자들 간에 열띤 논쟁을 벌인 결과, 제6조는 다음과 같은 여러 조건이 충족될 경우에만 해체를 허용하고 있습니다.

  • 첫째, 개인이나 기업이 디컴파일할 프로그램을 사용하려면 라이선스가 있어야 한다.
  • 둘째, 대상 프로그램 또는 다른 프로그램과의 상호 운용성을 달성하기 위해서는 반드시 디컴파일이 필요합니다.따라서 매뉴얼이나 API 문서 등 상호운용성 정보를 쉽게 입수할 수 없습니다.이것은 중요한 제한입니다.그 필요성은 디컴파일러에 의해 증명되어야 한다.이 중요한 제한의 목적은 주로 개발자가 자사 제품의 상호 운용성 [13]정보를 문서화하고 공개하도록 동기를 부여하는 것입니다.
  • 셋째, 가능한 경우 디컴파일 프로세스는 상호운용성과 관련된 대상 프로그램의 부분으로 제한되어야 한다.디컴파일의 목적 중 하나는 프로그램 구조를 이해하는 것이므로, 이 세 번째 제한을 충족시키기는 어려울 수 있습니다.디컴파일러에게 입증 책임이 있습니다

또, 제6조는, 분해에 의해 취득한 정보를 다른 목적으로 사용할 수 없고, 타인에게 제공할 수 없다고 규정하고 있다.

전체적으로 제6조에서 규정하는 디컴파일 권리는 소프트웨어 업계의 일반적인 관행이라고 주장하는 것을 성문화한다.유럽의 소송은 거의 일어나지 않은 것으로 알려져 있다.이는 다음 세 가지 중 하나를 의미하는 것으로 해석될 수 있습니다.

  1. 디컴파일권은 자주 사용되지 않으므로 디컴파일권은 불필요할 수 있다.
  2. )해산권은 잘 기능하며 법적 분쟁이나 법적 분쟁을 일으키지 않도록 충분한 법적 확실성을 제공한다.
  3. )의 불법 해독은 대부분 발견되지 않습니다.

2000년의 유럽 회원국에 의한 소프트웨어 디렉티브의 실시에 관한 보고서에서, 유럽위원회는 [14]제2의 해석을 지지하는 것처럼 보인다.

도구들

디컴파일러는 보통 특정 바이너리 형식을 대상으로 합니다.네이티브 명령어 세트(Intel x86, ARM, MIPS 등)와 가상 머신의 바이트 코드(Dalvik, Java 클래스 파일, Web Assembly, Ethernet)도 있습니다.

컴파일 중에 정보가 손실되기 때문에 디컴파일은 거의 완벽하지 않으며 모든 디컴파일러가 특정 바이너리 포맷에서 동일한 성능을 발휘하는 것은 아닙니다.다른 [15]디컴파일러의 성능을 비교하는 연구가 있습니다.

「 」를 참조해 주세요.

자바 디컴파일러

기타 디컴파일러

레퍼런스

  1. ^ Van Emmerik, Mike (2005-04-29). "Why Decompilation". Program-transformation.org. Archived from the original on 2010-09-22. Retrieved 2010-09-15.
  2. ^ Miecznikowski, Jerome; Hendren, Laurie (2002). "Decompiling Java Bytecode: Problems, Traps and Pitfalls". In Horspool, R. Nigel (ed.). Compiler Construction: 11th International Conference, proceedings / CC 2002. Springer-Verlag. pp. 111–127. ISBN 3-540-43369-4.
  3. ^ Paul, Matthias R. (2001-06-10) [1995]. "Format description of DOS, OS/2, and Windows NT .CPI, and Linux .CP files" (CPI.LST file) (1.30 ed.). Archived from the original on 2016-04-20. Retrieved 2016-08-20.
  4. ^ Paul, Matthias R. (2002-05-13). "[fd-dev] mkeyb". freedos-dev. Archived from the original on 2018-09-10. Retrieved 2018-09-10. […] .CPI & .CP codepage file analyzer, validator and decompiler […] Overview on /Style parameters: […] ASM source include files […] Standalone ASM source files […] Modular ASM source files […]
  5. ^ Cifuentes, Cristina; Gough, K. John (July 1995). "Decompilation of Binary Programs". Software: Practice and Experience. 25 (7): 811–829. CiteSeerX 10.1.1.14.8073. doi:10.1002/spe.4380250706. S2CID 8229401.
  6. ^ Mycroft, Alan (1999). "Type-Based Decompilation". In Swierstra, S. Doaitse (ed.). Programming languages and systems: 8th European Symposium on Programming Languages and Systems. Springer-Verlag. pp. 208–223. ISBN 3-540-65699-5.
  7. ^ ）Cifuentes, Cristina (1994). "Chapter 6". Reverse Compilation Techniques (PDF) (PhD thesis). Queensland University of Technology. Archived (PDF) from the original on 2016-11-22. Retrieved 2019-12-21. 。
  8. ^ Rowland, Diane (2005). Information technology law (3 ed.). Cavendish. ISBN 1-85941-756-6.
  9. ^ "U.S. Copyright Office - Copyright Law: Chapter 1". Archived from the original on 2017-12-25. Retrieved 2014-04-10.
  10. ^ "The Legality of Decompilation". Program-transformation.org. 2004-12-03. Archived from the original on 2010-09-22. Retrieved 2010-09-15.
  11. ^ "Digital Millennium Copyright Act" (PDF). US Congress. 1998-10-28. Archived (PDF) from the original on 2013-12-10. Retrieved 2013-11-15.
  12. ^ "Federal Register :: Request Access". Archived from the original on 2022-01-25. Retrieved 2021-01-31.
  13. ^ Czarnota, Bridget; Hart, Robert J. (1991). Legal protection of computer programs in Europe: a guide to the EC directive. London: Butterworths Tolley. ISBN 0-40600542-7.
  14. ^ "Report from the Commission to the Council, the European Parliament and the Economic and Social Committee on the implementation and effects of Directive 91/250/EEC on the legal protection of computer programs". Archived from the original on 2020-12-04. Retrieved 2020-12-26.
  15. ^ Harrand, Nicolas; Soto-Valero, Cesar; Monperrus, Martin; Baudry, Benoit (2019). "The Strengths and Behavioral Quirks of Java Bytecode Decompilers". 19th International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE: 92–102. arXiv:1908.06895. Bibcode:2019arXiv190806895H. doi:10.1109/SCAM.2019.00019. ISBN 978-1-7281-4937-0. S2CID 201070711.

외부 링크

무료 사전인 Wiktionary에서 디컴파일러를 검색합니다.
Wikibooks는 다음과 같은 토픽에 관한 책을 가지고 있습니다.