Edit FRIDA mode DEBUGGING.md

This commit is contained in:
llzmb 2021-11-25 20:50:18 +01:00
parent 9a485106b0
commit 133fba724a
2 changed files with 73 additions and 54 deletions

View File

@ -1,6 +1,8 @@
# Debugging
If you are using FRIDA mode and have hit some problems, then this guide may help If you are using FRIDA mode and have hit some problems, then this guide may help
you to diagnose any problems you are encountering. This assumes you have you to diagnose any problems you are encountering. This assumes you have
followed the [osx-lib](#test/osx-lib) example to start fuzzing your target. followed the [osx-lib](test/osx-lib) example to start fuzzing your target.
It should be noted that attempting to debug code using gdb which has been It should be noted that attempting to debug code using gdb which has been
instrumented in FRIDA is unlikely to be successful since the debugger will be instrumented in FRIDA is unlikely to be successful since the debugger will be
@ -10,69 +12,76 @@ you are very familiar with the implementation of Stalker, the instrumented code
generated by FRIDA is likely to be very difficult to follow. For this reason, generated by FRIDA is likely to be very difficult to follow. For this reason,
the following debugging strategies are outlined below. the following debugging strategies are outlined below.
By convention below all files should be provided with their path (they are By convention, all files below should be provided with their path (they are
omitted for readability) and all items in `<braces>` are placeholders and should omitted for readability) and all items in `<braces>` are placeholders and should
be replaced accordingly. be replaced accordingly.
# Select your version ## Select your version
Test with both the `dev` and `stable` branches of AFL++. The `dev` branch should Test with both the `dev` and `stable` branches of AFL++. The `dev` branch should
have the very latest version containing any fixes for identified issues. The have the very latest version containing any fixes for identified issues. The
`stable` branch is updated less frequently, but equally might avoid a problem if `stable` branch is updated less frequently, but equally might avoid a problem if
a regression has been introduced into the `dev` branch. a regression has been introduced into the `dev` branch.
# Enable Diagnostic Information ## Enable diagnostic information
- Run your target specifying the `AFL_DEBUG_CHILD=1` environment variable. This
will print a lot more diagnostic information to the screen when the target Run your target specifying the `AFL_DEBUG_CHILD=1` environment variable. This
starts up. If you have a simple configuration issue then you will likely see a will print a lot more diagnostic information to the screen when the target
warning or error message in the output. starts up. If you have a simple configuration issue, then you will likely see a
warning or error message in the output.
## Check your test harness
# Check your Test Harness
If any of the following steps fail, then there is a problem with your test If any of the following steps fail, then there is a problem with your test
harness, or your target library. Since this is running without FRIDA mode or harness or your target library. Since this is running without FRIDA mode or
`afl-fuzz` that greatly reduces the search area for your defect. This is why it `afl-fuzz` that greatly reduces the search area for your defect. This is why it
is *VERY* important to carry out these basic steps first before taking on the is *VERY* important to carry out these basic steps first before taking on the
additional complexity of debugging with FRIDA mode or `afl-fuzz`. additional complexity of debugging with FRIDA mode or `afl-fuzz`.
- Run your harness outside of the fuzzer, passing it a representative seed as - Run your harness outside of the fuzzer, passing it a representative seed as
it's input `./harness <input>`. it's input `./harness <input>`.
- Pass you harness multiple seeds to check that it is stable when running - Pass your harness multiple seeds to check that it is stable when running
multiple tests as it will when running in fork server mode `./harness <input1> multiple tests as it will when running in fork server mode `./harness <input1>
<intput2>`. <intput2>`.
- Build your test harness with `CFLAGS=-fsanitize=address` and - Build your test harness with `CFLAGS=-fsanitize=address` and
`LDFLAGS=-fsanitize=address`. Then run it again with multiple inputs to check `LDFLAGS=-fsanitize=address`. Then run it again with multiple inputs to check
for errors (note that when fuzzing your harness should not be built with any for errors (note that when fuzzing, your harness should not be built with any
sanitizer options). sanitizer options).
# Check the Samples ## Check the samples
FRIDA mode contains a number of different sample targets in the `test` folder.
Have a look throught these and find one which is similar to your real target.
Check whether you have any issues running the sample target and make sure you
compare the command line used to launch the sample with that you are using to
launch your real target very carefully to check for any differences. If possible
start with one of these samples and gradually make changes one at a time
re-testing as you go until you have migrated it to run your own target.
# FRIDA Mode FRIDA mode contains a number of different sample targets in the `test` folder.
## Basic Have a look through these and find one which is similar to your real target.
First just try running your target with `LD_PRELOAD=afl-frida-trace.so ./harness Check whether you have any issues running the sample target and make sure you
<input>`. An error here means that your defect occurs when running with just compare the command line used to launch the sample with the one you are using to
FRIDA mode and isn't related to `afl-fuzz`. launch your real target very carefully to check for any differences. If
possible, start with one of these samples and gradually make changes one at a
time re-testing as you go until you have migrated it to run your own target.
## FRIDA mode
### Basic
First, just try running your target with `LD_PRELOAD=afl-frida-trace.so
./harness <input>`. An error here means that your defect occurs when running
with just FRIDA mode and isn't related to `afl-fuzz`.
Now you can try commenting out the implementation of `LLVMFuzzerTestOneInput` so Now you can try commenting out the implementation of `LLVMFuzzerTestOneInput` so
that the harness doesn't actually run your target library. This may also aid in that the harness doesn't actually run your target library. This may also aid in
narrowing down the problem. narrowing down the problem.
```c ```c
int LLVMFuzzerTestOneInput(const unsigned char* data, size_t size){ int LLVMFuzzerTestOneInput(const unsigned char* data, size_t size){
// fpn_crashme(data, size); // fpn_crashme(data, size);
return 0; return 0;
} }
``` ```
## Persistent Mode ### Persistent mode
If your target is ok running in basic mode, you can try running it in persistent If your target is ok running in basic mode, you can try running it in persistent
mode (if that is the configuration you are having issues with) as follows (again mode (if that is the configuration you are having issues with) as follows (again
outside of afl-fuzz). This time you will want to run it inside a debugger so outside of `afl-fuzz`). This time, you will want to run it inside a debugger so
that you can use the debugger to send the `SIGCONT` signals (by continuing) that you can use the debugger to send the `SIGCONT` signals (by continuing)
usually sent by `afl-fuzz` on each iteration. usually sent by `afl-fuzz` on each iteration.
@ -84,13 +93,15 @@ gdb \
--ex 'set environment AFL_FRIDA_PERSISTENT_ADDR=<entry_address>' \ --ex 'set environment AFL_FRIDA_PERSISTENT_ADDR=<entry_address>' \
--args ./harness <input> --args ./harness <input>
``` ```
Note we have to manually set the `__AFL_PERSISTENT` environment variable which
is usually passed by `afl-fuzz`.
Note that setting breakpoints etc is likely to interfere with FRIDA and cause Note:
spurious errors. - We have to manually set the `__AFL_PERSISTENT` environment variable which is
usually passed by `afl-fuzz`.
- Setting breakpoints etc. is likely to interfere with FRIDA and cause spurious
errors.
If this is successful, you can try additionally loading the hook library: If this is successful, you can try additionally loading the hook library:
```bash ```bash
gdb \ gdb \
--ex 'set environment __AFL_PERSISTENT=1' \ --ex 'set environment __AFL_PERSISTENT=1' \
@ -100,6 +111,7 @@ gdb \
--ex 'set environment AFL_FRIDA_PERSISTENT_HOOK=frida_hook.so' --ex 'set environment AFL_FRIDA_PERSISTENT_HOOK=frida_hook.so'
--args ./harness <input> --args ./harness <input>
``` ```
Note that the format of the hook used for FRIDA mode is subtly different to that Note that the format of the hook used for FRIDA mode is subtly different to that
used when running in QEMU mode as shown below. Thus the DSO used for the hook is used when running in QEMU mode as shown below. Thus the DSO used for the hook is
not interchangeable. not interchangeable.
@ -112,12 +124,14 @@ void afl_persistent_hook(struct x86_64_regs *regs, uint64_t guest_base,
uint8_t *input_buf, uint32_t input_buf_len); uint8_t *input_buf, uint32_t input_buf_len);
``` ```
## ASAN ### ASAN
It is also possible to enable ASAN (if that is the configuration you are having It is also possible to enable ASAN (if that is the configuration you are having
issues with) without having to use `afl-fuzz`. This can be done as follows (note issues with) without having to use `afl-fuzz`. This can be done as follows:
that the name of the asan DSO may need to be changed depending on your
platform). Note that the asan DSO must appear first in the `LD_PRELOAD` Note:
environment variable: - The name of the asan DSO may need to be changed depending on your platform.
- The asan DSO must appear first in the `LD_PRELOAD` environment variable.
```bash ```bash
LD_PRELOAD=libclang_rt.asan-x86_64.so:afl-frida-trace.so \ LD_PRELOAD=libclang_rt.asan-x86_64.so:afl-frida-trace.so \
@ -132,29 +146,34 @@ DSO from coverage. Failure to do so will result in ASAN attempting to sanitize
itself and as a result detecting failures when it attempts to update the shadow itself and as a result detecting failures when it attempts to update the shadow
maps. maps.
# Printf ## Printf
If you have an idea of where things are going wrong for you, then don't be If you have an idea of where things are going wrong for you, then don't be
scared to add `printf` statements to either AFL++ or FRIDA mode itself to show scared to add `printf` statements to either AFL++ or FRIDA mode itself to show
more diagnostic information. Just be sure to set `AFL_DEBUG=1` and more diagnostic information. Just be sure to set `AFL_DEBUG=1` and
`AFL_DEBUG_CHILD=1` when you are testing it. `AFL_DEBUG_CHILD=1` when you are testing it.
# Core Dumps ## Core dumps
Lastly, if your defect only occurs when using `afl-fuzz` (e.g. when using
`CMPLOG` which cannot be tested outside of `afl-fuzz` due to it's need for a Lastly, if your defect only occurs when using `afl-fuzz` (e.g., when using
`CMPLOG` which cannot be tested outside of `afl-fuzz` due to its need for a
shared memory mapping being created for it to record its data), it is possible shared memory mapping being created for it to record its data), it is possible
to enable the creation of a core dump for post-mortem analysis. to enable the creation of a core dump for post-mortem analysis.
Firstly check your `/proc/sys/kernel/core_pattern` configuration is simply set Firstly, check if your `/proc/sys/kernel/core_pattern` configuration is simply
to a filename (AFL++ encourages you to set it to the value 'core' in any case set to a filename (AFL++ encourages you to set it to the value `core` in any
since it doesn't want any handler applications getting in the way). Next set case since it doesn't want any handler applications getting in the way).
`ulimit -c unlimited` to remove any size limitations for core files. Lastly,
when you `afl-fuzz` set the environment variable `AFL_DEBUG=1` to enable the Next, set `ulimit -c unlimited` to remove any size limitations for core files.
creation of the `core` file. The file should be created in the working directory
of the target application. If there is an existing `core` file aleady there, Lastly, when you `afl-fuzz`, set the environment variable `AFL_DEBUG=1` to
then it may not be overwritten. enable the creation of the `core` file. The file should be created in the
working directory of the target application. If there is an existing `core` file
already there, then it may not be overwritten.
## Reach out
# Reach out
Get in touch on discord and ask for help. The groups are pretty active so Get in touch on discord and ask for help. The groups are pretty active so
someone may well be able to offer some advice. Better still, if you are able to someone may well be able to offer some advice. Better still, if you are able to
create a minimal reproducer for your problem it will make it easier to diagnose create a minimal reproducer for your problem, it will make it easier to diagnose
the issue. the issue.

View File

@ -363,8 +363,8 @@ using `AFL_FRIDA_INST_RANGES` or similar.
## Debugging ## Debugging
Please refer to the [debugging](#debugging) guide for assistance should you Please refer to [DEBUGGING.md](DEBUGGING.md) for assistance should you encounter
encounter problems with FRIDA mode. problems with FRIDA mode.
## To do ## To do