wapiflapi / villoc Goto Github PK

Visualization of heap operations.

License: MIT License

Python 48.38% Makefile 2.40% C++ 22.62% CMake 1.31% Shell 1.88% C 23.42%

villoc's Introduction

Villoc

Villoc is a heap visualisation tool, it's a python script that renders a static html file. An example can be seen here: http://wapiflapi.github.io/villoc/, this is villoc running on an exploit of PlaidCTF 2015's challenge PlaidDB.

How to

The easiest way to use villoc is probably to run the following command and open out.html in a browser.

ltrace ./target |& villoc.py - out.html;

It is probably a good idea to disable ASLR for repeatable results and to use a file to pass the ltrace to villoc because otherwise the target's error output will be interleaved and might confuse villoc sometimes.

setarch x86_64 -R ltrace -o trace ./target; villoc.py trace out.html;

Using DynamoRIO

The problem with ltrace is that it doesn't track calls to malloc from other libraries or from within libc itself.

Please check https://github.com/wapiflapi/villoc/tree/master/tracers/dynamorio for (easy!) instructions for using a DynamoRIO tool to achieve full tracing.

Annotations

Villoc's input should look like ltrace's output, other tracers should output compatible logs. Villoc also listens to annotations of the following form:

@villoc(comma separated annotations) = <void>`

When using this it's possible to mark certain block as being significant which makes analyzing villoc's output that much easier.

Annotations from C code through DynamoRIO.

When using the dynamorio tracer there is a hack to easily inject annotations from a target's source code:

sscanf("Format string %d %d, FOO %s", "@villoc", 1, 2, "BAR");

Will inject Format string 1 2 into villoc's log and add the FOO and BAR tags to the block affected by the next memory operation.

Which malloc

This has been made with glibc's dl_malloc in mind. But it should work for other implementations, especially if you play with the --header and --footer options to indicate how much overhead the targeted malloc adds to the user data.

villoc's People

Contributors

Stargazers

Watchers

Forkers

idkwim hotelzululima hardbox t00sh jokerni 0xcc apcwowo ant4g0nist ksmaheshkumar intermezzo-fr bestpig eax64 kernelvuln dyjakan sigma-random polymorf palkeo firebitsbr pombredanne pyq881120 sixstars m0t r0cu3 lovebair2022 holinder4s chubbymaggie olivierh59500 flowm pentestingtools b1gw00d nnamon n30m1nd ykram lxpe markin gdlinklock zhouat crackercat fuzzamos ith4cker huntpig soolidsnake zxgio naim94a ampotos gavz totoroha luminixx ashr mrmugiwara bird8693 heruix xelentra1 nihilboy hobama loctempt 5l1v3r1 clayne asdyxcyxc 5433d-r32433 silentsoul04 0xc4se zha0 brokenice0415 amesianx gangaji15519 gmh5225 oub3ll4

villoc's Issues

The pintool is broken.

The pintool is broken. I shouldn't have merged it.

This isn't easy to get right because pintools isn't the right tool for the job. ltrace or LD_PRELOAD should be used to debug dynamic calls. If someone wants to fix this OK. Here are the issues:

There is no guarantee a called function will return using pintools because said function can jump into another one that isn't instrumented. For the pintool to be considered "working" it should handle this case and not be implementation dependent. This is a major issue. For example, on linux, calloc jumps into malloc at some point.
The pintool doesn't detect abnormal termination of the program. Abort or Segfault, etc. In general it should tell villoc that a function didn't return. Villoc will know what to do and mark corresponding blocks as failures. This is important.
The output isn't the same as ltrace's, (there is a missing space after the ',' in argument lists). This could also be fixed on villoc's side by changing the regex. Minor issue.

Support for malloc's from inside libc (eg. strdup or fopen)

Right now the easiest way of using villoc is with ltrace as documented in the README. This works fine in some cases but fails spectacularly when libc it's doing its own internal allocations, and especially if those are later freed from the target. (eg free(strdup()).

Right now the best (only?) idea I have is shipping a gdb script that sets some breakpoints and outputs something compatible with villoc's input.

If anyone has a better idea I'd be happy to talk about it!

villoc ignores output with ltrace -e

When using filters in ltrace, functions are prefixed with the calling library.
For example, if you run:
ltrace -e free+malloc gcc
You will get lines that are prefixed with gcc-> which villoc ignores:

...
gcc->malloc(6)                            = 0x1f6fd80
gcc->malloc(32)                           = 0x1f71a30
...

how can i use it with the pwntools script?

Output is reversed when using the trace file option

When using setarch x86_64 -R ltrace -o trace ./target; villoc.py trace out.html, the output is reversed. For exmple, the first malloc is at the bottom, and I have to read from bottom to top.