Start improving error handling in main module

[luis261]

here's some minor changes to get this started:

• cleanup code should preferrably run in a finally clause, this way we make sure it's always run without needing to duplicate code
• since it seems like what you're looking to handle with the except clauses for the non-std lib imports is errors caused by missing modules, that should also be the only thing they catch
  • except clauses without a specified exception or an overly general class in the inheritance hierarchy should be avoided, otherwise they'll catch all kinds of unexpected scenarios which they shouldn't really, such as:
  • SyntaxError (obviously you wouldn't want to catch these since they indicate the code itself is faulty, irrespective of circumstance)
  • KeyboardInterrupt (you run the risk of suppressing a users intention of shutting down the program if you're in a try codepath with such an overly permissive except when the interrupt is raised)
  • any general kinds of errors relating to resource limitations or the OS, such as the system running out of memory (MemoryError) during an import etc etc, you get the point
• I don't get what you're trying to accomplish with all the sys.exit(1) calls; I propose direct exception raises instead.
  • this way, we avoid "eating" (hiding) any information about what caused the error by letting it propagate upwards instead, so the end user has maximum context when troubleshooting bc he has a (full) traceback
  • we can still keep your additional prints (if you want, I don't think they really add much IF we make sure to deliver the traceback instead)

=======================================================================

Hey @CYB3RMX,

I appreciate your work on this project. I like what I'm seeing in terms of actual functionality, quite a holistic set of analysis features/file scanning capabilities you've built up here over the years! We use it at my org (as part of a set of lots of other, diverse analysis tooling) and I'd like to personally give back a bit by contributing in my spare time.

Think of the changes in this PR (and the ones I've already submitted, as well as further ones I might sent through the course of tonight) as just a small sample representing the kinds of changes I'd like to apply.

I'm a bit nitpicky when it comes to (Python) code and would also like to take care of typos as well as moving the codebase towards PEP 8 compliance (I'm not a complete stickler when it comes to PEP8 in particular, but let's at least get the simpler things right, such as moving variable and module names from inconsistent naming schemes/camelCase towards snake_case). However, since you're ultimately in charge here, if you tell me that I should ignore that kinda stuff upfront, I am happy to respect that and will try to let it go ^^

I hope you're open to me proposing changes, as I feel like your project could benefit from them (see below). If you are on board with me trying to improve this project, I have a lot more on my mind, e.g.:

Quality:

• better interactions with the system by using stdlib functions over subprocesses/subshells (this also improves security a bit)
• generally reducing the size of the codebase/making it less verbose by consolidating duplicated code and possibly rearchitecting some things
• introducing automated testing, specifically unit tests, at least in the places that could benefit the most from them (e.g. maybe for some of the more "fiddly" analysis modules?)
• focus on more defensive coding and generally try to safeguard the program against abuse/make it less susceptible to evasion techniques?

Usability:

• improving error handling on a broader scope (follow up with commits for qu1cksc0pe.py, then continue beyond the main module)
• make the code more platform agnostic (where possible, besides the given limitations)

Extensions (I work as a Security Analyst at my day job so I might have some stuff to offer when it comes to the analysis-specific parts of the code):

• adding new/improving/extending existing analysers

Performance:

• at first glance, I did not see anything of particular concern, but maybe assembling a test set of representative samples (whatever that means) and performing a profiling run is in the cards? (again, maybe .. in the long run, not an immediate priority)

I know the plan might seem overly ambitious/big but I'll take it slow in small steps, can't commit to working on this every single weekend but I do have some time I'd like to invest here and I really think I can achieve at least a good portion of the goals listed above given some time over the coming months and a bit of support in terms of reviews from your side.

Looking forward to working with you (: Obviously no need to rush any reviews, nothing of this is particularly urgent and I'll adjust to your pace

[CYB3RMX]

Could you please don't create requests before pulling your new changes? Because it causes conflict errors.

[luis261]

Sure, I'll take care to avoid such situations in the future. Stay tuned for a revamp/reapplied PR this evening as per https://github.com/CYB3RMX/Qu1cksc0pe/pull/50#issuecomment-2056454764