imported>Dabmasterars: Fixed a typo, added more wikilinks.

2025-06-18T17:21:36Z

Fixed a typo, added more wikilinks.

New page

{{Short description|Program translating executable to source code}}
{{Use dmy dates|date=December 2019|cs1-dates=y}}A '''decompiler''' is a [[computer program]] that translates an [[executable]] file back into high-level [[source code]]. Unlike a [[compiler]], which converts [[High-level programming language|high-level]] code into [[machine code]], a decompiler performs the reverse process. While [[disassembler]]s translate [[executable]]s into [[assembly language]], decompilers go a step further by reconstructing the disassembly into [[High-level programming language|higher-level languages]] like [[C (programming language)|C]]. Due to the one-way nature of the compilation process, decompilers usually cannot perfectly recreate the original source code. They often produce obfuscated and less readable code.

==Introduction==
Decompilation is the process of transforming executable code into a high-level, human-readable format using a decompiler. This process is commonly used for tasks that involve [[Reverse engineering|reverse-engineering]] the logic behind executable code, such as recovering lost or unavailable source code. Decompilers face inherent challenges due to the loss of critical information during the compilation process, such as variable names, [[Comment (computer programming)|comments]], and code structure.

Certain factors can impact the success of decompilation. Executables containing detailed [[metadata]], such as those used by [[Java (programming language)|Java]] and [[.NET]], are easier to reverse-engineer because they often retain [[Class (computer programming)|class structures]], [[method signature]]s, and [[debugging]] information. Executable files stripped of such context are far more challenging to translate into meaningful source code.

Some software developers may [[Obfuscation (software)|obfuscate]], pack, or [[Encryption|encrypt]] parts of their executable programs, making the decompiled code much harder to interpret. These techniques are often done to deter reverse-engineering, making the process more difficult and time-intensive.

==Design==
Decompilers can be thought of as composed of a series of phases each of which contributes specific aspects of the overall decompilation process.

===Loader===
The first decompilation phase loads and parses the input machine code or [[intermediate language]] program's [[binary file]] format. It should be able to discover basic facts about the input program, such as the architecture (Pentium, PowerPC, etc.) and the entry point. In many cases, it should be able to find the equivalent of the <code>main</code> function of a [[C (programming language)|C]] program, which is the start of the '''user written''' code. This excludes the [[Execution (computing)#Runtime|runtime]] initialization code, which should not be decompiled if possible. If available the [[symbol table]]s and debug data are also loaded. The front end may be able to identify the libraries used even if they are linked with the code, this will provide library interfaces. If it can determine the compiler or compilers used it may provide useful information in identifying code idioms.<ref name="Cifuentes_1995"/>

===Disassembly===
The next logical phase is the [[disassembler|disassembly]] of machine code instructions into a machine independent intermediate representation (IR). For example, the [[Pentium]] machine instruction
<syntaxhighlight lang="asm">
mov eax, [ebx+0x04]
</syntaxhighlight>
might be translated to the IR
<syntaxhighlight lang="asm">
eax := m[ebx+4];
</syntaxhighlight>

===Idioms===
Idiomatic machine code sequences are sequences of code whose combined [[Semantics (computer science)|semantics]] are not immediately apparent from the instructions' individual semantics. Either as part of the disassembly phase, or as part of later analyses, these idiomatic sequences need to be translated into known equivalent IR. For example, the [[x86 assembly language|x86 assembly code]]:
<syntaxhighlight lang="nasm">
cdq eax ; edx is set to the sign-extension≠edi,edi +(tex)push
xor eax, edx
sub eax, edx
</syntaxhighlight>
could be translated to
eax := abs(eax);

Some idiomatic sequences are machine independent; some involve only one instruction. For example, {{code|2=nasm|xor eax, eax}} clears the <code>eax</code> register (sets it to zero). This can be implemented with a machine independent simplification rule, such as <code>a = 0</code>.

In general, it is best to delay detection of idiomatic sequences if possible, to later stages that are less affected by instruction ordering. For example, the instruction scheduling phase of a compiler may insert other instructions into an idiomatic sequence, or change the ordering of instructions in the sequence. A [[pattern matching]] process in the disassembly phase would probably not recognize the altered pattern. Later phases group instruction expressions into more complex expressions, and modify them into a canonical (standardized) form, making it more likely that even the altered idiom will match a higher level pattern later in the decompilation.

It is particularly important to recognize the compiler idioms for [[subroutine]] calls, [[exception handling]], and [[switch statement]]s. Some languages also have extensive support for [[String (computer science)|string]]s or [[long integer]]s.

===Program analysis===
Various program analyses can be applied to the IR. In particular, expression propagation combines the semantics of several instructions into more complex expressions. For example,
<syntaxhighlight lang="asm">
mov eax,[ebx+0x04]
add eax,[ebx+0x08]
sub [ebx+0x0C],eax
</syntaxhighlight>
could result in the following IR after expression propagation:
m[ebx+12] := m[ebx+12] - (m[ebx+4] + m[ebx+8]);
The resulting expression is more like high level language, and has also eliminated the use of the machine register <code>eax</code>. Later analyses may eliminate the <code>ebx</code> register.

===Data flow analysis===
The places where register contents are defined and used must be traced using [[data flow analysis]]. The same analysis can be applied to locations that are used for temporaries and local data. A different name can then be formed for each such connected set of value definitions and uses. It is possible that the same local variable location was used for more than one variable in different parts of the original program. Even worse it is possible for the data flow analysis to identify a path whereby a value may flow between two such uses even though it would never actually happen or matter in reality. This may in bad cases lead to needing to define a location as a union of types. The decompiler may allow the user to explicitly break such unnatural dependencies which will lead to clearer code. This of course means a variable is potentially used without being initialized and so indicates a problem in the original program.{{citation needed|date=June 2022}}

===Type analysis===
A good machine code decompiler will perform type analysis. Here, the way registers or memory locations are used result in constraints on the possible type of the location. For example, an <code>and</code> instruction implies that the operand is an integer; programs do not use such an operation on [[floating point]] values (except in special library code) or on [[Pointer (computer programming)|pointers]]. An <code>add</code> instruction results in three constraints, since the operands may be both integer, or one integer and one pointer (with integer and pointer results respectively; the third constraint comes from the ordering of the two operands when the types are different).<ref name="Mycroft_1999"/>

Various high level expressions can be recognized which trigger recognition of structures or arrays. However, it is difficult to distinguish many of the possibilities, because of the freedom that machine code or even some high level languages such as C allow with casts and pointer arithmetic.

The example from the previous section could result in the following high level code:
<syntaxhighlight lang="c">
struct T1 {
int v0004;
int v0008;
int v000C;
};
struct T1 *ebx;
ebx->v000C -= ebx->v0004 + ebx->v0008;
</syntaxhighlight>

===Structuring===
The penultimate decompilation phase involves structuring of the IR into higher level constructs such as <code>while</code> loops and <code>if/then/else</code> conditional statements. For example, the machine code
<syntaxhighlight lang="asm">
xor eax, eax
l0002:
or ebx, ebx
jge l0003
add eax,[ebx]
mov ebx,[ebx+0x4]
jmp l0002
l0003:
mov [0x10040000],eax
</syntaxhighlight>
could be translated into:
<syntaxhighlight lang="c">
eax = 0;
while (ebx < 0) {
eax += ebx->v0000;
ebx = ebx->v0004;
}
v10040000 = eax;
</syntaxhighlight>
Unstructured code is more difficult to translate into structured code than already structured code. Solutions include replicating some code, or adding Boolean variables.<ref name="Cifuentes_1994"/>

===Code generation===
The final phase is the generation of the high level code in the back end of the decompiler. Just as a compiler may have several back ends for generating machine code for different architectures, a decompiler may have several back ends for generating high level code in different high level languages.

Just before code generation, it may be desirable to allow an interactive editing of the IR, perhaps using some form of [[graphical user interface]]. This would allow the user to enter comments, and non-generic variable and function names. However, these are almost as easily entered in a post decompilation edit. The user may want to change structural aspects, such as converting a <code>while</code> loop to a <code>for</code> loop. These are less readily modified with a simple text editor, although source [[code refactoring]] tools may assist with this process. The user may need to enter information that failed to be identified during the type analysis phase, e.g. modifying a memory expression to an array or structure expression. Finally, incorrect IR may need to be corrected, or changes made to cause the output code to be more readable.

===Other techniques===
Decompilers using [[neural network]]s have been developed. Such a decompiler may be trained by [[machine learning]] to improve its accuracy over time.<ref name="Meta"/>

==Legality==
{{original research|date=April 2013}}
{{Expert needed|Law|section|talk=Legality section and copyright law|date=March 2011}}
The majority of computer programs are covered by [[copyright]] laws. Although the precise scope of what is covered by copyright differs from region to region, copyright law generally provides the author (the programmer(s) or employer) with a collection of exclusive rights to the program.<ref name="Rowland_2005"/> These rights include the right to [[File copying|make copies]], including copies made into the computer’s [[Random Access Memory|RAM]] (unless creating such a copy is essential for using the program).<ref name="Law"/>
Since the decompilation process involves making multiple such copies, it is generally prohibited without the authorization of the copyright holder. However, because decompilation is often a necessary step in achieving software [[interoperability]], copyright laws in both the United States and Europe permit decompilation to a limited extent.

In the United States, the copyright [[fair use]] defence has been successfully invoked in decompilation cases. For example, in ''[[Sega v. Accolade]]'', the court held that Accolade could lawfully engage in decompilation in order to circumvent the software locking mechanism used by Sega's game consoles.<ref name="PT_2004"/> Additionally, the [[Digital Millennium Copyright Act]] (PUBLIC LAW 105–304<ref name="DMCA_1998"/>) has proper exemptions for both Security Testing and Evaluation in §1201(i), and Reverse Engineering in §1201(f).<ref name="QQVDZ"/>

In Europe, the [[Computer Programs Directive|1991 Software Directive]] explicitly provides for a right to decompile in order to achieve interoperability. The result of a heated debate between, on the one side, software protectionists, and, on the other, academics as well as independent software developers, Article 6 permits decompilation only if a number of conditions are met:

* First, a person or entity must have a license to use the program to be decompiled.
* Second, decompilation must be necessary to achieve [[interoperability]] with the target program or other programs. Interoperability information should therefore not be readily available, such as through manuals or [[Application programming interface|API]] documentation. This is an important limitation. The necessity must be proven by the decompiler. The purpose of this important limitation is primarily to provide an incentive for developers to document and disclose their products' interoperability information.<ref name="Czarnota_1991"/>
* Third, the decompilation process must, if possible, be confined to the parts of the target program relevant to interoperability. Since one of the purposes of decompilation is to gain an understanding of the program structure, this third limitation may be difficult to meet. Again, the burden of proof is on the decompiler.

In addition, Article 6 prescribes that the information obtained through decompilation may not be used for other purposes and that it may not be given to others.

Overall, the decompilation right provided by Article 6 [[Codification (law)|codifies]] what is claimed to be common practice in the software industry. Few European lawsuits are known to have emerged from the decompilation right. This could be interpreted as meaning one of three things:

#) the decompilation right is not used frequently and the decompilation right may therefore have been unnecessary,
#) the decompilation right functions well and provides sufficient legal certainty not to give rise to legal disputes or
#) illegal decompilation goes largely undetected.

In a report of 2000 regarding implementation of the Software Directive by the European member states, the [[European Commission]] seemed to support the second interpretation.<ref name="EU"/>

==See also==
* [[Disassembler]]
* [[Binary recompiler]]
* [[Linker (computing)]]
* [[Abstract interpretation]]
* [[Resource editor]]

=== Java decompilers ===
* [[Mocha (decompiler)|Mocha decompiler]]
* [[JD Decompiler]]
* [[JAD (JAva Decompiler)|JAD decompiler]]

=== Other decompilers ===
* [[.NET Reflector]]
* [[dotPeek]]
* [[JEB Decompiler]] (Android Dalvik, Intel x86, ARM, MIPS, WebAssembly, Ethereum)
* [[Ghidra]]
* [[Ida pro|IDA Pro]], which includes a decompiler as an optional paid feature
* [[Binary Ninja]]
* [https://pypi.org/project/uncompyle6/ uncompyle6] (Python Bytecode from 1.0 to 3.8)

==References==
{{reflist|refs=
<ref name="Cifuentes_1994">{{cite book |author-first=Cristina |author-last=Cifuentes |title=Reverse Compilation Techniques |chapter=Chapter 6 |type=PhD thesis |publisher=[[Queensland University of Technology]] |date=1994 |url=http://www.labri.fr/perso/fleury/download/papers/binary_analysis/cifuentes-thesis.pdf |access-date=2019-12-21 |url-status=live |archive-url=https://web.archive.org/web/20161122154356/http://www.labri.fr/perso/fleury/download/papers/binary_analysis/cifuentes-thesis.pdf |archive-date=2016-11-22}})</ref>
<ref name="Cifuentes_1995">{{cite journal |title=Decompilation of Binary Programs |journal=Software: Practice and Experience |author-first1=Cristina |author-last1=Cifuentes |author-first2=K. John |author-last2=Gough |volume=25 |issue=7 |pages=811–829 |date=July 1995 |citeseerx=10.1.1.14.8073 |doi=10.1002/spe.4380250706|s2cid=8229401}}</ref>
<ref name="Mycroft_1999">{{cite book |chapter=Type-Based Decompilation |title=Programming languages and systems: 8th European Symposium on Programming Languages and Systems |author-first=Alan |author-last=Mycroft |editor-first=S. Doaitse |editor-last=Swierstra |pages=208–223 |date=1999 |publisher=[[Springer-Verlag]] |isbn=3-540-65699-5}}</ref>
<ref name="Rowland_2005">{{cite book |title=Information technology law |author-first=Diane |author-last=Rowland |date=2005 |edition=3 |publisher=Cavendish |isbn=1-85941-756-6}}</ref>
<ref name="Law">{{cite web |url=http://www.copyright.gov/title17/92chap1.html#106 |title=U.S. Copyright Office - Copyright Law: Chapter 1 |access-date=2014-04-10 |archive-date=2017-12-25 |archive-url=https://web.archive.org/web/20171225173213/http://www.copyright.gov/title17/92chap1.html#106 |url-status=live}}</ref>
<ref name="PT_2004">{{cite web |url=http://www.program-transformation.org/Transform/LegalityOfDecompilation |title=The Legality of Decompilation |publisher=Program-transformation.org |date=2004-12-03 |access-date=2010-09-15 |archive-date=2010-09-22 |archive-url=https://web.archive.org/web/20100922091938/http://www.program-transformation.org/Transform/LegalityOfDecompilation |url-status=live}}</ref>
<ref name="DMCA_1998">{{cite web |url=http://www.gpo.gov/fdsys/pkg/PLAW-105publ304/pdf/PLAW-105publ304.pdf |title=Digital Millennium Copyright Act |publisher=[[US Congress]] |date=1998-10-28 |access-date=2013-11-15 |archive-date=2013-12-10 |archive-url=https://web.archive.org/web/20131210205708/http://www.gpo.gov/fdsys/pkg/PLAW-105publ304/pdf/PLAW-105publ304.pdf |url-status=live}}</ref>
<ref name="Czarnota_1991">{{cite book |author-first1=Bridget |author-last1=Czarnota |author-first2=Robert J. |author-last2=Hart |title=Legal protection of computer programs in Europe: a guide to the EC directive |date=1991 |location=London |publisher=[[Butterworths Tolley]] |isbn=0-40600542-7}}</ref>
<ref name="EU">{{cite web |url=https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:52000DC0199 |title=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 |access-date=2020-12-26 |archive-date=2020-12-04 |archive-url=https://web.archive.org/web/20201204144726/https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:52000DC0199 |url-status=live}}</ref>
<ref name="Meta">{{cite web |url=https://ai.facebook.com/blog/introducing-n-bref-a-neural-based-decompiler-framework/|title=Introducing N-Bref: a neural-based decompiler framework |author-first1=Yuandong |author-last1=Tian |author-first2=Cheng |author-last2=Fu |date=2021-01-27 |access-date=2022-12-30}}</ref>
<ref name="QQVDZ">{{Cite web |url=https://www.federalregister.gov/d/2018-23241/p-26 |title=Federal Register :: Request Access |date=26 October 2018 |access-date=2021-01-31 |archive-date=2022-01-25 |archive-url=https://web.archive.org/web/20220125073820/https://www.federalregister.gov/documents/2018/10/26/2018-23241/exemption-to-prohibition-on-circumvention-of-copyright-protection-systems-for-access-control |url-status=live}}</ref>
}}

==External links==
{{Wiktionary|decompiler}}
{{Wikibooks|Reverse Engineering}}

{{Authority control}}

[[Category:Compilers|*]]
[[Category:Decompilers| ]]
[[Category:Utility software types]]
[[Category:Reverse engineering]]

Decompiler - Revision history

imported>Dabmasterars: Fixed a typo, added more wikilinks.