LibAFL
LibAFL copied to clipboard
AFLplusplus
libafl_wizard
How about naming this libafl_wizard or something similar? Not sure if ftg means anything to many ppl
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.
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?
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!
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.
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?
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!
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
I've changed the approach to the functions a bit, now I'll tet to get everything working!
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.
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!
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.
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?
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
syncrate.
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?