Documented build commands do not generate winafl.dll about winafl HOT 9 OPEN

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.

from winafl.

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.

from winafl.

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.

from winafl.

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.

from winafl.

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.

from winafl.

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

from winafl.

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`

from winafl.

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.

from winafl.

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?

from winafl.