-
Notifications
You must be signed in to change notification settings - Fork 336
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
Target restart behavior #45
Conversation
Can you help me understand the use case? Why/when do you want to enable stop first? It might be cleaner to implement this in the procmon itself. We could give it a .restart method, and then Session could altogether stop worrying about stop_first. |
This was just a small change that assisted me with a particular target that I'm fuzzing. I simply needed to be able to control the value of the I implemented it in |
Thanks for the PR btw. Are you able to share your motivation for wanting to change the As for the design, I'm taking a second look at the layout, maybe you're right. The sessions file used to look a lot uglier, and my goal for a while has been to get stuff out of it. Unfortunately, it's still basically the catch-all, which is less than ideal from a design standpoint (e.g., Single Responsibility Principle). |
To put a bit of context to this, I'm currently working on a research project involving fuzzing. As part of this I'm attempting to extend the Unix procmon's ability to act as fuzzing instrumentation. This is happening over in my fork. Without going to extensive detail, I needed to be able to manipulate |
And yeah, the Session class is definitely something of a catch-all as you said, however personally I feel that a major refactor in that area isn't really worth the effort at this time. It's come a long, long way since sulley (well done btw) and is easy enough to work with as is |
Recording my design decision here for reference: Single Responsibility PrincipleOne of the background refactoring goals is to move toward observation of the Single Responsibility Principle (SRP), in which each class would be conceptually responsible for one thing. Session is a huge violation currently. The Real WorldHowever, given the state of the project, separating concerns can be a real pain. This is because the program has been previously developed in violation of the SRP and Separation of Concerns. As you said, a proper refactor would be a comparatively huge effort to the proposed change. It'd be frustrating and anti-pragmatic to block this feature since it's currently so easy to implement. FutureIf you're trying to expand the procmon's capabilities, and if you need to give it various options, consider sending options via
This allows the configuration to stay on the fuzzing host. It is transmitted to the procmon host over RPC. I think the configurability of |
@omnifocal Session.fuzz() also calls |
@jtpereyda Thanks, I hadn't noticed that call to |
When taking a closer look at Session it appears that the default behaviour of Restarting the target in At this stage to allow full configurability one would need to pass two separate options into Session. One for restart behaviour in |
Excellent observation. It sounds like the usage in
Thinking about it again, it seems like the default of not stopping first in Eventually, the best solution may be to supplement procmon's start and stop methods with a single restart. That way the procmon itself can stop the UUT if and only if it needs to. Let me know if you have any thoughts, and thank you again for the contribution and patience with the review. |
@omnifocal Gentle bump. Are you OK with reverting the March 13th commit (see previous post)? If you're not able/interested anymore, just let me know. |
Closing due to lack of updates. Anyone is welcome to open a new PR. |
Stopping the target process before it is restarted has been made optional via the instance variable
stop_first
inboofuzz.session.Session