Hi all,

Currently I am working on a disassembly engine. I almost completed the full opcode set, leaving only fpu opcodes and 3dnow! opcodes undone. For now I am seeking people to help me test it out and inform me of which part of it is not properly done. (I know that the test bed is pretty crudely done, but then I was hasty :) ). I have attached the file for people to come and help me with the testing of it. Please come and test it out for me.

Okay, furthermore I want to work on a disassembler. That's my next step. However I find it lonely to work on the project alone, thus I am in this forum recuiting people that is interested in helping me in the coding of the disassembler and some other stuffs which I had not thought of. For example:
1) Name of the disassembler. I need some suggestions or soemthing like that.
2) GUI of the disassembler. I need some ideas on how you guys want my disassembler to look like.
3) What addition functions that the disassembler should have?
4) I need some inspiration for icons and so on.

People, please come forward and give me some of your suggestion or anything. I just need some help here (I am not really a GUI person, more into algorithm).
Posted on 2003-08-26 11:18:43 by roticv
Hi roticv,

I'm not bad at GUI design, I have some ideas for a disassembler design that is a radical departure from the normal 5 or 6 MDI child design. I have always found that interface cumbersome. My idea is for a procedural disassembler, one where the main focus is procedures and data blocks.

The GUI would require that you supply disassembled code in a buffer encompassing a single procedure (entry to leave) also a table of addresses that were expressly addressed (i.e. mov edi,Mem32 not the inc edi ones).

The program can then be broken down into a treeview control with editable labels, each subitem representing a procedure. The root items would be the segments of the program. This would allow the user to create a list of labels for the procedures. The data would be sorted by address and become the subitems of the data segment root, again editable labels. When you select a treeview root item a summary of the contents of the segment is displayed, when you select a subitem the code or data for that block is displayed with references to other sub items.

I am knee deep in TBPaint right now but I would be glad to participate when you are ready to start the GUI.
Posted on 2003-08-26 11:49:18 by donkey
One question, will the dissasembled code be in MASM or FASM syntax?

Here's a litte sugestion for a name: ; (Maybe it isn't taht good - but hey you asked for suggestions ;))
Rigda - Roticv's Graphical Dissasembler
Posted on 2003-08-26 14:54:36 by scientica
Hey scientica,

Thanks for your suggestion. I will add it into my list of names. I tried to make the disassembled code be as generic as possible. But of course the code that is disassembled would not be properly assembled with masm or fasm without some adjustment. So the answer should be neither, until someone request for some change in the output. I will be willing to make changes.

I got some question for you. Would prefer

movs dword ptr ES:[edi],dword ptr ES:[esi]

or
movsd


And is the following FASM compatible?
add byte ptr [eax], al

and stuffs like that?

Hey donkey,

I certainly do like your idea about using a treeview control. Very nice idea I must say. Thanks. :) I got a question, do you have any suggestion on where the disassembled code be placed in? In an editbox? In a richedit (with some syntax highlighting)? In a listbox? Or some other weird controls. :rolleyes:

:
I made a mistake with the opcodes fxsave and fxstor. But then again the chances of one spotting it would be 1/256*1/256*2/256 :grin: Oh yes, one thing to note is that my engine is only compatible for PII and above because of the usage of cmov (was trying to cut down on conditional jmps). I was also be planning to be using mmx in the disassembler.
Posted on 2003-08-27 03:26:02 by roticv
My suggestion for the name: dissect

I agree with donkey, there is a need for a more advanced GUI than actual ones. In addition to treeview, it will be nice to have graphical (live) jumps and calls to both visualize and navigate through the code. It means neither listboxes or editboxes, but an ownerdraw working space. Such a control will be useful also to edit source code. I will prepare an example to show you what I mean.
Posted on 2003-08-27 08:08:53 by pelaillo
Hi Pelaillo,

In addition to treeview, it will be nice to have graphical (live) jumps and calls to both visualize and navigate through the code. It means neither listboxes or editboxes, but an ownerdraw working space.

Actually this reminds me of IDA pro, which has its own custom control which when you double click on the data, you would be "teleported" to the data section containing the data, and when you click on the jmp/call, you would be "teleported" to that code. Of course I am interested to see your example (Eagerly awaiting). Thanks.

I was thinking about the gui. Is there a need to show the actually hex values for the disassembler? When looking at disassemblers that lack that feature, the first thing that runs into my head is what's the hex value of this opcode. :) But of course different people have different opinions. Thus I am waiting for people to express their opinions on this issue.

There are many nice features in other disassemblers. My idea now is to incorporate them all into my disassembler (whatever that is possible of course). It would be nice for people to inform me what they want, and I would add it to the "things-to-do" list for this project. Of course I have not started on it yet. Still in the "brainstorming" session. School's taking alot of my time currently.
Posted on 2003-08-27 08:35:12 by roticv
Hi roticv,

Yeah I like pelaillo's idea for a custom control. The graphical links in the control will make it alot easier to analyze code. Suggestion for the name - ProDis (Procedural Disassembler)
Posted on 2003-08-27 08:40:18 by donkey
First of all:
movsd - there are opcode/instruction references.. :) The other form is IMO more confusing - movsd is better than movs

As for "add byte ptr , al", it will compile (correct - verified) if "ptr" is 'fix'ed (may work with equ too, but I prefer fix here):
ptr fix

add byte ptr [eax],al

It's only needed to fix ptr once in the sources

You're not interested in participating in Fresh? (Hopefully there will be a built in debugger - and a debugger needs a disassembler, right?)
Posted on 2003-08-27 09:24:33 by scientica
Hey scientica,

To make the code work on both masm and fasm I think there is a need for some slight changes (for example in the parser code to remove the "offset" and so on).

You're not interested in participating in Fresh? (Hopefully there will be a built in debugger - and a debugger needs a disassembler, right?)

I have yet to learn the fasm syntax (just need some motivation, which I lack now :) ) That's why I am not really interested in participating in Fresh for now. But of course my decision will sway due to some other factors. I don't mind sharing the core of my engine, but of course it is in masm. Prehaps I can generate a dll that you can use for Fresh.

I have attached my code for you to have a look. But take care, since the code is uncommented and looks "not normal". Just about more than 6000 lines of code. :) Some codes/data are pretty useless because I could not be bothered to remove them/comment them out (Came from my older version of the engine).
Posted on 2003-08-27 09:43:52 by roticv
Originally posted by roticv
I have yet to learn the fasm syntax (just need some motivation, which I lack now :) )

Hehe, I could write a "little" list with reasons... (but that would just be a "why-I-think-fasm-is-best"-list, not a direct motivation speach, so I'll spare your eyes from teh reading :grin: ;) )
But it's really not that hard to learn the syntax, at least I felt that it was more natural.

Originally posted by roticv
Prehaps I can generate a dll that you can use for Fresh.

Maybe, but that is something that JohnFound should answer. (Since it would involve some changes to the project). And for the second I think pelaillo is working on the debugger part - I'm currently working with the styles editor.
But personaly I think that it could work fine, but at the sametime, it feels a bit like Fresh is for fasm, and should be written in it.
Posted on 2003-08-27 09:56:10 by scientica

movsd - there are opcode/instruction references.. :) The other form is IMO more confusing - movsd is better than movs

But then how to differentiate these three instructions?


movs dword [edi],[esi]
movs dword [di],[si] ; has the 67h prefix
movs dword [edi],[fs:esi] ; has the 64h prefix

And about the 'ptr' syntax: fasm, when no macros nor 'fix'es are applied, it accepts the following two forms:


add byte ptr eax, al
add byte [eax], al

combining them into one instruction is for fasm just the same as doubling the square brackets.
Posted on 2003-08-27 10:48:37 by Tomasz Grysztar


But then how to differentiate these three instructions?


movs dword [edi],[esi]
movs dword [di],[si] ; has the 67h prefix
movs dword [edi],[fs:esi] ; has the 64h prefix

To be honest: I didn't know one could do that :o
But in that case then the above would be good, but for "standard movsd" (movs dowrd ,) simply movsd should be used IMO.
Posted on 2003-08-27 10:55:18 by scientica
Hey Privalov,

If I remember correctly, string functions can only operate in the data segment ES (Stated in the Intel Manual if I am not wrong). So prefix_64h does nothing actually.
Posted on 2003-08-27 10:56:03 by roticv
The destination (edi) cannot be prefixed, the source can.
Even fasm's docs cover this syntax option. ;)
Posted on 2003-08-27 11:08:33 by Tomasz Grysztar
This is a draft, but the ideas are:
1. The interface is a grid (or a goup of collapsible grids distributed in the working space)
2. The result is a plain text file that can be compiled on-the-fly (this is the reason for the column distribution and the : & ;
3. Referenced labels are marked out.
4. Ability to rename a label and all references through the code are renamed accordingly.
5. Jumps and calls are live links.
Posted on 2003-08-27 11:08:37 by pelaillo
Hey pelaillo,

Thanks for sharing your opinion on how you want the gui to look like. I will look into it and try my best to add your model in. Thanks.

Hey Privalov,

My mistake not raeding the intel manuals properly. Now I think I need to recode the string opcodes.
Posted on 2003-08-28 07:14:57 by roticv
The same scheme applies to xlat instruction.
Posted on 2003-08-29 01:43:03 by Tomasz Grysztar
Hey scientica,

I think your suggestion for the name sounds quite nice. But of course I was thinking it is better for Rigda to mean Roticv's Interactive Graphical DisAssembler. Long name I know.

Hey Privalov,

Thanks for informing me. I did not know about xlat.
Posted on 2003-08-31 21:12:57 by roticv

I will look into it and try my best to add your model in.


I am currently doing the custom control ("asmgrid") for edition purposes, but it will fit your needs as well. I will post here the sources as soon as it gets working.

Thanks,
Posted on 2003-09-01 03:03:46 by pelaillo
Anything new on this topic?
Posted on 2003-09-26 00:42:23 by Tommy