April | 2019 | My Technical Blog

Archive for April, 2019

25 Apr

Understanding open ports in Android applications: Discovery, diagnosis, and security assessment

Posted by Peter Teoh in technical. Leave a comment

https://ink.library.smu.edu.sg/cgi/viewcontent.cgi?article=5320&context=sis_research

24 Apr

A review: “Designing New Operating Primitives to Improve Fuzzing Performance” vs AFL-unicorn.

Posted by Peter Teoh in technical. Leave a comment

https://gts3.org/assets/papers/2017/xu:os-fuzz.pdf

Here an observation is made between the above paper and AFL-unicorn (https://tthtlc.wordpress.com/2019/03/16/afl-unicorn-what-is-it-and-how-to-use-it/).

First is the paper objective:

And this:

So to generalize even further, it is possible to optimize away any code path in the kernel, sacrificing certain kind of guarantee that operating system provide – those features that does not affect the fuzzing behavioral output, and thus allowing more CPU resources to be dedicated for fuzzing itself.

And to fuzz only the specific functions that need to be fuzzed: which is why snapshot() exist. It essentially capture the START of the CPU/process entire state (registers + memory) and then fuzz from that point onwards.

But this is exactly what Afl-Unicorn does too:

https://hackernoon.com/afl-unicorn-part-2-fuzzing-the-unfuzzable-bea8de3540a5

First the following is the “process state” at the start of the fuzzing cycle:

And next you have the end process state. So AFL-unicorn’s fuzzing process start state ==> snapshot(BEGIN) and AFL-unicorn’s fuzzing process end state ==> snapshot(END).

In fact AFL-unicorn is even leaner than that; any libraries call, or system call, generally have to be emulated. So fuzzing cycle may be faster – as only the bear essentials are computed. Anything non-userspace, or external libraries are treated differently – you can either use some precomputed values, or preallocate memory and supply it in piecemeal wise fashion at runtime (for the case of “malloc()” library calls, or “brk()”). Every individual system calls (or libraries call) need to be individually custom-handled, eg, what to do when “fork()” is called, or “malloc()”, or “open()” etc, fuzzing in the AFL-unicorn framework can be quite cumbersome, but in term of essential computations for the purpose of fuzzing – it is almost the minimum necessary.

So computationally, AFL-unicorn is even more efficient conceptually, but because this particular implementation is done in python – it suffers in term of speed. But Unicorn architecturally does allow non-python, or even raw binaries to be executed.