-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crashes saved aren't really crashes #47
Comments
Just to make sure. I tested this with AFL. Went throught the crashes using afl-collect (part of afl-utils), and found a heap error (which is exploitable). afl-collect 1.33a by rc0r hlt99@blinkenshell.org # @_rc0r [] Going to collect crash samples from '/home/kittytechno/fuzzing/pdfcrack/out_afl'. [] Saving sample classification info to database. |
Any reports? |
Hello. It's me again. So after letting pdfcrack fuzz. I wanted to analyze the crashes. However as it turns out. They weren't even crashes. When I looked pdfcrack gives an error about them not being save files (pdfcrack has save file feature I used to make go by faster). Sure an error, but no a crash.
It also let this fuzz overnight. It took up over 200GB by logging manul though to be crashes.
I'll upload the file so you can test this.
pdfcrack_fuzz.zip
Recreate Issue :
Just run the command
manul.py -i in2 -o out -n 3 -c pdfcrack_manul.config "pdfcrack_scource/pdfcrack -l @@"
The pdfcrack is already instrumented. When you have fuzzed as much as you want. Then you can run. pdfcrack_source/pdfcrack -l <a .sav in out>, and it should tell you that this is not a save or is corrupted, not crash.
The text was updated successfully, but these errors were encountered: