Re: In search of the perfect Disassembler



Betov wrote:
> randyhyde@xxxxxxxxxxxxx écrivait news:1117549033.580722.44400
> @g44g2000cwa.googlegroups.com:
>
> > For the longest time, Rene was claiming that 100% automatic (and
> > perfect) disassembly was possible and RosAsm was going to do that.
>
> Liar.

Too bad the claims you made were on the MASMForum. Perhaps you've
forgotten because you made such claims in the "heat of battle?" In any
case, let's say you are correct and you've never made such a claim. The
fact that you've expended considerable effort fighting claims that the
halting theorem was just "academic B.S." certainly indicates that you
felt you were going to provide a perfect disassembly. IIRC, it was
about six months (into the latter part of 2003, according to posts I'm
reading now) that you back-tracked on the capabilities of your
disassembler.

So we're faced with one of two possibilities: you were lying then or
you are lying now. Either you recognized that 100% automatic
disassembly was impossible early on and you made all those early posts
against the claims of the halting theorem knowing that the other person
was correct (meaning you were lying back then), or you finally
discovered that perfect disassembly was not possible and you changed
your opinion on the subject (meaning you're lying now). Take your pick.



>
> Feel free to show any Link to a Post of mine, where i
> would have written that RosAsm Disassembler was going
> to disassemble and Reassemble all Applications in two
> Clicks.

Okay, point to Rene. I do see figures like 95% being discussed though.
No chance of reaching that, either.

>
> > All the while maintaining that
> > "interactive disassembly" was a waste of time.
>
> True. More than this: This is unhonest illusion selling:
>
> "The Disassembler fails to do the job. Solution: Let us
> let the user do the job, instead". Absurd.

Be careful what you say. The statement immediately above certainly
gives the impression that if the user cannot do it, the program can.
Therefore, 100% perfect disassembly must be possible, eh?


>
> With Small Apps, a Disassembler must be able to produce
> a 100% valid Disassembly Source from most Files.

Impossible. Size is not the relevant parameter. Coding style is. When
you get your disassembler finished, I can promise you that I can break
it in a few minutes with a few lines of code.

> In the
> case of RosAsm Disassembler-Reassembler, there is no need
> of the so called "Interactivity", because the user can
> modify the Source, by hand, in case of minor errors, and
> in case of complete failure, there is no hope, anyway.

In modern software terms, a 30K program is *tiny*. Certainly a good
example of a "small app". I recently disassembled such an application
and it produced a listing about 140 pages long. It took me about a
month to clean up that code and figure out what was going on. And that,
by the way, was for analysis purposes only (i.e., I didn't bother
fixing the code to the point where it could be reassembled, producing
the same exact output as the original source file would, when assembled
to an arbitrary load address).

Fixing "minor" errors by hand is a disaster. For example, one nice
thing about IDAPro's interactivity is that I can easily change labels
at any time and the changes are automatically reflected throughout the
source file. You might think that this is a simple "search and replace"
editor function, but it is not. The problem with S&R is that if I
accidently use the same label twice, you've broken the code (backing
out of a mistake is very difficult). OTOH, an interactive disassembler
like IDAPro automatically catches problems like this and doesn't allow
you to make this mistake. This is one of 100s of useful features that
IDAPro provides.

In the past you've made posts along the lines of "I'll just provide the
gross feature set and get back to the little features when I have
time." The problem with that approach is that you never get back to
those features because you always find the next "big feature" to add to
your program. I suspect that when you get "happy" with the
disassembler, you'll run off and start working on those "wizards" you
keep talking about (or maybe some of the "preparsers" you keep talking
about). The only problem is, all the nice features that make a
disassembler convenient to use will still be absent from your product.
Again, people don't need a "two click disassembly/reassembly". They've
already got the executable file. Producing a new (broken, most likely)
version of it isn't too important. What a disassembler user *does* need
is the ability to easy correct the difficiencies in their code that the
disassembler couldn't handle automatically. And they need the ability
to save their disassembly work in progress, so they can continue where
they left off in the last interactive disassembly session (i.e., like
IDAPro does). Somehow, I suspect you'll never get around to cleaning up
the disassembler to that level. If history is any indication, you'll
get distracted by another project and never get around to finishing the
disassembler. Want proof? What's going on with your assembler these
days? Still a *lot* of clean up to do there. Why not work on the main
tool that everyone who uses RosAsm actually uses? That would be the
*assembler*, not the disassembler.


>
> On middle size and big size apps, either the disassembler
> is able to do it all clean, or not.

Again, size has nothing to do with it. The disassembler will handle a
20 megabyte executable filled with NOPs with no problems at all. And it
will choke on a 50 byte program written in such a way that the
disassembler cannot figure out what's going on. Coding style, not size,
is the determining factor. I would have hoped that someone who has
spent two years, or so, working on a disassembler would understand
this.

> In case not, there
> is no hope that the user could be ever able to do better
> than the Disassembler Engines.

I doubt RosAsm's disassembler would *ever* be able to properly
disassemble the code I've recently looked at. And even if it did,
there's a lot more to disassembly than properly converting code and
data to their appropriate source code form. You claim (within the past
year or so) that RosAsm will help the HLL programmers convert all their
HLL code to RosAsm so they can start working in assembly language.
Let's assume that RosAsm's disassembler did a perfect job disassembling
the binary code to RosAsm source code. Do you honestly think that
people *want* to work with the synthetic source code that a
disassembler produces? By the time they add comments, real labels, and
otherwise organize their source code to make it (more) readable, they
could have manually translated the source code by hand.

And I don't know if you've looked at the assembly output of many
compilers (well, I do know, it's pretty obvious that you have not), the
code they produce is very difficult to read by the average person.
You're living in a dream world if you think that people are going to
disassemble their HLL code and work on the disassembled output with
RosAsm rather than continuing to support the code in the HLL in which
it was originally written. Even if they want to convert it to assembly,
using a disassembler just *isn't* the right way to proceed. The sad
part is that you're not going to figure this out until you've wasted a
fair percentage of your life on the disassembler. You'll have a great
toy to play with, but it will be of little practical value and it
certainly *won't* see much usage the way you envision.


> And saying the reverse is
> nothing but lies and swindling, given the demential work
> that the user would have to do.

???

>
> Though for the Users and for the Developpers of the
> Disassembler, the way this "bit of Interactivity"
> is implemented will be really much helpfull, for
> two purposes:
>
> 1) Speed-up the Multiple Disassemblies of a same File.
>
> 2) Force some Recognitions in a simple click, in order
> to experiment and understand where and why an Automatic
> Recognition was wrong. Accessory, it may even achieve
> the work promissed in vain by the so called Interactive
> thingies, with their illusions selling, probably in the
> case of middle size applications... To be tested...

Again, without interactivity, the program will be worthless.

>
>
> > Also note: when Rene announces that his disassembler is complete, I'll
> > be able to break it in about two minutes. It's not hard to confuse an
> > automatic disassembler.
>
> Could anybody have any doubt about this point?

Of course not.


>
> After all, aren't you the definitive idiot who
> claims every nbow and then that "RosAsm Symbols
> Table is broken"?

Shall I post the source code yet once again?
Is it no wonder your user base is so small? You waste critical time
working on a disassembler that will never be useful, while important
issues to RosAsm users, such as the ability to properly handle
syntactically correct source files, are ignored. No wonder you've only
been able to get about 80 members on your support board.
Cheers,
Randy Hyde

.

Relevant Pages

  • De- Evolution
    ... > RosAsm Disassembler-Reassembler is actually (developement ... disassembler *doesn't* disassemble anything properly. ... RosASM as long as you take the attitude "I'll get around ... recursive macro invocations. ...
    (alt.lang.asm)
  • Re: .EXE -> .ASM -> .EXE
    ... You are mistaken in asuming that all RosAsm users are only the ones ... But you guys have claimed how great your disassembler ... The goal is translation of libraries to pure assembly code, ... insetad simply you do as in other assemblers that is.. ...
    (alt.lang.asm)
  • Re: Theoretical Computer Science and Disassemblers
    ... you probably are not using RosAsm disassembler ... It ws added recently some interactivity. ... The same thing applies to RosAsm, the automated process ios took in 1st ... try disassembling a simple VB app on Ida ...
    (alt.lang.asm)
  • Re: Renes Revisionist History, Again
    ... When I said the apps "sucked hard", ... I was astonished that even Rene would use a few simple "hello world" ... examples as proof that RosAsm is "the fastest, ... >> have you seen how poorly it works compared to a real disassembler? ...
    (alt.lang.asm)
  • Re: A modern view of the halting problem
    ... RosAsm can disassemble properly. ... the other ones, where the Disassembler fails. ... RosAsm could chocking when adding a NOP to a disasembly. ... you use separate code to process the RosAsm equates file. ...
    (alt.lang.asm)