Comments (9)
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.
Related Issues (20)
- Compilation failed HOT 3
- How to stop WinAFL properly? HOT 1
- Winafl + Libprotobuf-mutator
- WinAFL Internal Crash at PC 0x5a1a456e HOT 6
- PROGRAM ABORT : Unexpected result from pipe! expected 'P', instead received '' HOT 1
- ERROR while building winafl HOT 1
- Error: Can't open .cur_input
- drrun.exe and afl-fuzz.exe giving error when -fsanitize=address flag given to compile target
- PROGRAM ABORT : Test case 'id_000000' results in a crash HOT 3
- Occur time out when init test case
- Incorrect detection count threads on multiCPU motherboards HOT 2
- Winafl doesn't want to start, reading other issues didn't help
- PROGRAM ABORT : CreateNamedPipe failed, GLE=231 HOT 2
- tmin: Proposing del_len option for improved speed HOT 2
- Is dumb mode (-n) currently implemented? HOT 4
- My output keeps showing a timeout HOT 8
- problem about finding crashes HOT 6
- not running under DR HOT 4
- No expected output when using standalone debug mode of WinAFL client HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from winafl.