Paint Me Like One Of Your Firmwares

Hello. Um, I'm going to be, as I say, talking about some iPod stuff. Uh, this is kind of about nine months of research crammed into about 50 odd slides. Um, so we're going to talk a bit about some um, some history of the subjects very briefly and then we're going to talk into uh, basically how I hacked some iPhones that no one has actually yet followed. Um, so we're going to be talking about uh, iPod Nano specifically. Um this is the five and at the point of restarting this uh we had um some wrong bug that called Q3K who does a few other talks um had found which meant we had full kind of control

over this device and could use it as a research uh starting point for our research but we didn't have anything for any of the later devices um these were bit of the book was patched. We didn't know how it was patched or why it was patched, but it didn't work anymore. Um, so I set out after reading the blog post talking about the uh the bug, how I set out to basically solve that problem and see if we could figure out how these devices work. What OS do they run on these iOS? They might be and they're not. Um, do they have any secret features? They do. Um, and did Apple do anything weird? Yes. Um, so we'll start

by talking about some firmware. Um, basically they work very similar to OG iPhones. Um, so image one containers, everything is signed. Basically everything is encrypted. Um, except the actual resources. Um, so things like images, uh, databases, stuff like that. Um but because it's sign we can't modify anything. So these are inaccessible entirely. We can't put any data on it except music pretty much in theory. Um the actual um the actual files start with header that looks like this. Um but the only field that matters here is that they have names. Um, and there's multiple partitions for multiple different modes. There's a recovery mode and a regular mode, which are kind of the two important modes for this. Um, and

weirdly, the signature doesn't include that name for some reason. I mean, you can technically change it. Of course, there's only a few preset options that you can use, but that's weird. Um and when I saw that I started looking into this a bit further to see what um what you could do with that essentially. Um well if we look at how the processor works uh when you press power button it checks are you holding the two volume buttons and if you are it goes into a recovery mode like that but it doesn't check the signature on the resources. This is funny because you should never be able to access any of those resources from that recovery mode.

That recovery mode has its own because it's designed to assume that the rest of the firmware is corrupted and gone completely. Um, except what if we can change that? As I mentioned, we can change the name of partitions. So what if we just swap the recovery mode and the normal mode around? Um if we do that you end up with this thing we call this swapping which is one of the first bugs that I found. This is a real bug. They can't patch it. Um and essentially if you swap those partitions around and pull out the volumes uh it will load with completely unsigned resources. So you can you have a massive attack surface at this point. This was

the first big breakthrough. And when you look at what's in there, there's images, there's databases, there's audio. We had some of this already, so it wasn't really new, but it also has fonts. And fonts are really hard to do correctly. Um, so they probably took somebody else's code. Um, yeah, font formats are infamous for a history of lots of exploitable bugs. Um, so let's look at what the older devices used to get an idea for what they might have done. Well, the N3 apps kind of first one I had access to had a look at all these and these are version three type from 2006 which makes sense because that was probably about when they started working on it.

And then on the number four they didn't bother changing it. Yeah, they've never changed it ever. Um, 206 is really old for this. Um, and there are a lot of really good books, but there is one in particular that's quite interesting. Um because [Music] uh yes there is um this bug is present in that version free 17 uh 97 which basically is a really trivial bug where they don't check when you push uh they don't check when you are doing any operation other than push if you have overflow the stack. Um, so essentially any operation that pushes uh but isn't push will cause corruption. Um, and Fonts and OTF fonts specifically. There's newer versions of this, but this

is the original version has essentially every single character, every string that you render on screen is a program that gets executed and it uses that program to compute all sorts of properties about font, how to characterize, how much space is put between the letters, etc. Um, and it can do normal VM things like control formats, but it can also do kind of graphics focus things as well. Um, these aren't really used anymore. Um, I don't know how work exactly, but they've got away with all this because this is really hard to do correctly. You know, um, and hence why you get books like this. Um there are a load of operations that the operations on this stack um

that aren't the push instruction and these are kind of the three important ones that we care about. We can push around the values. We can swap the current value with the previous value. And we can move down uh essentially just pop. Um and that is all you need to turn this bug into code execution uh on these devices. Uh so to give a walkrough of kind of what we do. Um this is kind of what the stack looks like. Very very simplified. Um, and if we do push, we get a value and we move the sample up. Um, if we push a random value, if we push another value, it goes on top. If we push a random value, uh, then

it uh, ends up out of, at this point onwards can't use any push instructions. So if we want to move values around, we have to find ways to do it without using push. Hence why we push this random value. Um but then we have this exchange operation. This exchange operation is really useful because it means we can move that control value into the outbound slot. Um and if we keep exchanging things, we can actually move things further up. Um if we actually look at what kind of the structure that defines this stack, it looks like that. Um, I've removed a bunch of stuff here. This stuff is huge. Um, but you've got your stack with a fixed size. Um, and then

you've got these zones. And zones are used for defining sub routine calls because apparently you can do a function call in a font. Um, the interesting one here is zone. And zone every single time you run an instruction gets set to the first element in the zones list, the current element. But we never do a function call. So it'll always be the first one. Um and the position is quite important. We'll try and build it'll be relevant later. Um that's got a bit. Um so essentially if you've written out of bounds up until you get to zone um your stack will kind of look a bit like this. which is the kind of messed up uh

slides here. Um if we at this point do an exchange operation, our zone that zones field will get moved down uh and uh overwrite the previous random value first and then our control value will go into the zones field. But because it does this overwriting thing every time we perform an operation, it will actually get set to zones again, which means we have two copies of this controlled this known pointer. This is really useful because of you completely blinding scenario. We don't know what anything looks like on this kind of device. We don't have any debugging. Um so we need to make our exploit for this uh work completely uh blindly and reliably. Um if we keep kind of pushing

we will just move that value anywhere in that structure. Um and as we mentioned there was that billchar at the end. If we move our zone zones zero into there, then we get an interesting primitive because chart is technically supposed to be used for kind of reading array and temporary storage um because fonts apparently need RAM um their own memory. Um but what we can do is turn this into an arbitrary break because if we overrite build and we change the length to something random then we essentially have the ability to hook and peak any memory relative to that zones. So we can move uh we can edit anything after that uh anything after that first element of

the zones field which includes that build chart field. Um which means we can set length to anything we want. send Twitter to anything we want and then we can write our own code anywhere we want. So we can now execute code on these devices. Um sort of the problem is the code is still encrypted so we don't know what any of it looks like. Maybe we can do it. Um, but we don't know how. How do you get anything out of it when you don't know what how to access any of the IO? We don't know how any of the devices work because Apple famously does everything themselves and documents none of it. Um, and yeah, how

does any of this work? Try playing it audio. um and listen to our software, but that is I'm I'm scared of analog and I don't know how audio works. So, um that is not what I do. Um we could do it by just dumping a file doing the trivial option just write it to a file, plug it in and call the file off. We don't have a clue how files work. Um, the storage on these is bizarre. For some reason, when Apple designed the iPod, manual at least, the power chips specifically with the ability to uh have an audio core processor to optimize audio and make it sound good and then didn't use it and then realized they had

this kind of wasted block on their uh on their device and weren't using it for anything. Um, so he came up with a really smart idea of putting the file system driver in the audio chip. Um, so you play sound to write files and the audio chip was random Samsung chip that has no documentation ever and never was used in anything else. So we are still trying to figure out how flash works. Maybe we'll eventually figure it out. It will be useful if any other OS on it. So if anybody wants to help um there'll be links to download this one there. Um the other option is we could do USB. USB is hard to do generally but we might

be able to abuse some of the parts of the USB. Um specifically when you plug a new USB device in it basically sends some identifying strings, manufacturer, product name, etc. and and those strings probably appear somewhere in our firmware. We can try and find them. If we can, then we can copy bits of our bits of FM and try and print them out very slowly. The problem is we have to find those strings first and we still don't have way to get any info out of these devices. Um, so what we can do is crash the device a lot. I'm really good at doing this. after a lot of trial and error. Um, so it turns out if you jump to someone

invalid memory, it will reboot. Um, or if you put it in a while loop, it will hang forever. So we can actually use that to leak one bit of data of whether or not our device is essentially has a value within a certain range. for example. Um, so we can use binary search to search through the entire RAM of the device looking for the string apple and hope that that's the one that it prints when plugging in over USB. Turns out it is. Um, so if we find it, we crash. Uh, if we don't find it, we can. Um, and that is essentially how we can do single bits. we can slowly narrow our range down until we eventually uh

know where our magic string is. This takes a long time and it has a really slow data. >> Um, for what it's worth, that would take I think it's 300 years to leak the whole firmware. I'm not likely to be alive in 300 years, so that's not really going to work. But now that we've got the string, we can just print out our data. So, we essentially just write some code uh essentially just find somewhere where it will run and um keep unplugging and replplugging the device in and have it very slowly move the data that it's copying. So, we can very slowly get bits of firmware out. Um, and I left this running for about 8 hours. Turns out for

some reason it reboots after about 8 hours. So, you have to restart it. And I think that's a bug USB stuff, but I actually have no clue. Um, and if you leave that for long enough, you uh eventually get your firmware. That is an example of what it looked like when I was doing my testing. Just overwrite that string with a to print what is next to it. hoping that what was next to it is the code for actually copying that over USB. Um, so now we just found some USB code. We've got our own back door essentially, so we can go read this or log of memory. Um and skip over a couple of steps. Um, we can

actually get the ROM. So this was the first public dump of the 96 ROM. Uh, first dump of a S5 or whatever that number is. Um, and we can also see how they patched the wrong bug. Um, which seems to be somebody just came into came into the USB code one day and randomly added an if that wasn't there before. Um, the Nano 7 is almost the same, but the problem is they changed the USB port. Um, and they've changed it from the fact the pin connector that some of you might call to lightning. And lightning requires a lot more setup to actually get it to work. And it really did not like being unplugged and replugged. Um,

so I had to find another way to get data out again. So we couldn't go back to the drawing mode. We could try looking files. We could try looking at sound. Uh they did this on Bluetooth for Bluetooth. Um the way they did Bluetooth is bizarre. They essentially brought up user space sort of emulator for iOS and then copied the iOS Bluetooth stack. Um pretending that it was an iPhone. Um but we also have a screen. Um and the nice thing about screen is if you know where the place it reads the pixels from. um which I just assumed they hadn't changed. Absolutely hasn't. You can write whatever you want. Um so if I um if I want to do it,

all I need to do is write my own GPU driver assembly. Uh step one. Thankfully, there's actually an example of um how to initialize some of this that was figured out when people put Linux on the older iPods. Um so, I had a bit to go off, but yeah, trying to um try to write this took a lot of trial and error. Um and then if we take every kind of if you take two bits of data, you can map them into four characters um by just making a lookup table. So I actually use that pocket table because you can type it with one hand um which is really useful because you slowly can print the data onto the screen um and

then retype it [Music] um which looks like that indefinitely. Um, and essentially this is sort of start from I start from a known string. I basically went through every instance of Apple Inc. in somewhere and typed out what was after it. Looked if it looked like the right code and manually calculated every branch following through slowly dumping out bits functions. So eventually I found the same USB code that I found in six. Um, and with that I could basically repeat the steps and get the first boot run for the 8740 as well. Um, so these were at the time the first and only way to jailbreak um, iPod 96 and 7. Uh, but these actually came on since then. Um,

that is that was the state at the end. Um so that is kind of where I uh essentially took a break but there were actually some kind of things that happened after. Um so super diag is essentially none of this was necessary um if I had have spent some time and actually looked at all of the possible vectors before going through the first one that I found cuz that's a good kind of thing to take from this talk is survey everything uh before just diving into the first kind of book you find or technique that you find. Um, essentially the debug menu uh exists very by some key combination on every iPod, but to get to it, you need to

access it via serial. There is no driver for serial. Um, but they left the console in which has the ability to read and write all of the memory of the device. Uh, set break points, etc. GB almost. Um but as I say there's no driver except the actual way these uh images are packed means you can take modules from other binary take modules from other firmware partitions and put them into the diag partition. Um, and they actually shipped all of the required ones in the uh in the main firmware and in the tool that flashes the firmware which is called WTF. Where's the firmware? Uh, so if you pack that all together, you essentially can make a uh a fully

debugable iPod without having to do any exploitation at all. So someone someone figured this out and had this popped up in about 2 hours and replaced 9 months of work. Um and it's more reliable. You don't have to hold buttons. Um also um actually going over surface that other people have said before I've looked at. Um, so the book wrong after having the book, the original book was patched, um, I decided it wasn't worth spending any time looking at in detail. It would have been researched to death. Um, it mustn't have anything in it. Fairly wrong. Uh, so Espir is a book by uh, someone called G. Um, that's probably a butchered pronunciation. um which essentially is when you upload

firmware um you send it um over USB a ball of data and it copies that to a global variable. Um there's no size limit on the firmware you can send because they didn't want to put a any restrictions on it. They also don't prevent you from going off the end of RAM which loops back around again. So if you just send it a 100meg file, uh it allows you to overwrite all of the code from the boot ROM as well. Um if I had have looked at uh loaded the boot, then I might have might have found that. Um and that's really nice because you can uh get code execution essentially from the earliest possible

point. Um, which is really nice if you want to do things that put Linux on it. This is pretty recent. Um, so this is a game she's working on a court with Linux. So eventually there might be a full Linux dro that you can run on an iPod which I think is funny. Um, that is pretty much everything. Um, um, but join our Discord. uh QR code and then the other QR code link to the GitHub so you can get uh all of the all the code. Um, thanks to me for actually letting me give a talk. Thanks to me for finding the original. Thanks to MJ Walsh who work who worked at Apple in

about 2006 um and didn't ever update free type essentially. I would have never been able to do any of this. And I was listening.

>> When you print out the device, were you thinking of using any like doing it by hand? >> So I I did end up doing it by hand. Um, but I did speak to somebody and they said it would have been really funny if I had have printed the whole thing. Um, and did some OpenCV magic with a webcam to actually read it out and it would definitely be doable and if I had to do any more than the small amount that I did, um, then I would probably look at ways to mean ways to do that. So even if I hadn't been able to kind of get the other techniques working, then that's how I could have done it. And I will do

that really quickly. Um, so if anybody has any other questions. >> So firstly, I feel I was interested in you mentioned how you did that.

Um so essentially the uh the USB stack has um has a bunch of vendor commands. Um so you can send these kind of um a command there's a command line tool called like gaz something um which allows you to essentially send raw byes as a vendor command and you can use that to implement extra functionality and Apple uses this internally a lot for iTunes um so things like syncing um send special vendor commands to put the device into certain modes and there's ones to reboot the device there's one to wipe the device as I found uh Um, and I took one of those kind of branches in that code and replaced it with a tiny chocolate

stone that um would take an address, read that give me that value back. Um, and I kind of just guessed what functions did around that. Um, so yeah,

I lost my slides. Oh, no. Anybody else? Well, if that's everything then. Thank you.