Best class decompiler?
in [Java Programming]
|
From: Peter Duniho on 5 Jul 2010 20:24 Mike Schilling wrote: > "Peter Duniho" <NpOeStPeAdM(a)NnOwSlPiAnMk.com> wrote in message > news:Ua-dnaBDH6Wsr6_RnZ2dnUVZ_oWdnZ2d(a)posted.palinacquisition... >> The .NET community has been very well-served by Red Gate's Reflector >> utility, which does a wonderful job of disassembling .NET programs. >> No one has tried to sue or prosecute them, nor do I think it likely >> anyone would. > > I've always suspect that Microsoft pays for Reflector and provides > helpful hints to its developers. That's a lot cheaper than documenting > all the hidden behavior you currently learn about only from using > Reflector on the system assemblies. Ignoring for a moment the fallacy of thinking there even might be some motivation to "document hidden behavior" (if you hid the behavior, why would you want to document it?)� Microsoft's .NET source code is available directly from Microsoft. There's very little you can learn from Reflector that you can't learn from the source code directly (the main issue is that Microsoft consistently lags in their release of the source code, so Reflector is still the best way to look at the most recent .NET implementation, at least for the areas that have been changed in that version). I wouldn't be surprised if there are people at Microsoft who have at least some kind of relationship with the folks at Red Gate and who help them out. But that's actually not unusual for any software publisher with a strong presence in the Windows community. I doubt that whatever support Microsoft offers Red Gate, they do so for any reason other than that it's part of their interest in making sure the best tools are available for Windows development, and that they support the significant publishers in the Windows community generally. Pete
From: Joshua Cranmer on 5 Jul 2010 20:22 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. > 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. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Mike Schilling on 5 Jul 2010 20:28 "Peter Duniho" <NpOeStPeAdM(a)NnOwSlPiAnMk.com> wrote in message news:Iq-dnUt2iOAp6q_RnZ2dnUVZ_tqdnZ2d(a)posted.palinacquisition... > Mike Schilling wrote: >> "Peter Duniho" <NpOeStPeAdM(a)NnOwSlPiAnMk.com> wrote in message >> news:Ua-dnaBDH6Wsr6_RnZ2dnUVZ_oWdnZ2d(a)posted.palinacquisition... >>> The .NET community has been very well-served by Red Gate's Reflector >>> utility, which does a wonderful job of disassembling .NET programs. No >>> one has tried to sue or prosecute them, nor do I think it likely anyone >>> would. >> >> I've always suspect that Microsoft pays for Reflector and provides >> helpful hints to its developers. That's a lot cheaper than documenting >> all the hidden behavior you currently learn about only from using >> Reflector on the system assemblies. > > Ignoring for a moment the fallacy of thinking there even might be some > motivation to "document hidden behavior" (if you hid the behavior, why > would you want to document it?)� Well, if you document next to nothing, and that badly, almost everything's hidden.
From: Peter Duniho on 5 Jul 2010 20:50 Mike Schilling wrote: > [...] >> Ignoring for a moment the fallacy of thinking there even might be some >> motivation to "document hidden behavior" (if you hid the behavior, why >> would you want to document it?)� > > Well, if you document next to nothing, and that badly, almost > everything's hidden. Fortunately, that's not the case with .NET. I have very rarely needed to go to the source code (Reflector-generated or published) to understand how to use the public API. My most common reason for inspecting the source code is sheer curiosity. There are some areas of .NET that are not as well-documented as others, especially for the newer features. I find WPF in particular to be lacking in good reference material, though the user-guide section is much better. But I'll take .NET's brand of "hit and miss" over Java's any day (and really, I don't have that much trouble with Java either). Pete
From: Mike Schilling on 5 Jul 2010 21:31
"Peter Duniho" <NpOeStPeAdM(a)NnOwSlPiAnMk.com> wrote in message news:bfOdnaRwTf5A4K_RnZ2dnUVZ_sednZ2d(a)posted.palinacquisition... > Mike Schilling wrote: >> [...] >>> Ignoring for a moment the fallacy of thinking there even might be some >>> motivation to "document hidden behavior" (if you hid the behavior, why >>> would you want to document it?)� >> >> Well, if you document next to nothing, and that badly, almost >> everything's hidden. > > Fortunately, that's not the case with .NET. > > I have very rarely needed to go to the source code (Reflector-generated or > published) to understand how to use the public API. My most common reason > for inspecting the source code is sheer curiosity. > > There are some areas of .NET that are not as well-documented as others, > especially for the newer features. I find WPF in particular to be lacking > in good reference material, though the user-guide section is much better. WCF too, at least in 3.5. There's simply no comprehensive list of the different customizations that can be made to a service. Perhaps it's gotten better since. |