I am sure there is a lot of things that can happen to make rendering faster.

Tracer matched against:

b'26 bind(4,{sin_family=AF_INET,sin_port=htons(3004),sin_addr=inet_addr("0.0.0.0")'

This is incorrect.

One potential solution is enforcing that the number of ( is equal to the number of ), and the number of { is equal to the number of }. Strings could still mess this up.

QEMU can exit without the target triggering an exit syscall. This needs to be detected.

https://github.com/ConnorNelson/cartprograph/blob/master/tracer/qemu/patches/exit-double-read.patch

Overview

Currently there are 3 separate layers to Cartprograph:

• qtrace
  This implements the core tracing logic. It includes a QEMU plugin to instrument blocks and syscalls with coverage instrumentation; and a python interface which collects this trace, and also interfaces with the QEMU gdb stub to interleave in a user-requested data trace. Ultimately, this tool produces a trace containing an ordered list of all basic blocks executed, syscalls executed, and any user-requested data (registers/memory values at some specific point in time).

• cartprograph
  This is basically a server for managing qtrace traces. Clients connect and supply interactions which will be traced. These interactions can fork off of other partial interactions to form a tree of interactions.

• angr management
  This is the primary supported client to cartprograph. Users can supply interactions via this client, and receive traces back, which can in turn guide analysis within the larger angr management ecosystem.

Problems

Data Traces

This concept of the data trace is new. Collecting syscall traces is no problem. Collecting complete basic block traces is pushing it, but seems to be tractable. Collecting a complete data trace seems entirely non-feasible.

For this reason, users can specify what data they want to collect. This is pretty straight forward to do programmatically within qtrace. The question is how we want to do this within angr management, and to what extent it should be "collaborative".

If we aren't expecting a syscall to block, it will block forever and nothing will ever resolve itself.
This can be handled by giving syscalls a time limit between start and finish.

When two traces are equivalent, it probably isn't worthwhile to have them both exist.

Additionally, this can get at the idea of what it means for two traces to be equivalent.

Currently:

• socketio.connect
• receive update events containing all prior events
• receive update events as they occur
• update event contains:
  • node
    • id
    • parent_id
    • interaction (syscalls/syscall args/syscall ret/io)
    • bb_trace
    • annotation
  • edge
    • start_node_id
    • end_node_id
    • interaction
    • bb_trace
    • annotation
• send entire node with interaction filled in for input

New:

• socketio.connect
• receive update events containing all prior events
• receive update events as they occur
• update event contains:
  • src_node_id, dst_node_id
• query server for more data
  • id:
    • node: <node_id>
    • edge: <src_id>-<dst_id>
  • /trace/basic_block/<id>
    • return list of basic blocks
  • /trace/syscall/<id>
    • return list of syscalls
      • syscall_nr
      • syscall_args
      • syscall_ret
        • None if blocked here
      • basic_block_index
  • /trace/interaction/<node_id>
    • return list of interactions
      • channel
      • direction
      • data
        • None if blocked here
      • basic_block_index
        • should be equal to some syscall's basic_block_index
• push input
  • /input/<node_id>
    • data

Deprecate annotations for now (needs more thought on if/how this fits into cartprograph).

tracer.IOBlockingTracer implements logic for handling stdio.
IOBlockingArchrTracer adds logic for handling tcp.
Aside from handling the accept system call, the code for read/write to stdio/tcp is basically equivalent.

Code duplication makes me sad. Fix.

In some cases, node headers do not properly center.