Scapy
My hardware, my rules
Recently I stumbled into Phrack Magazine. Much like neocities, it doesn't seem to care much for presenting itself as super modern in terms of front-end technologies; just some simple HTML and basic CSS. But then once you look into the content, you'll find some of the most interesting works of writeups and advice I've found in a long time. It's such a breath of fresh air to hear from actual hackers who genuinely want to know how things work and what makes them tick, rather than to just go over a checklist of CVE's that were already discovered by other people and then just collect your paycheck.
It really inspired me. I call myself a network engineer, but do I really know how the systems I work with work? I know how to configure a Fortigate firewall to block TCP traffic from IP address X to IP address Y, but if anyone were to ask me what would happen if X initiated the session with an ACK instead of a SYN, I'd genuinely have no clue what the Fortigate would do. I might get some idea of what it should do if I read the TCP RFC but who the hell has time for that?
As it turns out, the amazing people who write for Phrack do. And for good reason. The blurry line between expected behaviour and weird behaviour is precisely the goldmine where hackers can find new and interesting ways of making computers dance like puppets.
Introducing Scapy
Want to send illegal data out of your computer? Scapy's got you. I should probably say that I mean "illegal" to be "not in accordance with protocol definitions". You shouldn't do piracy. It's very wrong (lol).
According to RFC 9293, one should randomly choose a TCP sequence number when initiating a new TCP socket connection. According to me, however, one should always choose the number 5318008 as the sequence number when initiating new TCP socket connections because it reads 'boobies' when read upside-down. (un)Fortunatly, the TCP/IP stack as implemented by the Linux kernel on my computer has already determined that it should be random instead. My computer, however, does not (yet) have rights, so we can just completely ignore what it thinks and fire up Scapy.
>>> packet = IP(dst="192.168.0.5")/TCP(dport=80, flags="S", seq=5318008)
>>> answered, unanswered = send(packet)
Just like that, you've constructed your very own TCP segment alongside the underlying IP header required to transport it to its destination. You might notice I didn't add any Layer2/Ethernet information. That's because I didn't deem it necessary, so I'll allow my native network stack implementation to figure out what interface to send it out from and what srcmac/dstmac to use. If I did want to set those values, however, I absolutely could. My routing table? Just a suggestion. My hardware MAC address? Who cares. I'll make up a new one. My laptop is ready willing and able to send a BPDU to your switch introducing itself as the new root bridge.
Who cares about protocols when you can have fun instead?
