Netgazer

i finished my first proper port check of a /8! mass scans now use a feistel cipher with xorshift round function to visit every IP exactly once in a random order, which avoids saturating any particular subnet with too much traffic. however, the amount of results also reminded me that if even 0.01% of probes are answered, that’s still a lot of data to query and compile so i decided to remove ipv6 and rule-based matching support temporarily

i fixed the error and got the rest of the probes to work!

service detection (kinda)!! –i still need to figure out why google immediately resets any attempts from my program to dial port 443 ([None] should say [Some(("ssl-tls", "ssl-alert"))] instead)

i decided to move on to service scanning because that will probably be the main bottleneck of everything. i began by researching a bunch of protocols commonly exposed to the internet, then spun up multiple servers and versions of each in order to write a correct probe and regular expression. i put all of the service definitions in a file and made a custom parser to read it.

the current in-memory representation of the service definitions is really inefficient to access because for every single target contacted, the scanner has to trudge through all protocol-port combinations until the correct one is found. i completely forgot to write a devlog before i began fixing this issue, so dear hack club god please don’t smite me 🥺

i was able to successfully SYN scan an entire class A CIDR block at ~150,000 packets per second over wifi!! naturally, i also spent far too long prematurely reviewing the concurrency model, zero-copy, memory usage, etc., while the real bottleneck was the physical network 🤦.

the scanner just dumps everything into a text log file at the moment, which is perfectly fine for testing because the SYN scan results are only supposed to inform a more detailed scan via the OS network stack, and not be directly recorded.

P.S: the borrow checker was a lot more annoying to deal with than i expected. for example, while I desparately wanted to combine the rawsocket transmit and receive functions into one struct to minimize complexity, it actually prevented me from having separate tx/rx threads without liberal use of unsafe. looks like javascript’s automatic concurrency has me spoiled :(

single port, single target SYN works now! the program uses pnet to connect to a specified interface, autoconfigures gateway ip/mac if necessary, then sends a SYN probe. everything is properly multithreaded too!

i tried running the scan through a mullvad vpn tunnel via the tun interface it creates, but while nmap’s implementation has the kernel return an RST packet to the inevitably unexpected probe response, mine doesn’t? this is bad because it could lead to accidental SYN flooding of the target :(

did some research and quickly bodged together a basic TCP port checker with tokio::net::TcpStream. when I checked the output, ports reported open were indeed open, but running this on just 1 port and 1 /8 block is soooo slow :c (how the heck does nmap do this so quickly without raw interface access?)

i later found out that macos was only creating ~150 total TCP connections at a time, even though it should theoretically support 16383 per host per port. i’ll probably have to look into implementing tcp syn scanning (see https://nmap.org/book/synscan.html), and/or a custom socket event loop, and/or a full TCP/IP stack? on the otherhand, even such a low speed might be acceptable, considering that the primary goal is banner collection, not port checking?