Fix rollover on failed exploit.

[NullArray]

We need to gracefully handle exploit failures in order to facilitate proper rollover to the next one. Since we wish to automate as much as possible, it is important to handle exploits failures in an automated manner as well. Some tools that automate MSF functionality do so by employing msfrpc. I'll be looking into a way of implementing similar measures as a fix to this issue.

[Ekultek]

Possible to thread one in the background, start a second process and move between them?

[NullArray]

Maybe, found this on Rapid7's site though.

https://metasploit.help.rapid7.com/docs/running-metasploit-remotely

Metasploit Framework can be run as a service and used remotely.
The main advantage of running Metasploit remotely is that you can control
it with your own custom security scripts or you can control it from
anywhere in the world from any device that has a terminal and supports Ruby.

A python implementation for msfrpc can be found here

https://github.com/SpiderLabs/msfrpc/tree/master/python-msfrpc

[NullArray]

Reading the docs as we speak. I might commit something later on today if everything works out.

[Ekultek]

I mean it seems like running it as a service might be a smart idea. But it also says that you have to send the arguments to the RPC as a dict. That leaves a couple of potential hard issues to solve such as;

1. Dicting the args, right now we call them as is to metasploit, so we’d have to figure out what argument has to be dictified with what value (might actually be kinda easy, like interacting with the sqlmap API)
2. Getting the end user to run it as a service. Idk if you want this to be all OS compatible or not (I’m assuming so) then our best bet would to be create a config file containing information on the users system and bash and batch scripts to get everything in place as a sort of “installation method”

[NullArray]

I designed it at first to be just *Nix compatible. But if it's feasible to make it cross platform compatible then we could. However there is no equivalent for Blessings on Windows. And i am fine with it just being *Nix compatible personally. And of course if the setup will be a hassle then i'll write an installation script in Bash. Batch too if we are going for Windows as well, but making it Windows compatible is not a priority for me.

[Ekultek]

Thank god because I hate Windows with a passion lol. The arg dicting might be kind of troubling though. Btw are we going to allow this to create payloads as well?

…

On Feb 22, 2018, at 6:16 AM, NullArray ***@***.***> wrote: I designed it at first to be just *Nix compatible. But if it's feasible to make it cross platform compatible then we could. However there is no equivalent for Blessings on Windows. And i am fine with it just being *Nix compatible personally. And of course if the setup will be a hassle then i'll write an installation script in Bash. Batch too if we are going for Windows as well, but making it Windows compatible is not a priority for me. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[NullArray]

I'm not entirely sure what you mean with "allowing it to create payloads", you feed the payloads as a dict as well to the service i thought. Which is going to be easy since we are already handling payloads in JSON format, which is treated as a dict when you load it in with Python, right?

[Ekultek]

Yeah nvm I meant something else. Raw payloads, save them to a file, but it doesn’t make sense with the program.

…

On Feb 22, 2018, at 6:22 AM, NullArray ***@***.***> wrote: I'm not entirely sure what you mean with "allowing it to create payloads", you feed the payloads as a dict as well to the service i thought. Which is going to be easy since we are already handling payloads in JSON format, which is treated as a dict when you load it in with Python, right? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.