Documented build commands do not generate winafl.dll

[blincoln-bf]

The troubleshooting steps for winafl involve running the DynamoRIO tool drrun.exe with winafl.dll. However, when I follow the build instructions in the README.md, there is no winafl.dll file generated. All of the binaries are generated, and they appear to work at least superficially, but there is no winafl.dll.

There used to be a version of winafl.dll included in the repo, but it was deleted in December 2022:

fc4361a#diff-58e5d6f1761f2f5be820b8f1f7913d109cc142ea8d05b0131e6f505ca60eda45

I looked in the cmake files and didn't find an obvious way to compel it to create the DLL either.

Were the steps dependent on that file?

I'm trying to run the troubleshooting steps because I'm having the same timeout issue discussed in the following open issues, some of which have been around for over a year:

#408

#402

#368

#278

I'm using Windows 10, Visual Studio 2022.

[ifratric]

Hi, I just built WinAFL on a new machine and verified everything's building correctly (Windows 11, VS 2022, DynamoRIO 10.0.0). winafl.dll should be output in the same directory as the .exe files (but that being said, it's possible it ended up in another subdirectory inside the build directory, so a file search can't hurt).

Most likely, however, is that the build system couldn't find DynamoRIO cmake files in the location pointed to by -DDynamoRIO_DIR cmake flag (or the flag is misspelled or missing). You can try using absolute rather than relative directory here as that's less error-prone.

There used to be a version of winafl.dll included in the repo, but it was deleted in December 2022

This file was outdated and thus removed. It is now always recommended to build your own WinAFL.

I'm trying to run the troubleshooting steps because I'm having the same timeout issue discussed in the following open issues, some of which have been around for over a year

Please note that the "timeout" issues in WinAFL likely indicate incorrect usage (as also indicated by FAQ) and not an issue with WinAFL itself, hence why a lot of them get left open.

[blincoln-bf]

Using the absolute path to the DynamoRIO cmake files seems to have done the trick regarding building the DLL. Thank you. It might be worth adding some explicit mention to the documentation that winafl.dll is only built if DynamoRIO support is correctly enabled in the build process. There wasn't anything in the build output or the docs that made me think those two things were directly related.

[ifratric]

Normally, I'd except this error to trigger:
https://github.com/googleprojectzero/winafl/blob/master/CMakeLists.txt#L153
Not sure why it didn't in your case.

[blincoln-bf]

Weird, yeah, didn't get that one.

FWIW, now that I have the DLL, I was able to determine that the reason for the underlying timeout in my case was that I was giving the offset in memory for the -target_offset option, as opposed to the offset in the image itself.

Now that I know it's expecting the offset in that form, I can use the tooltip in Ghidra to retrieve the actual value (Ghidra calls it the "Imagebase Offset"), but if I were using any other tool, I wouldn't have a great idea where to retrieve it from. Would it be practical to add a -target_address alternative that would accept the function's memory address instead of offset in the file, or at least display something like "the -target_offset value is greater than the size of the target binary on disk. Please verify that you're specifying the offset of the function in the file, not its address in memory"? I imagine this might be the cause of a lot of the mysterious timeout issues new users report.

[ifratric]

It isn't practical to take an absolute address because, due to ASLR, it's going to change each time the OS is rebooted and potentially even for each run. There is an alternative to -target_address which is -target_method which takes the function name instead of offset. It requires building WinAFL with -DUSE_DRSYMS=1 (see readme), but unfortunately it doesn't always work due to DynamoRIO issues.

[goldstar611]

This is outside my area of expertise but I think something changed in cmake because there's a warning that states Ignoring extra path from command line. As a workaround, I set a registry key that I know cmake will check at HKLM\Software\Kitware\CMake\Packages\DynamoRIO and just use -DDynamoRIO_DIR=1 on the command line.

For anyone who cares, my build steps are documented at https://github.com/goldstar611/winafl-releases/blob/master/.github/workflows/build_and_release.yml#L53-L57

[yuhui518]

I compile the winafl in Windows 10, Visual Studio 2022:
1.mkdir build64-debug && cd build64-debug
2.cmake -G"Visual Studio 17 2022" -A x64 .. -DDynamoRIO_DIR=D:\downnload\DynamoRIO-Windows-10.0.19824\cmake -DUSE_COLOR=1 -DUSE_DRSYMS=1
3.cmake --build . --config Debug

And after, I copy the winafl directory to the win11-arm64 computer.I run this:
afl-fuzz.exe -i in -o out -D "C:\Users\User\Desktop\Tools\Fuzzing\DRRUN\DynamoRIO-Windows-8.0.18929\bin64" -t 20000 -- -fuzz_iterations 5000 -target_module test_gdiplus.exe -target_method main -nargs 2 -- "test_gdiplus.exe" 1.bmp

The timeout error happened yet:
`[-] The program took more than 20000 ms to process one of the initial test cases.
In WinAFL, this error could also mean incorrect instrumentation params.
Please make sure instrumentation runs correctly using the debug mode
(see the README) before attempting to run afl-fuzz.

[-] PROGRAM ABORT : Test case 'id_000000' results in a timeout
Location : perform_dry_run(), D:\Download\winafl\afl-fuzz.c:3254`

[yuhui518]

And I run this:
C:\Users\User\Desktop\Tools\Fuzzing\DRRUN\DynamoRIO-Windows-8.0.18929\bin64\drrun.exe -c winafl.dll -debug
-target_module test_gdiplus.exe -target_offset 0x16e0 -fuzz_iterations 10 -nargs 2 -- test_gdiplus.exe input.bmp
there is no log occured.

[yuhui518]

I fuzz my test.exe in windows 10,Visual Studio 2022,it runs normal.When I move it and winafl to win11arm virtual machine,it resluts in a timeout.So,is it a bug in win11?