Your first routersploit session does not need to be ambitious. It needs to teach your hands the basic rhythm of the console: load a module, look at its options, set a target, and run it against a router you own. This beginner’s guide walks through exactly that, using a safe lab setup and the friendliest module in the framework, the autopwn scanner. Follow it once, slowly, and the rest of the tool opens up, because every other module in routersploit follows the same pattern you are about to learn.
Set up your lab first
Before any commands, build the playground. routersploit is meant for devices you own or have permission to test, as its documentation states, so take an old spare router, reset it to factory settings, and connect it as its own small network, separate from the one your household relies on. Connect your computer to that lab router, and note its admin address, commonly 192.168.1.1. That address is the target for everything in this guide.
Working this way is not a limitation, it is the whole method. On a lab router you can make mistakes, misread results, and reset the box as often as you like. Professionals learn tools exactly like this, on hardware set aside for the purpose.
Start the console
Open a terminal and launch the framework. If you installed with pip or the Kali package, the command is routersploit. If you cloned the repository, move into its folder and run the rsf.py launcher. The banner appears, modules load, and you land at a prompt that reads rsf. Everything you do from here happens by typing short commands at that prompt.
Two habits help from the very first minute. First, the console supports tab completion, so type the start of a command or module path and press Tab to let the shell finish it. Second, nothing you type at the prompt touches any device until you load a module, set a target, and run it. Browsing is always safe.
Look around before loading anything
Get your bearings with the listing commands. Try these:
show scannerslists the scanner modules.show credslists the credential-testing modules.show exploitslists the exploit modules, a long list organized by vendor.search netgearfinds every module whose name or description mentions that word.
Scrolling these lists teaches you the shape of the library faster than any documentation. Notice how exploit paths name a vendor and a device family; that naming is how you will later pick modules that match hardware in front of you.
Load your first module
Now load the autopwn scanner, the standard discovery tool:
use scanners/autopwn
Watch the prompt change: it now names the module you are inside, which is how you always know where you stand. Everything you set from here applies to this module until you leave it with the back command.
Before setting anything, read the module. show info prints its description, so you know what it claims to do. show options lists the settings it needs, typically a target address and a port, each with its current value and a note on whether it is required. Making a habit of reading info and options before every run is the single best practice this guide can give you.
Set the target and run
Point the scanner at your lab router:
set target 192.168.1.1
If your lab router uses a different admin address, use that instead. The port option defaults to the standard web port, and the scanner’s option list will show you the current value if you want to confirm it with show options once more.
Then start it:
run
The scanner probes your router and checks it against the framework’s router exploit modules, then prints what it found. On a factory-reset spare router, do not be surprised if it reports matches; old firmware and default settings are exactly what it hunts for. Read the results slowly. Each line names a module that looks relevant to your device, and each of those names is a thread you can pull in a later session.
Pull one thread: load a suggested module
Pick one module from the scanner’s output and load it the same way, with use followed by its path, for example a path beginning use exploits/routers/... for the vendor your router belongs to. Read its show info and show options, set the same target, and then, instead of running it outright, try the gentler step first:
check
Many exploit modules support check, which tests whether the target looks vulnerable without running the full exploit. It is the professional way to confirm a scanner’s hint before deciding anything else. When you are done, back returns you to the main prompt, ready for the next module.
Settings that apply everywhere
One more command is worth meeting early. setg sets a global option, a value that applies to every module you load afterward. Setting your lab target globally, with setg target 192.168.1.1, saves retyping it in each module during a long session. Use plain set for one-off values inside a single module, and setg for the facts that stay true all day, like the address of the router on your test bench.
Mistakes every beginner makes once
A few stumbles are so common they are worth naming in advance. The first is forgetting to set the target after loading a new module: options belong to each module, so a fresh module starts with its own defaults, and a run aimed at the wrong address teaches you nothing except patience. The cure is the habit from earlier, show options before every run, no exceptions.
The second is running a module before reading it. show info takes five seconds and tells you the exact device and firmware the module was written for. Skipping it leads to the third classic stumble, confusion when a run reports nothing: beginners assume the tool is broken, when in fact the module simply does not match their hardware, which is the most normal result in this field. A lab router that survives your tests with clean results is not a failed session. It is a secure router, demonstrated.
The last stumble is aiming the framework at the wrong network entirely. Stay on your lab segment, confirm your target address belongs to the spare router in front of you, and your sessions stay relaxed and useful.
Where to go in your second session
Once the scanner flow feels comfortable, the natural second exercise is a creds module against the same lab router. A factory-reset box will almost certainly still carry its default admin password, and watching a creds module find it, quickly and without drama, teaches the most practical lesson in router security better than any warning label. The commands are the ones you already know: use the module, show options, set target, run. Afterward, log into the router yourself and change that password, then run the module again and watch it come back empty. That before-and-after is the whole philosophy of the tool in one small loop.
Conclusion
You now know the full routersploit rhythm: launch the console, browse with show and search, load a module with use, read it with show info and show options, point it at your lab router with set target, then run it, or check first when the module offers that gentler test. Every advanced topic in this tool is those same moves in a different order. The modules guide below explains what each family of modules does, so your next session can go beyond the scanner.
Read next:
Pingback: routersploit Commands Cheat Sheet: Use, Set, Run
Pingback: routersploit vs Metasploit: What Is the Difference?