I Ate FREE at My University Dining Hall for 3 Years

本站收录: 2026-05-21

[00:00:00]Hello again. It is finally summertime outside. Yes, I know it's spring. It's still May, but it feels like summer. I was outside in this t-shirt. What a wonderful feeling. No more snow. And I'm happy to see that there's some stories coming in from all of you coming to the email and getting posted on the Reddit.

[00:00:20]You can find both of those in the description for this video. It's great to see what people are sending. There's some funny stuff and I'll be reading that here with credit to you on the channel sometime soon. But today we have a story about someone who either is a genius or just very lucky to stumble upon something that well it worked out well. Let's see. I ate free at my university dining hall for 3 years. I didn't steal anything. Found a real software bug. It spent 6 months telling me the bug didn't exist. Let me be upfront. I'm a CS guy. I'm not. He is. I was a CS guy in college and now I actually computer science is what that means for those of you like me who were scratching their heads. I was a CS guy in college now actually work in software security professionally which is either very ironic or a direct result of what I'm about to tell you depending on how you look at it. This happened at a midsize state school in the Midwest. I'm not going to say which one. Not because I'm worried about myself at this point.

[00:01:14]The statute of limitations or whatever on whatever this even was is long gone.

[00:01:18]But because some people involved still work there, and I'm not trying to make their lives weird, intriguing.

[00:01:28]The dining system at my school ran on software called Blackboard Transact. If you went to college between like 2005 and 2020, there's a good chance your school used it, too. It's a long time to be using the same software. It's the thing that puts a balance on your student ID, and you tap it or swipe it at the dining hall, and it deducts the cost of your meal. your parents load money onto it at the start of the semester or buy you a meal plan and theoretically it just works like a debit card for food. I say theoretically.

[00:01:52]There's something so satisfying about using one of these cards. I don't know, maybe that's just me. Maybe some people prefer cash or something. But those cards usually they're a little bit heavier. At least mine was. It's a little thicker. I worked at this concrete factory, believe it or not.

[00:02:05]Piano man worked at a concrete factory one summer. Uh and they had meals that were $2.50.

[00:02:13]$2.50 for the meal. And it was actually good food, very good food, like lasagna.

[00:02:16]That was the best thing the owner of this plant did is he hired these decent chefs to make food for all of us. And so even though the work was horrible and we were outside in the blazing heat all day, we had these cards and we could just go in tap and the wonderful lunch ladies would give us amazing food for $2.50. I love that card. I wonder if I still have it. I found a bug completely by accident in the first week of sophomore year. My dining dollar's balance was almost gone. I burned through most of it faster than expected because the dining hall had a waffle station that I had zero self-control around. I swiped my card for lunch knowing I probably didn't have enough left. I was going to see what it said and then either use actual cash or just put the tray back. The terminal beeped.

[00:02:54]Green light. I looked at it, picked up my tray, went and ate my lunch. When I got back to my room, I checked my balance online. It was the same as before I'd swiped. 0 and change. Nothing had been deducted. Why did he Why did he try to pay if it said zero dollars and change? I feel like it's exactly what I would have done in their shoes. It's just beep. Even if you know that it's there's nothing there. You think that maybe maybe the wonderful system will glitch and you'll just get free food. I thought maybe I'd misread it. I went back to the dining hall for dinner and did it again. Green light. Balance unchanged. I sat there in the dining hall eating dinner I hadn't paid for, trying to figure out what had just happened and felt a sensation I now recognize as a stroke of genius, if I don't say so myself. Like a gear catching. Here's what was actually happening. and I'll try to explain it without getting too technical. Thank you. Because the technical version is long and kind of boring and the logical version is more interesting. The dining hall terminals, those card readers at the registers, communicate with a central server to process transactions.

[00:03:52]When you swipe, the terminal sends a request to the server. This card, this amount, approve or decline. Server checks your balance, sends back a yes or no. Normal operation, totally fine. But here's the thing about any network system in a hightraic environment.

[00:04:06]Sometimes the server is slow. Sometimes the network hiccups during the lunch rush at a university dining hall. You've got hundreds of students swiping cards simultaneously and the server is handling all of it at once. The engineers who built the terminal software had to make a decision. When the server doesn't respond fast enough, what does the terminal do? Two options.

[00:04:24]Fail closed. Decline the transaction until the server responds. safe also means the entire lunch line stops every time there's a network hiccup which in a dining hall means chaos and angry students and probably a strongly worded email to the president of the university. Fail open approve the transaction locally and sync with the server later. Keeps the line moving, creates a small window where transactions are approved without server confirmation. They went with fail open because of course they did. Nobody wants to be the IT guy who made 300 students miss lunch. The problem, and this is the part that I think the original developers didn't want to think all the way through, is what happens during the sync. When the terminal comes back online and sends its locally approved transactions to the server, the server is supposed to process them retroactively and deduct the balances.

[00:05:08]It did this usually, but there was a timing issue. When the server was under peak load and had a backlog of transactions to process, some of the retroactive syncs from the offline approved transactions would fail silently. The server would log them as sync received but actually complete the deduction. And because both sides thought the other had handled it, nobody followed up. Free meal.

[00:05:28]The window was narrow but consistent.

[00:05:30]Peak lunch hours 11:45 to 12:30 p.m.

[00:05:33]when the server was getting hammered. If you swipe during that window, you had maybe a 40% chance of getting a free meal on any given day. Is 11:45 to 12:30 p.m. really peak lunch hours? I feel like that's more like breakfast hours at a university, right? I mean, people are sleeping in. I mean, unless you have morning classes, I suppose higher if you went right at noon when the load was at absolute maximum. I didn't know all of this at first. I just knew sometimes it worked. And I started paying attention to when I want to be honest about something the moment I realized this was a real repeatable thing, not a one-time glitch. I knew I should have reported it and I didn't. I told myself that it wasn't really stealing because the system was authorizing the transaction.

[00:06:13]The terminal said yes. I wasn't forging anything. I wasn't intercepting anyone else's balance. I wasn't doing anything that looked different from a normal transaction from the outside. A cashier watching me would see a green light in a student picking up a tray. Was that rationalization? Yeah, probably. I was a 19-year-old who was also genuinely curious and also broke in the way that college students are broke when you technically have enough money, but spending it on dining hall pasta when the dining hall might give you pasta for free feels insane. So, I kept going.

[00:06:42]Over the next few months, I mapped it out pretty carefully. I kept the spreadsheet. I love Excel. I don't understand you, but I'm glad that you love Excel so that I don't have to.

[00:06:52]Thank you. Tracking which days, which times, which registers had the highest success rate. Turns out it wasn't random. The terminal closest to the main entrance had the oldest hardware and the most unstable connection. Noon on weekdays was peak window. The breakfast shift was almost useless. Load was too low. I got my success rate up to about 70% during optimal windows. Of course, other people might get free lunches, too, but I was getting more wins here. I told exactly one person, my roommate Tyler, who was a finance major and therefore thought about risk in a way I found useful. He listened to my whole explanation and then said, "Dude, that's genuinely impressive, but please don't tell me anything else about this. I don't want to know." Fair enough. I went back to eating free lunches. Second semester, sophomore year, I got more curious about the actual system mechanics and did something slightly more deliberate. I started monitoring the network traffic in the dining hall, which before you panic is not illegal on a network you're authorized to use. And I wasn't intercepting anyone else's data. I was just watching the packets on a shared network like anyone with Wire Shark could do. I want to skip ahead a little because the middle part of this story is basically just me eating free lunches for 2 years, and that's not that interesting. I kept it to one meal a day, always lunch. I wasn't being greedy about it. Partly because I'm not actually that greedy and partly because I understood that anomalies at scale get noticed faster than anomalies that just say small. Also, I do not believe that this fellow is not greedy. I mean even just noticing this in the first place.

[00:08:19]I I'm not saying I'm just saying. Junior year, nothing happened. First semester senior year, nothing happened. Second semester senior year, February, something happened. The dining services director, a woman named Carrie, I found out later, had been doing a routine budget reconciliation for the year and noticed that their food cost percentage was off. Not by a huge amount, but consistently off across the whole year.

[00:08:42]A little more food leaving the kitchen than the revenue numbers accounted for.

[00:08:46]She thought it was waste. She thought it was staff eating. She thought it was the portion sizes. Then she thought, "What if it's the card system?" She brought it to it. It looked at the transaction logs and said, "Everything looks fine. All transactions are showing as authorized.

[00:08:59]Balances are being deducted. We don't see a problem. Carrie said the food numbers don't match. It said the system is working correctly. And here's the part I genuinely love about this story.

[00:09:09]They went back and forth like this for 3 months because both of them were correct from within their own data. It's log showed authorized transactions. Dining's inventory showed missing food. And because nobody was looking at the specific intersection approved transactions that never resulted in a balanced deduction, neither side could see what the other side was seeing. I found out all of this later. At the time, I just noticed in February that the card reader closest to the main entrance had been replaced with newer hardware. I tested it. My success rate dropped to almost zero.

[00:09:39]I thought maybe they'd figured it out and upgraded the system. I mostly stopped. Ate free probably a dozen more times over the rest of the semester, but it wasn't reliable anymore. They found me in April, 6 weeks before graduation.

[00:09:52]A junior IT staff member named Greg, dude was genuinely very good at his job, got to say that, had decided to approach the problem differently. Instead of looking at whatever the server logged as approved, he started looking at what the terminals logged as locally approved and then comparing it to actual balance deductions. The gap was obvious once you looked at it that way. Then he looked at which student IDs showed up most frequently in the gap. Mine was up at the top by a lot. I got an email from the dean of students asking me to come in for a meeting. No explanation, just please come in. I knew what it was about. I'll describe that meeting carefully because it was one of the stranger hours of my life. There were four people in the room. The dean of students, the dining services director, Carrie, Greg from IT, and a university attorney, which if you want to know how seriously they were taking it, is your answer. They explained what they found.

[00:10:39]They were very precise about it. Greg walked me through his methodology, which was good methodology, and I told him so, which made the room feel weirder. Then the attorney said they were considering several possible responses. Academic discipline, restitution for the value of the meals consumed, possible referral to campus police. I said, "Okay." Then I asked if I could explain what the actual bug was. They said yes. I spent about 20 minutes walking them through the fail open architecture, the sync timing issue, the server side Q overflow, and why their monitoring had missed it. Greg was taking notes. Carrie looked like she'd eaten something bad. The attorney was very still. At the end, the dean said, "So, you're saying the system authorized your transactions?" I said, "Yes, every time. I never touched a register, never accessed any account that wasn't mine. I never did anything that looked different from a normal swipe from the outside." The attorney said, "Can you give us a moment?" They made me wait in the hallway for about 35 minutes. Here's what I worked out later about what happened in that room while I was sitting in the hallway. The terminal had authorized every single one of my transactions. He could argue intent to exploit, but the actual policy language was genuinely ambiguous about whether the authorization meant the system said yes or the university intended yes.

[00:11:52]Taking it to campus police was messier.

[00:11:54]The same problem plus the question of whether I had actually taken anything or whether the university's own system had given it to me. They can make it painful for me regardless of whether they won.

[00:12:04]But I was six weeks from graduation with a full-time job offer already signed and nothing on my record. This fellow is insanely lucky. Insanely lucky. Probably not the fight they wanted either. They came back and the dean did most of the talking. He said they were not going to pursue formal disciplinary action or police referral. He said I would pay restitution for estimated meals consumed, which they calculated at $2,340.

[00:12:26]Three years of average meal value at their rates. That doesn't seem very fair because he didn't eat free every single day. right? Was this 70% of the time? He said I would sign a written acknowledgement of the conduct policy.

[00:12:39]He said this would not appear on my academic record. I said, "Okay." Then Carrie piped up. She said, "We'd like you to do a full review of the dining system before you leave. Document everything you found. Walk Greg through the specific failure points." She paused. "We'll pay you for it.

[00:12:53]Consulting rate, 2 weeks of work." I looked at her. She said, "We've been trying to figure out what's wrong with the system for 4 months. You figured it out in a semester." Pretty sure a semester is about 4 months. The attorney looked like he had opinions about this offer that he was keeping to himself. I said yes. Again, this guy is too lucky.

[00:13:09]Too lucky. I spent the last month of my senior year writing a 34-page technical document on the security architecture of my university's dining system. I found two additional vulnerabilities that I hadn't exploited. One of them was actually more serious than the one I had used involving the building access system that shared the same card infrastructure. Greg and I worked well together. He was annoyed at me in a very specific professional kind of way that I completely understood and respected.

[00:13:32]Carrie paid me $3,800 for the consulting work, which was almost exactly $1,500 more than the restitution I paid. So, I came out slightly ahead, which I have thought about more than once. At my last day, she shook my hand and said, "I genuinely cannot decide if you're the worst or best thing that happened to this dining department." I said, "Probably both." She laughed. I've been in software security for 6 years now.

[00:13:53]Finding the gap between what a system thinks it's doing and what it's actually doing is basically my entire job. Turns out three years of field research at a dining hall was decent preparation. I still think about the fail open decision. Some engineer made that call.

[00:14:05]Keep the lunch line moving. Prioritize user experience over security. And it was a reasonable call given the stakes.

[00:14:11]Nobody thought the stakes of a dining hall card system were high enough to justify a fail approach. And they probably weren't. I got free pasta for 3 years. Not exactly a national security crisis, but there's always a gap between what a system is designed to do and what it actually does under real conditions.

[00:14:27]Always finding that gap is either a career or a free lunch depending on your situation. In my case, it was eventually both. Edit. Yes, I paid the $2,340.

[00:14:37]I felt fine about it. Actually, the number was fair given what I'd eaten.

[00:14:41]Edit, too. Greg is genuinely excellent at his job. He solved in two weeks what a whole team couldn't solve in 3 months by simply changing the question he was asking. I've thought about that approach a lot professionally. Edit three. People asking about the second vulnerability I found. I'm not going to describe it in detail even now because it involved building access and that's a different category of problem than free lunch.

[00:15:01]It's fixed. That's enough. Edit four.

[00:15:03]The waffle station is where this all started. And I maintain that a dining hall waffle station is the single most financially dangerous amenity a university can offer to a 19-year-old.

[00:15:12]So, if you enjoyed this content, you can subscribe to the channel. You can tell your friends. You can send me stories.

[00:15:16]You can post them to our piano man has no plan. Should be up here somewhere.

[00:15:22]And you can send them to the email which is a Gmail piano manhasnopplan@gmail.com.

[00:15:28]And I will read the stories you send me.

[00:15:29]Send me funny things, uh, interesting things, fascinating things, confusing things, paranormal things, all kinds of stuff. I will read it and I will decide whether we can use it here on the channel. And with your permission, I will read it with the piano and my reaction. I'll see you next time. Bye for now.