ASSERT FAILURE (error connecting to pipe) when testing the programs like notepad.exe about winafl HOT 11 CLOSED

Notepad seems to be running fine for me on Windows 7 64-bit. Most likely your target offset is wrong as suggested in the log. For me, this is how it looks like:

WinDbg output of 'lm' (relevant line)
start end module name
00000000ff980000 00000000ff9b5000 notepad (deferred)

WinDbg output of 'x notepad!WinMain'
00000000ff9834b8 notepad!WinMain =

So the offset on my system is 0x34b8

Here is my command line
c:\work\winafl\source\bin64>c:\work\winafl\DynamoRIO-Windows-6.1.1-3\bin64\drrun.exe -c winafl.dll -debug -target_module notepad.exe -target_offset 0x34b8 -fuzz_iterations 5 -nargs 4 -- C:\Windows\system32\notepad.exe test.txt

And here is the part of the corresponding debug log

Module loaded, dynamorio.dll
Module loaded, USER32.dll
Module loaded, KERNEL32.dll
Module loaded, ntdll.dll
Module loaded, winafl.dll
Module loaded, drmgr.dll
Module loaded, drx.dll
Module loaded, drreg.dll
Module loaded, drwrap.dll
Module loaded, notepad.exe
Module loaded, WINSPOOL.DRV
Module loaded, COMCTL32.dll
Module loaded, VERSION.dll
Module loaded, KERNELBASE.dll
Module loaded, RPCRT4.dll
Module loaded, GDI32.dll
Module loaded, OLEAUT32.dll
Module loaded, SECHOST.dll
Module loaded, LPK.dll
Module loaded, USP10.dll
Module loaded, COMDLG32.dll
Module loaded, msvcrt.dll
Module loaded, ADVAPI32.dll
Module loaded, MSCTF.dll
Module loaded, SHELL32.dll
Module loaded, ole32.dll
Module loaded, SHLWAPI.dll
Module loaded, IMM32.dll
In pre_fuzz_handler
Module loaded, CRYPTBASE.dll
Module loaded, UxTheme.dll
Module loaded, dwmapi.dll
In OpenFileW, reading C:\Windows\Fonts\staticcache.dat
In OpenFileW, reading test.txt
In post_fuzz_handler
In pre_fuzz_handler
In OpenFileW, reading test.txt
In post_fuzz_handler
In pre_fuzz_handler
In OpenFileW, reading test.txt
In post_fuzz_handler
In pre_fuzz_handler
In OpenFileW, reading test.txt
In post_fuzz_handler
In pre_fuzz_handler
In OpenFileW, reading test.txt
In post_fuzz_handler
Everything appears to be running normally.

A bit unrelated, but also note that WinMain might not be a good offset for notepad.exe since it will create a window and you'll need to manually close the window for every iteration in order for WinMain to return. Normally, you'd want to use a target_offset of the function that returns on its own after processing the input file.

from winafl.

1. WinAFL relies on DynamoRIO drwrap extension to wrap the target function. The entry point point is not called / returned from like a normal function and I assume drwrap is not meant to cover this case. While the ability to fuzz the entire process without providing any parameters might be an interesting feature to add in one of the future updates, I don't consider it a major issue since the ability of the user to select the target function is very much a deliberate feature and not a limitation. Note that target_offset of main in the examples is just that: an example. In other examples some other target functions would work better and that's precisely the case with with your second question.
2. The best way to fuzz a program such as this is to, instead of trying to run the entire program, choose a function inside the program that reads the input file, processes it and then returns. This will not be main/winmain but rather something deeper inside the program. There is no generic way to simulate interaction with the target program and if you really need that then you need to add your own code that does that.

from winafl.

The error you are getting means that winafl instrumentation (running inside your target process) attempted to connect back to afl-fuzz but was unable to do so.

For Chrome, being a very complex app that involves several processes, this could be explained if the main (browser) chrome process creates a child (e.g. a renderer) process and the child process attempts to connect to afl-fuzz, because if the parent process connected to the pipe correctly, afl-fuzz is no longer going to listen to new connections when the child process attempts it. To resolve problems such as this the new WinAFL version that I just released added -no_follow_children to DynamoRIO options. Note that if you want to fuzz Chrome you should run it in a single process mode.

On the other hand, I'm not sure how to explain problems with Notepad since I don't think it creates another process. If you are still experiencing problems with it, could you provide more details, such as Windows version, WinAFL debug log, exact command line you are using, what is your target function etc.

from winafl.

Ok.. I think that maybe I just set the wrong offset for notepad error, but it still didnt be run correctly on WinXp system.
command line :
afl-fuzz -i in -o out -t 5000+ -D DynamoRIO-6.1.1-3\bin32 -- -coverage_module notepad
-fuzz_iterations 5000 -target_module notepad.exe -target_offset 0x739D -nargs 2 -- notepad.exe @@
error: all test cases time out, giving up

Actually, Im not sure what the define of target_offset options is. i think it can be run when i give AddressOfEntryPoint or main function offset. But AddressOfEntryPoint is not right.
When I have no idea about the function name without pdb by IDA pro ,it is hard to set the right target_offset ...

from winafl.

Actually you should be able to get the PDBs for notepad (as well as most Microsoft apps), just use Microsoft's symbol server.

When you have an offset, first run WinAFL in the debug mode, as the debug mode will be able to tell you if the offset is incorrect. Make sure you use the latest WinAFL version which dumps more data in the log.

from winafl.

hi, I still have problems for nopate.exe. I have found the the PDB and offset value( WinMain function ) through windbg command. The problem is still occured.
Command line :
afl-fuzz -i in -o out -t 2000+ -D DynamoRIO-6.1.1-3\bin64 -- -coverage_module notepad
-fuzz_iterations 500 -target_module WinMain -target_offset 0x3a14 -nargs 2 -- notepad.exe @@
Error:
All test cases time out, giving up!
Log:
Target function was never called. Incorrect target_offset?
I know that this problem is setting wrong offset... Can you give me some suggestion to solve this one?thanks!
(My system is Win7 sp1 64bits and use 1.01 version. )

from winafl.

Looking at your command line again, this is wrong
-target_module WinMain
since WinMain is a function and not a module.
Also note that coverage_module should be 'notepad.exe' (not 'notepad', it needs to be exactly the same as in the debug log). Also note that WinMain takes 4 arguments and not 2.

from winafl.

hmm... It is successful to run after changing the arguments and target_module.
But I still dont know the offset and arguments mechanism. What is the execution mechanisms when i give the offset like Search function? Is it just only monitor this function or does it start from this function to run? (whatever i give the offset,the window is still open).
And when I gave the wrong arguments(even i dont give this option), the program can be run but immediately stopped at the cmd. What is the purpose of argument ?
The debug log:
Module loaded, dynamorio.dll
Module loaded, KERNEL32.dll
Module loaded, USER32.dll
Module loaded, ntdll.dll
Module loaded, winafl.dll
Module loaded, drmgr.dll
Module loaded, drx.dll
Module loaded, drreg.dll
Module loaded, drwrap.dll
Module loaded, notepad.exe
Module loaded, WINSPOOL.DRV
Module loaded, COMCTL32.dll
Module loaded, VERSION.dll
Module loaded, KERNELBASE.dll
Module loaded, msvcrt.dll
Module loaded, SHELL32.dll
Module loaded, LPK.dll
Module loaded, ADVAPI32.dll
Module loaded, IMM32.dll
Module loaded, RPCRT4.dll
Module loaded, MSCTF.dll
Module loaded, COMDLG32.dll
Module loaded, SECHOST.dll
Module loaded, GDI32.dll
Module loaded, ole32.dll
Module loaded, SHLWAPI.dll
Module loaded, USP10.dll
Module loaded, OLEAUT32.dll
Module loaded, CRYPTBASE.dll
Module loaded, UxTheme.dll
Module loaded, dwmapi.dll
In OpenFileW, reading C:\Windows\Fonts\staticcache.dat
Module loaded, CLBCatQ.DLL
Module loaded, ChewingTextService.dll
In OpenFileA, reading C:\Program Files (x86)\ChewingTextService\Dictionary\dictionary.dat
In OpenFileA, reading C:\Program Files (x86)\ChewingTextService\Dictionary\index_tree.dat
In OpenFileW, reading C:\Users\roger\ChewingTextService\uhash.dat
In OpenFileW, reading C:\Program Files (x86)\ChewingTextService\Dictionary\symbols.dat
In OpenFileW, reading C:\Program Files (x86)\ChewingTextService\Dictionary\swkb.dat
In OpenFileW, reading C:\Program Files (x86)\ChewingTextService\Dictionary\pinyin.tab
In OpenFileW, reading C:\test1.TXT

from winafl.

The idea is that you select a function that you're interested in fuzzing and WinAFL runs that function in a loop without restarting the target process (for speed). You tell WinAFL what function you selected by giving it the module and the offset.

The behavior should be

1. Target process executes normally until the target function is reached
2. Target function executes normally, but coverage gets recorded
3. When the target function returns coverage gets reported to afl-fuzz, WinAFL redirects the execution back to step 2 and restores the arguments of the target function (that's why nargs is important). This happens until fuzz_iterations have been completed. After that, the target process gets killed.

So if the target creates a window before target function gets reached (or during its execution) that's normal.

from winafl.

Thanks!!! It's really help me understand a lot!
Many programs have been run successfully, but I still have a little question want to ask...

1. Why I cant fuzz the target by main entry (AddressOfEntryPoint) , since it is very easy to find when I want to fuzz all the program functions.
2. How can I fuzz the interactive program? Whatever the systems is ( Window / Ubuntu ), the program like notepad.exe, VLC player will be opened windows and wait to close. However, the hang problem will happen.... Can you give me some advice how I can fuzz the interactive program?

from winafl.

Thanks @ivanfratric @ifratric
It really makes me understand a lot !

from winafl.