/logs - scapy | networking | internship

A few days ago, I came across a LinkedIn post for an internship role, posted by an alumni connection of mine. Looking at their profile, all I knew about them was that they seemed smart: PhD at an Ivy League, and was now a senior security researcher. Bonus points: they'd been a student director at CEG Tech Forum in their senior year, just like me!

The internship was a cyber security research internship, involving hardware-level network protocol pipelines for application-layer SCADA protocols, not that I knew what that meant at the time. What intrigued me was the fact that to get the application link or other details, I had to first complete a small packet crafting assignment. Not more than an hour's work for someone muddling about in netsec, but unfortunately, I was out of touch. However, I love my network protocols; many of my projects involve networks in one way or another.

At this point, I was on the edge: should I spend potentially a few hours on this assignment to get an application link that would then lead to the latest rejection among dozens, or spend it working on boring, pending coursework? The answer was obvious.

When shooting your shot, you have to put your best foot forward. And to do that, you need to know what you're stepping into and if it's worth it. I messaged my connection for details of the job description and what kind of qualifications I needed. Needless to say, they weren't too impressed: it was a cyber sec research internship, and I didn't exactly have meaningful work in cybersec or research. But they did encourage me to apply, and one key requirement they mentioned was proficiency with scapy and packet crafting.

This specific hint sparked my drive; scapy was easy to use, I'd worked with it. Off I went, trying to craft a Modbus TCP/IP packet with an incorrect packet header length. Took me a while to remember the fact that I needed to establish a TCP connection with the challenge server before sending my packet. Oh well, at least I know I'm dumb. Then I set about establishing a TCP connection with scapy's TCP_client.

Interestingly, I came across an ignored exception, which seemed weird: why would an exception be ignored? Digging deeper, I found that scapy's Automaton class did not handle connection termination and socket cleanup in the right manner: in short, calling must-have logic from inside the __del__ function of the connection automaton class is a bad practice, as I found out from many discussions on StackOverflow, as well as an older yet similar issue on the Selenium web driver project.

I've raised the issue, waiting for replies and maybe get to work on a fix. Link to issue: https://github.com/secdev/scapy/issues/4182

Never thought I'd get to contribute to open source while working on a job application assignment, but here we are :)