Fun with Python and Tycho

Posted on January 2, 2018 by Jacek Galowicz

This article demonstrates how simple it is to setup our analysis tool Tycho and plays with the Tycho Python API in order to outline its potential. We will pause and resume processes, read interesting process information, and inject errors using the Tycho Python API.

Tycho, which is the name of our live binary analysis tool (you may also regard it as a super debugger), can be used to hook into processes in order to analyze/debug them. As user frontends it may talk with GDB, IDA Pro, or any graphical debugger application that supports GDB, which feels familiar to most users.

In this post, we will not regard the GDB interface, but the Python API. We will see that it is really easy to integrate Tycho into your own python scripts and this way combine it with whatever other libraries you have been using already (like e.g. Volatility).

The Python library part is open source and you can always get the latest version in our Github Repository.

Setup

In order to analyse processes with Tycho via Python, we first need to set up both the analyst system and the system that is subject to analysis. This setup consists of just 2 steps:

  1. Boot supernova on the analysis box
  2. Run tycho-server on the developer laptop.

The following picture shows the typical setup:

Tycho Hardware Setup
Tycho Hardware Setup

When the analysis box gets to boot the supernova hypervisor, the hypervisor in turn will chainload the operating system that is already installed. This way supernova can quickly be deployed to any system with a reboot. After another reboot, it’s gone again.

Now we need to start tycho-server on the developer laptop. tycho-server connects to the running supernova instance via serial cable or USB debug cable and listens on a TCP port on the developer laptop. This way we get a communication channel to the hypervisor and can use python scripts that instruct it to do what we need.

Python Example

Now that we have a running hypervisor that we can talk to, let’s fire up a python shell and stop the builtin calculator calc.exe:

After the calc.pause() line, supernova is kind of “armed” to stop calc.exe as soon as it sees this process being scheduled again. When this happens, we observe the following:

On the analysis box: Tycho paused calc.exe
On the analysis box: Tycho paused calc.exe

An interesting detail is that this happens completely without support from the Windows side. Windows is not aware of us pausing this process! With a closer look at the task manager we see that calc.exe burns 50% CPU cycles, which is a side effect of our process pausing method. Note that this does not really burn 50% of the CPU cycles.

By running calc.resume(), we can resume normal process execution and everything is like it was before.

We can also do more. Let’s print the PID of calc.exe and see how many threads it has.

As we can see, our running calc.exe instance has PID 2932. Task manager shows us the same number. The get_thread_list() function yields us a list with only a single item. If we do the same query on the also running Internet Explorer, we get a more interesting result as it has a few threads running:

Let’s see what else we can do. How about listing what DLLs are loaded into a process? This information is listed in the VAD tree in the Windows kernel:

We can also kill calc.exe by sending it a page fault:

With the inject_pagefault line we inject a page fault at address 0, which looks like a null pointer dereference. From the perspective of the Windows kernel, this page fault came directly from the CPU. In reaction to that, it kills the calculator process.

calc.exe is being killed by Windows after we sent it a page fault via Tycho
calc.exe is being killed by Windows after we sent it a page fault via Tycho

Summary

We have seen how easy it is to prepare the analysis box for tampering around with it using the Tycho Python API. After rebooting the analysis box, the system is completely restored to the untouched state it was in before we booted supernova.

We have seen how to pause and resume processes like it is possible with normal debuggers - but without the support of the Windows kernel. This way the applications that run on this system cannot see any debugger artifacts.

In addition to that, we listed various process information (PID, thread list, VAD tree) and also killed a process by sending it a page fault.

Generally, there is more functionality like the following:

We will showcase more features within the next blog articles.


Share this article: