 Yeah, so I'm just gonna share a little debugging story with you, and I just, it's not really, maybe in the end the bug is not terribly complex, but I still feel it contains all of the essence of what I find exciting about programming, you know, and that is the unexpected. So one day, a bunch of my co-workers came back from lunch, and they discovered that everyone's coffee of chrome had crashed. And it would just keep crashing. It was like, no, you could not open crash. So obviously, productivity plummeted to zero, and I thought this was wonderful already. But, you know, first principle of debugging, you isolate what changed. And, you know, so the question was, well, was there just like a Chrome update, and that killed everything, but there was nothing online, no evidence that this was anywhere else but here. Like, well, what else, you know, what else happened, you know, in our environment? And the only other thing is we had bought this printer. And then we got suspicious because we had named the printer an emoji. We had named it printer emoji. So we unplugged the printer, right, and Chrome stopped crashing. And then we plugged it in again, and boom, all everybody's copy of Chrome on the entire network crashed. And so, okay, you know, obviously, we start debugging this, but I have to say, what I said, this is the greatest day of my life. That's how excited I got about issues like this. So what was the first thing, first approach for this? So the first thing that I did is I dove into GDB on the system. Now this is actually only macOS, Chrome. This was a company with a lot of, almost everyone was running Macs. So pretty dominant. On macOS, you'd usually use LLDB, but old dogs, new tricks, I'm sort of more comfortable with GDB. So anyway, we see here that like Chrome is crashing in STRLN, just the C standard library function to get the length of a string. And so that initially is really exciting because something terrible is probably happening, right? But we go into, of course, Chrome is an open source, although we'll get to more of that later, but at the very least, we can always, we can always disassemble. We can always look at the registers. That's one of my favorite things to do. The registers after a program is crashed often tell such a fascinating story. They tell us all sorts of places it's been, but in this case, I actually, it's a pretty boring register dump. You can see that in particular, like the stack is fine. All these things are fine. And RDI, which is the first argument to STRLN, is zero. So we just have a null pointer dereference. It's still exciting because we can reduce productivity in the office to zero anytime we want, but we can't necessarily make Chrome dance for us. So the next step is, well, what's happening? What is the printer doing? And so we turn to an excellent tool called TCP Dump, and there actually is an amazing zine that just came out that should be available here, I think, maybe, that will tell you all about TCP Dump and how wonderful it is and how to use it. So I won't say too much about that, but I do want to mention, paired with that is another tool that I really love, which is called TCP Replay, which allows you to replay packet dumps. So TCP Dump spies on your network, shows you what packets are going by your network interface, TCP Replay lets you replay those packets, right? So this was a way for us to figure out what traffic is actually causing this problem. And so we apply an idea from property testing, and if you don't already know what property testing is and you don't already do it, you should come up to me afterwards and talk to me about it because I think it's a really important idea. And actually, we have the author of an excellent C property testing library called Theft here with us, it's a wonderful library, you should check it out. But a really interesting idea from QuickCheck and all these things is the shrinking of inputs. So we captured a bunch of traffic where the printer was spewing out its weaponized emoji and then we bisect it and we chop it down until TCP Replay is just playing back just the packets that are causing this problem and it turns out it's these two packets. And then nicely we can package into a script, starbucks.sh that triggers the problem wherever we like, it's very convenient. But so what are these packets? So these are MDNS packets, which is the multicast DNS. And of course it's like notable, I immediately looked at the RFC. Actually, I'll get back to that. I looked at the RFC and there's this sort of quote that I enjoyed that the obvious elegant solution is that everything should be encoded as UTFH. And of course, so we look at these packets, this is what the packs look. So MDNS is basically, so DNS is this glue that sort of essentially keeps the internet together. MDNS is a very similar protocol, but just for local service discovery. But something that's interesting about it is it sort of changes the kind of the, inverts the relationship between servers and clients because basically unlike DNS where you're asking a server for something, in MDNS you're just constantly being bombarded by packets from every device on your network like this printer, right? But anyways, this printer is advertising itself. We can see that the service name is 1F5A8 downstairs, printer downstairs. That actually worked right. But this TXTTY register, so this is some kind of Google Clown Print thing that I don't understand that's some new feature. But the type record here is obviously not encoded correctly. And so we look at this, so something that, I mean, I noticed emojis have been a part of every successful talk here, right? So we can't deny their vast importance. But, you know, so one of the ways that emojis are represented is Unicode, which has this large space, and then you have different ways of how do you actually represent Unicode on the wire. So the most common way and what MDNS is supposed to use is UTF-8, which is actually this really elegant encoding except for the fact that there's lots of sequences of bytes you can generate that aren't valid UTF-8, right? And in this case, the printers is spewing out F08DA0BD, F08DB6A8. So this sequence that's twice as long as what we would expect, and it turns out that this is like a UTF-8 encoding of a UTF-16 encoding of the printer emoji, right? So some classic kind of problem, but wasn't caught in time. Anyway, why does this cause Chrome to crash? So luckily, of course, there's sort of an open source version of Chrome called Chromium, and we're able to reproduce the problem there. And it turns out that it's like a very simple problem. So we can see here that we're creating this string and initializing it with these bytes that we received off the wire, which is always a tenuous thing. I think you always want to be very careful when doing that. Although in this case, it's not nearly as much fun as we had hoped. The key thing here is we're asking for this NSUTF-8 string encoding. And if we actually look at the core foundation documentation, this says, well, this returns nil if record bytes isn't valid UTF-8. And so it isn't. So that's where our null pointer dereference comes from. So it turns out the fix that restores productivity in the office is just this almost a one-liner kind of thing. And so, yeah, I submitted that. And unfortunately, because it was technically a security issue, the bug was sealed for a long time. And it took some poking and patches before it finally got fixed. But, you know, and so all's well that ends well, except that actually, you know, this printer is still lurking, right? It's still sending out its weaponized packets. And I tried to contact HP to report this. There was just no way to get in contact with anyone responsible. And probably it's hard to fix anyway. It's probably, you know, upgrading that firmware is difficult. But consider this their public shaming. In any case, you know, it was a really simple thing in the end. But it just was lovely going through all these systems. And having this such an unexpected, huge result from such a tiny thing I think is really the essence of, you know, the unexpected, which is what's so exciting about programming. So anyway, I think if there's a moral to that story, it's that everyone should go out and stuff every input field with emoji. Thank you.