Best class decompiler?
in [Java Programming]
|
From: BGB / cr88192 on 6 Jul 2010 04:52 "Joshua Cranmer" <Pidgeot18(a)verizon.invalid> wrote in message news:i0tt10$9gi$1(a)news-int.gatech.edu... > On 07/05/2010 06:52 PM, BGB / cr88192 wrote: >> for languages like C and C++, there are some useful hints: >> the target of a 'call' is typically the entry point of a function (extra >> so >> if one sees the usual "push ebp; mov ebp, esp" sequence...); >> the "ret" is often the end, and is almost assuredly the end so long as >> there >> were not previously conditional jumps past this point... > > That generally works, but some optimizations can throw that out the > window. ebp assumes you do not have -fomit-frame-pointer. IDA seems to > have given good results for me in function determination in practice. > However, if you have functions only called indirectly, using only tracing > from entry points will miss some functions and assuming all executable > sections are code and looking for function prologues will probably create > some "fake" functions. Another reason why fully automated systems will > have problems. > fair enough... >> yes, but these are problems for a decompiler, not necessarily the >> disassembler phase. >> if the disassembler can produce a sane representation of all the >> instructions, its work is done... > > You can draw the line on either side. Most uses of disassembly will want > the function method anyways, so anyone making a hypothetical disassembler > library would probably include these analyses as well. possibly. however, this depends some on ISA. for example, matters are a little easier with Windows on x64, since the prologue and epilogue are fairly well defined, and to do something differently from the predefined forms is essentially a violation of the ABI. granted, yes, it can't be done reliably on x86.
From: BGB / cr88192 on 6 Jul 2010 12:17 "Peter Duniho" <NpOeStPeAdM(a)NnOwSlPiAnMk.com> wrote in message news:57idnUKpJo_p66_RnZ2dnUVZ_gOdnZ2d(a)posted.palinacquisition... > BGB / cr88192 wrote: >> [...] >>> I was imprecise, as .NET Reflector is both a disassembler (inasmuch as >>> Java or .NET byte code are "assembly" languages) and a decompiler >>> (Reflector will reconstruct to the best of its impressive abilities any >>> managed language version of the MSIL it's analyzing). It has had no >>> real legal challenges to its existence or use. >>> >> >> fair enough... >> then again, it is possibly because this hasn't really come up in court... >> >> the question is not what what has happened thus far, but what would a >> judge and jury conclude, and which jurisdictions the plaintif and >> defendants are located within... > > That is always true with any legal question. However, it's fairly > implausible that a tool that doesn't do any decryption applied to data > that hasn't been encrypted would somehow be found in violation of the DMCA > with respect to the "no circumventing encryption" clause. it can be used on the decryption logic... it can also be used by someone wanting to try to interface with a decryption module by someone wanting to make unauthorized use of the encrypted data. .... > That said, there are some people who can tolerate no risk whatsoever. > Those people are probably not well-suited to engaging in any creative > business at all, since creative enterprises inherently involve doing > things that no one has done before, and thus for which there is poor or no > legal precedent to look to for guidance. > > Fortunately, there are still people who are willing to try something new > and not worry about remote possibilities of legal action or other unlikely > events. And the vast majority of the time, no harm comes to them. yep, fair enough... >> [...] >>> The fact that the tool displays the low-level byte code as some >>> reconstructed higher-level language versus simply a textual >>> representation of the byte code itself is essentially irrelevant. In >>> neither case is copyright being violated. Simply rearranging, >>> reformatting, redisplaying, etc. some copyrighted material that you >>> already have legal access to does not in and of itself violate the >>> copyright. >> >> yes... >> >> >> however, the issue is if the tool can be used for committing a crime, and >> has any substantial non-infringing use. >> this would be the type of argument likely to come up WRT a tool. > > I think it's a pretty far stretch to argue that a decompiler in any > significant way helps someone violate copyright, never mind in a context > that involves encryption. And it _clearly_ has substantial non-infringing > use. fair enough...
From: Peter Duniho on 6 Jul 2010 12:30 BGB / cr88192 wrote: > [...] >> That is always true with any legal question. However, it's fairly >> implausible that a tool that doesn't do any decryption applied to data >> that hasn't been encrypted would somehow be found in violation of the DMCA >> with respect to the "no circumventing encryption" clause. > > it can be used on the decryption logic... > > it can also be used by someone wanting to try to interface with a decryption > module by someone wanting to make unauthorized use of the encrypted data. [...] That does not in and of itself constitute circumventing encryption for the purpose of violating copyright, as the circumvention would be taking place after the fact, not through the use of the decompiler itself. The only copyrighted material related to the use of the decompiler would be the program the decompiler operates on, not whatever encrypted, copyrighted material that program is intended for. To view it any other way would be to classify every component even remotely attached to the process of analyzing and circumventing the actual encryption logic. And in any case, even if you do attempt to follow that logic, it's patently obvious in that hypothetical scenario that the decompiler was not created for the purpose of circumventing the encryption. The "substantial non-infringing use" would hold sway, just as it would for your RAM, your hard drive, your CPU, your video card, your operating system, your electricity provider, the builders who constructed the house to protect all of the copyright-circumvention technology from the elements, the farmers who provide the food that helps keep the copyright-circumventer alive� Pete
From: Lew on 10 Jul 2010 22:57
Arne Vajhøj wrote: > The problem is to be absolutely sure that the new code actually > has the exact same functionality as the unreadable code. I couldn't agree more. It helps if you have a good set of requirements, or can elicit such. Without that, there is the very urgent need to fully understand what the bad code does - a task that is required regardless of whether you rewrite from scratch or adapt from existing code. I don't remember where, now, but I read an article some months ago pointing out that even (or perhaps especially) the messiest code has what it has because it had to solve one problem after another, and careless rewrites will lose that implicit knowledge. The lesson there being that going forward, rewriting or adapting, one must fully document the decisions and reasons for the way the code is what it is, both in source comments and extrinsic documentation. Once one recognizes the problem it's necessary to break the cycle that caused the mess one encountered. > That would be solved by a serious suite of unit tests. But even though > that is not uncommon in general, then the chance that very unreadable > code has good unit tests is not so high. And one desirable action after and during the aforementioned analysis is to rectify the dearth of unit tests, as you pointed out: > And if you need to understand the unreadable code, then one could > fix that. > > It would still be good to rewrite it though, because the next > developer that has to look at that code would have a lot easier > job. Now that is the professional developer's attitude! Code written with attention to maintenance is better code. And successful code spends far more time in maintenance phase than in initial development phase. (And why would anyone develop code not to be successful?) Lew wrote: >> As for justification to rewrite parts of Hibernate, I am at best >> skeptical. Hibernate is a robust and rather complete set of libraries. I >> have to wonder what changes it required that would not have been better >> served by writing libraries or client code extrinsic to the Hibernate >> libraries themselves. OP? Arne Vajhøj wrote: > I can not see any reason either. > > But sometimes weird requirements show up. > > There may be a 98% chance that the need to hack the library > was utterly bullshit, but that still leaves 2%. We're still waiting for the OP to answer that question almost a week after I asked it. Lew wrote: >> What raises my suspicions even further is that >> the rewrites were performed by people who didn't have the wisdom to >> protect their code against loss. Arne wrote: > That is where you are just guessing. Well, duh. Anything short of absolute certainty is "just" guessing, but I'd lay odds on it. > The fact is that there are no way to make it impossible to > lose source code. > > One can only make it extremely unlikely to happen. To paraphrase the master, there may be a 2% chance that the effort was made to protect the code, but that still leaves 98%. Blake McBride, I ask again - what were the changes to those "large JAR files such as Hibernate", and why had that to be done to the libraries themselves rather than to the layer(s) that used them? Please answer. -- Lew |