problems about bytes input of tracer and dynamic length

[EricCornell]

Hi, guys. Merry Christmas to you and your family. I was using tracer of angr to generate new paths for libpng.

1. about the bytes input of tracer The input of tracer seems to be string only and in my case the input is the bytes stream of png file. So the input is not string. How can i transform these bytes stream to Tracer? Now my provisional solution is to put the bytes stream of png file into the write element of pov(Proof of Vulnerability) file. Then i transform the pov file to tracer.

2. about dynamic length When the length parameter of read or fread is determined by another input data, the tracer result seems confusing. The following is one snippet of the code. read(0, p_header, 0x10); length = *(int*)(p_header + 8); p_data = (char*)malloc(length); read(0, p_data, length); I attach the full source code of my test.c file. This file is a demo of parsing a simple file format like this: 0-7 the magic fields 8 -11 the length of data 12-?? data The data of the write element in the pov file is as the following. <data>\x89\x50\x4e\x47\x0d\x0a\x1a\x0a\x00\x00\x00\x0d\x49\x48\x44\x52\x00\x00\x00\x5b\x00\x00\x00\x45\x08</data> The length field should be 0xD and occupy 4 bytes in the write element of pov file.

However, the length field in tracer result is 0x01F0f and it seems that the length field occupies 8 bytes. The result of tracer is attached in the output_of_tracer.txt.

output_of_tracing_test.txt test.c.txt

[zardus]

Pasting @salls' response from the mailing list, for completeness.

For question 1, strings in python can contain arbitrary bytes, so it should be fine to make the bytes a string and pass it to the program that way. That way is better tested than using a pov write element, although either should work

For your other question, tracer will ensure that it takes the same path that qemu took when it solves for inputs, these inputs might have different values than those in the input. To me it looks like the length field in the tracer result is 0 and occupies 4 bytes. It seems the solver just returned 0 when solving for the read length, which is valid since it will still take the same code path.

If you are looking to find new paths you should look at the code of driller https://github.com/shellphish/driller which uses tracer to do that. Although driller expects afl's bitmap, you can run it like in this example: https://github.com/shellphish/driller/blob/master/tests/test_driller.py to look for any additional paths.

Also, tracer and driller have only been tested a little bit on non-CGC binaries. If you run into things you need to fix, don't hesitate to send us a pull request.

-Chris

[github-actions[bot]]

This issue has been marked as stale because it has no recent activity. Please comment or add the pinned tag to prevent this issue from being closed.

[github-actions[bot]]

This issue has been closed due to inactivity.