:[diStorm}: Looking for features/ideas for diStorm3, now is the time

[Mario Alejandro Vilas Jerez]

On Wed, Sep 30, 2009 at 5:34 PM, Tom Keetch <twkeetch at googlemail.com> wrote:

> Gil,
>
> I have two feature requests, one is very similar to yours, Mario.
>
> 1) Categorisation of decoded instructions. I.e a new member in the
> _DecodedInst struct.
>
> This would contain an enum of instruction types like:
> Call
> Branch
> Conditional Branch
> Arithmetic
> String instruction
> FPU instruction
> etc.
>
> This would make it super simple to make a disassembler that continues to
> disassemble a whole binary using control flow. It might be better to return
> more than a single enum, not thought about it in detail.
>
>
I like this a lot :)


> 2) Being able to register callbacks for when a soft breakpoint is found in
> the instruction stream (int 3). That way if there is a software breakpoint,
> then the main program can replace that byte in the instruction stream with
> the original byte that it replaced. Otherwise, if you want to disassemble
> code which you are debugging, you have make sure that any breakpoints you've
> set are replaced with the code they overwrite before sending the code to
> DiStorm. There may not even be any breakpoints in the code! So I think this
> would be a cool feature...
>
>
This could be a problem for previously existing breakpoint instructions,
plus you'd hit this a lot since some compilers use \xCC as padding between
functions in debug builds (not sure about release builds). I'd replace the
bytes before sending the instruction stream to diStorm, it's more efficient
IMHO.


> Cheers,
>
> Tom
>
>
>
>
>
>
>
>
> On Wed, Sep 30, 2009 at 6:46 PM, Mario Alejandro Vilas Jerez <
> mvilas at gmail.com> wrote:
>
>> Did you take a look at BEA? It's got some interesting features, like the
>> ability to output assembly in multiple syntaxes.
>>
>> Anyway, the feature I'd like the most would be to have diStorm tell me
>> what code/data references each instruction makes. For example,
>>
>> CALL 0xDEADBEEF
>>
>> has one code reference, the memory address 0xDEADBEEF. But this:
>>
>> JE 0xDEADBEEF
>>
>> has two code references, 0xDEADBEEF and the address following the
>> instruction (the two possible code paths). And this:
>>
>> MOV EAX, [0xDEADBEEF]
>>
>> has one data reference, again 0xDEADBEEF.
>>
>> This information would be most useful to identify basic blocks, try to
>> plot function call graphs, and attempt some simple data flow analysis. What
>> do you think?
>>
>>
>> On Wed, Sep 30, 2009 at 4:05 AM, Gil Dabah <arkon at ragestorm.net> wrote:
>>
>>> Hi
>>>
>>> I am currently working hard on diStorm3, this is the time to ask for
>>> features or if you have any other ideas. Give it a try please, although
>>> I can't promise to put it inside.
>>>
>>> In a sentence, diStorm3 preserves the diStorm64 interface and supplies a
>>> new function which returns structures instead of text, which is also
>>> much faster, of course.
>>>
>>> Thanks,
>>> Gil
>>>
>>> _______________________________________________
>>> diStorm mailing list
>>> diStorm at ragestorm.net
>>> http://ragestorm.net/mailman/listinfo/distorm_ragestorm.net
>>>
>>
>>
>>
>> --
>> HONEY: I want to… put some powder on my nose.
>> GEORGE: Martha, won’t you show her where we keep the euphemism?
>>
>> _______________________________________________
>> diStorm mailing list
>> diStorm at ragestorm.net
>> http://ragestorm.net/mailman/listinfo/distorm_ragestorm.net
>>
>>
>


-- 
HONEY: I want to… put some powder on my nose.
GEORGE: Martha, won’t you show her where we keep the euphemism?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ragestorm.net/pipermail/distorm_ragestorm.net/attachments/20090930/db487e49/attachment.html>