Talk:Decompiler

Untitled

In the process of "merging" decompilation and this article decompiler, a fair bit of material has been cut. For example, the idea that entry points to DLLs produce better output; I would argue that this is one of the jobs of a good decompiler. Other snipped material suggests that a symbol table is important; I argue that the symbols can be edited post decompilation. There is also the observation that decompilation is the inverse of compilation; I suggest that this is obvious from the term itself.

I think we could also lose the "See Also" section. "Decompilation" is now almost a redirect back to this article, and the other terms seem weakly related to me, apart from "disassembler", which is already linked from the main text. This will make it a slim article, but I don't think that much more if any belongs here. I'm writing a theis on this subject, so I could add plenty more, but I don't think that much more belongs in an encyclopedia.

Comments welcome. --Mike Van Emmerik 8 July 2005 13:11 (UTC)

Thanks, Mike Van Emmerik. I don't know much about decompilation/decompilers myself, so I figured I probably shouldn't be the one to merge the two articles. -Hyad 21:44, July 9, 2005 (UTC)

As interesting as I find decompilers (as I'm sure you know), I think the whole "Phases" section, which I have renamed to "Design" could probably be replaced by a few good references. I suspect some admins will delete it soon anyway, as it probably doesn't belong in an encyclopedia anyway and may be considered "original research", and you might be considered to have a conflicting interest. So might I for that matter. QuantumG (talk) 13:21, 5 December 2007 (UTC)

Reverse Engineering Wikibook

I've started a wikibook on Wikibooks:Reverse Engineering. It has several chapters so far, but because of low readership, and few contributers, we have been unable to give particularly good coverage to topics such as decompilation or disassembly. I think that a complete (or mostly complete) wikibook on reverse engineering would be an excellent free resource for people interested in the field. On that note, if anybody who reads this would like to contribute to the wikibook, feel free to stop on by and share your knowledge. --Whiteknight 14:07, 12 October 2005 (UTC)

Legality section and copyright law

The legality section claims that the copyright holder has rights to the binary or machine code. That is not the case under US law. Apple Computer versus Franklin Computer resulted in binaries not being protected by copyright. An expert needs to review the legality section and remove misinformation. —Preceding unsigned comment added by 98.243.106.85 (talk) 11:30, 17 July 2010 (UTC)

I would like to add the following. Nobody is being sued if he dissects a car engine he owns with a hack saw and does a chemical analysis of the oil springs. And somebody who looks at the internals of a computer program using a decompiler is considered a criminal? Especially because no harm ensues to anybody, it goes against the feeling of justice. Furthermore, suppose I decompile a program of someone and uncover an algorithm, that is not patented and used as a trade secret. There is no way it can be proved that I didn't discover the algorithm by myself. As a matter of fact we know it happened all the time in Borland versus Microsoft C compiler wars, and it probably happens right now in areas of databases. So in my opinion the reason that there is no jurisprudence around this is simple that it is weak law and bad justice and favours economic power over innovation. Would be offenders are forced into submission before it comes to court. I strongly agree that this section should be reviewed by a legal expert.

Then there is the matter of flaws. If my car exhaust has a hole I can weld the hole shut. If I have a computer program that fails on me, I would not be legally allowed to fix it? Come on!

Albert van der Horst 80.100.243.19 (talk) 20:50, 8 December 2010 (UTC)

This page is for discussions about improving the article, not personal rants. Dmcq (talk) 21:33, 8 December 2010 (UTC)

The Legality section is horribly outdated. It needs to incorporate the relevant sections on trade secrets from the US Defend Trade Secrets Act of 2016 and of the EU Directive on the Protection of Trade Secrets of 2016. According to both laws, it's illegal to obtain source code by means of decompiling any program that's not explicitely open source, and is effective as soon as the original creator or rights owner even just makes a public statement on their website to that effect that they don't allow decompiling of their product (such as in the TOS, EULA, or informally) in order to obtain the source code, and they can demonstrate that they've applied any kind of technical security measures to prevent it. It's like the difference between just downloading a file lying on a public server and actively cracking a copy-protection mechanism. The company doesn't even have to sue, it can simply report suspected such activity to the police. Note that this is different from reverse engineering in the form of independently writing code with the same or similar program output and behavior, and from using simulators or translators (such as Wine) that supply other OS with libraries to understand Windows APIs. --2003:EF:170A:9222:AD00:8CAF:5BFC:28BE (talk) 16:59, 1 January 2023 (UTC)

Copyright is not the only legal issue. The License of most commercial software specifically forbids reverse engineering.

The law in some countries states that products must be 'of merchantable quality' and 'fit for purpose'. The consumer has the right to return products that fail to meet these standards.

In the different situation of a physical item, the customer who wishes to obtain recourse under warranty must have given the supplier/producer an opportunity to rectify the situation. Attempting to fix the problem oneself will usually invalidate the warranty.

This article may be encouraging illegal actions. BlueWren0123 (talk) 09:49, 24 October 2023 (UTC)

Resource Editors as a DeCompiler

I think you should also add some information about Resource Editors, because it's a kind of decompiler - it's allows to change the code of a compiled software, althogh the developer might block the access to the code using this type of softwares, so the only thing that will appear is some of the file properties and maybe a Manifest file if was used. Galzigler (talk) 19:02, 25 October 2011 (UTC)

While resource editors/extractors may warrant a "see also" link, they aren't particularly similar to decompilers. They are used to view or edit the data in a binary that isn't compiled code. CorrosiveSubstance (talk) 21:10, 26 August 2012 (UTC)

Decompilers for Higher-level VMs, Bytecode and Dynamic Languages

This article is largely about decompilers which start out with machine code. However for a couple of decades, there are higher-level languages with higher level bytecode (Ruby, Python, CIL, Lua, GNU Emacs Lisp, Visual Basic, Pascal P-Code, Smalltalk, and Ethereum Solidity) or interpreter threaded tree structures (think Perl5, Korn shell). What characterizes these languages is that the objects in these kinds of interpreters matches the primitive objects of the underlying programming language that they serve. For example Python bytecode variables can be dictionaries, sets, functions, instance objects and so on.

Given this, sections of the article such as data flow analysis, type analysis, universal IR, and possibly loader are not needed. And in my opinion there are approaches not mentioned that are possible here.

Given this dichotomy, I think decompilers for dynamic language interpreters could be in its own section or maybe a different page altogether. I've written some of my thoughts about decompilation in such high-level languages at http://rocky.github.io/Deparsing-Paper.pdf (and that is in need of revision).

Decompilers for Java and perhaps WASM is in my opinion somewhere in the middle of what is here and what is described in the paper cited above. Typically Java compiles to JVM, which is bytecode. But the types are not the same as the high-level objects in other bytecode interpreters. And it has both stack operations (favored in higher-level bytecode), as well a also register instructions of non-interpreters. So decompilers for Java and JVM languages may be in a slightly different class.

Since there is a section for Java decompiler, I think there should be a section for Python as well. There have been a number of different Python decompilers written which work in different kinds of ways. — Preceding unsigned comment added by Rockybernstein (talk • contribs) 15:02, 24 December 2021 (UTC)