Go: Explore Windows fuzzing artifact----WINAFL

Ext.: HTTP://WWW.TUICOOL.COM/ARTICLES/J2EQYM6

Summary: Find functions of interest, calculate offsets, automate fuzz.

This is a guest article, the author is a cloud binary vulnerability mining white hat K0SHL. In fact, 17th last month, this article has been finished, but we have been "cover" to today. It's a gift for the white hat in the binary direction:)

0x01 What is WINAFL

In fact, said Afl-fuzz everyone will not be very unfamiliar, Afl-fuzz is Linux for fuzz file format, protocol and other binary vulnerability artifact, and WINAFL is Afl-fuzz of Windows Edition, recently I did some shallow research on WINAFL, by In the past also carried out a period of time in the binary vulnerability mining, but basically are stuck in the manual excavation, more and more feel the powerful automation artifact, but also for their own development of fuzz tools to provide a very important guidance basis.

What the hell is WINAFL?

WINAFL is a semi-automated tool for mining file format, Protocol Vulnerability in Windows, why is semi-automated, because WINAFL does not provide a comprehensive sample library for specific software, although WINAFL does provide some test samples, but actually the process of real fuzz , many files need to be constructed by hand.

Second, compared to Automatic fuzz, WINAFL need to manually locate the function address offset needed to fuzz, to determine the specific location of the function to be fuzz.

So what is the advantage of WINAFL in comparison? Here I would like to mention my understanding, the advantage of WINAFL is that it uses code extension to determine the input and output, so as to determine whether the existence of loopholes, so that may be more dizzy.

This principle is a bit like a pin plug-in, the pin plugin is a kind of plug-in provided by Microsoft for Assembly instruction extension, I use a picture to describe this process briefly.

How to understand this process, you can imagine hooks, piles and other processes, in the function entry and function return, check the program input and output is expected and so on, by inserting some "extra" instructions to check, so that the location of the crash position more accurate, false alarm rate is very low and so on.

How did you first learn fuzz ?

There are a lot of people just beginning to contact binary, or learning for a while the binary partner will ask me how to dig, or just start to learn how to dig a binary vulnerability method, in fact, I would like to say that binary vulnerability mining is a difficult process, as now some similar to strcpy_s, or software security is getting better, Fuzz more and more difficult, want to dig high-level loopholes, need some knowledge of getting started, my level is not high, here with you to share some of my fuzz experience, but also for the use of WINAFL fuzz do some foreshadowing.

In the introduction of vulnerability mining, the most important thing is to focus on the vulnerability of the program may exist, in fact, and the web very much like, in the binary, the user input should also be untrusted, and here the so-called vulnerable point, is in the user input and program interaction process, the more interesting functions are: strcpy, memcpy, sprintf, read and other functions, pointer passing, pointer assignment, and other operations.

Let me give you a simple example of using IDA to analyze a software and find a more interesting call.

Here we pay attention to call a strcpy call, we can through the WinDbg additional debugging, in the j_strcpy position breakpoint, so that, in the program execution, if called this function, will hit this breakpoint (of course, here with ollydbg is also possible).

In the sensitive function location, the breakpoint, through the additional execution of the sample and so on, until the breakpoint, and then the function execution before and after the input and output to determine whether the sample can cause the program crashes, whether it is controllable, is a cause of denial of service or code execution of the vulnerability.

Through the subsequent execution, judging the stack space coverage, to determine whether this is an exploit, you can see that the stack backtracking has been shattered by the malformed string, the malformed string is the structure of the sample, the user-controllable string part.

Here is simply a brief description of the simplest binary vulnerability mining process, in fact, carefully recall the process I described, the function into the launch of the input and output check, that is, to add a similar to the extension of the instruction process, then in fact, automation fuzz a simple model.

0x02 WINAFL Fuzz before the preparation

Here, we use a software called Vuplayer to make use of WINAFL fuzz to do a simple vulnerability mining, see the online Afl-fuzz tutorial of the small partners may find in fact, this excavation process takes a long time, instruction extension in a sense to increase the code redundancy, increase the execution time, Here I provide a PoC that can trigger a vuplayer buffer overflow vulnerability, just to explain the use and simplicity of WINAFL fuzz.

Looking for a potential vulnerability.

I mentioned earlier that WINAFL fuzz needed to provide a function offset, and in the simple exploit above, I mentioned the search for a sensitive function, so let's take a look at the function structure of vuplayer and use IDA to analyze the function part of Vuplayer.

The function called the function Lstrcpya of a system DLL was found, so we traced the lstrcpya and found a function.

Then we choose this function to fuzz, the function entry offset is 0x532a0, and then we start to prepare fuzz.

What is Dynamorio?

Before the fuzz, have to mention WINAFL fuzz must be used Dynamorio, this software I also first heard, may be a lot of binary old driver to it is not unfamiliar, in fact, after a cursory look at the source of WINAFL, I found in fact WINAFL a lot of implementation, have borrowed D Ynamorio, a communication pipeline is established between the two to achieve a call between the two.

And Dynamorio should be regarded as the core of WINAFL, it is the main implementation of the instruction dynamic insertion pile, in fact, I mentioned the instruction extension, the function input and output of a certain check. About the principle of Dynamorio and introduction on the internet has a lot of description, here do not introduce too much.

test process with Dynamorio

Here we need to use the Dynamorio Ddrun.exe tool, the code is as follows

<code>

PATH\TO\DYNAMORIO\BIN64\DRRUN.EXE-C winafl.dll-debug-target_module [target EXE or dll]vuplyaer.exe-target_ Offset0x532a0-fuzz_iterations--[Target Exe]vuplayer.exe </code>

Here are some simple explanations, first,-D, to link to the AFL fuzz, mainly called Winafl.dll, Target_module is the test target module, Target_offset is offset, so the target program will open.

Next attach a sample, found that the program crashed, in fact, at this time, in the target directory will generate a log file.

This log file actually records the modules that were loaded during the test Vuplayer, as well as the changes in the position of the offset function, which allows a simple analysis of the crash scenario.

Analysis of 0x03 WINAFL fuzz and Core source code

Using WINAFL for fuzz

After understanding the basic workflow of the DYNAMOAFL fuzz, we can use WINAFL for vulnerability mining, in fact WINAFL need to provide multiple samples to mine the target program.

To introduce WINAFL, we still use sample files that can cause crashes to the target program.

<code>

C:\programfiles\vuplayer>afl-fuzz.exe-i In-o out-d C:\Users\Administrator\De

Sktop\dynamorio-windows-6.1.1-3\dynamorio-windows-6.1.1-3\bin32-t 20000---Fuz

Z_iterations 5000-target_module vuplayer.exe-target_offset 0x532a0-nargs 2--VUPlayer.exe @@

</code>

Here still need some simple description of the parameters, first afl-fuzz need and winafl.dll at the same time in the target folder, the-i parameter is used to record input samples,-o parameter to save the output data,-D is the path of the Dynamorio,-T is the sample test delay,-t Arget_offset is the offset to test the function.

When exposed to crashes.

Results analysis

When the WINAFL encounters a crash scenario, a series of files are generated under the folder-O setting and the various information generated in the instruction extension is recorded in detail.

The crashes file records the crash sample, and the queue records various information in the instruction extension, Cur_input is the current input information.

The analysis of the instructions after the generation of crash can clearly analyze what happens to the input and output of this function. Or, after obtaining a sample that can crash, directly attach WinDbg to reproduce the vulnerability, but also can quickly analyze the cause of the vulnerability.

Key points in the source code

Before mentioned the importance of Dynamorio in WINAFL fuzz, in fact, there are many parts of the source code, the following from the source of the point of view some of the key points in the fuzz.

This location defines the path to the Dynamorio so that subsequent calls to the tool in the Dynamorio will be called.

The key statement of the construction instruction insert pile, can see here calls the Ddrun, is the dynamorio dynamic inserting the pile the core tool.

Process information for the target process to crash. In fact, there are many, such as the process restart mechanism, command expansion after the record input and output, key function address and other information, and so on.

Go: Explore Windows fuzzing artifact----WINAFL