Module 'info'?

[0x646e78]

Coming from recon-ng here, so perhaps I've missed a piece of info in the docs, but so far I can only see high level info on a module.

For example, using shodan-certs:

I can get some high level info here:

> pkg search shodan
kpcyrd/shodan-certs (0.1.0) - 639 downloads [featured] [installed]
        Find IPs using certificates for target subdomains

It doesn't tell me if it needs an API key or not, which would be useful.

I then 'use' it, but I find no way of finding out more about it - such as api key, if I can manipulate the input to it, perhaps anything else that could be useful to know about it? recon-ng has an info when in the context of a module, which can be helpful. In this case maybe the detail such as -- Keyring-Access: shodan from the module could be used?

[sn0int][default] > use shodan-certs 
[sn0int][default][kpcyrd/shodan-certs] > 
activity      autonoscope   back          help          mod           pkg           scope         select        target        quickstart 
add           autoscope     delete        keyring       noscope       run           set           workspace     use 

$ sn0int --version
sn0int 0.18.2

[kpcyrd]

Sorry for the late reply. This is definitely a big todo since there's also no way to know which options can be set unless you look into the source.

I'm thinking about adding:

• a long description that can be used to show demo usage
• a list for available options so they can be listed and tab-completed
• which access keys are required and preferably also how to get them
• a tag system that's also going to be used for "noise control", so you could configure sn0int to be fully passive and never send a request to the actual target or "very noisy" which would allow triggering things like password resets. The default would be somewhere in the middle.

[limakzi]

@kpcyrd This is something I really miss too. Take a look at mine modules. Shodan ports scanner is fully passive, like ctlogs. On the other hands, url-metadata is aggresive. Is there anything I can help you with delivering this feature?

[kpcyrd]

thanks! I've broken this up into smaller issues:

• 184 to make required access keys easier to discover

• 183 to track how stealthy/noisy a module is

@limakzi Ideally there'd be something like:

[sn0int][default] > use shodan-certs 
[sn0int][default][kpcyrd/shodan-certs] > info

I'm a bit stuck in the design phase though. Information I've been considering to include:

• The short description, version, author and repository url if known
• A long description - right now there's only one line to describe the module. Some modules may require a longer description about usage or how to works that could be shown.
• The info from #183 and #184
• Options that are set, can be set, and what they are supposed to do. This is slightly complicated because right now we don't track this in metadata, and we'd need a format that's somewhat powerful:
  • The type may matter, specially for boolean options we could consider limiting possible values to true/false/yes/no
  • We might want to display the default value. This is not possible with the current getopt('foo') or 1 constructs, so we need to move this into metadata and make getopt know about this.
  • The description of the option

Input very welcome!

A naive -- Option header could look like:

-- Option: foo: describe the option here

This is easy to parse but lacks the default value and the type of the option.

The challenge with the long description is that this would require multi-line support. I'm not sure about the aesthetics, I was considering something like:

-- Description: asdf
-- Version: 0.1.0
-- License: GPL-3.0
--- Text goes here
--- in multiple lines.
---
--- And paragraphs.

function run()
    info('ohai')
end