rad10 / searchsploit.py Goto Github PK

For documentation sakes, nothing could improve documentation more than a wiki for the program.

The only real problem is a lack of information to place. If there isnt enough information to document, then there really is no point to a wiki. It would be excess work for very little payout to users.

This may change as more work is done, but if there are any ideas, I'm all ears

Currently, visual results from searchsploit do not work because of how the program gets the size of the screen. If output is piped out, then there's no screen to get info from or display to. It should be possible to pipe out, so I just have to do some try and except statements to allow for screen information to fail

Clearly this program was not made with standards in mind. In some worse situations, it is just as unreadable as the bash script that came before it.
That is how it's been for the longest time. Well no more. Once I have the majority of current changes I want done (because I am a creature of habit), I will change it all to meet Python's PEP8 coding conventions.

Now modifying Offensive Securities searchsploit configs is not the intention here. That was an idea before, but I reverted it in order to retain backwards compatibility for the original program (though I dont know why anyone would want to use the original over this) in case someone wanted to use the original, both, or if databases were added by Offensive Security or the user.
I have no intention of altering the original configs, but I have noticed that finding those configs can sometimes be an issue for this program. So in order to fix that, I have to try a few ideas for improving this issue.

• Finishing fixing #5 so that I can find the configs better
• Fiddling with the idea of an internal config that needs to be edited. Instead, have an external config script to be imported, so that program doesnt need to know its current location (config could have that)

With Offensive Securities new update of searchsploit, I now need to work on including the new functions brought by the new program.

Functions to build

• --strict - Perform a strict search, so input values must exist, disabling fuzzy search for version range e.g. "1.1" would not be detected in "1.0 < 1.3")
• --verbose - Display more information in output
• --help - Show this help screen
• --install - A program I want to include. Can be used to directly install a source database from the application

The exclude argument doesn't properly work. Gonna have to go back to that.

I would like to make my life as a developer of this project easier on myself by using a native library for handling the arguments. especially since the arguments provided by exploitdb can easily be integrated to use it instead

I made navigating the users filesystem a odd and confusing mess in the program. This ranged from issues involving how to navigate the filesystem based on what OS the script was run on, to using semi-obscure ways of getting the users home directory.
Though these methods work, logically and in use, they're a nightmare in terms of readability and work to get to the ultimate goal of those results.
This will probably be best fixed with os's internal path library.

Though I doubt anyone wanting to use this tool is going to use pipenv (you never know) with this tool, it is still useful to include files documenting the version used to test the program, but also so that github can recognize the library used and note it on the repo.

This basically means just running pipenv on the repo to grab all libraries needed. Simple enough.

If it wasn't obvious, the current README is a straight rip from the README from Offensive Securities exploitdb repo. This is because this repo was originally a fork from that repo, that I never really changed besides small things like referencing that it was made in python instead.

Currently, the program has to do a lot of math to make sure that the terminal fits to exact conditions of the given terminal screen. It does a fantastic job already, but it could be better with the help of string formatting.

In my trek to give GitHub more and more love, I managed to forget a really useful checklist for caring for a GitHub repo, the community tab under insights. This should be a great marker for caring for the repo.

The work that needs to be completed:

• Code of Conduct
• Contributing
• Issue Templates
• Pull Request Template

As wonderful and amazing as BeautifulSoup is, I could do better. BeautifulSoup is currently only used for crawling the xml files given with the --nmap argument. It does it's job very well, but the problem with it is that it is an external library. External libraries aren't bad at all, but if it isn't too big of an adjustment, native libraries are almost always better than external libraries. It means that it's less likely to fail (unless the original devs really messed up with their library development cough cough MinGW C/C++), and it means users wont have issues involving forgetting to install any libraries before use.
The library that will be replacing BeautifulSoup is a native Python library called ETree. ETree really only does a good job if you already know the pathing of the HTML/XML. Luckily, the XML data isn't organized in an unpredictable way. Because of this, I will be replacing BeautifulSoup with ETree.

The current help screen looks aweful and is out of date compared to offensive securities changes as of May 27th 2019 offensive-security/exploitdb#174. With these changes, it'll be quick work to setup argparse to organize the tools into categories.