initial commit

This commit is contained in:
2026-06-19 07:11:17 +00:00
parent 33435ab4b4
commit 41130a5093

90
FORK.md
View File

@@ -295,93 +295,3 @@ If any exists, log `[+] auto-loading nmap-payloads from <path>` and use it as if
**Why:** nmap's `nmap-payloads` file ships ~300 UDP probes for protocols masscan doesn't have built-in. Loading it adds full coverage of those services for free, without changing the user's CLI. (Note: modern nmap on some distros — Ubuntu 24.04 included — compiles the payloads into the binary instead of shipping the file, so the auto-load is a no-op there. Still works on Alpine and older systems.)
---
## What the fork does **not** change
These are deliberately deferred:
- **No SNI extension in TLS hello.** The `server_name` extension would significantly improve cert harvesting from CDN-fronted hosts, but per-target SNI requires switching from `static char hello[]` to a `transmit_hello` callback. ~half-day of work; not done yet.
- **No Chrome 120 ClientHello with GREASE.** The curl-shape hello defeats the "is this masscan?" detection, which was the goal. Full Chrome JA3 mimicry only helps if you specifically need to evade Cloudflare WAF / Imperva / Akamai bot blockers.
- **No per-connection TCP timestamp simulation.** The Linux SYN template includes a Timestamp option with zero placeholders. Real Linux uses a tcp_clock millisecond counter and echoes the peer's TSval. Adding this requires per-TCB state — not free.
- **No multi-threaded banner-grab.** The userland TCP stack in `stack-tcp-core.c` is single-threaded by design. At very high banner-grab rates (theoretically) the receive thread saturates. Multi-threading it is real work and we haven't proved it's actually the bottleneck in practice.
- **CLI unchanged.** No new flags. The OS-mimic chosen at startup is random (50% Linux, 50% Windows) and there's no `--mimic-os <linux|windows>` flag. Add one if you want determinism.
---
## Validation done
| Test | How | Result |
| --- | --- | --- |
| Build cleanly | `make` with `-Wall -O2` | ✅ no warnings beyond upstream's |
| Real-world scan | Frantech /9 (72k hosts), 8 ports, `--banners`, `--rate 3000` | ✅ 34,897 opens found, ~309 banners completed, TLS cert chains parsed from Let's Encrypt |
| Cloudflare DNS TLS handshake | `masscan 1.1.1.1 -p443 --banners` | ✅ TLS/1.2 cipher 0xc02b, full SAN list (`cloudflare-dns.com, *.cloudflare-dns.com`) |
| Fingerprint detection (own tool) | Run `masscanned.py` against 500-packet capture (310 SYNs + 41 PSH-ACKs from real scan) | ✅ 0 hits across all 9 detector categories |
| SYN shape check | Inspect outbound SYN with scapy | ✅ TTL=128, win=64240, DF set, dataofs=8, options match Windows 10 byte-for-byte |
The fingerprint detector ([`masscanned.py`](../masscan/research/masscanned.py)) is the same one used in our research to identify masscan packets — it knows every public masscan signature. On 500 packets from this build, zero signatures fire.
---
## Open issues
Documented honestly because they exist:
1. **Banner-grab completion rate at high `--rate` is low.** On 35k open ports we got ~309 banners. That's either (a) most of those ports aren't running services that respond to our default hellos, (b) masscan's single-threaded userland stack saturates somewhere below 510k banner-grabs/sec, or (c) `--wait 10` isn't enough for the tail of slow targets. Unverified — we haven't measured the actual saturation point. Workaround: two-pass scanning (SYN-only first, targeted banner-grab pass at lower rate on the open set).
2. **One occasional `UNHANDLED EVENT` warning** during banner-grab: `[-] <ip>:443: FIN-WAIT-1-SEND:SYNACK **** UNHANDLED EVENT ****`. Pre-existing upstream behavior — happens when a target sends SYN-ACK during connection teardown. Harmless.
3. **TLS 1.2-only ClientHello means TLS-1.3-mandatory servers don't return clear-text certs.** A small minority of modern sites (mostly Cloudflare with HTTP/3 priority). Workaround: send a follow-up probe with TLS 1.3 advertisement — but then certs are encrypted and you only get the JA3-S.
4. **Some hello-string probes overlap with masscan's built-in pattern matching.** When the user generates a config file from `nmap-service-probes` and includes it, ports may get an unexpected hello (e.g., port 80 gets `OPTIONS / RTSP/1.0` instead of `GET /`). Last-wins / first-wins semantics handled by the Python generator, but worth understanding.
---
## How to use
Identical to upstream masscan. Examples:
```sh
# Simple scan
sudo bin/masscan 10.0.0.0/8 -p80,443 --rate 100000
# With banners
sudo bin/masscan -iL targets.txt -p- --rate 50000 --banners \
--output-format ndjson --output-filename results.ndjson
# Distributed (32 shards)
sudo bin/masscan --shards 1/32 --seed 42 -iL all-v4.txt ...
sudo bin/masscan --shards 2/32 --seed 42 -iL all-v4.txt ...
# etc.
```
Which OS template got picked this run? Check the first outbound SYN's TTL:
- TTL = 64 → Linux template active
- TTL = 128 → Windows template active
---
## Building
Standard masscan build. From the repo root:
```sh
make # gcc, -Wall -O2, single-threaded build
make clean # nuke tmp/
```
Binary lands at `bin/masscan`. Drop-in replacement for `/usr/bin/masscan`.
Dependencies same as upstream: `libpcap-dev`, `gcc`, `make`. No new deps.
---
## Diff against upstream
```sh
# Quick stats
diff -r /home/acidvegas/masscan-src/src ./src | grep -c "^[<>]"
# Full diff
diff -r /home/acidvegas/masscan-src/src ./src
```