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

libafl_wizard #1344

Draft
wants to merge 24 commits into
base: main
Choose a base branch
from

Conversation

matheusbaptistella
Copy link
Contributor

No description provided.

libafl_ftg/questions.csv Outdated Show resolved Hide resolved
Copy link
Collaborator

Choose a reason for hiding this comment

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

Perhaps consider using an existing TUI crate instead of managing the UI yourself?

@domenukk
Copy link
Member

How about naming this libafl_wizard or something similar? Not sure if ftg means anything to many ppl

@matheusbaptistella matheusbaptistella changed the title Libafl ftg libafl_wizard Aug 15, 2023
@domenukk
Copy link
Member

I love the wizard logo :)

@domenukk
Copy link
Member

domenukk commented Nov 3, 2023

What's the status here?

@matheusbaptistella
Copy link
Contributor Author

What's the status here?

Hey guys, sorry for the late response, i've been having some trouble with Slint, turns out my implementation for both the UI and CLI version wouldn't work together. I tried separating the logic on another thread for the UI but when I had to communicate back to the event loop on the main thread I had to upgrade my weak reference of the window and when you do that the program crashes (took me some time to figure this out hahaha). Since my solutions to that problem weren't working, I decided to step back and first implement a working UI version and then see how the code would adapt to de CLI. I'll commit by the end of the day so you guys can check out the progress :)

Right now I'm finishing the details on how information is displayed on the screen. The code already generates a flowchart image of the questions diagram. Then develop the questions.

@domenukk
Copy link
Member

domenukk commented Nov 8, 2023

I'm not sure we need a proper gui, a cmdline thingy is more than enough, right? I assume our target audience is mostly on the commandline, anyway?

@s1341
Copy link
Collaborator

s1341 commented Nov 9, 2023

Yeah I had always envisioned this as a cli tool.

@matheusbaptistella
Copy link
Contributor Author

matheusbaptistella commented Nov 9, 2023

Yeah I had always envisioned this as a cli tool.

Alright! I'll just make the commit for you to see how it's looking so far, and then I'll begin to make the changes!

@matheusbaptistella
Copy link
Contributor Author

Hey guys, I made some changes: now the tool has a cli interface. Also, I changed the Question struct: now there is an Answer struct as well (so I had to changes some of the methods). So there is no need to associate code[0] with answer[0], now the Rust code associated with an Answer is contained in its struct.

@domenukk
Copy link
Member

So is it ready to merge or does it need work?

@domenukk domenukk marked this pull request as draft November 19, 2023 19:42
@matheusbaptistella
Copy link
Contributor Author

matheusbaptistella commented Nov 20, 2023

So is it ready to merge or does it need work?

Almost there, I'm providing a set of questions to generate a simple baby_fuzzer to test if the functions that arrange the code are working correctly. Also, about resolving the imports, do you think we can add them together with the code that will be written and then separate it e.g

use libafl::observers::StdMapObserver; // When writing to the file, the code would be parsed to separate the import  from the code and then add it at the baggining of the file.

let observer = StdMapObserver();

Or is there a better approach?

@matheusbaptistella
Copy link
Contributor Author

Hey guys, I'm working on the functions to resolve the imports, I'm using Regex to identify the modules name and do the logic. Think I'll make the commit tomorrow or on Suday!

@matheusbaptistella
Copy link
Contributor Author

The functions are not yet working, turns out it was easier doing it without Regex than with it. Just for you guys to take a look. Essentially, each piece of code in the TOML file should have the imports they need too. Then, we select all the imports needed for the whole code, exclude equal imports, modify the others etc

@matheusbaptistella
Copy link
Contributor Author

I've changed the approach to the functions a bit, now I'll tet to get everything working!

@matheusbaptistella
Copy link
Contributor Author

Hello guys, the wizard is working. I implemented the functions to arrange the imports, and made some tests. The currently output fuzzer file can be seem under the ./fuzzers. I feel like there is room for improvement on my logic for the imports functions, so I'll try to enhance it.

@matheusbaptistella
Copy link
Contributor Author

Hey guys, the wizard is ready to merge! Now it arranges imports correctly. I couldn't develop better question because I'm not so used to the components, but newer questions should work just fine. Please, contact me for future improvements if any errors appear. Thank you!

Comment on lines +176 to +184
use libafl::{
feedback_or_fast,
feedbacks::{CrashFeedback, TimeoutFeedback},
};

let mut objective = feedback_or_fast!(
CrashFeedback::new(),
TimeoutFeedback::new()
);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Instead of importing I believe it would be more robust if the full-qualified path to the struct/item is used.

    let mut objective = libafl::feedback_or_fast!(
        ...
    );

@maxammann
Copy link
Collaborator

I like the idea, however it seems like the current approach is to concatenate string segments together. A more robust way would be to have a abstract syntax tree representation of the final fuzzer. That way any conflicts in naming could be detected and errors could be reported before actually compiling it.

Maybe something like that is possible with the syn crate.

@maxammann
Copy link
Collaborator

Also, could it make sense to have this as an external crate? I seems like this is quite a burden for the LibAFL core devs to maintain as it is basically a large set of additional example fuzzers that need to be maintained. Maybe just advertising could make sense?

@matheusbaptistella
Copy link
Contributor Author

I like the idea, however it seems like the current approach is to concatenate string segments together. A more robust way would be to have a abstract syntax tree representation of the final fuzzer. That way any conflicts in naming could be detected and errors could be reported before actually compiling it.

Maybe something like that is possible with the syn crate.

Sure, at the time my knowledge on rust was shallow, which limited what I could develop. Are you working with this now? Do you know the status?

@maxammann
Copy link
Collaborator

Not really, I'm just a random user of Lib afk who saw a stale PR :)

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.

4 participants