Your iPhone is Lying to You About Files...

If you pay attention to the news, there's a trend going around that Gen Z doesn't understand file systems. Large publications like The Verge or Futurism have talked about this phenomenon where even really smart students have this large gap in what's really a fundamental part of computers. But what if I told you that this gap isn't really their fault? What if I told you that one company in particular has contributed greatly to the abstraction of file systems? Eventually, the file system management is just going to be an app for pros and consumers aren't going to need to use it. — There may be this persisting illusion that iPhones have no file system, but there's actually some fancy abstractions happening on the back end. And as a researcher myself who's presented at multiple Apple security conferences, let me break that illusion for you and show you what's really going on. But first, some history. When you're using Mac, Windows, or any desktop operating system, the first thing you probably do is open up your file manager to view your files. And you probably repeat this process dozens of times while you're using your operating system. This could be Finder on Mac OS, Explorer on Windows, or even just a plain terminal on Linux. Now, think about how you use your phone. You probably don't open up and view any files. Or do you? Back in 2005 at the D3 conference, Steve Jobs shared his plan for reducing the learning curve of operating systems. He really hated the fact that the file manager was the main front of the operating system when every user study ever also told him that this was the most complicated part of the operating system. In order to shift computers towards becoming more accessible and intuitive, he wanted to do things differently. and that's when he made his sort of file system prediction or you could call it his file system vow. Now, keep in mind this revelation was shared 2 years before the first iPhone was even announced. But when 2007 finally did come around and the first iPhone was released, you would notice that a dedicated app for viewing the files was indeed absent on the device. Now, Apple wasn't the first one to introduce this kind of appentric model. Pom OS takes the cake there, but they were very early on and they implemented it in a really polished manner. Even though this seems like kind of a controversial design decision because people would be so used to having a file system management application previously, it really didn't make headlines when the first iPhone was actually released. A few power users complained, but for the most part, it really just went along with the simplified UI design that Apple was really aiming for. It's nice to take a look at the original articles to see the actual sentiment of the reception of how the iPhone was meant. So, if we go over to the original Arts Technica article from 2007, I really like this because it really puts you back in the day in 2007 and it shows you that all of these technology reviews really haven't changed over the years. So, stuff that seems groundbreaking today, I wonder what that will be like in a decade or two. Anyway, so this talks about the original specifications and attributes of the initial iPhone. You can see we go over here and it says meet the iPhone has storage flavors of 4 GB or even 8 GB. They're feeling really generous with the storage here. And it's like a tall iPod. Haven't heard that word in a while. Pros saying it's really got that simplified experience. Easy to use. That's really what they intended. But if we go to the cons, there's no mention of the file system management application absence at all. Now, some of you might be confused when you look today, and you might say, "But Lori, there is a dedicated files app to view your files, and I've used it. " But the missing files app isn't the Mandela effect. The no userfacing file system philosophy only managed to stick around about a decade before some fundamental limitations really forced Apple's hand there, but I'll get into that shortly. Now, despite the persisting illusion that iPhones have no file systems, iOS does actually have a very sophisticated file system. So, I'm going to open up my jailbroken device so that we can actually see the hierarchical structure of it. Now, I'm on this jailbroken iPad, very similar to iOS, so it's going to be roughly the same when we take a look at the directories. And I'm going to go over to the FilZA file manager. And this is not available on regular devices. Your device actually has to be jailbroken in order to get this. and it gives you a much more raw understanding of the real hierarchical structure. You can see I'm in the applications directory at the moment. These are all the apps that are currently installed on this device. But I want to go over to the root directory. That's going to sound a little bit familiar to you if you've used any other Unix based operating system before. And this whole structure is going to start to give you like flashbacks to using other oss. You can see we've got this user file. User bin might sound kind of

familiar. We've got this bin with all of these different binaries inside of this. You've got cat pwd. You've got bash. All of this kind of stuff. And additionally, we have our Etsy directory with our list of pseudoers. Additionally, if we go over to our applications out of the way, Miku. If we go over to the app files, you can see the app isn't actually a file. It's an it's a directory. So, we have multiple different kinds of directories inside of this, as well as our actual executable that comprises the application that you're running when you click on that app in the UI. Now, you might have noticed some similarities in folder naming conventions to both Mac and Linux, but this isn't an accident at all. iOS derives from OSX, now called Mac OS, which derived from an operating system called Darwin, which derived from Unix, which is why iOS actually has an ancestor of Unix and so has inherited many different characteristics from it. One of these important characteristics is FHS or file system hierarchy standard, which specifies kind of the basic directory structure for Unix like operating systems. So you might have noticed that the root directory was slash which is standard across like Linux, Mac, iOS, iPad OS. You might have also noticed we had the / etsy directory which contains config files and we even had the /bin directory containing common GNU utils which might seem a little bit odd to you. If we want to get more information about what's part of the basic directory structure for FHS and then what's custom to iOS, one of my favorite references is the Apple wiki, which is a community set of notes that you can use to check really obscure information about all different kinds of Apple devices and even jailbreaks. So, what I'm going to do is I'm going to go over to the Apple wiki and I'm going to go to file system. And you can see this directory structure of the folders looks very similar to what we had on the iPad over here. Now what I'm going to do is I'm going to go over to Etsy and you can see this directory is specified by FHS and it's kind of required to be there for Unix like operating systems. But if we wanted to go to any of the other directories, some of them are actually custom to iOS devices. FHS isn't a file system itself though. It's more just a set of guidelines. The actual file system implementation and the one that currently runs on all different Apple operating systems right now is something called APFS or Apple file system. They really got creative with the naming conventions there, but this is their proprietary file system format. APFS is implemented as a kernel space driver. So what happens underneath the hood when you make a write request to write a file to disk is the OS takes that request, passes it over to the APFS kernel space driver, which then is responsible for all of the intricate details of finding available disk space, actually writing that data to disk and then updating the internal file system records. A couple weird differences between iOS and traditional Unix file systems is that generally Unix file systems are case-sensitive, but iOS file systems are case insensitive but case preserving. So what that means is that if you tried to create a file, let's say record. ext with a lowercase R and then you tried to create a secondary file capital R record. ext, text. It wouldn't let you create the second file because it treats them as the same file, but it would remember the initial capitalization that you associated with that file. Another thing is that APFS is based on the Unicode standard. So, if you want to, you can totally name your files with emojis. Please don't. Before we get into some idiosyncrasies of the Apple file system, let's get our hands on a real iOS application file and see what it actually normally looks like. iOS application files come in the form of IPA files. These are going to be the main application type that gets uploaded to the Apple App Store. Now, I have an example right here. This is Animoji Studio. And you can see the IPA file. If we do unzip our IPA, it actually is just kind of a special kind of zip file. So it contains all the associ associated resources for that iOS application. And that app extension might look a little bit familiar to you. We saw that on the jailbroken iPad a little bit earlier. So we know this is the application bundle. And remember that is actually a directory, not a file, even though it ends inapp. Now we can see we suddenly have this payload folder. So I'm going to go into the payload. And now you see ourapp file. So let's go into that. app file. And we have all of the associated resources for this

particular iOS application. We have the info. p list which contains uh all of the configuration information for the application in key value pairs. And we also have something called the MacO binary. So if I do file and then I do that binary, you can say this is a MacO 64-bit executable ARM binary. This is going to contain all of the actual executable code that runs when you touch the UI and trigger that particular iOS application file. If I want to take a better view of this, what I have is a iOS decompiler based off of GEDra that I wrote and released at my last abducted by the sea presentation. All of this code is available for you online if you would like to start analyzing iOS applications. So let's go over to Malamite where I've already loaded this application and this is going to be a more friendly view of the decompiled iOS app. So first of all, we start in the info. p P list which remember contains that main configuration information. So you can see it has like the name of the application plus a lot of different permissions that it requires when executing plus the associated text with what is going to pop up to the user when it's requesting those permissions when the user is deciding whether or not they want to actually give the application permission. Or if we go over you can see all of the associated assets that are necessary for this application to run. And we can also take a look at the actual code that comprises this application. Now, the funny thing about iOS files is they bundle all of the necessary resources and libraries for this application to run. So, it's a little bit challenging to distinguish between library code and then the core application code that the developer actually wrote. So, let's take a look at some of these class names. Let's look at an interesting one. I don't know, recording flow controller. So this is going to be all of the code that is decompiled that actually executes on the device once you trigger this application. Now that we know what a standard iOS application really looks like, let's talk about some of the illusions that are part of the iOS system itself. Now first of all, there is a standard directory for iOS frameworks and libraries and these are consolidated in a unified location kind of like system 32 on Windows. But unlike Windows, which puts all of the associated executable code for the system inside of each respective DLL or executable file, on iOS, there's something weird and all of the expected executables are missing. You would normally think to find a MacO binary inside of each folder, but this is mysteriously gone. So, let's take a look at what that really looks like on disk. Now, I have a shell connection to my jailbroken iPad over here. Remember, this isn't going to work on a regular device, but I'm in the root directory currently. So, I'm going to go over to system and let's go over to library and we can go to I think it's called frameworks. There we go. And these are all of the associated framework or framework files inside of the system that are necessary for regular execution. So, let's look for one in particular. I'm going to do lsp pipe grip and let's look at webkit I think. So it's just going to be webkit framework. And if you haven't seen my video on grip, make sure you check it out because it is actually an acronym. So I'm going to go over to webkit. framework and let's like take a look at the contents here. This might look familiar to you. We have our info. p list. We have a lot of different associated resource files. But something is mysteriously missing. We're missing that macro binary. You would expect this ARM 64 binary with the real associated executable code that runs when this framework is triggered. But that is missing. So what's happening here? Actually, the code has been parsed out for optimization purposes and placed inside of this kind of mega shared cache that bundles in all of the executable code for all of the different frameworks. So, if you're trying to analyze the executable code part of the system, it really turns into kind of a nightmare and it's not where you expect. Let's talk about a second illusion associated with the iOS system. And this is iOS's heavy reliance on SQLite databases of all things. Yes, you heard me. SQLite databases. They're not just convenient for you and me. Now what happens is most applications and even system services have their own associated SQLite databases. Applications are sandboxed from one another. So they have to have their own personal databases. But what this does is it allows applications to write a ton of data to disk without having to manage thousands of individual tiny files. So

even if you feel like you're storing an additional file in your notes application, what you're really doing is you're adding an additional entry to its SQLite database. If we want to take a look at an example, we can go back over to the Apple wiki and check our mobile notes application. You see we have this mobile notes. app. Thatapp extension should start looking pretty familiar to you now. And you can see there's really only two files inside of this. And the main file is going to be the SQLite file that contains all of the table information for your notes. If you look a little bit lower, it even contains the actual schema for the database itself, which contains a lot of different tables, including the note body, which you can guess is just going to be the real text associated with a particular note. We can even scroll down and see the notebody table inside and it has also an associated schema. Now, we've established that iOS doesn't just have files, but an entire complex hierarchical file system that is completely abstracted from the simple user interface. But I did mention previously that they do have a dedicated files app that is available to users. And you might be thinking that this goes against the grain for the original vow that Apple gave. And this totally does, and Apple fought against it for about a decade. There were pros and cons to the original iPhone design in 2007. Not only were users completely removed from the ability to access files directly, but additionally, applications were sandboxed from each other without any unified location for being able to share files. They eventually came up with some workarounds for sharing files, which basically meant copying files for every different application. meaning that instead of everyone sharing one single unified file, you'd have these bizarre version control problems with the same file in different applications. iCloud attempted to fix some of these issues with a somewhat consolidated file location, but with the advent of the iPad Pro in 2015, which Apple was marketing as a replacement for PCs. Yeah, sure. They really began to see the fundamental limitations of not having this kind of dedicated files app. Which is why with iOS 11 in 2017, Apple finally caved and gave us a native files application that's viewable to users themselves. It also solves a lot of the interoperability problems between Apple devices as well as with third party services. Now, let's take a look at what the real files app looks like on the iPad. So, first of all, let's not go over to the Philza version. Let's more boring looking files app. So this is going to be the files app that is available to the general public. So if you look on your iPhone right now, this is the application that you're going to see. If we go to downloads, you see we actually have a lot of real files inside of this. And you might be thinking, finally, we have the real directory structure of all the folders inside of the iOS device. But that's actually just another illusion. Now the files manager is using guess what? A SQLite database. So it's more just like a generic lookup table inside of that so that we can preserve the sandboxing of the untrusted files for the application. So what it's doing is it's creating this kind of fake directory structure and then if you try to go to an associated file, it's doing a lookup into the SQLite database to find the real location of the actual file. So what do you think? Do you think it was the right decision to abstract away the complicated file system and make it more accessible to the average user? Or do you think it's better to put all of the power in the hands of the user themselves? Leave your opinions in the comments section below. So, as always, thank you so much for watching everyone. Lori wired out.