ASM.HLP File and Other Useful Files

Started by Donald Darden, June 07, 2007, 11:26:50 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Donald Darden

Assembler Help File attached below

A link to an alternative, provided by Theo:

IDA Pro Debugger Home Page:

IDA Pro, Freeware version 4.3 Download Link Page:

Dissassembling Code:  IDA Pro and SoftICE - paperback book on Amazon.com


IDA Pro, Freeware version 4.3 Download Link:

IDA Pro Freeware version 4.3 Alternate Download Link:

IDA Pro Freeware version 4.3, 3rd Download Link:

Article with useful links on IDA Pro:

Linux Kernel Debugger - Linice:

I noted that the book above about Debugging mentioned SoftICE, so I did a bit
of research, and this was a powerful Kernel Debugger that started life under DOS, and kept being upgraded for versions of Windows, finally getting patched to work with XP.  It's not around any more - at least not legitimately.  The company producing it apparently closed shop in the middle of 2006,  There was no free version, and it was reportedly pretty expensive.  Maybe they decided that the transition to Vista was going to require a complete rework of their product, and that embedding it in Vista was going to be very difficult.  Just a guess.  Anyway, unless you were writing device drivers, concerned with system vulnerabilities, or attempting to hack the OS yourself, it was probably overkill. 

Donald Darden

We need to understand that different type files have different type of formats, and that formats refers to how data is structured inside those files, and even includes how files are named and identified.  In Windows and DOS, it is sommon to use a file extension, that is, a trailing period, followed by a number of characters, that identify what the file's internal structure is expected to be, and what it is generally expected to do.  You don't find extensions widely used with Linux or Unix systems, so the decision as to what the file represents is dependent on how you attempt to use it, and what the system determines for examming the file itself.

Microsoft defined a number of executable program types, and the one of greatest interest is often the one that is described as a Portable Executable, usually abbreviated as PE.  Some programs designed to examine PEs incorporate this into their name, such as PEBrowser and PE Explorer. 

These are actual programs, and just as I attempted to provide some leads to the IDE Pro products and community on the Internet, I want to be fair and provide
some clues to what is available from other parties.

PE Explorer:

PE Explorer 1.96:

Neuron PE Disassembler 1.0 b3:

Neuron PE Disassembler 1.0 b7:

Software on SimTel (use onsite search to find "dissassembler"):

Download Disassembler Software:

RosAsm, the Bottom-Up Assembler for ReactOS:

Windows based multi-cpu multi-format disassembler:


Other Windows Disassemblers:

Donald Darden

PE Explorer and Neuron's PE Dissassembler were frequently linked or referenced on the Internet.  But PE Explorer will not produce an ASM or LST file output until you buy the commercial version for $129.00.  The free version of IDA Pro will do that for you.  But that left Neuron's product to be evaluated.

Well, I tried.  It is definately not intuitive.  My problem is that I could not find any way to actually see the disassembled code in Neuron.  I saw breakdowns on statistics, and other things, but could not figure out how to view the code itself.  The only view I could get was a hex view of the file's contents.  I finally decided that I wasn't going to waste any more time with it.  I could not even see a way to create an output file with dissassembled code in it.

If anyone ever puts some finishing touches to the BinEditPlus project, it offers the advantage of being adapted at the code level to work as an extension to your own PowerBasic development.  It occurs to me that someone could use the DisASM code and look for translation gaps by seeing where it's translation fails, and another product, such as IDA Pro, succeeds.  But that would be pretty involved work.  I doubt that there would be much profit in it.

Theo Gottwald

I ahd a few cases only, where DisASM was NOT giving the real Output.
Actually I can use it as it is.

Just missing "Drag'n Drop" :-)) sometimes.
While I think there was such  a version somewhere ....

Donald Darden

Actually, if DisASM had complete mnemonic breakouts of all x86 instructions, I would use it without Drag and Drop.  In fact I would modify the interface to work
through the COMMAND$, which would allow me to shell to it from my own program.
That way, I could call it to create an .ASM output of any given EXE, then use my own program to take the ASM output and present it for immediate viewing - at least the part that would be of interest to me.

There are many times when you want to be able to reposition back to a place in your code easily.  In PowerBasic, I often use a statement like "A=A", which effectively does nothing, but which I can search for easily.  Some people prefer to use as dpecial type of comment, or even a line label.

In Assembly Language, Theo has suggested using the NOP (No OPeration) operand.  This works well, but what if you want some variety in the inline tags that you used?  A comment does not transition from PowerBasic into the final ASM code, nor does a line label.  You really need to use an instruction that can be implemented via the inline assembler capabilities of PowerBasic.

Actually, there are many, many instruction constructs that effectively act as NOP instructions.  MOV instructions, for instance, do not change flag states, so if you move a register to itself, nothing is changed.  So you could use statements like these and get the NOP effect:

     ! NOP
     ! MOV eax, eax
     ! MOV al, al
     ! MOV ah, ah
     ! MOV ax, ax
     ! MOV ebx, ebx
     ! MOV ecx, ecx

Anyway, you get the idea.  This provides you with many options for setting flags in the code you want to examine.  Now I suggested previously that you could use a leading ! NOP and trailing ! NOP to mark off any section of code to examine, but with so many options, you could mark different parts of your code
to be examined with separate leading and trailing instructions, such as:

      ! MOV al, al       'marks the leading part of a sequence to examine
      ...                   'the sequence to examine
      ! MOV ah, ah     'ends the sequence to be examined.

Now the neat thing here is that you could write a simple program that would
open both the source code file and the produced ASM file and use the same
search method to display the comparative sequences in parallel to each other,
So if you wanted to see how PowerBasic's LEN() function is implemented, you
could do something like this:

     ! MOV al, al
     ! MOV ah, ah

And when you use a Dissassembler to procude an ASM (or LST) file output, your
search tool could then show you what lies between the paired ! MOV statements.

By using different pairs of ineffectual ! MOV statements, you could examine different parts of the source and ASM files together, and be sure that each part was a match to the other, somehow.

My impression of the resulting code is that PowerBasic employs a large number
of CALL statements with appended called routines to perform some operations,
and that understanding what is going on gets a bit involved.  But by knowing where each group of statements both begin and end, you should be able to determine quite a bit from this process.