routersploit Commands Cheat Sheet: Use, Set, Run

Nobody works in routersploit by memorizing a manual. You work by knowing about a dozen console commands cold and letting tab completion handle the rest. This cheat sheet gathers those commands into one page, grouped by the job they do: finding modules, loading them, reading them, setting values, and running them. Every command here works at the routersploit rsf prompt, and each one is shown the way you would actually type it during a session against your own lab router. Keep this page open for your first few sessions and the commands will settle into your fingers quickly.

Finding modules

You cannot run what you cannot find, and the console gives you two ways to search the library.

search <keyword> finds every module whose name or description mentions your word. search dlink gathers one vendor’s modules, search telnet gathers everything about that service.
show exploits lists the exploit modules, organized by vendor.
show creds lists the credential-testing modules by service.
show scanners lists the scanner modules, including autopwn.
show payloads and show generic list the remaining two families.

Reach for search when you know a name or a topic, and for the show lists when you want to browse a whole family and see what exists.

Loading and leaving a module

Two commands move you around the framework:

use <module path> loads a module and puts you inside it. The prompt changes to show the module’s name, so you always know where you are. Examples: use scanners/autopwn, or a path under exploits/routers/ for a specific vendor’s module.
back leaves the current module and returns you to the main rsf prompt.

Tab completion works on module paths, so type use exploits/routers/d and press Tab to let the console finish vendor and module names for you. Long paths stop being a burden once you lean on that.

Reading the module you loaded

Before you set or run anything, read the module in front of you:

show info prints the module’s description: what it does, and the devices or services it was written for.
show options lists the settings the module needs, each with its current value and a mark showing whether it is required.

These two commands are the cheapest insurance in the whole tool. show info stops you pointing a module at hardware it was never written for. show options stops the classic beginner error of running with a default target that points at nothing you own.

Setting values

Modules do nothing until you fill in their options, and two commands cover that job:

set <option> <value> sets a value inside the current module. The pair you will type most is set target 192.168.1.1, followed by set port 80 when a service lives somewhere unusual.
setg <option> <value> sets a global value that every module you load afterward inherits. setg target 192.168.1.1 at the start of a lab session means each new module already knows which router you are testing.

Run show options once more after setting values. Seeing your target and port sitting in the list, confirmed in the module’s own words, is a five-second check that prevents most wasted runs.

Running and checking

Two commands actually touch the target, and the difference between them matters:

check asks the module to test whether the target looks vulnerable, without running the full exploit. Many exploit modules support it, and it is the right first move whenever it exists.
run executes the module in full: a scan scans, a creds module works through its password list, an exploit runs its test against the device.

The professional habit is check before run wherever the module offers both. You confirm the target matches the weakness first, then decide if the full run teaches you anything more.

A complete session in eight commands

Here is the whole rhythm in one block, scanning a lab router and checking one of the scanner’s suggestions:

use scanners/autopwn
set target 192.168.1.1
run
back
use exploits/routers/<vendor>/<module> (the path your scan suggested)
show info
set target 192.168.1.1
check

Notice that the target had to be set again inside the second module. Options belong to each module, which is exactly why setg exists for values that stay true across a whole session.

Small comforts worth knowing

A few details make long sessions easier. The console keeps a command history, so the up arrow recalls earlier commands when you repeat a pattern across modules. Tab completion extends beyond module paths to command names and option names, so half-typed words are normal working style rather than sloppiness. And if you ever feel lost, look at the prompt: inside a module it names the module, and at the top level it shows plain rsf, so your location is always written in front of you.

Working through several modules in one session

Real sessions rarely involve a single module. You scan with autopwn, check two or three candidates, run a creds module for completeness, and by the end you have loaded half a dozen modules in sequence. The commands scale to that without any new ideas. back out of the finished module, use the next one, and repeat the read-set-run pattern each time.

Two habits keep multi-module sessions tidy. First, set your standing facts globally at the start with setg, above all the target, so each module you load begins life already aimed at the right router. Second, keep show options as a reflex rather than a chore: options reset per module, a default port from the last module says nothing about this one, and the five seconds spent looking is what separates a systematic sweep from a pile of runs you cannot trust afterward.

When a command surprises you

Every user eventually types a command and gets an answer they did not expect: a module that refuses to load, an option the console rejects, a run that ends instantly with an error instead of results. Treat the surprise as information. A module that fails on load is usually missing a dependency, and its error names the library involved. A rejected option usually means the name belongs to a different module, which show options settles immediately by listing the ones this module actually accepts.

And when a run reports nothing at all, remember that silence is a result too. It means the module found no match on the target you gave it. Check the target and port once with fresh eyes, confirm the module’s show info really covers your device, and accept the clean answer if both hold up. The fixes guide below works through these cases in the order you will meet them.

Conclusion

The routersploit console rests on a small set of verbs. Find modules with search and the show lists, load them with use, leave with back, read them with show info and show options, aim them with set and setg, and finish with check before run. Master those dozen or so commands and the framework has no other doors to unlock; every guide on this site, from the autopwn walkthrough to the creds tutorial, is built from exactly these pieces.

Read next:

RouterSploit Commands Cheat Sheet: Use, Set, Run and Check