Hi, guys.

If you're interested in developing new Interactive Disassembler and Decompiler please visit

http://igg.me/p/117506?a=642317

for more information.


Main points are:

x86, x64, ARM disassembler and decompiler

Thanks.

Idea and intention are at their right place.

But need more interactivity in the disassembler. I'd say ability to convert from code v/s data would be good--for a start.

Also, considering the speed, it seems like a static disassembler. Just a disassembly of the mnemonics. Am I correct? Or does it actually follow all paths of executions to provide the disassembly?

The basic question above stems from the ever-present query: how does your disassembler mark the beginning of a routine--and what if it misses the beginning of a routine?

While no need to compare with IDA Pro (*grin*) you can try and incorporate these features perhaps in the next iteration of the development.

Either way, I laud the fact that you are actually building your own tools. I like that.

Have Phun,
Aimless

PS: You may want to dial down the "please contribute for growth" message. It's occupying more footage than the disassembler on the webpage.

PPS: You may want to share some documentation about it. Yes, I know videos and YouTube, but I prefer paper or PDF any days

Hi, Aimless

thanks for response

Yes you're correct. Now it's static. Analysis engine is not ready yet.
It's planned to make analysis engine shareable between disassembler and decompiler.
For this purpose I've disabled small decompiler shown on video until I get it stable enough,
and can use it both for function analysis and recompilation.

As for marking functions (routines) start. It is loader's task to queue all entry points.
E.g. for PE it's exported symbols, tls callbacks.
Need just start address, then analysis engine should trace code/data flow and queue other referenced routines.

If it fails, say, at self-modified code, then it should make some list for user of failed addresses.

I don't prefer marking typical code sequences, cause there can be embedded executable,
and it can add more mess. Anyway it can be done as an option.

About interactivity.
There's very base Type Manager. It stores mapping of TypeName and Actual decoder for the name.
Decoder get bytes at VA and gives text.

GUI has buttons:
Y - to make bytes at VA of certain type. Now there are: uint8, uint16, uint32, uint64, guid, str8 (asciiz string)
D - to make it data (in cycle). It's only uint32 now.
C - to make it code. Code is aliased type, e.g. arm loader on loading end adds decoder type 'arm', and aliases 'code=arm'.
I've even thought to make more than one code aliases in executable.
A - to make it string. str8 only now.

Created small PDF at http://igg.me/vdisasm?c=activity


* VA is Virtual Address

VDisAsm Alpha Release is ready and can be downloaded from here. More details in readme.txt ("https://www.dropbox.com/sh/xbietajej93w0i9/MjZxQa_o3F")

https://www.dropbox.com/sh/xbietajej93w0i9/MjZxQa_o3F

On the right track baby! On the right track.

Good!

Have Phun

lol: