And it's enough for now. When we finish those I can jump to more complicate things I've also implemented in Bluebox: network mapping, app level mapping, brute-force, etc
But it's better to agree in the simpler ones before to avoid big refactors :)
My only important doubt until now is why the handlers never return anything. I see it important to be able of testing and using them from another handlers (even if the main client doesn't use this result). Does it have sense or am I losing something?
The main question is how to organise these and get them visible :)
Also we should consider if we are going to allow each tool to be configured in their own way or perhaps provide a generic module for configuration. In the case of the shodan module it will be useful to setup the API key somehow permanently and it will be nice if it is centralised.
Btw, it will be also useful to create a style guide for these modules because there are a few things to keep in mind in order to make everything as performant as we can :)
Ey, I'm was doing a lot of work also in Bluebox, but now I'm doing it for a bigger cause xD. Really I only have to adapt the code I already have, don't worry! :)
About the fact of keeping the API key somehow I totally agree, but the mechanism I use in bluebox doesn't apply here because we have to keep it among each module run, which are different process in pown. Due to this same reason I'm asking how to return values from modules, because the future "session" pown module should parse it, ie: network mapping is going to discover hosts, which should be kept in the session
About the style guide I also totally agree. If a module passes to the main dist, IMHO it should repect it and have a minimal test coverage (eventually, we're still born ;) )
I like the Airbnb one because it uses ES6 and it's very complete (the most I found) and they provide a proper npm package with the setup. The only difference is they use babel so I need to add a check for 'use strict').
Sessions are just directories with files. Pown modules can be aware what files exist in the current working directory. That's all. If you want to change your session to something else, well you sure can by CDing into another directory.
It is also transferable, you can ZIP it, store it, encrypt it or whatever... there is no need to understand yet another binary format or worry about databases.
In terms of style, I am not worried so much so how modules are written but how they are loaded. For example, in some of your modules the imports are at the top of the command files which means that they will be loaded during the module discovery phase when commands are listed. It will be better to move this into the actual command handler. That way, the way is interpreted yes but not fully executed and as a result the imports are not loaded as well. It will be hell of a lot quicker :)
Metasploit particularly sucks because of the way modules are loaded.
(the ones which have the "map" method implemented)
(the "brute" is for something similar I have for brute-forcers)
I "only" have to adapt it to use the pown-iterators instead of mines
pown-net-map: By default it uses the TCP protocol (and accepts also UDP) because don't require extra dependencies for that.
then we need to add the rest of the protocols, but I still don't have too much clear how to organize that to avoid dependencies (I'm still understanding the project ;) , any suggestion?
Agree with the UNIX style thinking and in using files (instead a DB) to keep a sessions, the Postgre sucks in Metasploit xD. I like the idea, I wanted to do something similar in Bluebox. So, to resume, the modules should write the result in a file, which another modules could read. My doubt then is: how i know when the module has finished (ie: to start the next action in a more complex module)? polling the filesystem? I mean, we could choose callbacks, promises, generators or whatever, but we need something. Isn't it? :)
BTW, regarding the position of the requires we can setup our ESLint to control they're always inside the handler. If this rule doesn't exist I can write one for us, it's quite easy.
And I also saw yesterday this tool for mapping using external sites. It's a good idea, agree in porting it here. :)
@pdparchitect I've fixed all modules to make the requires properly :) and some other minor improvements.
BTW I've created this package because there are some modules (ie: voip-creds) that are still not passing to the official distribution and this way we can make them visible. I suppose I'll add it to the future "pown-sip" or something similar.