ncatlin / rgat Goto Github PK

First of all, great job on rgat, the live animations are great!

How feasible would it be replace DynamoRIO in drgat? e.g. using Intel PIN to trace.

Shouldn't be a major change, this is likely going to be the number 1 to deal with complex graphs

With qt the distribution is getting a bit unwieldly. May leave this until I have implemented an updater

Drawing text is horribly slow, there are lots of instructions -> we only want to draw the instruction labels on the screen.

To do this, rgat uses colour picking - regularly (a few times a second) drawing a sphere to the screen with 32 columns with a green gradient and 16 rows with a red gradient. It looks like this:

Before it's cleared, we check the green value of the pixel either side of the screen (and the red on top and bottom, but those values are not used yet).

This tells us the columns we need to draw text in.

Then we iterate through every node on the graph to checking if it is within those columns.

The problem with this is that my maths is horrendous. The formula to convert a node coordinate to a column looks like this [graphicsMaths.cpp]:

node column = floor(<horizontal coordinate> / (COLOUR_PICKING_MYSTERY_CONSTANTA / <horizontal edge separation>)) % 32;

The constant was found by looking at a few example row/node mappings and multiplying them.
eg: coord 8a is between col 0 and 1 at h_edge_sep ~1.39.
-> 1.39*8 = 11.12

(The constant that has worked best so far is 11.16).

This generally works but it gets very dubious at high graph widths and breaks entirely when the graph starts wrapping a long way around the sphere.

On multigraph views it's difficult to see which graph is performing the activity. Having each preview be animated is a lot to ask but some kind of text or icon display would be a start.

Small task

For cases where the code generates more trace data than we can process

Improving loop detection/compression would help if the overhead outside of loops doesn't cause more problems than it solves.

We could also track how many times a block has been sent to the visualiser and stop sending it after so many identical executions.

Example of a Cryptowall 1 loader sample:

It doesn't do very much before it fills the trace buffers with a tight loop.

If we removed instrumentation from the worst offenders and re-enabled it when different execution moved to different blocks then we are going to get a lot closer to native performance.

Problems with this approach:
We are sacrificing edge count, so accurate number on the heatmap are lost. drgat can send a notification that those blocks were too hot to handle though.

Bigger problem: If you remove instrumentation from multiple blocks with call [eax] terminators and one of them breaks the loop, the integrity of the control flow graph is compromised.

A softer approach would be to maintain instrumentation of the blocks but not send their tags to rgat until their target changes. This won't make drgat output much faster but it will stop us having a 500000+ item backlog in rgat.

Pin: pin-3.17-98314-0c048d619
Copyright 2002-2020 Intel Corporation.
E: Pintool version does not match Pin
Pin: 0c048d619
Tool: 0d0c92f4f

Could you tell me which version it works on?

I am also waiting for a tutorial video from you

wow, such a nice tool! we linked to your project from our website now: http://www.capstone-engine.org/showcase.html

keep it up, cheers!

I don't see any significant barriers to doing this in the visualiser, just need to properly separate out the Windows API functions into OSSpecific

agui is nice and lightweight but using GTK/qt/wxWidgets/etc would let us provide a UI on restrictive VM's and provide support for toolbars. Not keen on massively increasing the distribution size but it's probably not a big deal?

• Module information
• Number of calls
• Connected nodes
• Call arguments

The globe is a good starting point but apparently we are drawing graphs and not planets. The spacing varies by latitude so drawing has to be kept away from the poles. Effectively we are using very constrained cylinder so... why not just draw it on a cylinder?

Downloading and unpacking from github isn't much fun

Exceptions are noticed and result in a message being printed, but they haven't been taken into account during development.

It happens in a thread during vlc startup and looks like this:

Since rgat don't process the exception as a tag it thinks the thread is blocking on that conditional jump, which never reaches it's target.

Groundwork is laid in the timeline class, just need to do the drawing

Not sure how practical this is

See https://github.com/ncatlin/rgat/wiki/Limitations

[copy] and [paste] buttons are great if you don't have a keyboard I guess?

At the moment it just continuously sends back every tag that executes from the start of the program, which is probably excruciatingly slow enough to be useless for most applications.

Better would be to have the '*_dbg' functions call an intermediary which track time the time differences between calls.
Big difference -> probably stepping -> use the current debug_mode logic
Small difference (multiple times) -> use optimised process_block logic

Most of the work is in the drgat client, the visualiser just needs to be made resilient to longer addresses.

I have a problem. I try with my x86 "hello world" application and it crashed (picture bellow).

• Colours
• Paths
• Dimensions
• Fonts

This is somewhat tricky to raise a DynamoRIO issue for since you have to execute live malware to reproduce it, but lots of sameples (eg TeslaCrypt, Shylock) will make DynamoRIO nope out with

ERROR: Failed to create process for [target path]

This might be an internationalisation issue

Colour graph based on number of different instructions at each memory address

Hard mode bonus points: Animation showing the code change. Not sure how useful this would be.

Option 1 (Current): Dev adds wrappings for arguments that they think look interesting, in a format that suits. This allows for handy custom formats like "RWX" instead of "0x40".

If it's not already there then you need to request it or write+build it yourself. Distribution of your fancy wrapping code would have to be in the form of source (pain in the neck) or binary (what could go wrong).

Option 2: The client reads in an optional user-supplied text file for each library it loads. It reads symbols, arguments required from each symbol and the format of each argument.

Pros- Easy to contribute to, customise for individual binaries and safe to distribute.
Cons- Does nothing more than return the argument. No custom processing code.

Option 3: Option 1 [unless an option 2 file exists]

Option 4: ???