Discussion:
Disassembler
(too old to reply)
Profetas
2004-05-18 20:42:45 UTC
Permalink
Hi I am looking for a good Disassembler.
I am using ndisasm but I can't assembly the disassembled
file back. because it can't deal with the labels.
if you have any sug--ion.

Thanks
Eric
2004-05-19 04:06:50 UTC
Permalink
Post by Profetas
Hi I am looking for a good Disassembler.
I am using ndisasm but I can't assembly the disassembled
file back. because it can't deal with the labels.
if you have any sug--ion.
Thanks
What kind of labels is it generating, and what assembler are you using that
has trouble with them? possibly you could create a short script to re-do
the labels to something workable. Are they too long, is that the problem?

need more input :-)

Eric
Profetas
2004-05-19 05:16:37 UTC
Permalink
The program has been half coded as NASM and other half as C++

the problem whit the labels are that when I disasm
It gives me the address instead of the label, and when I try
to assemble it back it will ask for a label
here is some bit of the program disasm
00000010 0200 add al,[bx+si]
00000012 0300 add ax,[bx+si]
00000014 0100 add [bx+si],ax
00000016 0000 add [bx+si],al
00000018 E080 loopne 0xff9a
0000001A 0408 add al,0x8
0000001C 3400 xor al,0x0
0000001E 0000 add [bx+si],al
00000020 50 push ax
00000021 D30F ror word [bx],cl
00000023 0000 add [bx+si],al
00000025 0000 add [bx+si],al
00000027 0034 add [si],dh
00000029 0020 add [bx+si],ah
0000002B 0003 add [bp+di],al
0000002D 0028 add [bx+si],ch


I created a script to remove the first bit in the front

and this is what I get when I try to recompile it

head.buff:1: error: label or instruction expected at start of line
head.buff:410: error: label or instruction expected at start of line
head.buff:481: error: label or instruction expected at start of line


I just whante to disasm and the assemble it back
Frank Kotler
2004-05-19 06:40:20 UTC
Permalink
Post by Profetas
The program has been half coded as NASM and other half as C++
16-bit C++ or 32-bit C++?
Post by Profetas
the problem whit the labels are that when I disasm
It gives me the address instead of the label,
The label isn't *in* the object code, so of course ndisasm can't
reproduce it.
Post by Profetas
and when I try
to assemble it back it will ask for a label
What I do is delete the leading zero, so, for example:

00000018 E080 loopne 0xff9a

becomes:

00000018 E080 loopne xff9a

Then I find "ff9a" in the address column and make it "xff9a:". (not in
this particular file...) This gets real tedious in anything more than a
couple dozen bytes. Replace 'em with "meaningful" labels, as soon as you
figure out what's what.
Post by Profetas
here is some bit of the program disasm
00000010 0200 add al,[bx+si]
00000012 0300 add ax,[bx+si]
00000014 0100 add [bx+si],ax
00000016 0000 add [bx+si],al
00000018 E080 loopne 0xff9a
0000001A 0408 add al,0x8
0000001C 3400 xor al,0x0
0000001E 0000 add [bx+si],al
00000020 50 push ax
00000021 D30F ror word [bx],cl
00000023 0000 add [bx+si],al
00000025 0000 add [bx+si],al
00000027 0034 add [si],dh
00000029 0020 add [bx+si],ah
0000002B 0003 add [bp+di],al
0000002D 0028 add [bx+si],ch
Looks to me like you're disassembling data...
Post by Profetas
I created a script to remove the first bit in the front
The address and opcode columns, you mean?
Post by Profetas
and this is what I get when I try to recompile it
head.buff:1: error: label or instruction expected at start of line
head.buff:410: error: label or instruction expected at start of line
head.buff:481: error: label or instruction expected at start of line
And what do these lines look like, after being processsed by your
script? This doesn't sound like a "label problem" to me.
Post by Profetas
I just whante to disasm and the assemble it back
A disassembly - at least with ndisasm - is *not* sourcecode. Ndisasm is
pretty dumb, at best - doesn't try to read and/or skip over any headers
or data. There's supposed to be an "autosynch" feature, but it doesn't
work, that I've noticed. You'll have to feed ndisasm a whole long string
of command-line switches to get anything intelligent out of it. RTFM, if
you haven't:

http://nasm.sourceforge.net/doc/html/nasmdoca.html

IDA has a reputation as a better disassembler (ndisasm's pretty easy to
beat), but I doubt it'll produce Nasm-compatible, assembleable source,
either.

http://www.datarescue.com/

I think I've got a patch for ndisasm, contributed by "Anonymous Coward",
that allows ndisasm to produce something more like source code. I'll
take a look at it, and get back to ya if it looks like something you'd
want. (can you build Nasm?)

Later,
Frank
Frank Kotler
2004-05-19 07:40:31 UTC
Permalink
Post by Frank Kotler
I think I've got a patch for ndisasm, contributed by "Anonymous Coward",
that allows ndisasm to produce something more like source code. I'll
take a look at it, and get back to ya if it looks like something you'd
want. (can you build Nasm?)
Later,
Well, that was easy... A.C.'s added a "-j" switch, for "just
instructions. Output from:

ndisasm -u -j -o 0x8048000 -e 0x80 showenv>tmp

Looks like:

mov eax,[esp]
lea ebx,[esp+eax*4+0x8]
mov esi,[ebx]
or esi,esi
jz 0x8048021
call 0x804802a
mov esi,0x80480c6
call 0x804802a
add ebx,byte +0x4
jmp short 0x8048007
xor ebx,ebx
mov eax,0x1
int 0x80
pusha
mov eax,0x4
mov ebx,0x1
mov ecx,esi
or edx,byte -0x1
cmp byte [ecx+edx+0x1],0x1
inc edx
jnc 0x804803a
int 0x80
popa
ret
... and a whole flock more garbage that I've snipped...

As you see, it doesn't do anything about labels. If you've got a copy of
the disassembly with and without the "-j" switch "side by side" it isn't
*too* bad to make up labels and substitute 'em... Not something I'd want
to do on something as large as I imagine your C++ output to be!!!

You might be better off to start with the asm output of your C++
compiler. Better yet, look over what the C++ code *does*, and write it
from scratch.

Anyway, if you want that "-j" patch... even if you don't, it's no
longer'n a Bethpost :) Here 'tis:

--- ndisasm.c.0.98.38
+++ ndisasm.c
@@ -21,9 +21,10 @@
#define BPL 8 /* bytes per line of hex dump */

static const char *help =
-"usage: ndisasm [-a] [-i] [-h] [-r] [-u] [-b bits] [-o origin] [-s
sync...]\n"
+"usage: ndisasm [-a] [-i] [-j] [-h] [-r] [-u] [-b bits] [-o origin] [-s
sync...]\n"
" [-e bytes] [-k start,bytes] [-p vendor] file\n"
" -a or -i activates auto (intelligent) sync\n"
+" -j just emit instructions -- no offsets or encodings\n"
" -u sets USE32 (32-bit mode)\n"
" -b 16 or -b 32 sets number of bits too\n"
" -h displays this text\n"
@@ -32,7 +33,7 @@
" -k avoids disassembling <bytes> bytes from position <start>\n"
" -p selects the preferred vendor instruction set (intel, amd, cyrix,
idt)\n";

-static void output_ins (unsigned long, unsigned char *, int, char *);
+static void output_ins (unsigned long, unsigned char *, int, char *,
int);
static void skip (unsigned long dist, FILE *fp);

int main(int argc, char **argv)
@@ -45,6 +46,7 @@
int lenread;
long lendis;
int autosync = FALSE;
+ int just_insn = FALSE;
int bits = 16;
int eof = FALSE;
unsigned long prefer = 0;
@@ -65,6 +67,10 @@
autosync = TRUE;
p++;
break;
+ case 'j':
+ just_insn = TRUE;
+ p++;
+ break;
case 'h':
fprintf(stderr, help);
return 0;
@@ -247,7 +253,7 @@
if (!lendis || lendis > (p - q) ||
(unsigned long)lendis > nextsync-offset)
lendis = eatbyte (q, outbuf);
- output_ins (offset, q, lendis, outbuf);
+ output_ins (offset, q, lendis, outbuf, just_insn);
q += lendis;
offset += lendis;
}
@@ -268,9 +274,15 @@
}

static void output_ins (unsigned long offset, unsigned char *data,
- int datalen, char *insn)
+ int datalen, char *insn, int just_insn)
{
int bytes;
+
+ if (just_insn) {
+ fprintf(stdout, "%s\n", insn);
+ return;
+ }
+
fprintf(stdout, "%08lX ", offset);

bytes = 0;


...
Best,
Frank
Profetas
2004-05-19 08:52:11 UTC
Permalink
My main goal is to disassemble a program. and right after
assemble it an run it.
I will try this patch, But I think it won't work,
as you said.
It doesn't make cross ref for the labels.

my script will make
from this
Post by Profetas
00000010 0200 add al,[bx+si]
00000012 0300 add ax,[bx+si]
00000014 0100 add [bx+si],ax
00000016 0000 add [bx+si],al
00000018 E080 loopne 0xff9a
to this
Post by Profetas
add al,[bx+si]
add ax,[bx+si]
add [bx+si],ax
add [bx+si],al
loopne 0xff9a
I though that it would help. (I am kind new to this)

I have tested with a simple program that print A to screen and it worked.
but with more complex program it may be diff.
Eric
2004-05-20 06:01:00 UTC
Permalink
Post by Profetas
The program has been half coded as NASM and other half as C++
the problem whit the labels are that when I disasm
It gives me the address instead of the label, and when I try
to assemble it back it will ask for a label
here is some bit of the program disasm
00000010 0200 add al,[bx+si]
00000012 0300 add ax,[bx+si]
00000014 0100 add [bx+si],ax
00000016 0000 add [bx+si],al
00000018 E080 loopne 0xff9a
0000001A 0408 add al,0x8
0000001C 3400 xor al,0x0
0000001E 0000 add [bx+si],al
00000020 50 push ax
00000021 D30F ror word [bx],cl
00000023 0000 add [bx+si],al
00000025 0000 add [bx+si],al
00000027 0034 add [si],dh
00000029 0020 add [bx+si],ah
0000002B 0003 add [bp+di],al
0000002D 0028 add [bx+si],ch
I created a script to remove the first bit in the front
and this is what I get when I try to recompile it
head.buff:1: error: label or instruction expected at start of line
head.buff:410: error: label or instruction expected at start of line
head.buff:481: error: label or instruction expected at start of line
I just whante to disasm and the assemble it back
Generally disassemblers are for reverse engineering and studying the code
from an executable. Its pretty hard, if not impossible, to generate some
kind of original looking source code from an executable. There's issues
with labels as you've seen, and distinguishing data from code and assigning
meaningful names to constants and on and on. Disassemblers are ok for some
quick and dirty "whats this doing" type questions or for examining short
routines output from a compiler to see how it optimized a loop or
something. but forget about taking an executable and generating a source
code listing, its generally just not gonna happen.
Eric
Betov
2004-05-20 07:15:40 UTC
Permalink
Post by Eric
forget about taking an executable and generating a source
code listing, its generally just not gonna happen.
No more true: RosAsm does this with some success. Not
_always_, most likely not on _huge_ files, but it _does_
make it happend, more than once.


Betov.

< http://betov.free.fr/RosAsm.html >
Profetas
2004-05-20 11:30:57 UTC
Permalink
But if we know the way it iscompilled how comes we can't
reverse the process?
I will hopefully learn that in my compiller construction course
rjb
2004-05-20 18:42:59 UTC
Permalink
Post by Profetas
But if we know the way it iscompilled how comes we can't
reverse the process?
Because a compiler does not pass on to the compiled code those things that
make a source text understandable - not just labels, but also commentary. To
understand how a program works you need the source text, not a disassembly
of the code. Even the labels that Betov was talking about, that are
generated by Rosasm, will not be meaningful labels. A meaningful label is
one that gives you some idea what the routine does. An instruction like
"call write_to_file" is what might be in your source text. You know
immediately what it does. But the same line reverse-engineered from the code
will just give you something like "call 60FC", which tells you nothing.

rjb
Betov
2004-05-20 19:07:18 UTC
Permalink
Post by rjb
m...
Post by Profetas
But if we know the way it iscompilled how comes we can't
reverse the process?
Because a compiler does not pass on to the compiled code those things
that make a source text understandable - not just labels, but also
commentary. To understand how a program works you need the source
text, not a disassembly of the code. Even the labels that Betov was
talking about, that are generated by Rosasm, will not be meaningful
labels. A meaningful label is one that gives you some idea what the
routine does. An instruction like "call write_to_file" is what might
be in your source text. You know immediately what it does. But the
same line reverse-engineered from the code will just give you
something like "call 60FC", which tells you nothing.
rjb
I was answering about:

"forget about taking an executable and generating a source
code listing, its generally just not gonna happen."

_This_ does happend, as RosAsm Disassembler is actually
able to disassemble and to reassemble a significative
number of PEs. Saying this on an Asm NG means that we
have it in _our_ language, and so forth _we_ can
understand it in deepth - often times much better than
in some HLL Sources, at least for me... -.

... "label names and Comments", i agrea. Though this is not
completely hopeless either, if we consider a Disassembler
as a _translation_ Tool (what is the main purpose of RosAsm
Disassembler). In these cases, the 'alien' Source may be
available and it is possible to add a "Labels and Comments
Recoverer" on top of the Disassembler for a complete
restitution. (one of my future plans...).

Also, for a Win32 Disassembler, many "talking" interpretations
are possible. Actually, for example, RosAsm Disassembler may
succeed (not always...) to restitute the Menu Items Names,
the Win32 Data names (after analyses of the Api calls), and
this may help a lot at understanding a Disassembly, as well
as the api calls themselves do.


Betov.

< http://betov.free.fr/RosAsm.html >
The Wannabee @@@szmyggenpv.com>
2004-05-20 19:37:21 UTC
Permalink
Post by rjb
Post by Profetas
But if we know the way it iscompilled how comes we can't
reverse the process?
Because a compiler does not pass on to the compiled code those things that
make a source text understandable - not just labels, but also
commentary. To
understand how a program works you need the source text, not a
disassembly
of the code. Even the labels that Betov was talking about, that are
generated by Rosasm, will not be meaningful labels. A meaningful label is
one that gives you some idea what the routine does. An instruction like
"call write_to_file" is what might be in your source text. You know
immediately what it does. But the same line reverse-engineered from the code
will just give you something like "call 60FC", which tells you nothing.
rjb
Actually RosAsm is very good in this respect. It will recognize Win32 API
call for example. So every call to a DLL, as written in code :

"
call 'kernel32.SetUnhandledExceptionFilter' Application_Exception
"

will become

"
push Code04135DE
call 'KERNEL32.SetUnhandledExceptionFilter'
"
in the disassembled source.

To try this out on a file to see for yourself:

Download http://www.szmyggenpv.com/downloads/FileSearchDemo.Zip

Unzip with directory structure.

Then download this : http://betov.free.fr/SourceKiller.zip

Unzip and then use SourceKiller.exe to load FileSearchDemo.exe, select
EDIT/DESTROY SOURCE

Then download http://betov.free.fr/RosAsmFull.zip and install it.
Installation is easy. Just unzip and assign two directories when RosAsm
start. One for the helpfile and one for the include files. Restart.

Then load in the project, by loading the FileSearchDemo.exe into the
assembler. The built-in disassembler will detect a file without sources
and will ask you for 3 alterantives. Just keep the normal disassebly and
press ok.

Then press F6 to re-assemble and run the file. You know have asm source
again. Because of the win32 API calls, you will have some very nice clues
as to what code does what. You will eg see code like this :

Code0413CF0: I0:
push 08064
push D$Data0405918
call Code040743D
push 05
push D$Data0405918
call 'USER32.ShowWindow'
push D$Data0405918
call 'USER32.SetForegroundWindow'
ret

I can imidiatly recognize what this code is. Its the code that runs after
the app gets restored from a minimized state.

You can easily see that D$Data0405918 must be a variable for the window
handle.

RosAsm is very good. Go get some.
assemblyperson
2004-05-21 01:54:44 UTC
Permalink
The Wannabee <***@.@***@.@***@.@szmyggenpv.com> wrote in message news:<***@news.broadpark.no>...
.
.
.
Post by The Wannabee @@@szmyggenpv.com>
Actually RosAsm is very good in this respect. It will recognize Win32 API
"
call 'kernel32.SetUnhandledExceptionFilter' Application_Exception
"
will become
"
push Code04135DE
call 'KERNEL32.SetUnhandledExceptionFilter'
"
in the disassembled source.
.
.
.
Post by The Wannabee @@@szmyggenpv.com>
RosAsm is very good. Go get some.
Is there an equally capable disassembler for NASM under Linux?

Thank you for your help.


***@yahoo.com
Robert Redelmeier
2004-05-21 02:16:30 UTC
Permalink
Post by assemblyperson
Is there an equally capable disassembler for NASM under Linux?
I dunno about Intel syntax, but I've always
used `objdump -d` under Linux with good luck.
I believe it does symbol lookup.

It dumps AT&T syntax, but that's OK
because that's what I use on Linux.

-- Robert
The Wannabee @@@szmyggenpv.com>
2004-05-21 02:45:52 UTC
Permalink
På 20 May 2004 18:54:44 -0700, skrev assemblyperson
Post by assemblyperson
Is there an equally capable disassembler for NASM under Linux?
Thank you for your help.
I dont know. But the LuxAsm team are working on something. But other than
that I dont know.

If they can only be done reading Beth, selfproclaimed codemaster and gury
of teory. :-))

Dont count on it. She made some genious conclusion about
code=data=macro=whatever. Its all the same.
Therefore they are going to use C syntax for the macro language and build
an assembler sentered around macros. To avoid macroni I suppose :-))

O :-))

PS : I have the feeling that one day the LuxAsm team will come crawling
Back on their kneees beggin Betov to write a Linux version of RosAsm.
We'll see. Good luck to them anyhow. May the force be with them.

:-)
Frank Kotler
2004-05-21 05:37:51 UTC
Permalink
Post by The Wannabee @@@szmyggenpv.com>
På 20 May 2004 18:54:44 -0700, skrev assemblyperson
Post by assemblyperson
Is there an equally capable disassembler for NASM under Linux?
Thank you for your help.
I dont know. But the LuxAsm team are working on something.
When it comes to the disassembler, it might be better to say we're
"contemplating" something than "working on" something. We haven't even
got an assembler yet. Before we can get "integrated", we need an editor.
*Then* maybe we can think about adding a disassembler... You're going to
*love* it, Assemblyperson, but I'm afraid it may be a long wait...

(In the meantime, I wonder what it would take to mutilate "objdump" so
it emitted Nasm syntax???)
Post by The Wannabee @@@szmyggenpv.com>
If they can only be done reading Beth, selfproclaimed codemaster and gury
of teory. :-))
Dont count on it. She made some genious conclusion about
code=data=macro=whatever. Its all the same.
Do you disagree? I'd call it an "observation" rather than a "genious
conclusion"... Beth isn't the first one to notice that it's "all just
bytes". She *might* be the first to capitalize on it...
Post by The Wannabee @@@szmyggenpv.com>
Therefore they are going to use C syntax for the macro language and build
an assembler sentered around macros. To avoid macroni I suppose :-))
O :-))
Boom, boom. :)

I don't think the "therefore" follows. There are all kinds of jokes
possible about "C syntax" vs "C's syntax", but seriously... Have you
looked at C's proposed examples, or is this a "phantom book review"?

All code can be browsed here:

http://cvs.sourceforge.net/viewcvs.py/luxasm/

Here's some proposed "convert to hex" code from the "examples"
section...

#include "control.lxl"
#include "gui.lxl"

module Example_Base_16_Integer_To_String_Conversion

procedure number_dialogue, value : dword
local string : byte, 12
mov edx, esp->value
mov ecx, -8
do
mov al, 0xf
rol edx, 4
and al, dl
if al > 0xA
add al, 'A' - '0' - 0xA
end_if
add al, '0'
mov esp->string[ ecx + 8 ], al
loop_until ++ ecx == 0
mov esp->string[8], 0
dialogue_box "Number", string, 0
end_procedure

end_module

(Note that this is *proposed*! There is at present no completed
assembler for it, and it's all "open for discussion"!) Looks a little
like C (the language), but not much, IMO. I can't say I'm in love with
the "style" of it, but I haven't seen anything in the code that's going
to *force* me into this style. LuxAsm will accept "real assembly", and
hopefully will have a powerful enough macro system to allow me to write
my own macros that would allow me to do the same thing in a completely
different "style"...
Post by The Wannabee @@@szmyggenpv.com>
PS : I have the feeling that one day the LuxAsm team will come crawling
Back on their kneees beggin Betov to write a Linux version of RosAsm.
I don't know that it would involve any "crawling back on our knees".
We'd be delighted with any help Betov wants to give us. He's made it
clear that he hasn't got time, and isn't much impressed with Linux - in
spite of that he's made some useful suggestions... I know there's some
"feelings" between Betov and Beth, but don't imagine that LuxAsm is
Betov's "enemy", or an "enemy" of RosAsm (not even a direct
"competitor"!). On the contrary, we hope to bring some of RosAsm's good
features (such as the fully integrated disassembler) to Linux.

Unfortunately, it isn't going to be soon. (not entirely caused by
reading Bethposts :)
Post by The Wannabee @@@szmyggenpv.com>
We'll see. Good luck to them anyhow. May the force be with them.
:-)
Thanks, Wannabee!

Best,
Frank
Beth
2004-05-24 11:52:10 UTC
Permalink
Post by Frank Kotler
Unfortunately, it isn't going to be soon. (not entirely caused
by
Post by Frank Kotler
reading Bethposts :)
Partially caused by _writing_ Bethposts, though ;)...

Beth :)
The Wannabee @@@szmyggenpv.com>
2004-05-24 12:11:30 UTC
Permalink
På Mon, 24 May 2004 12:52:10 +0100, skrev Beth
Post by Beth
Post by Frank Kotler
Unfortunately, it isn't going to be soon. (not entirely caused
by
Post by Frank Kotler
reading Bethposts :)
Partially caused by _writing_ Bethposts, though ;)...
Beth :)
Beth if it wore not for your posts, I would never have found RosAsm!!!!
And that is so COOL. But on the other hand, if I didn't enjoy reading you
post so much, I would probably made some serious progress by now too :-))
You are a costly hobby Beth :-))
--
Lite vit Maver.
Evenbit
2004-05-24 15:28:17 UTC
Permalink
"The Wannabee" <***@.@***@.@***@.@szmyggenpv.com> wrote in message news:***@news.broadpark.no...
[]
Post by The Wannabee @@@szmyggenpv.com>
You are a costly hobby Beth :-))
And, like a typical female, when Beth gets sad, she becomes a
"high-maintainence" pet as well.

;-)

L8r
Nathan
The Wannabee @@@szmyggenpv.com>
2004-05-24 17:13:17 UTC
Permalink
På Mon, 24 May 2004 11:28:17 -0400, skrev Evenbit
Post by Evenbit
[]
Post by The Wannabee @@@szmyggenpv.com>
You are a costly hobby Beth :-))
And, like a typical female, when Beth gets sad, she becomes a
"high-maintainence" pet as well.
;-)
L8r
Nathan
_MICKEY MOUSE_ is a weapon of mass destruction
--
Lite vit Maver.
Randall Hyde
2004-05-21 05:55:00 UTC
Permalink
Post by assemblyperson
Post by The Wannabee @@@szmyggenpv.com>
RosAsm is very good. Go get some.
Is there an equally capable disassembler for NASM under Linux?
Thank you for your help.
There is IDAPro, which is actually a bit better than the "under development"
RosAsm disassembler at this point. IDAPro natively disassembles to a
MASM syntax, but the professional/commercial version has an option
to let you specify the syntax you want it to emit. So it might be possible
to convince it to generate NASM code for you. I don't know if the
free version includes this facility, and the commercial version is
moderately
priced (hundreds of dollars), so it's not appropriate as a toy. OTOH, they
do have a "free" version that you can try out. Just search for "IDAPro" on
the net and you'll be in business.

My experience using these two disassemblers is that neither worked amazingly
well in automatic mode. But IDAPro, at least, has an interactive mode that
lets you fine tune the output it produces. Something that Rene refuses to
admit would be useful in the RosAsm disassembler. As such, I suspect
the RosAsm disassembler is never going to achieve "professional" status.
It will be a cute toy for all the RosAsmites to play around with, and it
might actually turn out to be a *very* good automatic disassembler. But
the problems with automatic disassemblers are well-known and Rene
refuses to acknowledge this. Oh well, what a shame that he will invest
so much time into this project that will only do about 80% of the work
for you. I wish him luck. In the meantime, get a copy of IDAPro.
Cheers,
Randy Hyde
The Wannabee @@@szmyggenpv.com>
2004-05-21 09:16:29 UTC
Permalink
På Fri, 21 May 2004 05:55:00 GMT, skrev Randall Hyde
Post by Randall Hyde
I wish him luck. In the meantime, get a copy of IDAPro.
You are lying. You dont wish RosAsm any luck. ( Dont belive a word this
swindler tells you ). His green with envy and jealousy at RosAsm's growing
success.
--
HLA will get you nowwhere.
NOW WHERE ? ( is your code )?
BSpider
2004-05-21 09:28:27 UTC
Permalink
Post by Randall Hyde
There is IDAPro, which is actually a bit better than the "under development"
RosAsm disassembler at this point. IDAPro natively disassembles to a
MASM syntax, but the professional/commercial version has an option
to let you specify the syntax you want it to emit. So it might be possible
to convince it to generate NASM code for you. I don't know if the
free version includes this facility, and the commercial version is
moderately
priced (hundreds of dollars), so it's not appropriate as a toy. OTOH, they
do have a "free" version that you can try out. Just search for "IDAPro" on
the net and you'll be in business.
My experience using these two disassemblers is that neither worked amazingly
well in automatic mode. But IDAPro, at least, has an interactive mode that
lets you fine tune the output it produces. Something that Rene refuses to
admit would be useful in the RosAsm disassembler. As such, I suspect
the RosAsm disassembler is never going to achieve "professional" status.
It will be a cute toy for all the RosAsmites to play around with, and it
might actually turn out to be a *very* good automatic disassembler. But
the problems with automatic disassemblers are well-known and Rene
refuses to acknowledge this. Oh well, what a shame that he will invest
so much time into this project that will only do about 80% of the work
for you. I wish him luck. In the meantime, get a copy of IDAPro.
Well, as you mentioned IDAPro is quite expensive, but there are 2 freeware
IDA versions available for download.

The older MS-DOS version is a very good tool. It can successfully
disassemble (with a little help from the user) multiple 16 and 32-bit file
formats (standrard DOS, NE, LE, Windows PE and more).
http://www.simtel.com/product.php[id]27629[sekid]0[SiteID]simtel.net

And there's the newer Windows version with many advanced options.
http://www.simtel.com/product.php[id]29498[sekid]0[SiteID]simtel.net


BSpider
Continue reading on narkive:
Loading...