-
-
Notifications
You must be signed in to change notification settings - Fork 324
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
LibAFL_Frida: add scripting support #2506
Conversation
libafl_frida/build.rs
Outdated
xz2::read::XzDecoder, | ||
}; | ||
|
||
fn extract() -> Result<()> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this not be done in frida-rust?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't take into account windows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This really needs to be an option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should use frida-gum::Gum::obtain()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, all of these calls should be abstracted away by frida-rust objects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe move this into the fuzzer example (or even create a new fuzzer which uses this functionality).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe move this into the fuzzer example (or even create a new fuzzer which uses this functionality).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 :) |
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.js Loading 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...
|
If nobody really has the time to test this atm (I don't) - should we just merge this and fix things later if they come up? cc @s1341 |
Sounds good to me if you're happy. |
Thanks for the merge. |
Thanks for the scripting support ;) |
Co-authored-by: Your Name <you@example.com>
No description provided.