So you can see here when it loads you've got this
nice banner and all that good stuff,
but it says, No modules enabled or installed.
The reason why I want to bring that to your attention is because
I get a lot of folks that reach out and say, hey, I've installed
Recon‑ng, but there's nothing here.
It doesn't do anything.
Precisely.
Previous versions of Recon‑ng came with all the modules installed,
but it was very cumbersome.
They threw a lot of errors.
If one module broke and the others were working,
you would have to deal with all the errors of the
broken ones to use the functional.
It was just a mess.
So, as of version 5, Recon‑ng now uses a marketplace of modules,
which means nothing is installed by default. You get to pick and choose
what you want to install and use within the framework. So we'll go over
this in more detail here a few moments,
but just makes for a much better user experience.
So don't be alarmed by the message there that says,
No modules enabled or installed.
So you can see here we have a prompt.
We have a base prompt that says recon‑ng and then
another prompt that says default.
This is the global context,
meaning that we are at the first level of usage within the framework.
There are two contexts.
There's the global context, and there's a module context.
Obviously, the module context we'll explore shortly.
But right now, we're in the global context.
This default right here is actually the name of the workspace that we're in,
and we'll explore that here in a few moments.
But this will be context, this will be dependent on
the workspace that you're in, and you'll see that change. Now,
the way that the command structure works, and you can click Help
to display that, there is interactive help here, so help
followed by any of these commands are going to show you some
additional subcommands to those.
But in general,
how the commands work is they basically function on a
particular part of the framework.
So the marketplace command deals with marketplace,
keys command deals with all the keys,
modules commands deal with modules. And so you have this object within
the framework, and then it's usually this second part of the command is
some sort of action on that particular object.
And then anything expected after that on the command line is
typically some sort of variable input.
So let's say that I wanted to create a new workspace,
and here we're dealing with Pluralsight content, so we're
going to use Pluralsight as our target.
So we want to create a workspace for all this information that
we're going to collect about Pluralsight. So if I didn't know
right off the bat how to use it,
I would type help workspaces, and it would show me that there
are some subcommands to go along with this.
I can create a workspace, I can list that current ones,
I can load an existing workspace, or I can remove one. And then
some of these commands require further input beyond that, which
is annotated by the dot dot dot.
So let's do workspaces create, and since we're not really
sure what to give it, we hit Enter, and it says it needs a
name. So, very simple, pluralsight.
Now, as you can see here, once again,
this this follows that schema of object, action, variable input. And
I'm not going to talk about that anymore moving forward, but I just
want to point that out because it's generally how all of the different
commands within the framework work.
And so I'm just going to assume that we understand that
moving forward and continue to use the system.
So let's go ahead and create this workspace,
and now we're in pluralsight workspace.
Now each workspace has a separate set of preset configurations,
which we'll see here in just a moment, so you can all your
configurations, all of your data are completely segregated
from one workspace to another,
which allows you to give it good separation of data so that
nothing gets mixed up when you turn stuff into clients or share
stuff between peers and so on and so forth.
Okay, so now let's look at those.
Let's go and look at options.
And if we want use help just to see where it goes, help options, and
we have a couple different subcommands for options.
We have list, set, and unset.
So let's do options list just to see what's available to us. And
here you're going to see the options available to the global
context because we're in the global context. And these apply, these
are generally options that apply to the entire framework and how it
functions at its core.
So here we have a nameserver.
We have a proxy if we want to set a proxy for all of our web
traffic. We've got threads for modules that take advantage of
threading. We can set timeout for modules that are sensitive to
time limits on their requests.
We can set a specific user agent here if modules need that.
And then, of course,
there's a verbosity if we need additional information about an
issue that we're having or if we want less feedback and we just
want to get bare bones screen output.
And then we could set it too minimal. The default here is obviously verbose,
okay? And that's generally kind of what you want because that's a
good amount of information that comes back to you,
but not too much.
Normally, you don't have to touch any of these. Very specific use case is
needed here if you need to change these things. So normally,
you can go with the default, and you'll notice that when we get into
the module context there's some additional options,
some different options that you will absolutely want to take advantage of.