Skip to content
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

Debugging tips #2048

Merged
merged 3 commits into from
Apr 15, 2024
Merged

Debugging tips #2048

merged 3 commits into from
Apr 15, 2024

Conversation

tokatoka
Copy link
Member

No description provided.

@tokatoka
Copy link
Member Author

anything to add?

@domenukk
Copy link
Member

Lets move it to the book

DEBUGGING.md Outdated
This file answers some commmon questions that arise when you are writing a fuzzer using LibAFL.

## Q. My fuzzer crashed but the stack trace is useless.
You can enable `errors_backtrace` feature of `libafl` crate. With this the stacktrace is meaningful.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the errors_backtrace feature of the libafl_bolts crate

DEBUGGING.md Outdated
Try running the fuzzer with `introspection` feature of `libafl`. This will show how much time is spent on each module of your fuzzer.

## Q. I still have problems with my fuzzer.
Finally, if you really have no idea what is going on, run your fuzzer with logger enabled. (You can use `env_logger`, `SimpleStdoutLogger`, `SimpleStderrLogger` from `libafl_bolts`) (Don't forget to enable stdout and stderr), and you can open an issue or ask us in Discord.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should provide an example or link to a fuzzer that uses it

DEBUGGING.md Outdated
First, verify that your stdout and stderr are not redirected to `/dev/null`. If you get the log, then it should either fall into the previous 2 cases. Either the fuzzer crashed because you didn't have the initial seeds, or the coverage feedback is not working.

## Q. My fuzzer is slow.
Try running the fuzzer with `introspection` feature of `libafl`. This will show how much time is spent on each module of your fuzzer.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the ... feature of the ... crate

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A hyperlink here to the introspection feature would be nice that shows what it does

DEBUGGING.md Outdated
You can enable `errors_backtrace` feature of `libafl` crate. With this the stacktrace is meaningful.

## Q. I started the fuzzer but the corpus count is 0.
Unless the initial corpus is loaded with the "load_initial_inputs_forced" function, we only store the interesting inputs, which is the inputs that triggered the feedback. So this usually means that your input was not interesting or your target was simply not propoerly implemented.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Unless the initial corpus is loaded with the "load_initial_inputs_forced" function, we only store the interesting inputs, which is the inputs that triggered the feedback. So this usually means that your input was not interesting or your target was simply not propoerly implemented.
Unless the initial corpus is loaded with the "load_initial_inputs_forced" function, we only store the interesting inputs, which is the inputs that triggered the feedback. So this usually means that your input was not interesting or your target was simply not properly implemented.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A solution/debugging tip for either scenario would go a long way:

  1. How to confirm that my input was not interesting?
  2. How to check if target is not properly implemented. This one can be tricky but common pit falls could be mentioned at least.

DEBUGGING.md Outdated
Try running the fuzzer with `introspection` feature of `libafl`. This will show how much time is spent on each module of your fuzzer.

## Q. I still have problems with my fuzzer.
Finally, if you really have no idea what is going on, run your fuzzer with logger enabled. (You can use `env_logger`, `SimpleStdoutLogger`, `SimpleStderrLogger` from `libafl_bolts`) (Don't forget to enable stdout and stderr), and you can open an issue or ask us in Discord.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Finally, if you really have no idea what is going on, run your fuzzer with logger enabled. (You can use `env_logger`, `SimpleStdoutLogger`, `SimpleStderrLogger` from `libafl_bolts`) (Don't forget to enable stdout and stderr), and you can open an issue or ask us in Discord.
Finally, if you really have no idea what is going on, run your fuzzer with logging enabled. (You can use `env_logger`, `SimpleStdoutLogger`, `SimpleStderrLogger` from `libafl_bolts`) (Don't forget to enable stdout and stderr), and you can open an issue or ask us in Discord.

@tokatoka tokatoka merged commit da6118e into main Apr 15, 2024
19 of 20 checks passed
@tokatoka tokatoka deleted the debugging branch April 15, 2024 11:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants