WIP - Initial scripting support #2506
Conversation
libafl_frida/build.rs
Outdated
| xz2::read::XzDecoder, | ||
| }; | ||
|
|
||
| fn extract() -> Result<()> { |
There was a problem hiding this comment.
Should this not be done in frida-rust?
There was a problem hiding this comment.
Yeah. Mostly likely. Seems there is only support for the gum devkit right now, we would need to replace it (probably a crate config option) with gumjs. Since one is a superset of the other.
libafl_frida/build.rs
Outdated
| entry.unpack(full_name.as_path())?; | ||
| found_header = true; | ||
| } | ||
| "libfrida-gumjs.a" => { |
There was a problem hiding this comment.
This doesn't take into account windows.
There was a problem hiding this comment.
Nope. Nor all of the other architectures.
libafl_frida/src/helper.rs
Outdated
| @@ -429,6 +439,7 @@ where | |||
| .map(PathBuf::from) | |||
| .collect::<Vec<_>>(); | |||
| FridaInstrumentationHelper::builder() | |||
| .load_script("/tmp/script.js") | |||
There was a problem hiding this comment.
This really needs to be an option.
There was a problem hiding this comment.
Of course, it needs to come from the command line or similar.
libafl_frida/src/script.rs
Outdated
| /// Create a new Script | ||
| pub fn load<P: AsRef<Path>>(path: P) -> Result<()> { | ||
| unsafe { | ||
| gum_init_embedded(); |
There was a problem hiding this comment.
You should use frida-gum::Gum::obtain()
There was a problem hiding this comment.
In general, all of these calls should be abstracted away by frida-rust objects.
There was a problem hiding this comment.
Agreed. I didn't want to mix the two.
libafl_frida/src/script.rs
Outdated
|
|
||
| /// Callback function which can be called from the script | ||
| #[no_mangle] | ||
| pub extern "C" fn test_function(message: *const gchar) { |
There was a problem hiding this comment.
Maybe move this into the fuzzer example (or even create a new fuzzer which uses this functionality).
There was a problem hiding this comment.
The idea of this was to demonstrate that the library can export a function which in turn is accessible to the user through scripting. In AFL++ frida scripting support JS can be used to configure the fuzzer too. e.g. by setting the ranges to be included/excluded in coverage, enabling ASAN etc. See here.
| @@ -0,0 +1,13 @@ | |||
| "use strict"; | |||
There was a problem hiding this comment.
Maybe move this into the fuzzer example (or even create a new fuzzer which uses this functionality).
There was a problem hiding this comment.
This relates to the above. The idea is to add a namespace and API to the JS layer which the user can call to interact with libafl_frida itself. e.g. the functions exported would not be target specific.
|
The addition of the |
libafl_frida/Cargo.toml
Outdated
| @@ -44,7 +44,13 @@ track_hit_feedbacks = ["libafl/track_hit_feedbacks"] | |||
| auto-download = ["frida-gum-sys/auto-download", "frida-gum/auto-download"] | |||
|
|
|||
| [build-dependencies] | |||
| anyhow = "1.0" | |||
There was a problem hiding this comment.
I think we should stick to our libafl_bolts::Error struct in LibAFL (and potentially implement more .into() cases)
|
Cool stuff! |
|
The changes in frida-rust have landed right? |
Yup. Just need to get some free time and I'll integrate them. Happy if someone else wants to do it, if people are waiting on it. The heavy lifting is done. |
|
No rush :) |
WorksButNotTested
force-pushed
the
script
branch
from
ca8ba26
to
eeb4d5f
Compare
|
Running the command... LIBAFL_DEBUG_OUTPUT=1
./target/release/frida_fuzzer
-F LLVMFuzzerTestOneInput
-H ./libpng-harness.so
-l ./libpng-harness.so
--backend quick-js
--script /tmp/script.jsLoading the script... LibAfl.testFunction("TEST FUNCTION");
const bytes = new Uint8Array([0x11, 0x22, 0x33, 0x44, 0x55]);
send("SENDING", bytes);
console.log("LOGGING");Results in the output... |
No description provided.