search

CYB3RMX / Qu1cksc0pe

All-in-One malware analysis tool.
GNU General Public License v3.0
1.33k stars 186 forks source link

Make console prompt acceptance evaluation more flexible #63

Closed luis261 closed 4 months ago

luis261 commented 4 months ago

a tiny change, albeit quite nice to have IMO:

Currently, we only consider either y or Y affirmative responses. It might be nice for convenience to also accept "non-standard" answers, such as yes, yeah etc, anything starting with y after transforming to lowercase, you get the point.

While we're at it, we should also ignore whitespace.

Since the functionality for the prompts is now located at a shared, centralized location we can easily afford this change without much effort and have it apply consitently for all confirmation prompts to the user.

If you @CYB3RMX think this is too fuzzy & dumb don't worry, you can just reject & close it, it's just an idea (:

CYB3RMX commented 4 months ago

Hmm, it seems okay, but if someone tries to input anything that starts with 'y' and is nonsense?

luis261 commented 4 months ago

Good point, I'm not aware of any confirmation prompts where an unintended "go ahead" would be catastrophic though.

I can add a strict option which we could use in such circumstances to preserve a construct in the spirit of the old exact matching logic to avoid accidental confirmations for decisions with possibly "bad" outcomes.

I'll also grep through all occurences and see if I find any such code areas that should make use of that option.

luis261 commented 4 months ago

I can add a strict option which we could use in such circumstances [...] I'll also grep through all occurences and see if I find any such code areas that should make use of that option.

Ok, it's done. Regarding the possibly bad outcomes for unintended confirmations: I grep "user_confirm"'ed and we really just use it for verbosity/optional "add-on" analysis stuff for the most part, where even if it's accepted unintentionally it would still be benign, with the worst scenario being unintentional overcrowding of analysis output.

The only two occurences that may require the strict option would be the optional executable extrations in sigChecker.py, as well as possibly the signature database download in hashScanner.py. Let me know what you think: would enabling the strict option in those locations alleviate your concerns?

luis261 commented 4 months ago

I'm closing this for now. Maybe it's something we can reconsider in the future.