routersploit can look like a wall of module names when you first open the lists, and that wall makes a lot more sense once you know the library is organized into just five families. Every module belongs to one of them: exploits, creds, scanners, payloads, or generic. Each family has its own job in a test, its own moment in the workflow, and its own risks of confusion. This guide explains all five in plain language, with the real commands for browsing them, so you can look at any module name and know what kind of tool you are holding.
Exploits: one weakness, one device
Exploit modules are the heart of the library. Each one targets a specific vulnerability in a specific device or firmware, and they are organized by vendor. Browse them with show exploits and you will see paths grouped under names like D-Link, Netgear, TP-Link, ASUS, Linksys, Huawei, Cisco, and Zyxel, among others.
That specificity cuts both ways. An exploit written for one model on one firmware version will usually do nothing at all against a different model, and that precision is by design. These modules are records of real, researched weaknesses, not generic battering rams. It is also why so many of them support the check command: you load the module with use exploits/routers/..., set the target, and ask the module to test whether your device looks vulnerable before you even think about run.
Creds: testing the front door keys
Creds modules test a service on the target against default and common credentials. They exist because the single most reliable way into real-world routers is still a factory password nobody changed. List them with show creds and you will find modules for the services routers actually expose:
- HTTP basic authentication, the classic admin login prompt
- HTTP web forms, for routers whose login is a page rather than a prompt
- FTP and Telnet, older file and remote-access services
- SSH, the standard remote shell
- SNMP, the network management protocol with its own community strings
Each module ships with built-in lists of default router usernames and passwords. You set the target and the service port, the module works through its list with multiple threads, and it reports any working pairs it finds. Against your own router, a hit from a creds module is a gift: it shows you, concretely, the first thing to fix.
Scanners: the discovery step
Scanner modules answer the question you face at the start of every test: what is this device, and which of the hundreds of modules in the library could possibly apply to it? List them with show scanners. One scanner towers over the rest in everyday use: autopwn.
You load it with use scanners/autopwn, set the target, and run it. Autopwn probes the device and checks it against the framework’s router exploit modules, then prints the ones that match or look promising. That report becomes your shortlist. Instead of guessing which exploit fits an unfamiliar router, you let the scanner narrow the field, then investigate each suggestion properly with show info and check. The dedicated autopwn guide below walks through that whole flow step by step.
Payloads: what an exploit can deliver
Payload modules are small programs that certain exploits can deliver to a device once a weakness is confirmed. They are built for the processors embedded devices actually use, above all ARM and MIPS, with x86 in the mix as well. The typical payload in this world is a simple, single-purpose program, often a reverse-shell style tool that makes the device open a connection back to your machine.
Beginners can safely leave payloads alone for a long time. You meet them when a specific exploit gives you a payload choice among its options, and by then the module’s own info explains what it expects. Knowing the family exists, and that its members are organized by CPU architecture, is enough understanding to start with. Matching the payload’s architecture to the device is the detail that matters when you get there, since router chips vary and an ARM build will do nothing on a MIPS box.
Generic: the useful leftovers
The generic family holds modules that do not fit the other four groups. The best-known residents are helpers for Bluetooth Low Energy work, which reach beyond classic routers into the wider world of small connected devices. Generic is a small family compared with exploits, and many users never load one of its modules, but it shows where the framework’s edges are: if a test concerns an embedded device and matches no other family, it probably lives here.
One practical note: the Bluetooth helpers are also the modules most likely to ask for extra system libraries, such as the bluepy stack on Linux, before they will load. If a generic module complains on your machine, that missing dependency is the usual reason, and the fixes guide below covers it.
How the families fit together
A normal test uses the families in order, like a funnel. A scanner goes first, narrowing a whole router down to a shortlist of candidate modules. You read the shortlist with fresh eyes, checking the vendor and device details against the hardware in front of you. Creds modules often run next, because default passwords are the most common finding of all and the test is quick. Exploits follow, one at a time, each confirmed with check before any run, and payloads only enter the picture when a chosen exploit calls for one. Generic modules sit outside this flow, there for the odd jobs.
Seen this way, the library stops being a wall of names. It is a workbench with five drawers, and every session is just you opening them in a sensible order.
Browsing the library like you mean it
Two console habits make the five families easy to explore. The search command takes any keyword and returns matching modules across all families, so search telnet surfaces the telnet creds module alongside anything else that mentions the word, and search zyxel gathers one vendor’s exploits into a single list. Tab completion does the quiet work while you type paths, filling in long module names so you rarely spell one in full.
When a module catches your eye, read it before you load it into a session plan. show info after a use gives you the author’s own summary of what the module targets and expects. That thirty-second read is what separates someone testing a device from someone spraying modules at it and hoping.
Conclusion
routersploit’s five module families divide the work of testing an embedded device into clear parts. Scanners, led by autopwn, discover what might apply. Creds modules test the default usernames and passwords that ship with routers. Exploits confirm specific vulnerabilities in specific models and firmware, usually with a cautious check first. Payloads give some exploits something to deliver, built for ARM, MIPS, and x86 chips, and generic modules cover leftovers such as Bluetooth Low Energy helpers. Learn the five drawers and you can navigate the entire framework with confidence.
Read next:
Pingback: Scan Your Router with the routersploit Autopwn Scanner
Pingback: Test Default Passwords with routersploit Creds Modules