Rust CLI for bounded network reconnaissance: TCP/UDP port discovery, service identification, DNS/TLS/HTTP evidence collection, and public-source username search with correlation.
Reconnaissance & Evidence Engine
Bounded reconnaissance and evidence correlation in Rust.
RXScan combines network reconnaissance, public-source search, investigation, and evidence correlation in one CLI.
It can discover hosts and ports, identify observed services, collect bounded protocol and web evidence, search public providers, correlate findings, and persist results for later analysis and comparison.
RXScan is intentionally conservative about what it reports. A port number does not identify a service, an HTTP success does not by itself confirm an account, and incomplete coverage is kept distinct from a negative result.
Build and install from the repository:
git clone https://github.com/DarkRX1/RXScan.git
cd RXScan
cargo install --path . --locked
Check the installed build:
rxscan --version
rxscan --help
Run a normal reconnaissance scan:
rxscan example.test
Search public sources:
rxscan search --username exampleuser
Investigate and correlate public findings:
rxscan investigate --username exampleuser
Those are the three main entry points:
rxscan TARGET
rxscan search ...
rxscan investigate ...
The default scan uses the recon workflow, level 3, and balanced execution
settings.
rxscan example.test
Specify ports when you want exact port selection:
rxscan example.test --ports 22,80,443
rxscan example.test --ports 1-1024
rxscan example.test --ports 22,80,443,8000-8100
Scan the complete TCP port range:
rxscan example.test --all-ports
UDP discovery is explicit:
rxscan example.test --udp
Show the effective plan and additional execution detail:
rxscan example.test --explain
RXScan supports:
rxscan example.test --scan-mode auto
rxscan example.test --scan-mode connect
rxscan example.test --scan-mode syn
TCP connect scanning is the portable scan path currently used by RXScan on its supported platform.
Raw SYN scanning is available for IPv4 on Linux when the required capability is available. When the requested SYN path cannot be used, RXScan reports the effective fallback rather than silently presenting a connect scan as SYN.
UDP scanning uses bounded native probes and remains opt-in.
Current protocol-aware UDP discovery includes small probes for services such as DNS, NTP, and SSDP.
UDP silence is not reported as proof that a port is open or closed. RXScan
preserves the resulting open|filtered uncertainty.
OS detection is explicit and evidence-backed, never a guess from one hint:
rxscan example.test --os
--os runs a bounded probe plan per in-scope host (at most 6 normal
TCP/ICMP probes, reusing ports the scan already knows) and explains every
candidate: matched evidence, conflicting evidence, unavailable evidence,
coverage, and provenance. Without the raw-packet capability it degrades
honestly to passive evidence with reduced confidence. Unknown is a
first-class result when evidence is insufficient. See
docs/OS_FINGERPRINTING.md for the evidence model, limitations, and
current corpus reality.
RXScan identifies services from observed protocol behavior instead of assigning a service solely from its port number.
Current native identification covers common protocols including:
Depending on the protocol and available evidence, observations may include product/version information, banners, HTTP endpoints and titles, TLS certificate facts, SSH identity information, and normalized technology evidence.
Unknown services remain unknown when RXScan does not have enough evidence to identify them.
No authentication is required for these identification probes.
Username search is available through:
rxscan search --username exampleuser
Normal output concentrates on useful positive and uncertain findings instead of printing every negative provider result.
A finding can distinguish between an observed profile, another observed resource, and an unconfirmed candidate location.
For example:
FINDINGS
✓ provider / exampleuser
Profile https://example.test/exampleuser
high · 94% · public profile
? another-provider / exampleuser
Candidate https://example.test/u/exampleuser
low · 25% · weak evidence
The labels are intentional:
| Label | Meaning |
|---|---|
Profile | observed identity-specific public profile |
Resource | observed identity-specific resource that is not necessarily a public profile |
Candidate | identity-specific location that has not been confirmed |
Generic provider homepages or API endpoints are not presented as confirmed profile URLs.
RXScan also keeps provider outcomes such as blocked, rate-limited, unknown, error, and unscanned distinct rather than converting them into false negative results.
Show the complete human result set with:
rxscan search --username exampleuser --all
Show additional execution and classification detail with:
rxscan search --username exampleuser --explain
Public findings can be passed through RXScan's investigation and correlation pipeline:
rxscan investigate --username exampleuser
The default view focuses on accounts, useful URLs, confidence, and meaningful relationships.
Secondary web resources such as static JavaScript, stylesheets, fonts, and images are retained when relevant to the underlying evidence but do not dominate the default human report.
Detailed views can expose more of the collected relationship data.
Investigation remains passive by default. Discovering a network target through public evidence does not automatically authorize or trigger a network scan.
RXScan stores observations as typed evidence used by its reporting, investigation, graph, history, and analysis paths.
Several rules are deliberately enforced throughout the project:
200 alone does not establish that a public account exists;This distinction between observation and interpretation is a core part of RXScan's design.
For confirmed web services, RXScan can collect bounded HTTP observations such as:
robots.txtsitemap.xml