Mastodon
Skip to content
Go back

Security vulnerabilities I found in high school

Posted on:March 7, 2026

This is a collection of stories from my school days in Tunisia (2004 ~ 2010). Some involve computers, most don’t. I’m +30 now and living in a different country, so my parents can’t ground me - I think.

When the school ran on the honor system

Unauthenticated chalkboard

During middle school, the faculty used a big chalkboard near the entrance to post messages about teacher absences, schedule changes, and general announcements. This was Tunisia around 2004 - many people didn’t have a consistent internet connection or even a mobile phone. No automated systems, no Facebook groups, no WhatsApp chats. That chalkboard was it.

As a 12-year-old, every morning I would wish hard to see a teacher’s name on that board. It meant I could turn around at the gate and get at least an hour to hang out with friends, talk about metal music or the latest Counter-Strike trick.

One day something clicked.

Anything written on that board was implicitly trusted. There was no way to verify who wrote a message, and since students saw the board while crossing the school entrance, they’d turn around excited and never think to ask anyone inside.

So I decided to cancel first-period classes for all seventh graders. I widened the scope deliberately - targeting only my own classroom would have narrowed the suspect pool too much.

One sentence. Regular chalk on a regular chalkboard.

Like automatons, the students read the message, turned around, and asked no further questions.

The faculty was furious. They had no suspects and suspected older students had pranked the younger ones. The pool was too large to act on.

A few months later, the board was replaced by a locked glass display with printed, pinned papers.

Moral: Sign your public messages if you don’t want to be impersonated.

Authenticate your records

The mid-aughts were a weirdly analog time in Tunisian high-school education. As the world was unveiling the iPhone, Facebook, and Google Street View, my school was tracking attendance in large paper spreadsheets.

Each day, a sheet with a list of students was passed from period to period, teacher to teacher. Absent students got a capital “A” in the matching cell. At the end of the day the sheets were collected and transcribed into a central computer - that entry was the official record.

The vulnerability was obvious. Since the sheet only tracked absences - no positive confirmation of presence - all you had to do was mark everyone absent for a given period. Your own “A” disappeared into the noise. The teacher had supposedly been absent too, so no lesson was delivered and nothing was formally recorded.

The sheet came back to the admin office looking like a chaotic day. With half the class “absent,” no one could pin anything on any individual. The data was too corrupted to be actionable.

Moral: Absence of evidence is not evidence of absence - unless your record-keeping system can’t tell the difference.

The accidental command and control server

By the time I finished high school, some friends had moved on to university. Practical exams there had a specific ritual: the examiner would pace the room looking for the WiFi icon in the system tray. Connected = cheating. Disconnected = clean.

A friend described the situation to me. I was 16, bored, and knew just enough .NET to be dangerous. I built a small Windows application that hid the real WiFi tray icon and replaced it with the OS-appropriate disconnected icon. The network stayed up. The icon said otherwise.

It worked. Friends used it. I felt clever.

Then a naive idea crept in: since this was already running on exam machines in exam contexts, what if I also captured periodic screenshots? I didn’t have a plan for what to do with them - I just thought it would be interesting data.

So I added a screenshot loop.

Then I needed somewhere to send the images. I set up an FTP server.

Then the FTP server started filling up, so I added a config file that each installed copy would read - controlling when to capture, how often, whether to transmit.

I had, entirely by accident, built a command and control server. A lightweight, poorly secured, exam-screenshot-harvesting C2 infrastructure, running on my friends’ laptops, phoning home to my FTP server.

I deleted everything shortly after and never deployed it beyond the small group who’d asked for the WiFi trick. I also never actually needed to cheat - I graduated and consistently finished at the top of my class.

The lesson wasn’t about cheating. It was about how easily a sequence of individually reasonable-seeming decisions - hide an icon, capture a screen, store the data, add a config - can walk you straight into something you never intended to build. Every step made sense in isolation. The destination didn’t.


Looking back, what strikes me isn’t how reckless these were - it’s how genuinely curious I was. No malice, just a kid who couldn’t look at a system without wondering where the edges were.

The chalkboard had no authentication. The attendance sheet had no integrity check. The exam room had no real enforcement. Each one was a puzzle, and I couldn’t help but poke at it.

That instinct - to question assumptions, to find the gap between how something is supposed to work and how it actually works - is still the thing I rely on most. Whether it’s a paper spreadsheet in 2005 or an LLM pipeline in production today, the question is the same: what happens when you push on the edges?

Tunisia in the mid-2000s feels like a different world now. Chalkboards and paper spreadsheets, unmoderated forums and Counter-Strike on pirated CDs. It was a good place to grow up curious.