datasploit: option for file input #201
Conversation
This introduces the `-f` flag for file input source. The file needs to be a list of single target per line. The contents of the file can be a mixture of any of the currently allowed data types and will just run through them one at a time. This patch allows for both the `-i` and `-f` options to be called at the same time. Why someone would want to run through a text file of targets and manually specifying another at the same time is beyond me. But, allowing for this does not cause any issues so I figure why not allow it. This removes the -i option from being required and updates the `if len(argv) == 0:` check to confirm that at least `-i` or `-f` were invoked. Also, nuke some unnecessary whitespace.
datasploit.py
Outdated
| output=x.output | ||
| # if no target is provided print help and quit. | ||
| if not (single_input or file_input): | ||
| print "\nSingle target or file input requered to run\n" |
There was a problem hiding this comment.
Thanks for this catch! I'll get a new commit fixing this pushed shortly.
| except KeyboardInterrupt: | ||
| print "\nCtrl+C called Quiting" | ||
|
|
||
| def auto_select_target(target, output=None): |
There was a problem hiding this comment.
Awesome. Thanks for improving this file.
| output=x.output | ||
| # if no target is provided print help and quit. | ||
| if not (single_input or file_input): |
There was a problem hiding this comment.
So while you are at it. One more option that i always wanted to add. If there is no option switch use say someone executed datasploit in following manner.
./datasploit.py dmain.tld
./datasploit.py file_with_targets
Should we handle such situations check if the input is a file or a text and if file use that file as input otherwise if text use that as text input etc
Key is no -i or -f option is used so arg parse will not kick in.
What do you suggest.
There was a problem hiding this comment.
I initially thought about designing this patch in a smart fashion that would auto-detect if file or if string input as you describe. However, the more I brainstormed it the more areas of conflict I was able to think of, and the need to write in for potential edge cases grew to a point I thought it way too much code and error checking (while still not being able to account for nearly all cases). For me, that it just wasn't the cleanest way to go.
A quick example would be - lets say someone wanted to research the domain datasploit.py having just "installed" datasploit via git clone. It would recognize the file, and explode on reading the input line by line. We could write in an exception to check for that, or to check for #!'s, and then what about python (or other code/etc.) files that don't use shebangs, like osint_runner.py (which would be an odd domain to own, for certain). Okay, we'll we could check if the first lines are imports. Okay, but then what about files that don't call any imports. And that's just focusing on files that may be code.
In the end, I decided it was smarter to force the user to be conscious and just use args to specify file/string input.
There was a problem hiding this comment.
fully in agreement. This was something that came in my mind and i kind of drew simmilar conclusions, its good to get assurances from someone else that i am not crazy and my logic did make sense sometimes. Thanks for confirming that.
requered == required
This introduces the
-fflag for file input source. The file needs to be a list of single target per line. The contents of the file can be a mixture of any of the currently allowed data types and will just run through them one at a time. This patch allows for both the-iand-foptions to be called at the same time. Why someone would want to run through a text file of targets and manually specifying another at the same time is beyond me. But, allowing for this does not cause any issues so I figure why not allow it.This removes the -i option from being required and updates the
if len(argv) == 0:check to confirm that at least-ior-fwere invoked.Also, nuke some unnecessary whitespace.