The Forgotten Art of Filesystem Magic

Hello. Perfect. Can you hear me? Okay. >> How are you doing? Good. I hope if you're for the blue team talks, this is not going to be one of them. So, this is a heavily modified talk I gave earlier. Uh, this includes a bunch of bounty hunting stuff which I think you guys are going to be more interested about. So, who am I? I'm Ger. I'm on Twitter. I do a bunch of stuff. I'm a longtime Linux nerd accorder. Mostly I work full-time in the Apple security bounty program and I'm not an Apple fan strictly speaking. So believe me when I praise them I mean it. And so like that is also true for my criticism.

So I'm a moderately successful buck hunter which means basically this it's uh sort sort of good enough to make a living if you're not living in a very high cost of living country. Uh this presentation can go deep into fast system stuff and I published a bunch already. So this is just the tip of the iceberg. You can find more more info on my blog and more really deeply technical stuff. So in this talk we're going to get to know Apple's bug bounty program uh the protections in Apple systems. We're going to attack file system operations and fast uh file operations and file systems. We're going to look for some zero days and try to keep our

sanity. And I will try to do my best but it's going to be hard. So why would you want to do this? Well, basically file operations are everywhere and they're quite easy to exploit and they uh especially on Mac OS they give us a lot that otherwise would be pretty hard to get. So this is a this can go from classic Linux LPS from user to root to bypassing Apple's other protections and uh the reason for that is basically what Apple is trying to do in the user space is going to rockpool 40 years of uh postix expectations and uh that is not something that usually ends well. Now I said in the earlier slides of nobody's

paying attention is no longer true. I had multiple people approach me and they are much better at this than I am. So if you are please at least like publish a write up. So I dream of a system where everything is an SUID where the mountains are large and the triagers are quick. And I thought looking at Mac OS might be a good idea because it's um it's this unholy chimera of an operating system. It's it's it's kind of postings but not really mostly BSD but not quite. And it is pretty secure. Um there are some strong points definitely with it. Uh there's no code injections. Everything's code signed. There's no X11. Uh all the binaries are hardened

that come with Apple that are in scope in the bounty program. So everything is pretty hard. Uh root is severely restricted. And basically the operating system uses entitlements to assign privileges. But instead of using the file system to assign a permission bit, it uses the code signing to do this. This is genuinely a good effort. However, there's a bunch of stuff that can be considered a weak point. Not necessarily. is just how the how the how Apple works. So almost everything uses IPC which can be XPC MAC messages whatever Apple proprietary. When I say IPC just think like interprocess communication. Uh most good is Objective C and Swift which is very important from an exploitation perspective but I don't

have a lot of time so I can't go into that very deeply. Uh most of the operating system is fully closed source. However, there's some very crucial open source parts like the kernel and the lib uh the lib c and a bunch of other stuff that is very interesting in chabas talk about this arbitration d one one of the crucial components being open source and uh yeah as I said this breaks a lot of postix expectations and uh because of that a lot of code that is used in the operating system that is open source uh is going to find itself in this weird environment where things don't quite work how they expected to. Um

technically Apple tries to do this to introduce a privilege boundary between processes of the same UID. So on Linux this is not a problem. In post this is not a problem but Apple tries really hard to make this happen. Now the problem is this is crazy because this is impossible to do in the file system unless you engineer the system from the ground up correctly and there there are quite a few reasons why that is a very hard problem. Uh also the operating system has a quite a quite an intense amount of magic in it. uh be because either Apple's just being Apple and they try to think different or because of compatibility which Apple is actually

pretty good at getting rid of. So some example craziness uh on Mac OS by default you install software by mounting a disk image which is a pretty insane idea. Um the entitled binaries that you would run as an unentitled user will run as your UID. They're your processes as far as BSD is concerned but in the kernel they're actually entitled. They can do things that you can't. So there's a bunch of ways to hijack this obviously. Uh ASLR is not really a problem locally running. It's al u only meant to protect against remote attackers. Uh there are I'm sorry [clears throat] there are many privileged demons that also talk over IPC that you can just talk to because

this is a fairly new system. Not always but um and yeah because they're trying to backport this security functionality essentially and it's not baked into the design. We pretty much know how that will go right. So I I think Mac OS might be one of those systems. So how how hard can file operations possibly be? Well, uh there's a bunch of tricks you can do and this is only postix. This works on Linux and BSD and whatnot. Probably Windows, but I don't really care about that. Um this is what Apple put on top of it. This there are some people who paused on these slides for weeks. They told me this. There's a bunch of

insanity that you can do. Unfortunately, again, I'm pressed for time. I can't really get into this but like find me roaming around and I will I keep talking about this. Um so yeah basically the only thing you need to do is have one path component that you have control over that a privileged application is using. Um and from there you know file systems are racy path resolution is unintuitive. Access control is unimaginably complex much more complex than you would think. Um a user can mount move the mount points amount do all sorts of crazy stuff. Um the advanced protections there are regax based as far as the file system is concerned because that's the best they

can do uh in le of like re-engineering the entire file system changing all the file APIs and rewriting all the software in the world which is clearly not very feasible. Um so the attacker is in a definite advantage at least on Mac OS at this time and broad mitigation is is h impossible might be a bit strong but it's very very hard. So basically once you control one path segment uh since on uh Unix and Pix the parent controls the descendants you can do this by uh having right access using sim links using mounts using inheriting permissions which is a thing actually um and the only defense is actually completely separating the file operations into

their designated directory where nobody else can can manipulate them and this is how postics was always meant to be used. Um so but again this is not always feasible and on Mac OS this happens a lot. So a lot of demons run with specific privileges that you as a regular user you do not have. However this uh service or program runs with using files and directories in your home directory. So you get to have some control and Apple's been slow but cracking down on all of this. And uh yeah a lot of system programs are entitled that that weren't necessarily entitled like five years ago. And I had a couple hilarious examples on that. So

basically we know retrofitting security is always a great idea. Uh however it is commendable. This is what Apple is trying to do. But as far as you're concerned um app armor and SC Linux do the same things because at that level there's not much you can do. You can basically just like basically match rag access and file operations. And there's you know that that kind of sucks and it's kind kind of a clunky patchwork instead of like a a proper robust solution but you know still a whole lot better than nothing. told you tip of the iceberg. Please check out my other work. Uh it's this rabbit hole goes really really deep. Now this presentation is

kind of a uh I kind of screwed you over with it because I was meant to talk a lot about zero days, but I figured there's a lot of young people here who might benefit a ton of learning about the actual Apple security program and how bug bounty life works. So meet the ASB. The ASB's Apple's uh security bounty program is unironically an amazing initiative. it does have a great effect but in our research uh both for researchers lives and incomes and the quality of the software that Apple will ship to their uh actually billions of consumers. So as far as I know these are the best uh payouts uh they do pay bounties and they are fair. However,

there are some heavy caveats to this. So just very quickly Mac OS has this all this letter soup of uh various protections and it's very insane because some things are overlapping and some things are not. It's very hard to wrap your uh head around it but very very quickly CP system integrity protection is basically the substrate upon which everything is built. It's a bunch of kernel hooks and user space modules and whatever but uh for our file system purposes mostly it's like rag accesses that the kernel enforces on certain places. The app sandbox is the application sandbox. If you run an application from the app store it's going to run inside a sandbox. By the

way the system also has a default sandbox. So even root runs in that sandbox. So it's a sandbox inside of a sandbox. Yeah, it kind of screws in your head. Uh, transparency constant and control is Apple's way of restricting access to such things like that are very sensitive like camera, photos, location data, all that. So, that's again another uh layer of protection. Git keeper basically is just meant to like uh you can download an app but you won't be able to run it in most places and it checks a bunch of things. I'm simplifying a lot guys and launch constraints. Finally, I think I would like to take some credit for it along with Chubba and a bunch of other

researchers who do this for a living. uh and and and found a bunch of bugs and Apple eventually cracked down and disallowed a wide variety of trickery that we can do. But in our present talk, I'm going to talk about two main things that I usually go after the classic LP user to root. Everybody who use Linux is familiar with this and a TCC bypass, which means that the user who is an unsandboxed user uh is able to gain an FDA. An FDA is a full disk access. There's a full I'm calling it full disk access because you can enable this in your privacy panel in the settings. By default, you do not have it. But if you

enable this, basically all the TCC uh prompts that would that the operating system would show you are gone. So I get to steal your photos and uh I'm not sure if this works with camera, but probably would. Anyway, if you get the FDA access, that's a that's that's an actually pretty bad thing. So getting an FDA in some cases might be more serious than getting root, which is wild. So Apple pays a bunch for this. Yes. So uh this uh 40 CC bypass on iOS would be 100 grand and an LP2 root would be 50. Now there's a bit that math is a bit um weird because they do not actually pay this. In my experience they pay like

one/ird might be because iOS is is is super super hardened compared to Mac OS and probably because a lot less people use Mac OS than iOS. But iOS again is a gnarly gnarly target. I dare not touch it. Um, however, the bounties are still worth it, especially if you're living in Hungary or some low cost of living uh place. So, so how do you find bugs? How do I find bugs? How do I do all this stuff? Well, you do some research and testing. You read all the developer manuals, the M pages, you just learn a bunch. You watch conference talks, talk to people, uh, read writeups, and you test a bunch. You use the system

dayto-day. There might be some things that that they jump at you, how they jump out at jumped out at me. When I first started using it, I was never like a Mac user really. I come from a Linux background and a bunch of bunch of this file system stuff is like really weird like hey if Linux did this like this would be owned in two seconds. So um that's how that's why I focused on it so much. Uh you test your hypothesis uh and you test obvious things and you might be surprised because sometimes the obvious things will actually work uh or not work uh and you will either learn something or you discover that the system actually

works differently than uh advertised. Uh, sometimes you just get lucky. Sometimes you use it daily and something jumps out at you and boom, there's a bug. Apple, sometimes blunders a fix. Sometimes you get good ideas from a blog post that enable you to uh make progress on your other bugs. It's always good I think to focus on a niche a little bit uh because if you become an expert uh you will you get to know more than the devs in some cases and that is good because you are in really in competition with the devs. Now there's some competition among researchers as well but mostly security is all you do but to the developers security is one of the

many things. So if you know more than them you can dedicate you can outwork them essentially in a lot of the cases and that's just not this on developers. It's just how the economics of it work because you know they have to ship the software. They have to make sure it's performant. They have to make sure of a lot lot of things. You only care about security. So you're kind of uh you kind of have an advantageous posh position. You can dumpster dive for bugs. There are a bunch of bugs that are deemed garbage or unexloitable. If you find a good vector for them, you end up with a bunch of zero days essentially. And uh

but this is the standard security thing that you have to learn about code that is icky, that is ugly, that is old and difficult that nobody wants to touch because those are the codes that that haven't been audited. And yeah, generally uh collisions sometimes happen and they really suck. So you have to follow other researchers and see what they're up to. And if somebody like a like a really dedicated team has been winning pony to own by exploiting one singular subsystem and there's like five of them, there's no way I'm touching that, right? It would make no sense because I would duplicate their work and end up finding nothing. Um uh you can do this by the way if you use

like a very different method or uh or a very different approach, but again it's it's sort of a risky thing. And generally rule of thumb, just pick targets that have little public research and or CVES because it's likely that either there's nothing there or nobody's paying attention. [cough] [clears throat] So these were meant to be my seven bugs. Uh all all of this is public uh besides Jetson uh number seven and I tried to like uh cut out a lot of it because I have a lot of slides. So the uh letter Alison bat signal has write ups on my blog and Alfred is published in the slides for alligator count is also on my blog if you want to

like dig deep into that research and and have a have a have a hearty laugh. Check them out. There are some very good funny bugs in there. So the number one we're going to talk about, we're going to start off easy. This was a classic rename bug in music. And music at that time, the music app that you know plays music uh used to have FDA permission by default. it had like no business having this permission, but it had it by default. So, I figured uh there's this magical directory that I can dump a file into and when music starts up again, it's going to be very helpful like, hey, I'm going to organize your audio files

and call a a rename a system call where I control both parameters essentially. So, uh this is a best case rename bug because both parameters are pretty much fully controlled. To exploit this, I only needed to uh replace the date directory with a sim link, which is a very trivial race, trivial to brute force. I brought some videos because live demos don't generally work out very well for me. I don't know if you can make it out. Um, so what I do here is I clean up the privacy panel so that I have no permissions on anything. Uh, and yeah, the exploit was pretty quick actually. What I gained here is automation permission over Finder.

Finder is basically the explorer of Mac OS and Finder is great because Finder always has this FDA permission. So if I can come under Finder, I don't have to have the permission. I can just tell it to do things on my behalf. So this actually is worth $30,000. And that's not too bad for for something like this. And it doesn't always happen often. These are the best case scenarios as I tell you. Like I make it look easy. The reason is because I spent months and months and months trying to figure out how to exploit it easily, but I spent a lot on these. Not this one especially. This was actually easy. So the second one, massive blunder. Uh

Apple's going to be very happy that I'm talking about this again. Uh they compiled the best to debug on. What that means is they shipped this to like I don't know two billion devices. uh if this environment variable existed, you set it to whatever you wanted and when libculite loaded an SQLite DB, it would just create a copy and a statement log and an index file in the directory that you told it to. That is mental. So, first of all, that is a horrible info leak. Really, really like yeah, what the hell, right? So, horrible info leak among many others. A lot of applications use this because escalate is awesome. Uh among them, music. I could have used

anything else, but I'm it's kind of a meme that I abuse music. Uh, so yeah, bad info league, but I always, you know, wanted more seeing how far I can take this. And, uh, I figured, hey, because this is debug functionality, the open system call actually will follow sim links and will overwrite files. So, that's very good. The bad is that I don't really have content control like I would with a regular file, write, because I can't like modify the middle of an SQLite database. Not really. If I did it would be corrupt and it wouldn't work right. So I spend quite a lot of time uh because I'm an idiot also uh because as you will see the solution is

quite straightforward. Well since so in music I control some of the source DBs that will be copied right and I can put whatever I want into them and SQLite is absolutely amazing because there can be multiple tables for multiple applications living in the same database. And when have when have you seen software checking for other tables uh existing in the database? Never. Nobody does this. So what I did is basically I took valid TCCDB tables and cache DB tables and I merged them and put it into the cache DB of music. So whenever the copy happens, I could predict where the uh file name is going to go or or the copy is going to go. I

could sim link it and therefore I ended up with a TCCDB that could both function for music and both function for TCCD. So with that again I basically do the same thing. So I have no automation permission.

I could make the flickering go away but it's PC. Tada. Uh again, uh third 30 grand. Uh the fix was very easy. They completely vesculate correctly. Uh for my next trick, uh stop uh abusing music for a second and see if we can get root actually. Um so bad monologue. This is in a very very old bug, at least 20 years old. The first reference I found to it was in 2005 in frack. So it's quite fitting. It might have been there already. I don't know if it was buggy all the time or just like it bug became buggy recently. However, um so the dynamic loader whenever it saw these environment variables, it would just

force load this fully random apple signed framework binary. And that binary would start processing these environment variables and whenever they find a molex loading directory environment variable, it would write a debug file in here. And this happened in all processes including SUIDs. Um that was my face of yeah this this this is crazy, right? Like nothing does this like the dynamic loader should not ever do this. This is pure insanity. However, Apple's not stupid. They had defenses mainly that the directory the destination directory whatever would be checked with access first. The open that was used to create the files will not overwrite files and will not follow sim links. The permissions were restricted. So no you mask trickery and the file

name was randomized. So this you know it worked for like 25 years. You know surely it would be good. No, access and open is the quintessential example of a talk to race that is provably insecure. On no follow is used instead of on no follow any. This is actually not Apple's fault. This is postix's fault. On no follow means do not follow the sim link if it's the last path component. On no follow means do not follow any path components. Now since I provide the directory, I can set any to to anything really. I don't even need to use sim links. So like this is a moot protection. The fact that the permissions are restricted is actually

going to help us and I will tell you why. Uh and the file name is randomized and okay yeah so I tell you why now because sudo doesn't care because if you dump this file into etc sudoers sudo doesn't care at all that the file is full of garbage as long as there's there's one single valid line. Oh, it's going to cry about it a lot. But you can essentially sudo to root with a partial uh content control with no file name control. So all the randomization which was by the way hilariously broken uh was absolutely moot. You didn't even need to do anything with it. Now however there was one massive problem. This took me

like 6 months not actively but like I was banging my head against the wall like I I couldn't figure out that I had negligible content control. So I could not put that little piece into the file that I wanted to because this logs allocations. It's a super weird format and I'm clearly I haven't gone to school so I don't know how to like figure that out. And I spent quite a long time and then it dawned on me that I'm an absolute because open did not have the cloax flag set. So that means that since every application is affected, I could just run a sewage root binary. It has no idea that this has even happened

because no s operating system would ever just like oh I'm just going to force load a framework, right? Nobody would ever do that. So is there is there such a binary? Absolutely right. Chrome tab. Chrome tab by design. Very run my editor. It has no idea that this happened. That would be crazy. Absolutely crazy. So again, Chrome tab is not a fault. Absolutely works correctly. Tries to clean up and everything. It just doesn't expect the file descriptor to magically appear. Probably, you know, it could be improved, but really I I don't chuck this up to Chrome tab at all. So yeah, that'd be insane. So the X bit was actually quite easy. If it's an access

open race that could be trivially brute forced because this is a cool part about file systems is that uh you can try again and again and again and the smart solution would be of course like yeah do some math and then figure out and then measure and then ah use some AI model some or you know something like that. No, you set up the conditions in such a way that the only way that it can succeed is the one way you want it to be. do your best and then just burn the house down. Like just run your CPU through like 10 million iterations. It doesn't matter that your success rate is one in a billion. If you can try a

thousand times or 10,000 or 100,000 times a second on like every single CPU core, you don't care. So just basically do that. Uh kind of sucks that it's this um that the letters are this small. So I tried to sudo to root. Didn't work. And I'm trying to find my exploit because clearly I'm a professional. And that's it. I got a root shell in I don't know like 16 tries or something. And that's how long this took because I can just retry and retry and retry and retry. And the worst thing is going to I'm going to get is like an orphan file somewhere or maybe a log entry. But I I I don't even think that's going to work.

So yeah, good luck detecting this or like defending against it. Um this cost another 22 grand again for a 20-year-old bug. uh which was quite fun in my opinion. And my last one I think is uh Jetson. Uh there's this thing in uh Apple. Apple invented another format. It's called Jetack. It's a pretty simple format. Took me like 30 minutes to reverse and I'm not good. Uh it's basically a container of containers. It can contain a tar file, a brley. Brley is like like Google's whatever archive format doesn't matter. Um and this uh jetack format supports encryption, but the encryption was not turned on. uh for like most stuff. So again, music used one of these and a bunch of uh GU

applications used this. So there were two problems here. First of all, this file got downloaded into a temp directory I had access to. So I could switch it out and that music would just take the file. I just switched out and would extract it anywhere into a directory I controlled by the way. So that was really fun. So uh the files are extracted with open and it wouldn't follow with no follow. And if the file existed, o excl means that if the file exists, uh do not extract it. I think that goes for sim links as well by the way. So this would have prevented sim links because it would say that oh sim link is already a

file. However, this is what I had. I could replace the archive with my own and I can include so like the race was pretty tight and I was like having problems winning it and then I felt like hey can I can I can I put this file into the tar more than once? Absolutely. Tar is insane. You can literally take the same file, same file name, same permissions, same data, same metadata, same everything and just like include it multiple times in the archive and it would just extract the exact same file 100 times. There's nothing there's nothing that would prevent me from doing this. This is a feature in tar. I'm sure they had the reasons, but this also

means that I get like to like single click a pretty unlikely race. I could make this number 10,000 if I wanted to. 100 was plenty to win it. So basically with this I had full path and content control. Uh but you might remember hey you're not allowed to overwrite existing files right that is true. I wrote my exploit and I didn't really pay attention and it worked. And then I later noticed that hey this like this flag is set like how am I succeeding? Well jetack is helpful if the file exists like an it takes another code path that will unlink the file. [laughter] That is insane. So sometimes trying to do the impossible thing is actually

trying to do or or doing the smart thing because as you see the file operations here were individually secure. However, logically they weren't because there's still a logic bug that is only visible. Like good luck trying to find this statically by the way. Uh so as as long as you try to uh you're you're not trying to trigger the error condition, you're not going to see the different code path it takes. And probably somebody you some of you are gedra wizards and you would be able to see like haha well I didn't. So ever since then I check for various weird stuff. I just set like invalid permissions on a file. Sometimes especially on Mac

programs are very helpful. You delete a config file. IT'S LIKE OH HEY YOU have that config file deleted. Let me just like rewrite it for you with content that you provided previously and they do it in security. Boom. There you go. You have zero day. So yeah sometimes it's a free win. And not to beat the dead horse, but I exploited music again and I got nothing. Apple said that this bug was not eligible unfortunately because they were already turning encryption on internally. And I was like, I mean, yeah, it is absolutely plausible. I had nothing on them. It's like, okay, fine. Like, I saw you were already doing this. Okay, fine. And and uh then I tried to

like close out my old tickets and Apple just wouldn't close it, but it's not the first because they do all sorts of insanity sometimes. And I got this. It's very very I'm sorry about this. It's very uh small. The princip is small to make out. But basically, this is where they tell me that hey, I got 30 grand for this bug that they adjudicated. They re-evaluated internally and they pro I don't know why they probably find an internal version or somebody was just really nice. I don't know. Probably not. Uh they found a path where this was actually still exploitable and they credited me for it. So yeah, this was great. It took them a year. I'm not I'm

not crying though. Uh, there was supposed to be a video that I totally forgot to record and to write the blog post, but you know, it's ADHD things. So, let's move back a little bit. These are all the bugs. Let's move back to my my experience with the ASB. So, as far as I know, the Apple program is quite good, fair payouts. I think the assessments are correct. Um, however, fixes take a very long time, which is kind of acceptable. I'm not knocking them for it because they do have like billions of customers, like literally billions. Um, but they communicate in a very frustrating way. They basically don't tell you anything and and they often make mistakes and uh the big

asterisk here is that sometimes these seem like very very unfair decisions and this has happened to me and everybody else who has ever participated in this program and you have to push back and when you push back uh a lot and it's quite infuriating but when you push back eventually they will internally resolve the conflict and realize that this fell through the cracks. So, um, but if you're using this as your main income and you've waited for 12 months for a fix and they close it as like, uh, this is not, you know, this is not bounty eligible. It's a very scary and frustrating experience. Also, with the unfair bounty amount, sometimes internal screw-ups happen more often than you

would think. Uh, like operating a program, by the way, is is not trivial at this scale. So, the fact that they even have some success in this program is quite impressive. Um, yeah, there's sometimes pandemonium over there from what I've seen. And but it's important to say I have never been wronged by Apple. There has never been been a case where I was like, "Oh, yeah, they they should have paid me, but they haven't." Um, and all the Apple people met were amazing. They basically just want to secure their platforms, but again, they're sitting in an absolutely massive bureaucracy. Is their second richest company with $2.7 trillion market cap, and they have more lawyer than our

Facebook friends combined. So yeah, things will get weird sometimes. Uh my advice to you if you're a new hunter uh is that know what you're getting into. This is not kindergarten stuff. They will require they're very very strict. Um and they will not tell you anything because of legal reasons that comes later. Um so you need to have a working exploit for the latest version on on Apple software by Apple that is legible preferably software out of the box. So third parties don't count because that's not Apple's responsibility which is quite fair. Uh Apple will keep you in the dark probably due to legal reasons. uh they will not tell the researcher any information because that you know oh Apple said this

and then you know the whole world loses it um research what this is like a lot of people have been talking about this and this is part of the reason that I'm here talking to you guys and then sharing my experience and then making my bug bounty amounts public and all that to like inform people and to like uh be as much help as I could be uh because when I started people were helpful help helpful to me partially it's good to give back anyway uh but again the scene is becoming more and more competitive and collisions do happen and it sucks. Um, this is generic advice in any bug bounty program or your job or whatever, but try

to be correct. Try to be objective and estimate the impact objectively because a lot of people don't do this and it's very hard sometimes and you and and you wish you had a higher impact. But no, just be honest. Just be brutally honest with yourself and try to like make an actual correct impact because the more you do this, the more objective and the more correct you are. The more secure you will feel when somebody tells you that hey this is actually not eligible and you can say no I know this is because X and Y and Z. So do your own research and just be very diligent. Uh obviously fulfill all the requirements. If you don't send a working exploit

they're going to say I'm sorry we required a working exploit. You didn't send us one. Uh I I think that's fair. uh and communicate professionally which is which is supremely difficult. I know the print is well actually that is legible uh after their like fifth lawyer speak template response that tells you nothing after they've been keeping you in the dark open and close open and close open and close open and close the ticket and then ends up like 12 months in you're not eligible after all very difficult to stay polite but try your best. Uh, al also be assertive, stand your ground. If if you did your research correctly and you did your evaluation correctly, this is the easy part because

you know what you have. You know that if an attacker had this, they could like do X and Y and Z, but maybe not A and B and C. And that's good, but know what you have. fight back against unfairness or perceived unfairness because these are likely by mistake and it's it's not like somebody sitting at Apple and it's like screw with that researcher. No, there's no incentive for them to do so. The PR fallout would be absolutely terrible for them. They want what you want fundamentally, but they're really overloaded. It's it's just how com big companies like this work. And yeah, it looks like malice and it can feel like malice, but usually it never is. So, I

hope you're still awake and and that you learned something. But all the bugs included, this is the total, by the way. Um, and this is only the start. If you want to get into file system stuff, I have so many tricks and really little funny uh bits and little things you can pull that that is absolutely insane and I would love to talk about it. And I kind of rushed through my talk quite furiously. So, uh, I want you to continue this research and I have some greets because Joe Fitzell, the original goat and a fantastic guy. If it weren't for him, I wouldn't be here. Uh for Apple for giving us the ASB, for Bites

for letting me be here, and you guys for letting me ramble and listening. Thank you very much. I I I think I can take some questions. [applause] Thank you.