BSidesSF 2026 - A Worm in the Apple: Wormable Zero-Click RCE in AirPlay... (Avi Lumelsky, Uri Katz)

So coming up now Avi and Uri who has a Starbucks name um and they are going to be talking about it was behind me a worm in the apple wormable zero click rce in airplay impacts billions of Apple and IoT devices so that's something to be very happy about um but guys over to you thank you very much for joining us big round of applause please thank you very much everybody can hear me Great. So, um it's a pleasure to be here. This uh research is actually um like an an after effect of a previous research that we've presented here exactly one year ago. Um it was a browser vulnerability um that is still very interesting to this day, but this

is the reason we actually um got to research AirPlay in the first place. We'll uh we'll see why exactly. Um so uh quickly about ourselves I'm Ailski um I've uh um been leading the AI security research in Oligo um in the past two years and with me is Zuri Kat which is the lead researcher um behind these uh vulnerabilities that we're here to discuss today and uh um let's understand um what is airborne. So, Airborne is a collective name for uh 23 vulnerabilities that we have reported to Apple. Um starting in October 24 um until April 25. Um out of these 23 vulnerabilities, 70s got CV assigned. And when chained together, we can use these vulnerabilities to run a zeroclick

uh remote code execution which is also wormable uh because AirPlay is on by default in many different devices. Um, so it has a warmable uh effect and uh not only Apple devices but actually billions of other um devices that are using AirPlay with uh the SDK. So it's not limited to Apple devices. We should all care um no matter um I believe most of us have AirPlay certified devices around us. Let's quickly go over the agenda. So we'll talk about why researching airplane first place. um it's not something that is um like uh often uh researched. Uh we'll deep dive into the protocol helping you understand um how it works and uh uh the basis for

understanding the vulnerabilities. Then the initial findings and what made us go uh deeper to reverse engineering. We'll understand the differences between using AirPlay on Apple devices and using it in the SDK uh way um like CarPlay. Then we'll demonstrate a user for free um vulnerability on Mac OS um that uh enabled us to do this zero click morable exploit. Um there are four different attack vectors. So it's not only the internet or the same network. Um there are two more novel ones and uh of course we will have time for demo and uh we will have time for questions. So and feel feel free to reach out at the end of the conversation in case you want uh

uh to ask anything specific or didn't have the time. So why researching airplane play um in first place? So uh 0000 day I know lots of zeros is a name that we dabbed a very um um overlooked vulnerability that has been actually exploited in the past 20 years. Um it impacts uh impacted uh all browsers. Uh most browsers are still impacted other than Safari and Brave. And it's around the uh ability of public uh websites that are hosted under a public domain to communicate with more local um locally running running services such as the ones that are exposed on the network um in the home or office uh networks or uh the local localized networks uh which is often

overlooked and we have many security assumptions made around that. uh when researching uh this uh vulnerability and reporting into the browsers we noticed something we could not ignore. So port 7000 was open on each and every MacBook in our office and uh um it seemed uh very interesting to us um especially since you can communicate with the service from a browser under any web page even if it's public.com domain. Um with that in mind we uh had to dig deeper and uh um understand what is this protocol whether or not we can abuse it uh from a browser context and uh uh this was the reason we actually started with it. Uh AirPlay did not originally start with

the name AirPlay. Um we um have seen it in 2004 by the name of Airunes. Uh it's actually a streaming protocol for media mostly for Apple devices but not uh not not only. Um in 2010 it was renamed to AirPlay. Um there is even AirPlay 2 which is uh what most of us are using today and uh um focused mostly on audio streaming originally. Today we can stream stuff such as uh uh images and video uh between u um certified devices. And this is an amazing protocol and uh um I guess most of us have used it um with or without knowing. Like every good uh protocol uh that works seamlessly, it has to um like have

some form of uh network discovery protocol. Um to enable seamless discovery, uh AirPlay uses MDNS, multiccast DNS. This protocol actually publishes the devices presence over the network in a broadcast way. You can see that the um name of the computer and the port um many things that are uh um usually um gained by attackers through port scanning are u published over the network just like that. Um and it makes it easier uh on attackers to understand where and uh uh which devices are available uh on the same network where I currently am being uh like present. Um unlike MDNS, the airplane protocol is not uh open source. It is not uh as uh open and mns might be easier to

understand but we had to understand what happens after uh the device presence and what the messages really look like. Um so we started by going over some public resources that we had online um documentation on GitHub. Uh some um open implementations for AirPlay clients helped us understand what kind of messages exist um how they are used, what is the authentication flow and uh whether or not um like uh they they helped us up to a certain point but most of them were either uh outdated or incomplete. So um um we had to dive uh deeper but it definitely helped us understand and to begin with this research. Um there has been great resources around it. Um now let's

understand how an airplane uh request even looks. Airplay uses HTTP and RTSP and the RTSP uses HTTP style methods such as HTTP like uh get post. Um RTSP has uh tear down and setup commands. The content type is quite interesting is a property list or simply pist. Uh you can see that it can uh be serialized into a binary format but uh if you would look at the bottom of the figure it looks like an XML. So property lists are consist of uh type value pairs and they can be serialized into uh stringified format like XML. But the more common way of using them in the Apple ecosystem precisely is a binary format which is

more efficient. Um and these are just two ways to use a pist lib in Python to um starting getting working with the payloads. Um now there are um many different kinds of commands in airplane. Um like uh you can see that some of the commands are pre-out or pre session commands. So anyone uh over the same network or with network access to the device can actually dispatch them. These are the commands on the left in the green uh figures. Then we have the authentication messages and the session setup and uh uh after that the um like session commands that change the property of a session like playback speed uh audio mode uh resolutions and stuff like that. Now uh

let's understand um what led us to the very initial findings and uh how we actually u got there. So uh fuzzers are the bread and butter for some of us and we um wrote a very complex fuzzer and no I'm just kidding. It took uh 20 uh lines of Python code and uh this is what actually led us to find the very first findings and we continued from there. So in order to understand the first finding that uh we had we first need to look about the different AirPlay configurations. Now AirPlay on Mac OS has three main configuration options with current user being the strictest one out of them. In this setting only devices that use the same Apple ID

should be able to communicate uh with the airplane server. So for example, if you have a Mac OS device connected to a specific Apple ID, only an iPhone using the same Apple ID should be a able to send messages to that AirPlay server. Now going back to the session life cycle that we discussed before, um we we noticed that many of the commands that were supposed to be only after that authentication step that checks the Apple ID were actually accessible um at all times. So this greatly increased the attack surface because now we can using a simple client without any Apple ID communicate with many more routes and we were even even able to play a full

screen video on Mac OS devices on the network without any form of authentication. Our second finding is the syslog leak. Now, Apple does a pretty good job at keeping PII secret generally, but in this case, we found that a simple get log command was enough to get the full SIS log of any Mac OS device on the network. And the SIS log itself contains the host name, running processes, boot time, and much more sensitive information about the device. Our last finding using the fuzzer is the FP setup 2 crash. Now, as you can see here, Mac OS uh on Mac OS devices, the AirPlay server runs under the control center, which is highlighted in red.

And using one simple command, the FP FP setup 2 command, we were able to crash the entire control center service. Now, this was a memory corruption which was not exploitable in this case. But since we found it so easily, we knew there are probably some more findings to come. >> Yeah. So as you all see um this straightforward fuzzing technique got us um very um like interesting results. We did not expect it to to work. Um but seeing this control center crashing and especially um when visiting a website crashing the control center um is uh uh something we did not expect and it just made us uh go um and um pull the thread uh if that makes sense. Now AirPlay is

not open source unfortunately. Uh it's a great protocol and uh we had to um be more creative um progressing for here um we didn't have any binaries at our hand and uh we could not get the source code right it's a closed source so we ended up um extracting the uh uh airplane binaries and libraries from the dyld cache uh directory on Mac OS and this is how we actually started to reverse engineering now let's look at an example of function that we found through reverse engineering and uh I believe it will make a lot of sense to all of us. So this function uh in this figure is handling the airplane different commands and is in charge of choosing um which

function handles which command. So to us it was like a gold mine. After we found it and we followed each and every pattern matching uh in the code um we had to do it manually and reverse engineer uh these functions further. But this made it uh very clear to us uh what code is in charge of which uh um logic and which command. Um there were two main kind of vulnerabilities that were very common between like among these 23 vulnerabilities that we reported. Um type confusion vulnerabilities is the first kind and the second one is null reference vulnerabilities. Um let's quickly see uh how these look uh just for the sake of example like one of

each. So in the get property uh command um with a a post htt http method you're looking at the code that uh is handling this command and v93 uh a variable is user control and if you would pay attention the bottom line uh expects a cf dictionary get value uh so essentially it's expecting a dictionary um but at the same time it does not check that this is indeed a dictionary. So if we would send a dictionary like the top right figure, it would work and uh uh will uh uh this is the intended way of using this uh endpoint. But we found out that uh using um a string or integer, anything that is not really a

dictionary uh would result in crashing the process. So um this is the first kind of vulnerabilities that we saw uh that was quite common. Um it only made it um more reasonable to us that Apple did not extend or like did not intend these uh session commands to be available before a session has been formed. Um so that's why might lack the uh type checking uh for example. Now the second uh kind of vulnerabilities is null the reference vulnerabilities. Now um you can look at the audio mode uh command. Uh it has a derived storage and it accesses a media audio session. Now as I said this session can uh be null because we have

no session in place yet. Uh so when accessing the rate property um at the next line it will result in a null d reference and uh would crash the process again. We took all of these vulnerabilities uh 16 total and something funny happened. Um Apple's ticketing system actually blocked us because it was too much for it at the short period of time. Uh we had to slow down and uh um this was kind of funny to get blocked by Apple's like CV reporting system. Um and uh we had to slow down uh because of that. Now let's understand what is the difference between uh using AirPlay like inside Apple devices versus using it uh through

the SDK. So there are many different devices um you can think of uh even very esoteric ones um that are uh supporting air play and they are doing it through an SDK. So upper is actually providing many manufacturers with the AirPlay SDK and uh together with another uh dedicated chip they can um detect that this is indeed an AirPlay certified device that was authorized by Apple to create and manufacture this uh uh thing. you can go on Apple's website and find um hundreds of vendors and kinds of devices. Um so it made it very easy for us to uh look uh for targets uh this way. Um it's based on the same code but it

has some limited functionality. So it's more of a narrow uh version of the uh full SDK. Uh and get this only two of these 23 vulnerabilities uh were actually impacting the SDK. uh the rest were uh mostly around the Apple platform. Um but the um kind of vulnerabilities is very uh unexpected to be uh working in 2025 uh when we published this research. Um and many devices have not patched uh to this day which I'll get to. But finding a stock overflow vulnerability uh that actually work and we managed to exploit it uh was uh surprising to us. and uh um also an integer uh overflow and you might recognize this airplane certified uh uh

logo. Um we needed a different approach when we started researching the SDK. So actually instead of buying an airplane certified device uh and as we all know uh um Apple certified devices and generally uh these models can be pricey uh so we had to be uh creative and it was actually real fun. So, URI managed to actually simulate a real certified uh device firmware and uh we make it uh we made it boot successfully. Uh on the left you have the uh the Raspberry Pi that actually um runs the uh uh the firmware and on the right you have the the MFI chip. So um uh the MFA chip is uh kind of faking the

the hardware uh um um identities that are required for the software to boot uh uh successfully and then we ran the exploit and it actually uh worked and uh only then after we proved that it's actually viable um and we saw that there are no stack canaries and stuff that would help normally prevent these stack overflows from working um we went and purchased a real the certified device and we ran the exploit and this is how it looked. So we got root privileges on a home speaker by Bose. Uh it has a Wi-Fi uh lag inside the network and uh we could essentially do anything we want. So these speakers they have a microphone they have ability to like uh send

messages to the same uh network. And after we took over this device, um theoretically it can be used to um poison other uh devices on the cell network and become sort of a pivot uh point for the worm uh uh that uh uh can actually propagate itself using this uh um root privilege and uh we can um do anything we want. Uh basically now speakers are really cool but there are things much cooler than a speaker. Uh maybe cars like it was the other thing we thought about. Uh but cars are expensive, right? Like Uria and I uh try to uh like convince our boss to make us uh like buy a car and we said like you

guys are crazy. It would never fit in the office like we cannot get it up in the elevator uh and stuff like that. So again, we had to be creative and we bought a head unit instead of the entire car which is essentially what we're trying to hack. You can see that it has CarPlay support uh on the on the left. And uh this um like funny setup also made by Uri was quite surprising, but uh it made us um run fast. And uh of course uh the same exploit with very slight modifications. The same stock overflow vulnerability that we used to hack this uh uh bow speaker from before uh uh was actually uh again the same way uh to uh

uh exploit this CarPlay device. Um and we um like we expected the vendors to patch um in a very fast way. Um but um the CV uh description was kind of ambiguous. It states that it can result in an unexpected app termination but as we showed you this is really an unexpected code execution. Um this is an rce uh we showed it on two different devices. Uh we believe it might be the reason to why vendors have not rushed to patching. Um and uh that's it. Most devices are still like vulnerable to this day unless you went and handed your car overnight in some garage to software update it and you don't have a Tesla.

So, uh you might be still vulnerable. Um there is actually a great resource in our website that uh uh is going in depth on the attack vectors, the pairing modes in CarPlay and so on. Uh I'll give you a second for the curious ones that want to go and scan the QR code. But uh there is uh a lot of in-depth research about the IP 2 protocol. uh the handshakes uh many things that uh were uh not as uh available when we um first looked into it. And um by the way, it's not just us today. There are some implementations on GitHub that try and go uh and reproduce this exploit um uh that are worth uh

checking out. Now we understood what the SDK implications are which gets me to the more interesting kind of devices the Mac OS ones we all use and then we found uh this use after free vulnerability and actually while Uri wrote the exploit for the use of free vulnerability um exploitation he actually found five more CVS which we also reported to Apple uh just while exploiting now I'll let to re elaborate on how this user to free works uh because it took some time and uh um that's it. >> Yeah. So the use of ty is part of the fair play decryption flow and fair play is used to encrypt and decrypt audio streams in air play. We kind of kept

this part of the research to the end because as you can see here the functions are highly obuscated. It was really hard to understand anything related to that uh protocol. But using some old uh um snippets we found and some old headers, we were able to reconstruct most of the names of the functions and look at it in a logical way. Look at the flow of the functions. Um and that got us to the use after free. So let's look at the flow of our typical decryption looks like. We start by calling the decrypt function which gets the encryption context and the buffer parameters. If for any reason the decryption fails, we call the tear down which frees the

encryption context itself. Now the third part is pretty interesting. We have a derived storage which is a global that is uh stores throughout the session and stores all of the session parameters. Now in this uh global we also have a pointer to the encryption context. So after it is freed in the tear down, we need to zero out that pointer. And here's how the use after free looks like. We start by calling the decrypt. If that fails, we call the tear down. But there's no third step here. This means we still have a valid pointer in the encryption context pointing to a now freed hip chunk. So uh we were pretty surprised that Apple doesn't have any um

heap spray protections on Mac OS and this allowed us to just spray the heap replace that encryption context and if we call the decrypt again we call it now with our own custom uh encryption context. This was pretty hard to h get into a fully working exploit but uh we were able to um make this into a write what where which allowed us to write any to any memory location on the heap. This essentially gave us full RC on Mac OS devices. Thank you. So, um the um less annoying part with all of that is that Mac OS usually prompts for user uh uh approval. You might recognize this widget um if you ever use AirPlay. Now, uh this

widget essentially requires us to click on accept for the code to run, which is a bummer for attackers and for us to prove the impact of the vulnerability. So, uh the next thing we did was uh trying to make this one click into a zero click and long story short, we managed to do it. Uh we did it by finding uh xrefs um like references to uh where this uh pop-up function is actually being used and then we found a very interesting flag somewhere uh inside the code. We found that if you specify um yourself and you are the client, you control your own like u um identity uh whenever doing this handshake uh and the flags that are

being sent to the server. if you specify this weird flag, the is remote control only uh flag. So it essentially does not pop up this uh popup and uh um this actually is a bypass to the authentication policy. Um and we reported this uh CV to Apple and this essentially turned our uh use of the free attack to a zeroclick uh wormable uh remote code execution on Mac OS. Uh to the best of our knowledge, it was the first warmable zero click on Mac OS. Um and that's it. So let's quickly um go over the vulnerabilities. Um I don't expect you to uh go over each one but just uh uh in high level uh we

had many uh out bypasses and user interaction bypasses access control issues remote code execution of course um arbitrary like fire reads and uh um like sensitive information disclosure and many forms of other uh logical issues um and uh we found all of them just by like looking at this SDK and naively approaching this nor like Uri neither neither myself had any um prior research with researching Apple devices. Um so we are uh quite proud of like our achie achievements in that sense many different vulnerabilities and uh we're happy um that they're all closed now. Um now this brings me to the final point which is the attack vectors. I think this is the most interesting part. Um so

the first two uh attack vectors are the internet and the intranet. So public facing internet servers. If you would go on showdown senses just to name a few uh you would find hundreds of thousands of uh airplane devices that are outdated and facing the uh the internet. And um again when we are connected to a Wi-Fi on the coffee uh or the the airport. So um anyone on the same network can run these vulnerabilities and uh exploits and uh take over our devices. Now these vulnerabilities have been patched for almost a year now. Um um in case you have not updated your Mac uh u in the past year um we encourage you to uh but uh some devices will never

be p be uh patched uh like uh when was the last time you've updated uh your speaker. Um now the next two ones are um more interesting and novel. So the first uh is um the third one is the web browser attack vector. So every website in the internet could uh essentially run uh some of these exploits um just by communicating with AirPlay that is listening on local host again using this uh weird 0000 uh IP address um which in Unix devices among them are Mac OS and Linux um it resolves to local host and just like that um public websites can communicate with locally running services. AirPlay is just one example. We actually proved that the web browser

is very overlooked when it comes to these interactions. Also, DNS rebinding a bunch of other very interesting techniques can be used uh as a as an attack surface. And my favorite one is the physical proximity. It's like in the uh James Bond movies when you like simply pass next to someone and in fact it's a a device. This is because Apple has a proprietary network interface um that is just for other Apple devices. It's called AWDL0. Um and it is always listening and accepting connections. Um this attack vector does not require the victim and the attacker to be on the same network but just in close physical proximity, Wi-Fi or Bluetooth range. And uh all of

these exploits could be delivered uh just by standing next to the victim. Now it's time for a demo.

Great. So now you're looking at the uh CarPlay system. Um essentially we're uh uh running the the exploit and as you can see um the um the credentials to Wi-Fi are shared in plain text. Now we're running the exploit and using this uh um uh exploit we gain root user privileges and a reverse shell. Now we're downloading an image and displaying it uh to the screen. Now this is just for the sake of demonstration. Of course you can do other um uh funny things like uh imagine I don't know spying on the driver and you have the location. these things have GPS or the worst thing you could do is like play shitty music uh in a loop, right? Uh

many things we can do uh to annoy the driver. Now the second one is uh um the Mac OS use of free vulnerability. Now we are going to override as Uri mentioned we had a write what primitive. Uh so we are just overriding the music app um address. Uh so the next time we enter the music app it would run arbitary code just open an image in that uh uh context. Now we are running it from the network. This shell you can assume it's the same bose home speaker from before. Now we run the exploit. We spray the heap and the next time we click on the music it opens an image instead of opening the music up. we

could do anything we want and uh we did not need that click eventually which we managed to bypass. Um so uh this is really cool. Um another quick fact is again browsers to this day are still able to communicate with the locally running services and many vendors have started patching. Uh Cisco is just one example. So they had uh at the time of writing um 63 different products that were impacted by these vulnerabilities because they of course um use their play SDK in many of their uh products. Um if you are using AirPlay and uh we encourage you to use it. Um the only thing we want you to to be aware of is that if you're not using the current

device uh as a screen so you don't want to cast to this device uh we encourage you to like not use the airplane receiver. it will reduce a lot of this attack uh surface. And if you want to use this device as a screen and keep the airplane receiver on, uh the current user option is probably the safest setting. And this is the one you should uh probably use. Um now, let's go over the main takeaways if I could just recommend uh a few. Um the worst part about this uh thing is that some devices will never be patched. As I said before, um I haven't personally updated my speaker uh for a very long time, if ever. I don't know

about you guys, but um some of these devices, unlike Apple that has a really good update mechanism to keep their devices up to date. They're really really good at it. Um not all vendors that support SDK are as good at uh releasing patches and um responding to such uh um vulnerabilities. Um and if it's not your code, it's still your responsibility. So if you integrated airplane SDK into your firmware and sold it to someone, you are the one that needs to patch it and it's not Apple's responsibility to patch all these AirPlay devices around the world. They cannot do it like themselves. So there is a shared responsibility model. Um and the most amazing part is that

it's the same line of code, the same piece of software that is making Mac OS, CarPlay and Bose home speakers vulnerable. Uh and these are just three kinds of devices. And there are um billions of uh devices around the globe that are using the AirPlay SDK uh still in the vulnerable uh version. Now, we definitely recommend using AirPlay. Like I am an an Apple fan and uh of course I don't want you to uh stop using it. It's an amazing and very efficient protocol, really state-of-the-art. Um and um um we want to thank Apple the product security teams for uh really working closely with us to help secure the users of AirPlay and uh um we definitely agree that the

most important things were was to um keep the users safe and it was the top of our mind. Uh therefore the um the patches had to be released accordingly. We did not want to release patches that will hint um for attackers and the bad actors that there are some bugs in some place in the code that where they should look. So uh choosing and uh scheduling these fixes was not the easiest thing but uh we definitely kept the user safety uh in mind and we uh work closely with Apple to fix these vulnerabilities. Um now if you want to connect with either Uri or me um just scan these QR codes and uh thank you very much. Now we

have uh time for questions.

>> Great talk guys. Really good great research as well. Love it. Um we've got a bunch of questions. Just as a reminder if you do have questions um you can wave your hand in the air. It is a bit bright down here, not going to lie. But you could also go to bsidesf.orgqna. Um, but we've got some questions already in the slideo. >> Um, remind me about those bags at the end because I will forget. No, >> I don't want to forget. Okay. Um, you kind of answered this, but I it's it's always interesting like you said it it wasn't all Apple's responsibility, but um, and you did work with them. Could you elaborate a bit more on kind of how

they react to these things? You know, what's that interaction like between you and and the folks over at Apple when you turn up and say everything's broken? >> Yeah, sure. So, um I think um both Uri and I uh didn't expect uh like u um to find this big of u like vulnerabilities. Now, Uri feel free to add anything if you add. Uh I think that um once we understood the the impact and we made it clear to them, they took it very um seriously and they got on call with us and we worked really closely with them um for more than 19 days uh which is the normal uh time life cycle of like responsible

disclosure. But um like overall they were very professional and uh as I said the user safety was the most important part and uh we agreed on that and it made things much easier. Good. I love that. Um, you don't always see that with vendors right? >> Yeah. It's uh, especially with the big ones, it's not something Yeah. And especially with the big vendors, sometimes you you expect them to like have the brand uh, uh, coming uh, first, but uh, it was not the case like they really cared for the users and we uh, did work very closely with them. Um, and we got a lot of uh, um, not only respect. So even URI's bag now has like

a a badge that says thank you from product security by Apple like a small terminal badge which is really cool. So they did also uh show us their appreciator appreciation and uh bounty and everything but uh uh in general I think like once we add the user safety uh in the first uh priority it uh made it very very swift and uh easy to make uh decisions what's the best action. >> Awesome. Um there's been a question about um some of the stuff you use when you're working on a new project. So what are the fundamentals you utilize when beginning fuzzing on a new project? So what does your testing harness setup usually look like? That's a talk in

itself, but yeah. Do you want to give a a little overview? >> Yeah. >> Yeah. So actually this was not our intention in this case. We saw the airplane protocol and we just wrote a super quick fuzzer with what we we knew at the at the time. We didn't expect to actually find anything. So, um my my usual setup is to get an understanding of the protocol or the product that you're trying to uh research. Get a basic understanding of it. Then either by fuzzing or by documentation. Try to map out the attack surface and decide where your first entry point best option for the entry point is. In this case, we add all of the network uh um u

routes from the documentation that we read. That was our best option to start the researching. >> Excellent. There's another question as well about kind of the the setup sort of. So, can you explain further about uh how you were able to simulate the Bose device? Yeah. So essentially the both device firmware was publicly available online. Um and we were able because the device itself runs on Linux and we were able to simulate it on a Raspberry Pi without that much uh difference. The only issue is the specific MFI chip used by Apple supported devices to authenticate that it is an actual Apple device and we did some reverse engineering of that um specific uh um

chip and used an Arduino to simulate it. We have uh a bit more details on our blog about blog about it. >> Cool. Cool. Okay. Um I might roll two of these into one. So someone's asking about the root cause of some of the interesting vulnerabilities um and how deep that went. And then somebody else asked um how many vulnerabilities were used in the exploits you how many or how many vulnerabilities did the exploits exploit I guess. So I I think there are different root causes as AI mentioned in the talk. Some of it was um things that were previously um after specific steps of authentication and sess session setup that were later um changed and didn't

get the same attention maybe. Um it's a longunning protocol. it's been for many years. Um, so I think changes in the protocol itself are some of the I can only assume are some of the uh things that made some of the vulnerabilities happen. Um, the specific chains are are pretty different between them. The SDK device, the Stack Overflow needs only one vulnerability. It's a pretty straightforward exploiter. um the uh use of the free run. Uh there is the main uh vulnerability that we discussed some additional uh things we used like the authentication or user interaction bypass but most of them are um one or two uh vulnerabilities for a chain. >> Awesome. Thank you for that one.

Anything else to add? >> Um no, thank you very much for staying until the end and uh we really appreciate it. It's our second year in a row and hopefully we'll be again next year. >> Chapter 3 next year. Yeah. Yeah. >> Awesome. All right. Thank you so much, guys. Hang on. Do the bags. >> All right. >> Thank you very much. >> Here are some luxury gifts >> from Beside San Francisco. >> Amazing. >> So, thank you for for coming. Hope to be seeing you again next year. Uh, thank you all for coming. Another big round of applause please. >> Thank you. >> There are probably some things I should be telling you. Hang on.