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 from 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. 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)

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 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, Emacs Lisp) 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 kinds of things that are possible are used 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 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)