diff options
Diffstat (limited to 'frida_mode/Scripting.md')
| -rw-r--r-- | frida_mode/Scripting.md | 92 |
1 files changed, 57 insertions, 35 deletions
diff --git a/frida_mode/Scripting.md b/frida_mode/Scripting.md index 2ee0c858..fcf8a490 100644 --- a/frida_mode/Scripting.md +++ b/frida_mode/Scripting.md @@ -1,25 +1,32 @@ # Scripting + FRIDA now supports the ability to configure itself using JavaScript. This allows the user to make use of the convenience of FRIDA's scripting engine (along with it's support for debug symbols and exports) to configure all of the things which were traditionally configured using environment variables. -By default FRIDA mode will look for the file `afl.js` in the current working +By default, FRIDA mode will look for the file `afl.js` in the current working directory of the target. Alternatively, a script file can be configured using the environment variable `AFL_FRIDA_JS_SCRIPT`. -This script can make use of all of the standard [frida api functions](https://frida.re/docs/javascript-api/), but FRIDA mode adds some additional functions to allow -you to interact with FRIDA mode itself. These can all be accessed via the global -`Afl` parameter. e.g. `Afl.print("HELLO WORLD");`, +This script can make use of all of the standard [frida api +functions](https://frida.re/docs/javascript-api/), but FRIDA mode adds some +additional functions to allow you to interact with FRIDA mode itself. These can +all be accessed via the global `Afl` parameter, e.g., `Afl.print("HELLO +WORLD");`. If you encounter a problem with your script, then you should set the environment variable `AFL_DEBUG_CHILD=1` to view any diagnostic information. +## Example -# Example -Most of the time, users will likely be wanting to call the functions which configure an address (e.g. for the entry point, or the persistent address). +Most of the time, users will likely be wanting to call the functions which +configure an address (e.g., for the entry point or the persistent address). -The example below uses the API [`DebugSymbol.fromName()`](https://frida.re/docs/javascript-api/#debugsymbol). Another use API is [`Module.getExportByName()`](https://frida.re/docs/javascript-api/#module). +The example below uses the API +[`DebugSymbol.fromName()`](https://frida.re/docs/javascript-api/#debugsymbol). +Another use API is +[`Module.getExportByName()`](https://frida.re/docs/javascript-api/#module). ```js /* Use Afl.print instead of console.log */ @@ -86,9 +93,9 @@ Afl.done(); Afl.print("done"); ``` -# Stripped Binaries +## Stripped binaries -Lastly, if the binary you attempting to fuzz has no symbol information, and no +Lastly, if the binary you attempting to fuzz has no symbol information and no exports, then the following approach can be used. ```js @@ -98,11 +105,12 @@ const address = module.base.add(0xdeadface); Afl.setPersistentAddress(address); ``` -# Persisent Hook +## Persistent hook + A persistent hook can be implemented using a conventional shared object, sample source code for a hook suitable for the prototype of `LLVMFuzzerTestOneInput` -can be found [here](hook/hook.c). This can be configured using code similar to -the following. +can be found in [hook/hook.c](hook/hook.c). This can be configured using code +similar to the following. ```js const path = Afl.module.path; @@ -112,7 +120,8 @@ const hook = mod.getExportByName('afl_persistent_hook'); Afl.setPersistentHook(hook); ``` -Alternatively, the hook can be provided by using FRIDAs built in support for `CModule`, powered by TinyCC. +Alternatively, the hook can be provided by using FRIDA's built-in support for +`CModule`, powered by TinyCC. ```js const cm = new CModule(` @@ -134,8 +143,10 @@ const cm = new CModule(` Afl.setPersistentHook(cm.afl_persistent_hook); ``` -# Advanced Persistence +## Advanced persistence + Consider the following target code... + ```c #include <fcntl.h> @@ -281,14 +292,15 @@ Afl.done(); Here, we replace the function `slow` with our own code. This code is then selected as the entry point as well as the persistent loop address. -## Replacing LLVMFuzzerTestOneInput -The function `LLVMFuzzerTestOneInput` can be replaced just like any other. Also +### Replacing LLVMFuzzerTestOneInput + +The function `LLVMFuzzerTestOneInput` can be replaced just like any other. Also, any replaced function can also call itself. In the example below, we replace `LLVMFuzzerTestOneInput` with `My_LLVMFuzzerTestOneInput` which ignores the parameters `buf` and `len` and then calls the original `LLVMFuzzerTestOneInput` -with the paramaters `__afl_fuzz_ptr` and `__afl_fuzz_len`. This allows us to +with the parameters `__afl_fuzz_ptr` and `__afl_fuzz_len`. This allows us to carry out in-memory fuzzing without the need for any hook function. It should be -noted that the replacement function and the original can *NOT* share the same +noted that the replacement function and the original *CANNOT* share the same name, since otherwise the `C` code in the `CModule` will not compile due to a symbol name collision. @@ -320,7 +332,8 @@ Afl.setInMemoryFuzzing(); Interceptor.replace(LLVMFuzzerTestOneInput, cm.My_LLVMFuzzerTestOneInput); ``` -## Hooking `main` +### Hooking `main` + Lastly, it should be noted that using FRIDA mode's scripting support to hook the `main` function is a special case. This is because the `main` function is already hooked by the FRIDA mode engine itself and hence the function `main` (or @@ -359,14 +372,16 @@ Afl.setPersistentAddress(cm.main); Afl.setInMemoryFuzzing(); Afl.setJsMainHook(cm.main); ``` -## Library Fuzzing + +### Library Fuzzing It doesn't take too much imagination to see that the above example can be extended to use FRIDA's `Module.load` API so that the replaced `main` function can then call an arbitrary function. In this way, if we have a library which we -wish to fuzz rather than an execuatble, then a surrogate executable can be used. +wish to fuzz rather than an executable, then a surrogate executable can be used. + +## Patching -# Patching Consider the [following](test/js/test2.c) test code... ```c @@ -498,7 +513,7 @@ int main(int argc, char **argv) { There are a couple of obstacles with our target application. Unlike when fuzzing source code, though, we can't simply edit it and recompile it. The following script shows how we can use the normal functionality of FRIDA to modify any -troublesome behaviour. +troublesome behavior. ```js Afl.print('******************'); @@ -537,8 +552,10 @@ Afl.done(); Afl.print("done"); ``` -# Advanced Patching +## Advanced patching + Consider the following code fragment... + ```c extern void some_boring_bug2(char c); @@ -565,7 +582,7 @@ void LLVMFuzzerTestOneInput(char *buf, int len) { } ``` -Rather than using FRIDAs `Interceptor.replace` or `Interceptor.attach` APIs, it +Rather than using FRIDA's `Interceptor.replace` or `Interceptor.attach` APIs, it is possible to apply much more fine grained modification to the target application by means of using the Stalker APIs. @@ -649,39 +666,43 @@ Afl.setStalkerCallback(cm.js_stalker_callback) Afl.setStdErr("/tmp/stderr.txt"); ``` -Note that you will more likely want to find the -patch address by using: +Note that you will more likely want to find the patch address by using: ```js const module = Process.getModuleByName('target.exe'); /* Hardcoded offset within the target image */ const address = module.base.add(0xdeadface); ``` + OR + ``` const address = DebugSymbol.fromName("my_function").address.add(0xdeadface); ``` + OR + ``` const address = Module.getExportByName(null, "my_function").add(0xdeadface); ``` The function `js_stalker_callback` should return `TRUE` if the original -instruction should be emitted in the instrumented code, or `FALSE` otherwise. -In the example above, we can see it is replaced with a `NOP`. +instruction should be emitted in the instrumented code or `FALSE` otherwise. In +the example above, we can see it is replaced with a `NOP`. Lastly, note that the same callback will be called when compiling instrumented code both in the child of the forkserver (as it is executed) and also in the -parent of the forserver (when prefetching is enabled) so that it can be +parent of the forkserver (when prefetching is enabled) so that it can be inherited by the next forked child. It is **VERY** important that the same -instructions be generated in both the parent and the child, or if prefetching is +instructions be generated in both the parent and the child or if prefetching is disabled that the same instructions are generated every time the block is compiled. Failure to do so will likely lead to bugs which are incredibly difficult to diagnose. The code above only prints the instructions when running in the parent process (the one provided by `Process.id` when the JS script is executed). -# OSX +## OSX + Note that the JavaScript debug symbol api for OSX makes use of the `CoreSymbolication` APIs and as such the `CoreFoundation` module must be loaded into the target to make use of it. This can be done by setting: @@ -691,10 +712,11 @@ AFL_PRELOAD=/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation ``` It should be noted that `CoreSymbolication` API may take a while to initialize -and build its caches. For this reason, it may be nescessary to also increase the +and build its caches. For this reason, it may be necessary to also increase the value of the `-t` flag passed to `afl-fuzz`. -# API +## API + ```js class Afl { /** @@ -973,4 +995,4 @@ class Afl { return Afl.module.getExportByName(name); } } -``` +``` \ No newline at end of file |