[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:11.73,Default,,0000,0000,0000,,{\i1}rC3 opening music{\i0}
Dialogue: 0,0:00:12.67,0:00:17.07,Default,,0000,0000,0000,,Jiska: Hello everyone and welcome to my\Ntalk, Fuzzing the phone in the iPhone. The
Dialogue: 0,0:00:17.07,0:00:22.27,Default,,0000,0000,0000,,phone in the iPhone is the component that\Nreceives SMS, sends SMS, receives phone
Dialogue: 0,0:00:22.27,0:00:26.93,Default,,0000,0000,0000,,calls, makes phone calls and also manages\Nyour Internet connection when you are not
Dialogue: 0,0:00:26.93,0:00:33.25,Default,,0000,0000,0000,,on Wi-Fi. However, you might now wonder,\Nwhat is it exactly? So I'm talking about
Dialogue: 0,0:00:33.25,0:00:39.51,Default,,0000,0000,0000,,CommC enter and fuzzing it via the QMI and\NARI interfaces. But this is a bit too
Dialogue: 0,0:00:39.51,0:00:44.35,Default,,0000,0000,0000,,technical for most of you. So I will first\Nintroduce you to the concept of fuzzing in
Dialogue: 0,0:00:44.35,0:00:50.42,Default,,0000,0000,0000,,general and protocol fuzzing before I dive\Ninto further details. For those of you
Dialogue: 0,0:00:50.42,0:00:54.89,Default,,0000,0000,0000,,have not yet heard about the concept of\Nfuzzing - you can send a lot of random
Dialogue: 0,0:00:54.89,0:01:00.33,Default,,0000,0000,0000,,messages and then try to test the security\Nof an interface with this. And in this
Dialogue: 0,0:01:00.33,0:01:07.15,Default,,0000,0000,0000,,video, you can see how I send SMS over a\NFrida-based fuzzer with something like 400
Dialogue: 0,0:01:07.15,0:01:12.14,Default,,0000,0000,0000,,fuzzcases per second. And then the IMH\Nreceives them, catches them and sends a
Dialogue: 0,0:01:12.14,0:01:18.90,Default,,0000,0000,0000,,couple of them also to the smartphone.\NLet's start with a motivation and an
Dialogue: 0,0:01:18.90,0:01:24.08,Default,,0000,0000,0000,,explanation to the attacker model. So, if\Nyou look into a modern smartphone, you
Dialogue: 0,0:01:24.08,0:01:28.68,Default,,0000,0000,0000,,have two components if you want to show it\Nin a simple way. So first of all, there's
Dialogue: 0,0:01:28.68,0:01:34.03,Default,,0000,0000,0000,,the hardware part with a lot of chips. And\Nthen on top of this, there is an operating
Dialogue: 0,0:01:34.03,0:01:39.59,Default,,0000,0000,0000,,system and applications. However, it's not\Nas simple as this because even those chips
Dialogue: 0,0:01:39.59,0:01:44.99,Default,,0000,0000,0000,,are so complex that they run their own\Nlittle real-time operating systems to
Dialogue: 0,0:01:44.99,0:01:51.19,Default,,0000,0000,0000,,preprocess data. So this means that you\Ncan even get code execution on such a
Dialogue: 0,0:01:51.19,0:01:55.56,Default,,0000,0000,0000,,chip. And this is usually much easier than\Nin the operating system itself, because
Dialogue: 0,0:01:55.56,0:02:05.94,Default,,0000,0000,0000,,those chips cannot have that many\Nmitigations. However, so what do you even
Dialogue: 0,0:02:05.94,0:02:11.40,Default,,0000,0000,0000,,do if you have code execution in such a\Nchip, so if you are in a baseband chip,
Dialogue: 0,0:02:11.40,0:02:16.42,Default,,0000,0000,0000,,then one escalation strategy from the chip\Ntowards the operating system might be to
Dialogue: 0,0:02:16.42,0:02:20.90,Default,,0000,0000,0000,,manipulate traffic in the browser.\NHowever, I don't think that this is the
Dialogue: 0,0:02:20.90,0:02:26.67,Default,,0000,0000,0000,,case, because if you look at the Zerodium\Nprice list, then actually the browser
Dialogue: 0,0:02:26.67,0:02:32.28,Default,,0000,0000,0000,,exploits are much more expensive. So it's\Nprobably not done like this. And there
Dialogue: 0,0:02:32.28,0:02:40.02,Default,,0000,0000,0000,,must be other ways to escalate from this\Nchip into the operating system. In
Dialogue: 0,0:02:40.02,0:02:44.83,Default,,0000,0000,0000,,general, the traffic manipulation is\Nsomething that you can always do in
Dialogue: 0,0:02:44.83,0:02:50.25,Default,,0000,0000,0000,,wireless transmission or also on the\NInternet. So if you look how those systems
Dialogue: 0,0:02:50.25,0:02:54.13,Default,,0000,0000,0000,,work these days, so you have something\Nlike the Internet in general that serve
Dialogue: 0,0:02:54.13,0:02:58.80,Default,,0000,0000,0000,,websites and so on, and also the core\Nnetwork of your mobile provider. And there
Dialogue: 0,0:02:58.80,0:03:05.37,Default,,0000,0000,0000,,are many, many ways to manipulate traffic,\Neither if you are a state level actor who
Dialogue: 0,0:03:05.37,0:03:11.80,Default,,0000,0000,0000,,is able to have something in the core\Nnetwork or just by sending around websites
Dialogue: 0,0:03:11.80,0:03:19.47,Default,,0000,0000,0000,,or modifying websites. And then there is\Nthe base station subsystem, there might
Dialogue: 0,0:03:19.47,0:03:25.02,Default,,0000,0000,0000,,also be dragons. We don't know exactly.\NAnd of course, there are over-the-air
Dialogue: 0,0:03:25.02,0:03:29.52,Default,,0000,0000,0000,,transmissions and wireless transmissions\Nare very special because, if there is
Dialogue: 0,0:03:29.52,0:03:33.80,Default,,0000,0000,0000,,something just slightly broken in the\Nencryption, for example, then it's also
Dialogue: 0,0:03:33.80,0:03:39.26,Default,,0000,0000,0000,,possible to manipulate traffic there, if\Nyou have a software defined radio, for
Dialogue: 0,0:03:39.26,0:03:44.54,Default,,0000,0000,0000,,example. So all of this could be attacked\Nto manipulate traffic. And I don't think
Dialogue: 0,0:03:44.54,0:03:53.05,Default,,0000,0000,0000,,that for this, one would craft a baseband\Nexploit. Already in 2014 at the CCC, there
Dialogue: 0,0:03:53.05,0:04:00.14,Default,,0000,0000,0000,,have been two talks about a SS7 protocol\Nwhich is run in the core network and is
Dialogue: 0,0:04:00.14,0:04:05.37,Default,,0000,0000,0000,,actually meant to connect different\Nmobile carriers to each other. And this
Dialogue: 0,0:04:05.37,0:04:09.98,Default,,0000,0000,0000,,can also be used to intercept phone calls,\Nfor example. And this also has been
Dialogue: 0,0:04:09.98,0:04:15.59,Default,,0000,0000,0000,,exploited recently. So even though, there\Nhave been some mitigations, etc. since
Dialogue: 0,0:04:15.59,0:04:23.23,Default,,0000,0000,0000,,then, it's still exploited for the same\Npurpose to spy on people. So really,
Dialogue: 0,0:04:23.23,0:04:28.25,Default,,0000,0000,0000,,really, really, basement exploits only\Nexists to escalate from the chip into the
Dialogue: 0,0:04:28.25,0:04:37.79,Default,,0000,0000,0000,,operating system. But now the question is,\Nwhat are the strategies? So if it's not
Dialogue: 0,0:04:37.79,0:04:43.46,Default,,0000,0000,0000,,via the browser, what else could it be? So\Nthe browser really I'm sure it is not,
Dialogue: 0,0:04:43.46,0:04:47.41,Default,,0000,0000,0000,,because also you need to have some\Ntraffic and so on, it doesn't really work
Dialogue: 0,0:04:47.41,0:04:51.94,Default,,0000,0000,0000,,instantly, you need to visit the website\Nto replace traffic on a website and so on.
Dialogue: 0,0:04:51.94,0:04:57.02,Default,,0000,0000,0000,,There must be something else. So\Nif you are on the chip with remote code
Dialogue: 0,0:04:57.02,0:05:01.55,Default,,0000,0000,0000,,execution and want to go into the\Noperating system, there is some interface.
Dialogue: 0,0:05:01.55,0:05:06.19,Default,,0000,0000,0000,,And this means that something in those\Ninterfaces needs to be exploitable, so
Dialogue: 0,0:05:06.19,0:05:15.40,Default,,0000,0000,0000,,that you can escalate the privileges from\Nthe chip into the system. And also, those
Dialogue: 0,0:05:15.40,0:05:19.23,Default,,0000,0000,0000,,interfaces are very interesting from a\Nreverse engineer's perspective. So even if
Dialogue: 0,0:05:19.23,0:05:24.56,Default,,0000,0000,0000,,you don't want to attack anything, just\Nunderstanding how they work, is also a
Dialogue: 0,0:05:24.56,0:05:30.00,Default,,0000,0000,0000,,goal of this work. So, for example, if you\Nhave a baseband debug profile, you can
Dialogue: 0,0:05:30.00,0:05:33.60,Default,,0000,0000,0000,,just download it onto your iPhone and then\Nyou open your iDevice syslog, you can
Dialogue: 0,0:05:33.60,0:05:38.85,Default,,0000,0000,0000,,already see a lot of management messages\Nthat are exchanged between the chip and
Dialogue: 0,0:05:38.85,0:05:45.13,Default,,0000,0000,0000,,the iPhone. And if you have a jailbreak\Nand Frida, you can even inject packets or
Dialogue: 0,0:05:45.13,0:05:52.81,Default,,0000,0000,0000,,modify packets to change the behaviour of\Nyour modem.But if you want to start to
Dialogue: 0,0:05:52.81,0:05:59.34,Default,,0000,0000,0000,,work on such a thing, the question is\Nlike, how do you even start? Where do you
Dialogue: 0,0:05:59.34,0:06:03.37,Default,,0000,0000,0000,,start? And fuzzing is actually a method\Nthat can be used to understand such an
Dialogue: 0,0:06:03.37,0:06:08.39,Default,,0000,0000,0000,,interface. So initially, if you identified\Nan interface, just to check if it is the
Dialogue: 0,0:06:08.39,0:06:13.11,Default,,0000,0000,0000,,correct interface, so, if it really\Nchanges behaviour, if you flip some bytes,
Dialogue: 0,0:06:13.11,0:06:17.20,Default,,0000,0000,0000,,but also how powerful this interface is.\NSo what are the features? What breaks
Dialogue: 0,0:06:17.20,0:06:23.42,Default,,0000,0000,0000,,instantly? And if things break, also you\Ncan check if the whole interface has been
Dialogue: 0,0:06:23.42,0:06:29.30,Default,,0000,0000,0000,,designed with security in mind. Now, let's\Nstart with an introduction to wireless
Dialogue: 0,0:06:29.30,0:06:34.23,Default,,0000,0000,0000,,protocol fuzzing, this will also be a\Nshort rant because the current tooling for
Dialogue: 0,0:06:34.23,0:06:39.96,Default,,0000,0000,0000,,fuzzing is usually not made to fuzz a\Nprotocol. So let's start with a very
Dialogue: 0,0:06:39.96,0:06:44.46,Default,,0000,0000,0000,,simple fuzzer, a fuzzer that is just an\Nimage parser. So, you browse your
Dialogue: 0,0:06:44.46,0:06:49.62,Default,,0000,0000,0000,,smartphone for unicorn pictures or PNGs or\NJPEGs, and then you send them to the image
Dialogue: 0,0:06:49.62,0:06:54.37,Default,,0000,0000,0000,,parser and in the image parser you might\Nbe able to observe which functions are
Dialogue: 0,0:06:54.37,0:07:00.79,Default,,0000,0000,0000,,executed in the form of basic blocks. And\Nthen, during this initialization, the
Dialogue: 0,0:07:00.79,0:07:05.40,Default,,0000,0000,0000,,image parser can even report which parts\Nwere executed and you can just go to image
Dialogue: 0,0:07:05.40,0:07:12.32,Default,,0000,0000,0000,,again and again with different images and\Nget this basic block coverage back. In a
Dialogue: 0,0:07:12.32,0:07:18.64,Default,,0000,0000,0000,,next step, you can then combine existing\Nimages or flip bits in these images and
Dialogue: 0,0:07:18.64,0:07:23.52,Default,,0000,0000,0000,,send them to the image parser and again\Nobserve the coverage, most of the time, it
Dialogue: 0,0:07:23.52,0:07:28.45,Default,,0000,0000,0000,,won't generate any new coverage. So you\Njust say you are not looking into this
Dialogue: 0,0:07:28.45,0:07:33.55,Default,,0000,0000,0000,,image in particular, but sometimes you\Nmight get new coverage, like here, and
Dialogue: 0,0:07:33.55,0:07:38.59,Default,,0000,0000,0000,,then you add this image to your corpus. So\Nover time, you can increase your corpus
Dialogue: 0,0:07:38.59,0:07:46.94,Default,,0000,0000,0000,,and increase your coverage. Another method\Ncan be, if you know how exactly an image
Dialogue: 0,0:07:46.94,0:07:52.22,Default,,0000,0000,0000,,format looks like, so you might know the\NJPEG specification and because of this,
Dialogue: 0,0:07:52.22,0:07:56.98,Default,,0000,0000,0000,,you could just generate images that are\Nmore or less specification compliant and
Dialogue: 0,0:07:56.98,0:08:02.25,Default,,0000,0000,0000,,they look more artificial like this. So\Nyou just generate images and send them to
Dialogue: 0,0:08:02.25,0:08:06.82,Default,,0000,0000,0000,,the image parser and at some point you\Nmight observe a crash. So that also
Dialogue: 0,0:08:06.82,0:08:10.00,Default,,0000,0000,0000,,depends, again, on your harnessing. Maybe\Nyou can observe basic blocks, maybe you
Dialogue: 0,0:08:10.00,0:08:18.62,Default,,0000,0000,0000,,can just observe crashes and then you know\Nat which image you had a crash. You might
Dialogue: 0,0:08:18.62,0:08:22.42,Default,,0000,0000,0000,,even be able to combine these two\Napproaches just depending on what you know
Dialogue: 0,0:08:22.42,0:08:29.27,Default,,0000,0000,0000,,about your input and how you can harness\Nyour target. Now it looks a bit different
Dialogue: 0,0:08:29.27,0:08:35.15,Default,,0000,0000,0000,,for a protocol. So, in a protocol, you can\Nhave a very complex state. Let's say you
Dialogue: 0,0:08:35.15,0:08:41.26,Default,,0000,0000,0000,,are in an active phone call or just\Nsomething like, you receive an SMS. You
Dialogue: 0,0:08:41.26,0:08:45.62,Default,,0000,0000,0000,,can actually force the iPhone to receive\NSMS, if you have a second iPhone and send
Dialogue: 0,0:08:45.62,0:08:54.30,Default,,0000,0000,0000,,SMS. And then during the fuzzing, you can\Nreplace some bits and bytes, like this and
Dialogue: 0,0:08:54.30,0:08:58.93,Default,,0000,0000,0000,,then you would have a modification. So\Nthis is a very simple approach and it
Dialogue: 0,0:08:58.93,0:09:02.97,Default,,0000,0000,0000,,preserves the state. So no matter how\Ncomplex the thing is, that you're
Dialogue: 0,0:09:02.97,0:09:07.04,Default,,0000,0000,0000,,currently doing, it's very simple to flip\Na bit here and there in an active
Dialogue: 0,0:09:07.04,0:09:12.61,Default,,0000,0000,0000,,interaction. But it's also a bit annoying,\Nbecause you need to have these active
Dialogue: 0,0:09:12.61,0:09:20.06,Default,,0000,0000,0000,,phone calls, etc. So something that's more\Nefficient is injection. So you would
Dialogue: 0,0:09:20.06,0:09:24.98,Default,,0000,0000,0000,,observe certain messages and then just send\Nthem again - and then you don't even need
Dialogue: 0,0:09:24.98,0:09:29.96,Default,,0000,0000,0000,,the second phone to make calls, etc., -\Nyou can just send a lot, a lot, a lot of
Dialogue: 0,0:09:29.96,0:09:34.42,Default,,0000,0000,0000,,data. And this is the effect, when your\NiPhone goes di-di-di-di-dimm or something
Dialogue: 0,0:09:34.42,0:09:39.54,Default,,0000,0000,0000,,because of all the notifications and all\Nthe data that is sent. But issue here is,
Dialogue: 0,0:09:39.54,0:09:44.08,Default,,0000,0000,0000,,that this does not preserve state. So\Nthere might be actions where the iPhone
Dialogue: 0,0:09:44.08,0:09:49.74,Default,,0000,0000,0000,,requests something that is then answered.\NSo, the iPhone might request, for example,
Dialogue: 0,0:09:49.74,0:09:54.70,Default,,0000,0000,0000,,a date and only then the chip would reply\Nwith a date and only then the iPhone would
Dialogue: 0,0:09:54.70,0:10:00.42,Default,,0000,0000,0000,,accept a date. But it's still very\Ninteresting to do this. So even though you
Dialogue: 0,0:10:00.42,0:10:03.42,Default,,0000,0000,0000,,cannot reach certain states because you\Ncan do this without a SIM card and you can
Dialogue: 0,0:10:03.42,0:10:09.90,Default,,0000,0000,0000,,do this very, very fast. So, just to\Nsummarize the issues here: if you fuzz the
Dialogue: 0,0:10:09.90,0:10:13.67,Default,,0000,0000,0000,,wireless protocol, you can have very\Nsignificant state differences and just
Dialogue: 0,0:10:13.67,0:10:21.74,Default,,0000,0000,0000,,injecting packets cannot reach all\Nstates. The fact, that you cannot reach
Dialogue: 0,0:10:21.74,0:10:26.90,Default,,0000,0000,0000,,all states also shows in very simple stuff\Nlike a trace replay. So a trace of
Dialogue: 0,0:10:26.90,0:10:30.50,Default,,0000,0000,0000,,something that you record. So let's say I\Nhave an active phone call, I record all
Dialogue: 0,0:10:30.50,0:10:35.11,Default,,0000,0000,0000,,the packets, and I can also observe the\Ncoverage. So , with Frida, you can observe
Dialogue: 0,0:10:35.11,0:10:42.08,Default,,0000,0000,0000,,coverage on an iPhone while the phone call\Nis active. And then, in a second step, you
Dialogue: 0,0:10:42.08,0:10:45.100,Default,,0000,0000,0000,,would do some injection. But the only\Nthing that you can inject are the packets
Dialogue: 0,0:10:45.100,0:10:51.33,Default,,0000,0000,0000,,sent from the basement to the smartphone,\Nnot the opposite direction. And this
Dialogue: 0,0:10:51.33,0:10:56.01,Default,,0000,0000,0000,,results usually in much less coverage. So\Nyou are missing a lot of things due to a
Dialogue: 0,0:10:56.01,0:11:00.33,Default,,0000,0000,0000,,missing state. And even worse, if you do\Nthe same thing again, you might be in a
Dialogue: 0,0:11:00.33,0:11:04.60,Default,,0000,0000,0000,,different state, and you might observe a\Ndifferent coverage. So you do the exact
Dialogue: 0,0:11:04.60,0:11:13.91,Default,,0000,0000,0000,,same thing, but you get different\Ncoverage.So, even replaying recorded
Dialogue: 0,0:11:13.91,0:11:22.21,Default,,0000,0000,0000,,messages results in less or inconsistent\Ncoverage. Anyway, let's take a look into
Dialogue: 0,0:11:22.21,0:11:29.15,Default,,0000,0000,0000,,an injection example. So, in this video,\Nyou can see how I'm in the Unicorn Network
Dialogue: 0,0:11:29.15,0:11:35.15,Default,,0000,0000,0000,,on an iPhone 8, which has obviously 5G,\Nbut also does a lot of fuzzing and in the
Dialogue: 0,0:11:35.15,0:11:40.85,Default,,0000,0000,0000,,fuzzing, what is interesting is, that you\Nmight do a lot of states in a combination
Dialogue: 0,0:11:40.85,0:11:45.37,Default,,0000,0000,0000,,that are not usually possible, like you\Nhave a lost network connection while you
Dialogue: 0,0:11:45.37,0:11:51.69,Default,,0000,0000,0000,,have to confirm a pin or you have a\Nnetwork connection during this, etc. To
Dialogue: 0,0:11:51.69,0:11:56.23,Default,,0000,0000,0000,,summarize my rant, some states cannot be\Nreached solely by injecting packets. So,
Dialogue: 0,0:11:56.23,0:12:02.25,Default,,0000,0000,0000,,even if we have a very good corpus and do\Nvery good mutations, we might miss
Dialogue: 0,0:12:02.25,0:12:08.06,Default,,0000,0000,0000,,80% of the code, but we can just fuzz\Nanyway. But we need to keep in mind, that
Dialogue: 0,0:12:08.06,0:12:13.62,Default,,0000,0000,0000,,some stuff is just not fuzzable. We looked\Ninto a lot of wireless protocols and have
Dialogue: 0,0:12:13.62,0:12:18.53,Default,,0000,0000,0000,,seen more in the past, so, it's worth to\Nalso consider, which tooling we already
Dialogue: 0,0:12:18.53,0:12:24.22,Default,,0000,0000,0000,,had available for fuzzing protocols. The\Nmost advanced tooling, that we have, is
Dialogue: 0,0:12:24.22,0:12:28.93,Default,,0000,0000,0000,,Frankenstein and it's built by Jan. So,\Nwhat Jan did is, he emulated the firmware
Dialogue: 0,0:12:28.93,0:12:34.49,Default,,0000,0000,0000,,and attached it to a virtual modem and\Nalso a Linux host. For this, he first
Dialogue: 0,0:12:34.49,0:12:40.02,Default,,0000,0000,0000,,looked into the firmware, that's here, and\Nwe had some partial symbols for this and
Dialogue: 0,0:12:40.02,0:12:47.05,Default,,0000,0000,0000,,also some information about registers.\NThen, Frankenstein is actually taking a
Dialogue: 0,0:12:47.05,0:12:53.56,Default,,0000,0000,0000,,snapshot, that you can see here, including\Nsome of those registers of the modem. And
Dialogue: 0,0:12:53.56,0:12:57.47,Default,,0000,0000,0000,,with this, you can build a virtual modem\Nand fuzz input as if it would come over
Dialogue: 0,0:12:57.47,0:13:02.89,Default,,0000,0000,0000,,the air. Then Frankenstein also emulates\Nthe whole firmware, including thread
Dialogue: 0,0:13:02.89,0:13:08.14,Default,,0000,0000,0000,,switches. So it gets into very complex\Nstates and it's even attached to a Linux
Dialogue: 0,0:13:08.14,0:13:15.14,Default,,0000,0000,0000,,host. So, it also fuzzes a bit of Linux\Nwhile actually fuzzing the firmware
Dialogue: 0,0:13:15.14,0:13:21.60,Default,,0000,0000,0000,,itself. Now, the issue with this is that\Nbasement firmware is usually 10 times the
Dialogue: 0,0:13:21.60,0:13:27.67,Default,,0000,0000,0000,,size of bluetooth firmware or even more,\Nand we don't have any symbols for this, so
Dialogue: 0,0:13:27.67,0:13:34.01,Default,,0000,0000,0000,,it's a lot of work to customize this. And\Neven if, one would do all those steps and
Dialogue: 0,0:13:34.01,0:13:40.58,Default,,0000,0000,0000,,put all the work into this, it's only, so\Nto say, code execution in the baseband.
Dialogue: 0,0:13:40.58,0:13:47.59,Default,,0000,0000,0000,,It's not yet a privilege escalation into\Nthe operating system. The next interesting
Dialogue: 0,0:13:47.59,0:13:52.44,Default,,0000,0000,0000,,tooling was built by Steffen and what\NSteffen did, he built a fuzzer based on
Dialogue: 0,0:13:52.44,0:13:57.72,Default,,0000,0000,0000,,DTrace and AFL. DTrace is a tool that can\Nprovide functional level coverage in the
Dialogue: 0,0:13:57.72,0:14:03.43,Default,,0000,0000,0000,,macOS kernel and user space. With some\Nmodifications you can even get basic
Dialogue: 0,0:14:03.43,0:14:08.52,Default,,0000,0000,0000,,block coverage in the user space, which is\Nrequired for AFL to work. So, in the end,
Dialogue: 0,0:14:08.52,0:14:16.07,Default,,0000,0000,0000,,you have AFL or AFL++ as a fuzzer on any\Nprogram on macOS. It's even slightly
Dialogue: 0,0:14:16.07,0:14:20.90,Default,,0000,0000,0000,,faster than Frida, at least the version\Nthat he used. And he gets a couple of
Dialogue: 0,0:14:20.90,0:14:27.29,Default,,0000,0000,0000,,thousand fuzz cases per second, even on a\Nvery old iMac. So, in our lab, we just had
Dialogue: 0,0:14:27.29,0:14:33.100,Default,,0000,0000,0000,,an old iMac 2012 for this and it works on\Nthis. But the issue is, that Wi-Fi and
Dialogue: 0,0:14:33.100,0:14:39.87,Default,,0000,0000,0000,,Bluetooth, which he fuzzed, are very complex\Nprotocols, so he couldn't find any new
Dialogue: 0,0:14:39.87,0:14:45.94,Default,,0000,0000,0000,,bugs with AFL. And also, in the kernel\Nspace, you only get this function level
Dialogue: 0,0:14:45.94,0:14:55.18,Default,,0000,0000,0000,,coverage. He still, despite not finding\Nany bugs in Wi-Fi or Bluetooth, got a CVE,
Dialogue: 0,0:14:55.18,0:15:03.05,Default,,0000,0000,0000,,because DTrace also has bugs. So, at least\Nsome funding, but on iOS, this is not
Dialogue: 0,0:15:03.05,0:15:07.52,Default,,0000,0000,0000,,supported out of the box. So it might be\Npossible to get DTrace working with some
Dialogue: 0,0:15:07.52,0:15:12.28,Default,,0000,0000,0000,,tweaks, but it's a lot of work. So\Nprobably it's easier to just use Frida in
Dialogue: 0,0:15:12.28,0:15:21.39,Default,,0000,0000,0000,,the iOS user space. Also during this, so\Nwhile Steffen was building all this very
Dialogue: 0,0:15:21.39,0:15:28.30,Default,,0000,0000,0000,,advanced tooling, Wang Yu found issues in\Nthe macOS Bluetooth and Wi-Fi drivers, and
Dialogue: 0,0:15:28.30,0:15:35.48,Default,,0000,0000,0000,,so he was very, very successful in\Ncomparison to us. That's really a pity.
Dialogue: 0,0:15:35.48,0:15:41.98,Default,,0000,0000,0000,,And I think, what he did, is much better\Nstate modelling, so, of how the messages
Dialogue: 0,0:15:41.98,0:15:51.72,Default,,0000,0000,0000,,interact and what is important to reach\Ncertain functions. So what is still left?
Dialogue: 0,0:15:51.72,0:15:57.90,Default,,0000,0000,0000,,So, usually fuzzing the baseband means\Nthat you need to modify firmware or also
Dialogue: 0,0:15:57.90,0:16:02.60,Default,,0000,0000,0000,,emulate firmware, you need to implement\Nvery complex specifications on a software
Dialogue: 0,0:16:02.60,0:16:07.80,Default,,0000,0000,0000,,defined radio if you want to fuzz over the\Nair or build proof of concepts. And for
Dialogue: 0,0:16:07.80,0:16:10.82,Default,,0000,0000,0000,,everything that's somewhat proprietary,\Nyou need to do protocol reverse
Dialogue: 0,0:16:10.82,0:16:17.88,Default,,0000,0000,0000,,engineering, so you can spend a lot of\Ntime and money just to do very, very basic
Dialogue: 0,0:16:17.88,0:16:24.75,Default,,0000,0000,0000,,research. Or, you can also use Frida, so\Nyou can fuzz with Frida and all you need
Dialogue: 0,0:16:24.75,0:16:30.84,Default,,0000,0000,0000,,to do for this is, write a few lines of\Ncode in JavaScript. So I kid you not. The
Dialogue: 0,0:16:30.84,0:16:37.80,Default,,0000,0000,0000,,option is Frida. Dennis was the first in\Nour team who was advised as a thesis
Dialogue: 0,0:16:37.80,0:16:43.05,Default,,0000,0000,0000,,student who built a Frida-based fuzzer,\Nand it's called ToothPicker. It's based on
Dialogue: 0,0:16:43.05,0:16:51.13,Default,,0000,0000,0000,,Frizzer and Radamsa. So what it does is,\Nwell, it hooks into these connections or
Dialogue: 0,0:16:51.13,0:16:57.15,Default,,0000,0000,0000,,into the protocols of the bluetooth\Ndaemon, you could also think of this upper
Dialogue: 0,0:16:57.15,0:17:01.50,Default,,0000,0000,0000,,part here, as one block. So the protocols\Nare implemented in the Bluetooth daemon,
Dialogue: 0,0:17:01.50,0:17:08.05,Default,,0000,0000,0000,,but we want to fuzz certain protocol\Nhandlers. And to increase the coverage, he
Dialogue: 0,0:17:08.05,0:17:13.43,Default,,0000,0000,0000,,creates a virtual connection. So a virtual\Nconnection holds a connection and pretends
Dialogue: 0,0:17:13.43,0:17:18.36,Default,,0000,0000,0000,,to the Bluetooth daemon that there would\Nbe an active connection to a device. And
Dialogue: 0,0:17:18.36,0:17:21.41,Default,,0000,0000,0000,,of course, the chip would then say, I\Ndon't know anything about this connection.
Dialogue: 0,0:17:21.41,0:17:26.00,Default,,0000,0000,0000,,So, there are also some abstractions in\Nhere, so that the connection is not
Dialogue: 0,0:17:26.00,0:17:34.07,Default,,0000,0000,0000,,terminated. So, that's a very simple tool,\Nbut it really found a lot of bugs and
Dialogue: 0,0:17:34.07,0:17:39.78,Default,,0000,0000,0000,,issues and even there were some issues in\Nthe protocols themselves that also apply to
Dialogue: 0,0:17:39.78,0:17:46.03,Default,,0000,0000,0000,,macOS. So it's not just iOS bugs, but also\Nprotocol bugs in macOS that Dennis found.
Dialogue: 0,0:17:46.03,0:17:50.91,Default,,0000,0000,0000,,And this really got me thinking,\Nbecause ToothPicker with only 20
Dialogue: 0,0:17:50.91,0:17:56.31,Default,,0000,0000,0000,,fuzz cases per second, so it's really,\Nreally slow and we were still able to find
Dialogue: 0,0:17:56.31,0:18:04.14,Default,,0000,0000,0000,,Bluetooth vulnerabilities at this speed.\NSo, why is this? So first of all, if you
Dialogue: 0,0:18:04.14,0:18:08.13,Default,,0000,0000,0000,,try to fuzz Bluetooth over the air, then\Nthe over-the-air connections are
Dialogue: 0,0:18:08.13,0:18:13.62,Default,,0000,0000,0000,,terminated after something like five\Ninvalid packets. So, over-the-air fuzzing
Dialogue: 0,0:18:13.62,0:18:18.69,Default,,0000,0000,0000,,is really, really inefficient. And with\NFrida you can actually patch these
Dialogue: 0,0:18:18.69,0:18:23.10,Default,,0000,0000,0000,,functions, so it's gone. Then the\Nvirtual connections are a very important
Dialogue: 0,0:18:23.10,0:18:32.12,Default,,0000,0000,0000,,factor. So they are really, really\Nimportant for having coverage. It's still
Dialogue: 0,0:18:32.12,0:18:37.03,Default,,0000,0000,0000,,a lot of coverage that we missed during\Nreplay and fuzzing. But it's
Dialogue: 0,0:18:37.03,0:18:41.47,Default,,0000,0000,0000,,really an advantage compared to the\Nother fuzzing approaches where you just
Dialogue: 0,0:18:41.47,0:18:47.27,Default,,0000,0000,0000,,inject packets. And in addition, there is\Nan issue here, because if you have a
Dialogue: 0,0:18:47.27,0:18:51.48,Default,,0000,0000,0000,,virtual connection, it might be that this\Nvirtual connection triggers behaviour,
Dialogue: 0,0:18:51.48,0:18:55.91,Default,,0000,0000,0000,,that you cannot reproduce over the air.\NSo, that means that everything that you
Dialogue: 0,0:18:55.91,0:19:01.85,Default,,0000,0000,0000,,find, you need also to confirm that it\Nworks over the air. At least the
Dialogue: 0,0:19:01.85,0:19:05.76,Default,,0000,0000,0000,,inconsistent coverage is also fixed in\NToothPicker, because ToothPicker
Dialogue: 0,0:19:05.76,0:19:10.86,Default,,0000,0000,0000,,replays all packets five times in a row.\NBut the issue here is that it also means
Dialogue: 0,0:19:10.86,0:19:17.02,Default,,0000,0000,0000,,that if you have a sequence of packets,\Nthat is like generating a certain bug -
Dialogue: 0,0:19:17.02,0:19:21.55,Default,,0000,0000,0000,,so you need multiple packets - this is\Nnothing that the mutator is aware of and
Dialogue: 0,0:19:21.55,0:19:29.06,Default,,0000,0000,0000,,also nothing that's logged properly in\NToothPicker. And because of this, I got a
Dialogue: 0,0:19:29.06,0:19:33.82,Default,,0000,0000,0000,,bit anxious. Maybe we missed a \Nlot of things? So once I got the
Dialogue: 0,0:19:33.82,0:19:38.10,Default,,0000,0000,0000,,intuition that we are actually missing\Ncertain state information, I had the idea
Dialogue: 0,0:19:38.10,0:19:44.06,Default,,0000,0000,0000,,to replace bytes in active connections.\NAnd this is one part of that you can see
Dialogue: 0,0:19:44.06,0:19:52.00,Default,,0000,0000,0000,,on a keyboard, so I'm just replacing bytes\Non keyboard input and see what happens.
Dialogue: 0,0:19:52.00,0:19:59.73,Default,,0000,0000,0000,,And I let this run for a couple of weeks,\Nalso for different protocols and so on to
Dialogue: 0,0:19:59.73,0:20:08.68,Default,,0000,0000,0000,,see, if there are further bugs or not that\Nwe didn't find previously. So here you
Dialogue: 0,0:20:08.68,0:20:13.45,Default,,0000,0000,0000,,can see the same for AirPods with SCO and\Nthen they produce crack-sounds for the
Dialogue: 0,0:20:13.45,0:20:18.51,Default,,0000,0000,0000,,replace bytes, it's even worse for ACL, so\Nactual music, because then you can hear
Dialogue: 0,0:20:18.51,0:20:25.23,Default,,0000,0000,0000,,very noisy chirps. I let this fuzzer run\Nfor multiple weeks and it didn't find
Dialogue: 0,0:20:25.23,0:20:30.07,Default,,0000,0000,0000,,any bugs that ToothPicker hadn't\Ndiscovered before. So, I think the reason
Dialogue: 0,0:20:30.07,0:20:35.28,Default,,0000,0000,0000,,for this is that I mainly passed in active\Nconnections like the one with the audio
Dialogue: 0,0:20:35.28,0:20:40.00,Default,,0000,0000,0000,,or the keyboard, but I only passed a few\Nactive pairings because this requires me
Dialogue: 0,0:20:40.00,0:20:48.31,Default,,0000,0000,0000,,to actually perform those pairings by\Nhand, so, nothing really interesting. The
Dialogue: 0,0:20:48.31,0:20:52.28,Default,,0000,0000,0000,,only bad thing that I could produce with\Nthis, but not worth a CVE, is that the
Dialogue: 0,0:20:52.28,0:20:59.81,Default,,0000,0000,0000,,sound quality of my AirPods is now a\Nreally, really bad. Well, OK. And also the
Dialogue: 0,0:20:59.81,0:21:07.74,Default,,0000,0000,0000,,Broadcom chips on iOS don't check the UART\Nlengths, but that's not that bad. So, I
Dialogue: 0,0:21:07.74,0:21:13.09,Default,,0000,0000,0000,,mean, if you consider that they removed\Nthe write-RAM recently, then you might now
Dialogue: 0,0:21:13.09,0:21:20.99,Default,,0000,0000,0000,,still be able to write into the RAM via UART\Nbuffer overflows. But yeah, nothing too
Dialogue: 0,0:21:20.99,0:21:27.70,Default,,0000,0000,0000,,interesting. So after all of this, I asked\Nmyself: "What is still left for fuzzing if
Dialogue: 0,0:21:27.70,0:21:33.21,Default,,0000,0000,0000,,we cannot find a new Bluetooth or Wi-Fi\Nbugs?" Well, the iPhone baseband - or
Dialogue: 0,0:21:33.21,0:21:39.19,Default,,0000,0000,0000,,actually the iPhone basebands, because\Nthere are two. The first variant of iPhone
Dialogue: 0,0:21:39.19,0:21:44.77,Default,,0000,0000,0000,,baseband, that you can get, are Qualcomm\Nchips and they are in the US devices they
Dialogue: 0,0:21:44.77,0:21:49.98,Default,,0000,0000,0000,,use the Qualcomm MSM interface. And this\Ninterface comes with some documentation
Dialogue: 0,0:21:49.98,0:21:55.46,Default,,0000,0000,0000,,and there are even open source\Nimplementations for it. So it's something
Dialogue: 0,0:21:55.46,0:22:03.39,Default,,0000,0000,0000,,that's probably easy to understand and\Neasy to fuzz. On the other hand in almost
Dialogue: 0,0:22:03.39,0:22:09.24,Default,,0000,0000,0000,,all devices that I had on my table, were\NIntel chips. Intel has been recently
Dialogue: 0,0:22:09.24,0:22:15.21,Default,,0000,0000,0000,,bought by Apple, at least the part that\Ndoes the baseband chips and these are the
Dialogue: 0,0:22:15.21,0:22:18.70,Default,,0000,0000,0000,,chips in the European devices, that's\Nthe reason why almost all my devices had
Dialogue: 0,0:22:18.70,0:22:22.87,Default,,0000,0000,0000,,Intel chips. And they use a special\Nprotocol. It's called Apple Remote
Dialogue: 0,0:22:22.87,0:22:26.90,Default,,0000,0000,0000,,Invocation. And if you search for this on\Nthe Internet, I even checked it like
Dialogue: 0,0:22:26.90,0:22:32.35,Default,,0000,0000,0000,,just today, there are no Google hits at\Nall. So it really hasn't been researched
Dialogue: 0,0:22:32.35,0:22:36.87,Default,,0000,0000,0000,,before, at least not publicly. It's\Ncompletely undocumented and it's a very
Dialogue: 0,0:22:36.87,0:22:41.12,Default,,0000,0000,0000,,custom interface. So it's not even used\Nfor Android. It's really an interface
Dialogue: 0,0:22:41.12,0:22:47.41,Default,,0000,0000,0000,,just for Apple. The component that we are\Ngoing to fuzz in the following is CommCenter.
Dialogue: 0,0:22:47.41,0:22:53.04,Default,,0000,0000,0000,,So CommCenter is the equivalent of, for\Nexample, the Bluetooth or Wi-FI daemon,
Dialogue: 0,0:22:53.04,0:22:58.60,Default,,0000,0000,0000,,but for telephony. It's sandboxed as the\Nuser "wireless", but it comes with a lot of
Dialogue: 0,0:22:58.60,0:23:02.76,Default,,0000,0000,0000,,XPC interfaces. And this is something\Nthat we will also see later in the
Dialogue: 0,0:23:02.76,0:23:11.12,Default,,0000,0000,0000,,fuzzing results. The next part is that\Nthere are two flavors of libraries, so
Dialogue: 0,0:23:11.12,0:23:15.38,Default,,0000,0000,0000,,depending on if you have a Qualcomm or an\NIntel chip, different libraries will be
Dialogue: 0,0:23:15.38,0:23:21.68,Default,,0000,0000,0000,,used before certain actions or data\Nactually is then processed by the
Dialogue: 0,0:23:21.68,0:23:28.77,Default,,0000,0000,0000,,CommCenter itself. So we have a different\Ncode paths here. But all of this runs in
Dialogue: 0,0:23:28.77,0:23:34.25,Default,,0000,0000,0000,,user space, and this means that both\Nlibraries can be hooked with Frida and can
Dialogue: 0,0:23:34.25,0:23:38.03,Default,,0000,0000,0000,,be fuzzed with Frida. So that's very\Ninteresting. There is still a lot of stuff
Dialogue: 0,0:23:38.03,0:23:44.97,Default,,0000,0000,0000,,that goes on in the kernel. So what you\Ncan see here is that QMI and ARI have some
Dialogue: 0,0:23:44.97,0:23:49.82,Default,,0000,0000,0000,,management information that is sent to\NCommCenter, but they don't contain the
Dialogue: 0,0:23:49.82,0:23:54.74,Default,,0000,0000,0000,,raw network or audio data. So they don't\Ncontain your phone call, they don't
Dialogue: 0,0:23:54.74,0:24:03.31,Default,,0000,0000,0000,,contain your website that you are opening.\NAnd the next issue is that QMI and ARI
Dialogue: 0,0:24:03.31,0:24:07.86,Default,,0000,0000,0000,,are not directly sent over the air, but\Nwhat is sent over the air are normal
Dialogue: 0,0:24:07.86,0:24:14.50,Default,,0000,0000,0000,,baseband interactions and these generate\NQMI and ARI messages. So there's still
Dialogue: 0,0:24:14.50,0:24:19.55,Default,,0000,0000,0000,,some section in between, but of course,\Nthere are now two ways: either you have
Dialogue: 0,0:24:19.55,0:24:24.58,Default,,0000,0000,0000,,interaction that you can do over the air,\Nthat is causing ARI and QMI messages
Dialogue: 0,0:24:24.58,0:24:32.26,Default,,0000,0000,0000,,directly, that are something that causes an\Nissue in the upper layers. Or you might
Dialogue: 0,0:24:32.26,0:24:36.72,Default,,0000,0000,0000,,have this full exploit chain requirement\Nthat you first need to exploit the chip
Dialogue: 0,0:24:36.72,0:24:44.39,Default,,0000,0000,0000,,over the air, and then from the chip\Nbreak the interface into the CommCenter.
Dialogue: 0,0:24:44.39,0:24:51.97,Default,,0000,0000,0000,,Now, QMI, the code has a lot of\Nassertions. So it's really asserting
Dialogue: 0,0:24:51.97,0:25:00.81,Default,,0000,0000,0000,,everything about a protocol, delaying the\NTRV format and so on, and if anything goes
Dialogue: 0,0:25:00.81,0:25:06.24,Default,,0000,0000,0000,,wrong, it really terminates CommCenter.\NSo if you just send one invalid packet,
Dialogue: 0,0:25:06.24,0:25:11.50,Default,,0000,0000,0000,,CommCenter is terminated. This doesn't\Nmatter a lot because if your protocol is
Dialogue: 0,0:25:11.50,0:25:15.51,Default,,0000,0000,0000,,stable and you usually don't send any\Ninvalid packets, then you know an attack
Dialogue: 0,0:25:15.51,0:25:21.40,Default,,0000,0000,0000,,is ongoing, so it's valid to terminate\Nthe CommCenter. And furthermore, it
Dialogue: 0,0:25:21.40,0:25:25.19,Default,,0000,0000,0000,,doesn't matter a lot to the user. So the\Nworst thing that happens when CommCenter
Dialogue: 0,0:25:25.19,0:25:28.77,Default,,0000,0000,0000,,crashes, for example, while you have an\Nactive phone call, it's just that the
Dialogue: 0,0:25:28.77,0:25:33.70,Default,,0000,0000,0000,,phone call gets lost or your LTE\Nconnection is re-established. So you don't
Dialogue: 0,0:25:33.70,0:25:40.34,Default,,0000,0000,0000,,really notice it. It just feels like your\NInternet connection breaks for a short
Dialogue: 0,0:25:40.34,0:25:46.63,Default,,0000,0000,0000,,moment. In contrast, there is the ARI\Nprotoctol, and this is the part that just
Dialogue: 0,0:25:46.63,0:25:51.37,Default,,0000,0000,0000,,works very, very, very different. So\Nwhatever it's getting, it just parses it,
Dialogue: 0,0:25:51.37,0:25:56.68,Default,,0000,0000,0000,,and it doesn't terminate CommCenter.\NSo you can send many, many,
Dialogue: 0,0:25:56.68,0:25:59.93,Default,,0000,0000,0000,,many fancy things and it just\Ncontinues, continues, continues,
Dialogue: 0,0:25:59.93,0:26:04.21,Default,,0000,0000,0000,,because the developers were probably very,\Nvery happy once they got their special
Dialogue: 0,0:26:04.21,0:26:10.97,Default,,0000,0000,0000,,protocol for Apple working and then they\Nnever touched it again. But what does it
Dialogue: 0,0:26:10.97,0:26:18.11,Default,,0000,0000,0000,,look like? So it has a very basic format,\Nalso with some TLS(?), and the first
Dialogue: 0,0:26:18.11,0:26:24.25,Default,,0000,0000,0000,,thing that I noticed when I fuzzed it is\Nthat in the iDevice syslog, it always
Dialogue: 0,0:26:24.25,0:26:28.83,Default,,0000,0000,0000,,complained about this sequence number\Nbeing wrong. So it just said I expected
Dialogue: 0,0:26:28.83,0:26:35.52,Default,,0000,0000,0000,,the follow-up sequence number, so and so.\NSo I started to fix this. And if you open
Dialogue: 0,0:26:35.52,0:26:38.97,Default,,0000,0000,0000,,it in IDA, you can see that the range,\Nthat is expected it's between zero and
Dialogue: 0,0:26:38.97,0:26:47.10,Default,,0000,0000,0000,,0x7ff hexadecimal. So you know it is\Nthe range and then it gets weird. So the
Dialogue: 0,0:26:47.10,0:26:51.63,Default,,0000,0000,0000,,sequence number is spread over three\Ndifferent bytes in single bits and
Dialogue: 0,0:26:51.63,0:26:56.85,Default,,0000,0000,0000,,shifted around and so on. And it's not\Neven continuous. So very weird code.
Dialogue: 0,0:26:56.85,0:27:02.00,Default,,0000,0000,0000,,Probably they just added those\Nsequence numbers to confirm some race
Dialogue: 0,0:27:02.00,0:27:06.75,Default,,0000,0000,0000,,conditions or something. I really don't\Nknow. Or out-of-order packets? Something
Dialogue: 0,0:27:06.75,0:27:12.62,Default,,0000,0000,0000,,weird going on there. But I wrote the\Ncode, I fixed the sequence number and
Dialogue: 0,0:27:12.62,0:27:17.71,Default,,0000,0000,0000,,then during the replay of packets, I\Nnoticed, well, it doesn't even matter! So
Dialogue: 0,0:27:17.71,0:27:22.47,Default,,0000,0000,0000,,no matter if your sequence number is valid\Nor invalid, parsing continues and even
Dialogue: 0,0:27:22.47,0:27:28.00,Default,,0000,0000,0000,,worse, even packets with a wrong sequence\Nnumber are parsed. Probably because
Dialogue: 0,0:27:28.00,0:27:31.35,Default,,0000,0000,0000,,otherwise there would be too many issues,\Nbecause the protocol implementation is too
Dialogue: 0,0:27:31.35,0:27:36.35,Default,,0000,0000,0000,,buggy. And there are also a couple of\Nother things, so, for example, if you sent
Dialogue: 0,0:27:36.35,0:27:41.19,Default,,0000,0000,0000,,the first four magic bytes wrong or a\Nwrong length or something, then the
Dialogue: 0,0:27:41.19,0:27:47.41,Default,,0000,0000,0000,,packet is potentially ignored. But parsing\Ncontinues and CommCenter is not terminated
Dialogue: 0,0:27:47.41,0:27:53.53,Default,,0000,0000,0000,,like in QMI. Since it's a proprietary\Nprotocol, there is currently no tooling
Dialogue: 0,0:27:53.53,0:27:57.77,Default,,0000,0000,0000,,available. But, Tobias is working on a\NWireshark dissector and once he finishes
Dialogue: 0,0:27:57.77,0:28:02.44,Default,,0000,0000,0000,,his thesis, it will also be publicly\Nreleased. So you need to wait a while, but
Dialogue: 0,0:28:02.44,0:28:10.77,Default,,0000,0000,0000,,then you will have a tool for this.\NAnyway, let's also talk about fuzzing
Dialogue: 0,0:28:10.77,0:28:16.68,Default,,0000,0000,0000,,this, so I would not recommend to fuzz\Nthis, because you might brick your device
Dialogue: 0,0:28:16.68,0:28:21.01,Default,,0000,0000,0000,,or at least get into weird states. So\Njust don't do this on your productive
Dialogue: 0,0:28:21.01,0:28:30.56,Default,,0000,0000,0000,,iPhone. I mean, obviously, I know what\NI'm doing, so, yeah, just fuzzing packets,
Dialogue: 0,0:28:30.56,0:28:36.62,Default,,0000,0000,0000,,right? But I'm not so sure about what\Nexactly I'm doing, so the only direction
Dialogue: 0,0:28:36.62,0:28:43.99,Default,,0000,0000,0000,,that I fuzz is from the baseband to the\NiPhone here, not the opposite direction.
Dialogue: 0,0:28:43.99,0:28:50.11,Default,,0000,0000,0000,,So I hopefully do prevent anything weird\Non the chip, right? But the iPhone might
Dialogue: 0,0:28:50.11,0:28:56.99,Default,,0000,0000,0000,,still answer with something invalid and\Nthis might confuse the baseband or cause
Dialogue: 0,0:28:56.99,0:29:04.27,Default,,0000,0000,0000,,other crashes. And so I actually had to\Ncall for help, like mimimimimi, I broke my
Dialogue: 0,0:29:04.27,0:29:08.34,Default,,0000,0000,0000,,iPhone - I mean, just one of my research\Ndevices - but still so it booted into
Dialogue: 0,0:29:08.34,0:29:14.64,Default,,0000,0000,0000,,pongoOS but no longer into iOS and it\Ndidn't tell me any debug message that was
Dialogue: 0,0:29:14.64,0:29:19.54,Default,,0000,0000,0000,,useful. Well, it turns out, at least\Nunder Qualcomm chips, and that's where
Dialogue: 0,0:29:19.54,0:29:25.59,Default,,0000,0000,0000,,this happens, it just boots after a\Ncouple of hours again. But before it's
Dialogue: 0,0:29:25.59,0:29:31.76,Default,,0000,0000,0000,,just entering a boot loop and on the\NIntel iPhones I also almost bricked an
Dialogue: 0,0:29:31.76,0:29:37.62,Default,,0000,0000,0000,,iPhone 8, but luckily it didn't\Ncompletely break. So the issue there is if
Dialogue: 0,0:29:37.62,0:29:42.64,Default,,0000,0000,0000,,you enable the baseband debug profile,\Nthen it writes a lot of stuff to the ISTP
Dialogue: 0,0:29:42.64,0:29:49.28,Default,,0000,0000,0000,,files, so that is some debug format of\NIntel, and every few minutes it just
Dialogue: 0,0:29:49.28,0:29:53.47,Default,,0000,0000,0000,,creates something like 500MB of data, at\Nleast on the iPhone 8. On the newer
Dialogue: 0,0:29:53.47,0:29:57.65,Default,,0000,0000,0000,,iPhones, this debug format is a bit\Nshorter, so it doesn't create as much
Dialogue: 0,0:29:57.65,0:30:02.36,Default,,0000,0000,0000,,data, but still a lot. And if you don't\Ndelete this regularly, then of course
Dialogue: 0,0:30:02.36,0:30:07.59,Default,,0000,0000,0000,,your disk will be full and an iPhone\Nbehaves quite strange if it has a full
Dialogue: 0,0:30:07.59,0:30:11.86,Default,,0000,0000,0000,,disk. So you can still interact with the\Nuser interface, but you can no longer
Dialogue: 0,0:30:11.86,0:30:18.97,Default,,0000,0000,0000,,delete photos because deleting a photo, it\Nseems, it just needs some file
Dialogue: 0,0:30:18.97,0:30:25.06,Default,,0000,0000,0000,,interaction. Also, you can no longer log\Nin with SSH, which is also an issue
Dialogue: 0,0:30:25.06,0:30:29.37,Default,,0000,0000,0000,,because it somehow seems to create a file\Nwhen logging in, so you can no longer
Dialogue: 0,0:30:29.37,0:30:36.30,Default,,0000,0000,0000,,delete any files. And I was just\Nrebooting the iPhone after trying a couple
Dialogue: 0,0:30:36.30,0:30:41.17,Default,,0000,0000,0000,,of things and luckily it came back and\Ndeleted some files and I was able to log
Dialogue: 0,0:30:41.17,0:30:48.46,Default,,0000,0000,0000,,in and removed the baseband logs. But be\Ncareful when doing this. And of course,
Dialogue: 0,0:30:48.46,0:30:52.60,Default,,0000,0000,0000,,all the iPhones are very confused from\Nthe fuzzing. So they really lose
Dialogue: 0,0:30:52.60,0:30:57.28,Default,,0000,0000,0000,,everything about their identity and\Nlocation and they want to be activated
Dialogue: 0,0:30:57.28,0:31:02.54,Default,,0000,0000,0000,,again. So here you can see a smartphone\Nthat lost its location and really wants
Dialogue: 0,0:31:02.54,0:31:08.08,Default,,0000,0000,0000,,to be activated, activated, activated.\NDuring SMS fuzzing, you might even get
Dialogue: 0,0:31:08.08,0:31:12.48,Default,,0000,0000,0000,,Flash messages. And if you click on the\Nhead menu on dark theme, they are
Dialogue: 0,0:31:12.48,0:31:18.26,Default,,0000,0000,0000,,displayed black on gray, so probably\Nnobody ever tested it. Also great if you
Dialogue: 0,0:31:18.26,0:31:22.56,Default,,0000,0000,0000,,have a locked iPhone, you can still\Ndisplay SIM menus and SIM messages on top
Dialogue: 0,0:31:22.56,0:31:30.77,Default,,0000,0000,0000,,of the lock. OK, so I guess I have to\Nrevise my first instruction. So fuzz this!
Dialogue: 0,0:31:30.77,0:31:36.50,Default,,0000,0000,0000,,Really, really fuzz this! It's a lot of\Nfun. Maybe just not on your primary
Dialogue: 0,0:31:36.50,0:31:43.64,Default,,0000,0000,0000,,device, but you will enjoy fuzzing these\Ninterfaces. But first of all, you
Dialogue: 0,0:31:43.64,0:31:50.46,Default,,0000,0000,0000,,obviously need to build a fuzzer, so how\Ndo you build a fuzzer? The first fuzzer
Dialogue: 0,0:31:50.46,0:31:54.68,Default,,0000,0000,0000,,that I used was the one that I also used\Nfor Bluetooth that just uses the
Dialogue: 0,0:31:54.68,0:32:00.51,Default,,0000,0000,0000,,existing bytestream protocol and then\Nflips single bits and bytes. So it has
Dialogue: 0,0:32:00.51,0:32:03.95,Default,,0000,0000,0000,,this high state-awareness. But it also\Nmeans that like some kind of monkey I was
Dialogue: 0,0:32:03.95,0:32:09.95,Default,,0000,0000,0000,,just calling myself, writing SMS to\Nmyself, enabling flight mode, everything
Dialogue: 0,0:32:09.95,0:32:15.35,Default,,0000,0000,0000,,that you could just imagine. And it's a\Nvery boring task. But it also found very
Dialogue: 0,0:32:15.35,0:32:19.68,Default,,0000,0000,0000,,fancy bugs that I couldn't reproduce with\Nthe other fuzzers yet, because it can
Dialogue: 0,0:32:19.68,0:32:26.08,Default,,0000,0000,0000,,reach states that just injection of\Npackets cannot reach. So at least it was
Dialogue: 0,0:32:26.08,0:32:33.74,Default,,0000,0000,0000,,quite successful. And when I fuzzed with\Nthis for something like three days and
Dialogue: 0,0:32:33.74,0:32:37.34,Default,,0000,0000,0000,,already found a bugs, that's very\Ndifferent with the Bluetooth fuzzers, so
Dialogue: 0,0:32:37.34,0:32:41.56,Default,,0000,0000,0000,,there seemed to be more bugs in\NCommCenter. And so I just wrote to Apple
Dialogue: 0,0:32:41.56,0:32:46.56,Default,,0000,0000,0000,,PR: "Hey there, I wrote this really,\Nreally ugly 10-lines-of-code fuzzer and
Dialogue: 0,0:32:46.56,0:32:52.13,Default,,0000,0000,0000,,see what it found. Awesome, awesome,\Nawesome! And crash logs are attached. And
Dialogue: 0,0:32:52.13,0:32:56.24,Default,,0000,0000,0000,,obviously this is simple to reproduce\Nbecause I only fuzzed for three days. Got
Dialogue: 0,0:32:56.24,0:33:01.84,Default,,0000,0000,0000,,most of these crashes multiple times.\NYeah. So here you go. Enjoy my fuzzer."
Dialogue: 0,0:33:01.84,0:33:07.22,Default,,0000,0000,0000,,And this was probably quite\Nstupid because it's not that simple. So
Dialogue: 0,0:33:07.22,0:33:12.19,Default,,0000,0000,0000,,it's really not easy to reproduce the\Ncrashes. First of all, well, of course
Dialogue: 0,0:33:12.19,0:33:17.43,Default,,0000,0000,0000,,this script is so generic that it runs on\Nall iPhones with an Intel chip, so no
Dialogue: 0,0:33:17.43,0:33:24.39,Default,,0000,0000,0000,,matter if I take an iPhone 7 or an iPhone\N11, it will just work. But the crash logs
Dialogue: 0,0:33:24.39,0:33:29.07,Default,,0000,0000,0000,,that you get are very different depending\Non if you fuzz on a pre-A12, so iPhone 7
Dialogue: 0,0:33:29.07,0:33:34.80,Default,,0000,0000,0000,,and 8, or on later versions like the iPhone 11\Nand SE2. So you cannot reproduce the same
Dialogue: 0,0:33:34.80,0:33:40.46,Default,,0000,0000,0000,,crash logs that easy. And also it depends\Na lot on the SIM. So even on a passive
Dialogue: 0,0:33:40.46,0:33:44.99,Default,,0000,0000,0000,,iPhone, if you don't do any phone calls\Nand so on, you would get different
Dialogue: 0,0:33:44.99,0:33:51.72,Default,,0000,0000,0000,,results. So I started my fuzzing actually\Nwith a Singaporean SIM card
Dialogue: 0,0:33:51.72,0:33:57.30,Default,,0000,0000,0000,,without any data contract or phone\Ncontract on top of it and already found a
Dialogue: 0,0:33:57.30,0:34:05.12,Default,,0000,0000,0000,,couple of things. But it might just \Nbehave very different on just a slightly
Dialogue: 0,0:34:05.12,0:34:12.54,Default,,0000,0000,0000,,different configuration. Anyway, let's\Nlisten to a null pointer that it found. And
Dialogue: 0,0:34:12.54,0:34:16.49,Default,,0000,0000,0000,,this null pointer has been fixed in iOS\N14.2 and it's in the audio controller, so
Dialogue: 0,0:34:16.49,0:34:26.05,Default,,0000,0000,0000,,you can hear some loop going on there.\NWhat you can see here is me calling the
Dialogue: 0,0:34:26.05,0:34:30.35,Default,,0000,0000,0000,,Deutsche Telekom and so on. So they have\Nthis very important text.
Dialogue: 0,0:34:30.35,0:34:35.37,Default,,0000,0000,0000,,Announcement: Guten Tag, und herzlich\Nwillkommen beim Kundenservice der Telekom.
Dialogue: 0,0:34:35.37,0:34:41.02,Default,,0000,0000,0000,,jiska: And then I call again and have a\Ncrash. And now let's listen to the crash.
Dialogue: 0,0:34:43.93,0:34:48.14,Default,,0000,0000,0000,,{\i1}Telekom jingle starts playing,\N final part loops ten times{\i0}
Dialogue: 0,0:34:51.18,0:34:55.52,Default,,0000,0000,0000,,jiska: Just for the sound effect, I also recorded\Nanother one, so this one is with ALDI TALK.
Dialogue: 0,0:34:57.98,0:35:02.52,Default,,0000,0000,0000,,Announcement: Guten Tag, ALDI TALK gibt\Ndie Senkung der Mehrwertsteuer vom ersten...
Dialogue: 0,0:35:05.35,0:35:08.17,Default,,0000,0000,0000,,jiska: And now let's listen to a special\Noffer by ALDI TALK.
Dialogue: 0,0:35:09.19,0:35:10.87,Default,,0000,0000,0000,,In 3, 2, 1... di-dimm...
Dialogue: 0,0:35:10.87,0:35:14.95,Default,,0000,0000,0000,,Announcement: Guten Tag, ALDI TALK gibt die\NSenkung der Mehrwersteuer vom
Dialogue: 0,0:35:14.95,0:35:18.03,Default,,0000,0000,0000,,{\i1}loops ten times{\i0}\Nerst-erst-erst-erst-erst-erst-erst-erst-erst-er
Dialogue: 0,0:35:23.21,0:35:28.50,Default,,0000,0000,0000,,Jiska: Since his first fuzzing results\Nwere very promising, I decided to use
Dialogue: 0,0:35:28.50,0:35:33.17,Default,,0000,0000,0000,,the latest ToothPicker version and extend\Nit for fuzzing ARI and I called it
Dialogue: 0,0:35:33.17,0:35:38.41,Default,,0000,0000,0000,,ICEPicker because the Intel chips are also\Ncalled ICE. So I just cloned Dennis'
Dialogue: 0,0:35:38.41,0:35:43.84,Default,,0000,0000,0000,,latest ToothPicker alpha, which is very,\Nvery unstable, but this one actually
Dialogue: 0,0:35:43.84,0:35:49.53,Default,,0000,0000,0000,,runs on the iPhone locally without any\Ninteraction with Mac OS or Linux. So it
Dialogue: 0,0:35:49.53,0:35:54.98,Default,,0000,0000,0000,,doesn't need to exchange any the payload\Nvia USB and also it's using AFL++, which
Dialogue: 0,0:35:54.98,0:36:02.19,Default,,0000,0000,0000,,is a much faster mutator than Radamsa.\NSo from a speed consideration, this is a
Dialogue: 0,0:36:02.19,0:36:08.04,Default,,0000,0000,0000,,much better design. However, AFL++ didn't\Nturn out to be the best fuzzer for
Dialogue: 0,0:36:08.04,0:36:12.86,Default,,0000,0000,0000,,protocol, so most of the time is actually\Nspent trying to brute force the first
Dialogue: 0,0:36:12.86,0:36:17.25,Default,,0000,0000,0000,,magic bytes, the first four bytes, because\Nit tries to shorten inputs. It's also not
Dialogue: 0,0:36:17.25,0:36:22.20,Default,,0000,0000,0000,,aware of something like a packet order, so\Nit was just brute forcing those first four
Dialogue: 0,0:36:22.20,0:36:28.86,Default,,0000,0000,0000,,bytes. And well, the next issue is, that\Nfor some reason, if the first four bytes
Dialogue: 0,0:36:28.86,0:36:33.77,Default,,0000,0000,0000,,are invalid, the ARI parser slows down a\Nlot. So I was suddenly down to something
Dialogue: 0,0:36:33.77,0:36:40.79,Default,,0000,0000,0000,,like less than 10 fuzz cases per second.\NAnd also there is no awareness of the
Dialogue: 0,0:36:40.79,0:36:46.39,Default,,0000,0000,0000,,ICEPicker in this case, of the ARI host\Nstate. So ARI sometimes shuts down this
Dialogue: 0,0:36:46.39,0:36:51.56,Default,,0000,0000,0000,,interface, if it thinks that something is\Nvery invalid and the fuzzer will just
Dialogue: 0,0:36:51.56,0:36:57.23,Default,,0000,0000,0000,,continue. So I looked into the iDevice\Nsyslog after the fuzzer couldn't find any
Dialogue: 0,0:36:57.23,0:37:01.34,Default,,0000,0000,0000,,new coverage for more than six hours.\NAnd I was wondering: "What is the
Dialogue: 0,0:37:01.34,0:37:07.52,Default,,0000,0000,0000,,issue here? Is the implementation\Nwrong or is it the fuzzer?" And it really
Dialogue: 0,0:37:07.52,0:37:12.99,Default,,0000,0000,0000,,looks like the fuzzer is producing inputs\Nthat are not good for protocol fuzzing.
Dialogue: 0,0:37:12.99,0:37:20.26,Default,,0000,0000,0000,,Of course, this is stuff that you can\Noptimize, so AFL++ can do a lot here, so
Dialogue: 0,0:37:20.26,0:37:25.69,Default,,0000,0000,0000,,you can tell it a bit how the protocol\Nlooks like and also get it to not brute
Dialogue: 0,0:37:25.69,0:37:30.41,Default,,0000,0000,0000,,force the first four magic bytes. But for\Nthis I would have to recompile the whole
Dialogue: 0,0:37:30.41,0:37:35.53,Default,,0000,0000,0000,,thing. And it was something that compiled\Non Dennis' machine, but it didn't compile
Dialogue: 0,0:37:35.53,0:37:40.14,Default,,0000,0000,0000,,on my machine , because I had my Xcode\Nbeta in a weird state. And well, of
Dialogue: 0,0:37:40.14,0:37:44.66,Default,,0000,0000,0000,,course, some of you now say:\N"Just download and install a new Xcode!"
Dialogue: 0,0:37:44.66,0:37:49.53,Default,,0000,0000,0000,,But this takes so long that actually\Nwriting the next fuzzer seemed to be.
Dialogue: 0,0:37:49.53,0:37:56.50,Default,,0000,0000,0000,,easier. Still, this variant of ICEPicker\Nwas interesting to me because it was the
Dialogue: 0,0:37:56.50,0:37:59.89,Default,,0000,0000,0000,,first time when I saw that the fuzzer\Ninitialization works, including
Dialogue: 0,0:37:59.89,0:38:07.00,Default,,0000,0000,0000,,coverage and also my replay works across\Nmultiple iPhone versions. So my call was
Dialogue: 0,0:38:07.00,0:38:14.32,Default,,0000,0000,0000,,collected on an iPhone SE2, was replayable\Non an iPhone 7. So it was not useless in
Dialogue: 0,0:38:14.32,0:38:22.06,Default,,0000,0000,0000,,that sense, but I just decided to not\Nuse this configuration. So I just wrote a
Dialogue: 0,0:38:22.06,0:38:27.01,Default,,0000,0000,0000,,very simple fuzzer again and I didn't do\Nthe porting of everything to run locally
Dialogue: 0,0:38:27.01,0:38:32.72,Default,,0000,0000,0000,,on iOS. I just kept the design a bit\Nsimpler or at least easier to code and had
Dialogue: 0,0:38:32.72,0:38:39.12,Default,,0000,0000,0000,,my fuzzer running on Linux and then using\Nonly Frida on iOS. It cannot reproduce all
Dialogue: 0,0:38:39.12,0:38:43.45,Default,,0000,0000,0000,,the states and crashes that I observed\Nwith my very first fuzzer, but most
Dialogue: 0,0:38:43.45,0:38:50.63,Default,,0000,0000,0000,,crashes could be reproduced. I didn't do\Nany coverage. I didn't do any smart
Dialogue: 0,0:38:50.63,0:38:56.72,Default,,0000,0000,0000,,mutations, just very stupid mutations. And\Nbasically I just did a very blind
Dialogue: 0,0:38:56.72,0:39:00.72,Default,,0000,0000,0000,,injection. But this was super fast, so\Ninstead of the 20 fuzz cases per second, I
Dialogue: 0,0:39:00.72,0:39:06.37,Default,,0000,0000,0000,,already had something like 400 fuzz cases\Nper second on an iPhone 7, which was about
Dialogue: 0,0:39:06.37,0:39:14.28,Default,,0000,0000,0000,,the same speed or even faster than the\NAFL++ variant. And I can at least correct
Dialogue: 0,0:39:14.28,0:39:21.34,Default,,0000,0000,0000,,the length field, sequence number and so\Non before injecting the payload. Since it
Dialogue: 0,0:39:21.34,0:39:26.34,Default,,0000,0000,0000,,doesn't do that great mutations, at\Nleast, I need to collect a good corpus
Dialogue: 0,0:39:26.34,0:39:31.100,Default,,0000,0000,0000,,with many SIMSs, many calls. And I'm also\Nlogging the packet order with this. So
Dialogue: 0,0:39:31.100,0:39:36.25,Default,,0000,0000,0000,,it's at least aware of a pocket sequence\Nin the sense of, I can reproduce the
Dialogue: 0,0:39:36.25,0:39:43.20,Default,,0000,0000,0000,,sequence later on. I had this fuzzer\Nrunning on a couple of iPhones in
Dialogue: 0,0:39:43.20,0:39:50.06,Default,,0000,0000,0000,,parallel for multiple weeks, and it found\Na lot of interesting crashes. So that's
Dialogue: 0,0:39:50.06,0:39:57.32,Default,,0000,0000,0000,,my go-to fuzzer. I still wanted to\Nconfirm that not collecting coverage
Dialogue: 0,0:39:57.32,0:40:02.16,Default,,0000,0000,0000,,wasn't an issue, so I also cloned the\Npublicly released of ToothPicker, which
Dialogue: 0,0:40:02.16,0:40:07.01,Default,,0000,0000,0000,,definitely finds new coverage, and it's\Nusing the Radamsa-mutator, which is very,
Dialogue: 0,0:40:07.01,0:40:14.46,Default,,0000,0000,0000,,very slow, but it does a bit smarter\Nmutations, at least in terms of protocol
Dialogue: 0,0:40:14.46,0:40:20.22,Default,,0000,0000,0000,,fuzzing. It's still only a aware of\Nsingle packets and it's only using the
Dialogue: 0,0:40:20.22,0:40:26.33,Default,,0000,0000,0000,,same packets five times in a row to\Nconfirm coverage, etc. And also an issue
Dialogue: 0,0:40:26.33,0:40:30.82,Default,,0000,0000,0000,,is that it cannot catch a lot of the\Ncrashes of CommCenter. So it happens
Dialogue: 0,0:40:30.82,0:40:35.60,Default,,0000,0000,0000,,quite often that CommCenter crashes. And\Nthen if you cannot catch the crash with
Dialogue: 0,0:40:35.60,0:40:40.08,Default,,0000,0000,0000,,Frida and everything crashes, then you\Nneed to start the fuzzer again. But you
Dialogue: 0,0:40:40.08,0:40:42.99,Default,,0000,0000,0000,,also need to delete the files in the\Ncorpus that led to the crash because
Dialogue: 0,0:40:42.99,0:40:47.87,Default,,0000,0000,0000,,otherwise you would just run into the same\Ncrash very fast. So it needs a lot of
Dialogue: 0,0:40:47.87,0:40:55.55,Default,,0000,0000,0000,,babysitting. I also had it running for a\Ncouple of weeks, but sadly, it didn't find
Dialogue: 0,0:40:55.55,0:41:00.07,Default,,0000,0000,0000,,any crashes. So at least I can be sure\Nthat fuzzing, much slower, but with
Dialogue: 0,0:41:00.07,0:41:07.03,Default,,0000,0000,0000,,coverage, is not any improvement. Still,\Nthe mutations it creates are quite useful,
Dialogue: 0,0:41:07.03,0:41:11.55,Default,,0000,0000,0000,,as you can see in the following. So you\Ncan even see this phone numbers scrolling
Dialogue: 0,0:41:11.55,0:41:18.68,Default,,0000,0000,0000,,here and so on. So it generated a very\Nlong phone number correctly into some TLV
Dialogue: 0,0:41:18.68,0:41:23.01,Default,,0000,0000,0000,,structure here. And that's quite\Ninteresting to see. So this is something
Dialogue: 0,0:41:23.01,0:41:27.90,Default,,0000,0000,0000,,that you could not reach by just \Nflipping bits and bytes.
Dialogue: 0,0:41:38.66,0:41:43.82,Default,,0000,0000,0000,,There is one big shortcoming that all of\Nthese fuzzers have, including the initial
Dialogue: 0,0:41:43.82,0:41:50.80,Default,,0000,0000,0000,,ToothPicker which is they don't have any kind\Nof memory sanitization. So the framework
Dialogue: 0,0:41:50.80,0:41:56.42,Default,,0000,0000,0000,,that you would usually use in user space\Non iOS is the MallocStackLogging
Dialogue: 0,0:41:56.42,0:42:02.18,Default,,0000,0000,0000,,framework. I even got this running for\NCommCenter, so it's a bit of a command
Dialogue: 0,0:42:02.18,0:42:06.15,Default,,0000,0000,0000,,line juggling. But in the end you can\Nenable MallocStackLogging also for
Dialogue: 0,0:42:06.15,0:42:13.20,Default,,0000,0000,0000,,CommCenter. The issue here is that it\Nincreases the memory usage a lot and even
Dialogue: 0,0:42:13.20,0:42:19.31,Default,,0000,0000,0000,,if you configure CommCenter to have a\Nhigher memory allowance, it is so high
Dialogue: 0,0:42:19.31,0:42:24.37,Default,,0000,0000,0000,,that it's just immediately killed by the\Nout-of-memory killer. So this doesn't
Dialogue: 0,0:42:24.37,0:42:31.53,Default,,0000,0000,0000,,work. Then there is also libgmalloc. It\Ndoesn't exist for iOS, it's just exists on
Dialogue: 0,0:42:31.53,0:42:36.88,Default,,0000,0000,0000,,Xcode. I got one of the Xcode libraries\Nrunning on one of my iPhones. I have no
Dialogue: 0,0:42:36.88,0:42:40.83,Default,,0000,0000,0000,,idea if this is an expected configuration\Nor not. At least I could execute smaller
Dialogue: 0,0:42:40.83,0:42:47.26,Default,,0000,0000,0000,,programs. And then when you use this on\NCommCenter, it just crashes with a
Dialogue: 0,0:42:47.26,0:42:52.70,Default,,0000,0000,0000,,libgmalloc error on parsing some of the\Nconfiguration files very, very early when
Dialogue: 0,0:42:52.70,0:42:58.30,Default,,0000,0000,0000,,starting the CommCenter. So all of this\Ndidn't work. And this also means that the
Dialogue: 0,0:42:58.30,0:43:02.99,Default,,0000,0000,0000,,fuzzer cannot find certain bug types or\Ncrashes much later when encountering
Dialogue: 0,0:43:02.99,0:43:11.67,Default,,0000,0000,0000,,bugs. So all of the fuzzers that I created\Nare not perfect, but at least they found
Dialogue: 0,0:43:11.67,0:43:16.51,Default,,0000,0000,0000,,a lot of different crashes. Let's look\Ninto this. I mean, the first obvious
Dialogue: 0,0:43:16.51,0:43:21.48,Default,,0000,0000,0000,,number that you see here is the 42. So I\Nstopped fuzzing after 42 crashes - at
Dialogue: 0,0:43:21.48,0:43:25.95,Default,,0000,0000,0000,,least crashes that I think are individual\Ncrashes and that are not caused by Frida -
Dialogue: 0,0:43:25.95,0:43:31.51,Default,,0000,0000,0000,,so I tried to filter out Frida crashes\Nand this corresponds to the total amount
Dialogue: 0,0:43:31.51,0:43:36.35,Default,,0000,0000,0000,,of crashes, but only some of them are\Nreplayable by either one or multiple
Dialogue: 0,0:43:36.35,0:43:42.25,Default,,0000,0000,0000,,packets. And for the replayable crashes I\Ncan also check if they were fixed in
Dialogue: 0,0:43:42.25,0:43:48.60,Default,,0000,0000,0000,,recent iOS versions or the most recent iOS\N14.3 or not. Then I also marked two
Dialogue: 0,0:43:48.60,0:43:51.90,Default,,0000,0000,0000,,colors here because there is the Intel\Nlibraries, but there's also the
Dialogue: 0,0:43:51.90,0:43:57.97,Default,,0000,0000,0000,,Qualcomm libraries. And for the Qualcomm\Nlibraries, I didn't spend as much time
Dialogue: 0,0:43:57.97,0:44:02.15,Default,,0000,0000,0000,,fuzzing, because I have less Qualcomm\Nphones, but also all the asserts in the
Dialogue: 0,0:44:02.15,0:44:07.00,Default,,0000,0000,0000,,code prevent a lot of issues from being\Nreached. So the libraries themselves have
Dialogue: 0,0:44:07.00,0:44:14.19,Default,,0000,0000,0000,,less issues and also within CommCenter,\Nless of the code that has improper state
Dialogue: 0,0:44:14.19,0:44:22.07,Default,,0000,0000,0000,,handling is reached. The location daemon is\Nmarked also with a big grey box here,
Dialogue: 0,0:44:22.07,0:44:27.18,Default,,0000,0000,0000,,because the location daemon is similarly to\Nthe CommCenter using some of the raw
Dialogue: 0,0:44:27.18,0:44:32.65,Default,,0000,0000,0000,,packet inputs and parses them. So it has\Nspecial parsers for Qualcomm and Intel.
Dialogue: 0,0:44:32.65,0:44:38.65,Default,,0000,0000,0000,,And it's also an interesting target\Nbecause of this. Other than this I got
Dialogue: 0,0:44:38.65,0:44:44.27,Default,,0000,0000,0000,,really a lot, a lot, a lot of different\Ndaemons crashing. Some of them, even with
Dialogue: 0,0:44:44.27,0:44:48.97,Default,,0000,0000,0000,,replayable behaviour. So, for example,\Nthere is the wireless radio manager daemon
Dialogue: 0,0:44:48.97,0:44:57.28,Default,,0000,0000,0000,,that you can just crash via one Intel\Npacket. But, this has been fixed. And then
Dialogue: 0,0:44:57.28,0:45:02.18,Default,,0000,0000,0000,,there is one interesting crash that I\Nactually got via Qualcomm and Intel
Dialogue: 0,0:45:02.18,0:45:08.33,Default,,0000,0000,0000,,libraries. So in the mobile Internet\Nsharing daemon, this also has been fixed
Dialogue: 0,0:45:08.33,0:45:12.57,Default,,0000,0000,0000,,and some of the crashes only happened via\NQualcomm, but I'm not sure if that's like
Dialogue: 0,0:45:12.57,0:45:21.47,Default,,0000,0000,0000,,a Qualcomm-specific thing or it's just\Nrandomness of the fuzzer. So the mobile
Dialogue: 0,0:45:21.47,0:45:26.42,Default,,0000,0000,0000,,Internet sharing demon has an issue where\Nit accesses memory at configuration
Dialogue: 0,0:45:26.42,0:45:31.62,Default,,0000,0000,0000,,strings, so there's different strings at\Nthis memory address and I found this quite
Dialogue: 0,0:45:31.62,0:45:36.55,Default,,0000,0000,0000,,early, but I was not aware of the fact,\Nthat so many other daemons are actually
Dialogue: 0,0:45:36.55,0:45:40.76,Default,,0000,0000,0000,,crashing when I fuzz CommCenter. So, I\Ndidn't look into this in the very
Dialogue: 0,0:45:40.76,0:45:44.33,Default,,0000,0000,0000,,beginning. And when I reported it to\NApple, they said: "Yeah, yeah, we already
Dialogue: 0,0:45:44.33,0:45:49.57,Default,,0000,0000,0000,,know about this and we fixed it and a\Nbeta prior to your report." So certainly
Dialogue: 0,0:45:49.57,0:45:56.55,Default,,0000,0000,0000,,nothing that I got a CVE for. Another\Ninteresting crash in the CellMonitor, but
Dialogue: 0,0:45:56.55,0:46:01.74,Default,,0000,0000,0000,,only of the Intel library. The CellMonitor\Nis something that is running passively in
Dialogue: 0,0:46:01.74,0:46:06.65,Default,,0000,0000,0000,,the background all the time and it parses,\Nfor example, GSM and UMTS cell
Dialogue: 0,0:46:06.65,0:46:11.58,Default,,0000,0000,0000,,information. I already found this on the\NSingaporean SIM without any active
Dialogue: 0,0:46:11.58,0:46:16.75,Default,,0000,0000,0000,,data plan in my very first round of\Nfuzzing and reported it back then to
Dialogue: 0,0:46:16.75,0:46:21.46,Default,,0000,0000,0000,,Apple. I don't know, if it's triggerable\Nover the air or not. So I guess it's
Dialogue: 0,0:46:21.46,0:46:25.86,Default,,0000,0000,0000,,something that you first need to get code\Nexecution for. And it has been fixed in
Dialogue: 0,0:46:25.86,0:46:31.36,Default,,0000,0000,0000,,iOS 14.2. And I wrote a lot of emails with\NApple because I thought, that they didn't
Dialogue: 0,0:46:31.36,0:46:37.60,Default,,0000,0000,0000,,fix it. And the reason for this is that\Nboth the GSM cell info and the UMTS cell
Dialogue: 0,0:46:37.60,0:46:43.32,Default,,0000,0000,0000,,info function, when they parse data, they\Nhave two different bugs. So I still got
Dialogue: 0,0:46:43.32,0:46:47.29,Default,,0000,0000,0000,,crashes in the same functions and I\Nthought: "OK, same function, still a
Dialogue: 0,0:46:47.29,0:46:52.41,Default,,0000,0000,0000,,crash: The bug is not fixed.". But actually,\Nit's very high quality code and it's just
Dialogue: 0,0:46:52.41,0:46:57.60,Default,,0000,0000,0000,,multiple bugs per function. And there is\Neven one more issue in the CellMonitor,
Dialogue: 0,0:46:57.60,0:47:03.14,Default,,0000,0000,0000,,even though I think the remaining bugs are\Nvery simple crashes or nothing that could
Dialogue: 0,0:47:03.14,0:47:11.94,Default,,0000,0000,0000,,be exploitable at all, but still hints to\Nthe great code quality. And the same story
Dialogue: 0,0:47:11.94,0:47:15.67,Default,,0000,0000,0000,,is, that there're even more bugs to be\Nfixed. So most of them are probably just
Dialogue: 0,0:47:15.67,0:47:21.67,Default,,0000,0000,0000,,stability improvements, but some of them\Nare still interesting. So, let's see how
Dialogue: 0,0:47:21.67,0:47:26.79,Default,,0000,0000,0000,,this goes. So since I told, that it's a\Nvery simple fuzzer, some of you might have
Dialogue: 0,0:47:26.79,0:47:31.87,Default,,0000,0000,0000,,already started coding those 10 lines of\Ncode for fuzzing, while I continued talking
Dialogue: 0,0:47:31.87,0:47:38.20,Default,,0000,0000,0000,,and grabbed their old iPhones, that they are\Nwilling to lose, if something goes wrong.
Dialogue: 0,0:47:38.20,0:47:44.49,Default,,0000,0000,0000,,So, how can we actually build a fuzzer\Nthat is performant and replicates some of
Dialogue: 0,0:47:44.49,0:47:49.87,Default,,0000,0000,0000,,the bugs that I found just within a day.\NLet's take a look. When you look, Frida
Dialogue: 0,0:47:49.87,0:47:55.34,Default,,0000,0000,0000,,fuzzing, a lot of the stuff that you do,\Nis limited by the processing power of the
Dialogue: 0,0:47:55.34,0:47:59.28,Default,,0000,0000,0000,,iPhone. So your iPhone will get very,\Nvery, very hot and it might even drain
Dialogue: 0,0:47:59.28,0:48:06.00,Default,,0000,0000,0000,,more battery, than it can get via the USB\Nport. So it might even discharge while
Dialogue: 0,0:48:06.00,0:48:14.54,Default,,0000,0000,0000,,fuzzing. And performance is really key. So\Nyou need to identify bottlenecks.
Dialogue: 0,0:48:14.54,0:48:20.11,Default,,0000,0000,0000,,I said ToothPicker or ICEPicker, the\Ninitial version is just 20 fuzz cases per
Dialogue: 0,0:48:20.11,0:48:26.89,Default,,0000,0000,0000,,second and you can tune this to something\Nlike 20.000 fuzz cases per second. So, I
Dialogue: 0,0:48:26.89,0:48:30.92,Default,,0000,0000,0000,,already told, that I tuned it to something\Nlike 400 or 500 fuzz cases per second,
Dialogue: 0,0:48:30.92,0:48:36.86,Default,,0000,0000,0000,,but, why the 20.000? So, initially, a\Nstudent of mine, did some fuzzing in a
Dialogue: 0,0:48:36.86,0:48:41.71,Default,,0000,0000,0000,,very different parser and said: "On my\NiPhone 6S, it's running with 20.000 fuzz
Dialogue: 0,0:48:41.71,0:48:51.37,Default,,0000,0000,0000,,cases per second." I was like: "No way, no\Nway!" But actually, you can do this. So,
Dialogue: 0,0:48:51.37,0:48:56.89,Default,,0000,0000,0000,,this depends a lot on the Frida design.\NThe first variant, how most Frida scripts
Dialogue: 0,0:48:56.89,0:49:02.72,Default,,0000,0000,0000,,are written is, that you have some Python\Nscript that runs on Linux or macOS, and it
Dialogue: 0,0:49:02.72,0:49:06.10,Default,,0000,0000,0000,,has a couple of functions that you can see\Nhere. So first of all, it has this
Dialogue: 0,0:49:06.10,0:49:10.04,Default,,0000,0000,0000,,on_message callback. So, this on_message\Ncallback is something that we need later.
Dialogue: 0,0:49:10.04,0:49:14.25,Default,,0000,0000,0000,,And we just register it to our Frida\Nscript, the Frida script, that I'm going
Dialogue: 0,0:49:14.25,0:49:18.72,Default,,0000,0000,0000,,to show you in a second. And you load the\Nscript and the script can then even call
Dialogue: 0,0:49:18.72,0:49:25.32,Default,,0000,0000,0000,,functions on your iPhone. For this, you\Nload a second script on your iPhone. So
Dialogue: 0,0:49:25.32,0:49:32.15,Default,,0000,0000,0000,,this is JavaScript injected into the iOS\Ntarget process and it can, for example,
Dialogue: 0,0:49:32.15,0:49:37.36,Default,,0000,0000,0000,,use to send function to send something\Nback to the on message function. And it
Dialogue: 0,0:49:37.36,0:49:46.84,Default,,0000,0000,0000,,can export functions via RPCs. So, you can\Nthen call them. All this happens via JSON.
Dialogue: 0,0:49:46.84,0:49:51.13,Default,,0000,0000,0000,,And so it needs serialization and\Ndeserialization, which means you cannot
Dialogue: 0,0:49:51.13,0:49:56.99,Default,,0000,0000,0000,,send hex data or binary data directly. So\Nyou have a hex string that you encode into
Dialogue: 0,0:49:56.99,0:50:04.21,Default,,0000,0000,0000,,JSON, which is then parsed as binary data\Nand also it's all via USB. So you also
Dialogue: 0,0:50:04.21,0:50:10.86,Default,,0000,0000,0000,,have the speed limitation by USB. And, of\Ncourse, if you use the Frida C-bindings
Dialogue: 0,0:50:10.86,0:50:19.25,Default,,0000,0000,0000,,locally on the iOS smartphone, it is a bit\Nfaster, but it's still not perfect. So,
Dialogue: 0,0:50:19.25,0:50:29.44,Default,,0000,0000,0000,,the more you can prevent from this JSON\Npart and the USB part, the better. The
Dialogue: 0,0:50:29.44,0:50:33.89,Default,,0000,0000,0000,,actual fuzzer looks a bit like this. So,\Nyou are in the libARIServer, so that's the
Dialogue: 0,0:50:33.89,0:50:40.52,Default,,0000,0000,0000,,lowest library from the diagram before.\NAnd then you define this inbound message
Dialogue: 0,0:50:40.52,0:50:44.03,Default,,0000,0000,0000,,callback function, which has two\Narguments, which are the payload and the
Dialogue: 0,0:50:44.03,0:50:49.68,Default,,0000,0000,0000,,length. So, this looks a bit cryptic, but\Nthat's basically it. And then you can, but
Dialogue: 0,0:50:49.68,0:50:55.94,Default,,0000,0000,0000,,you don't have to, add this interceptor\Nhere because you might want to fix your
Dialogue: 0,0:50:55.94,0:51:01.54,Default,,0000,0000,0000,,sequence number or add basic block \Ncoverage to your fuzzer, etc. So, this is also
Dialogue: 0,0:51:01.54,0:51:08.50,Default,,0000,0000,0000,,done there. And then you can just call this\Ninbound message callback of ARI and send
Dialogue: 0,0:51:08.50,0:51:17.00,Default,,0000,0000,0000,,ARI payloads. So, this already can be very\Ndifferent. So, if you now call this via
Dialogue: 0,0:51:17.00,0:51:22.58,Default,,0000,0000,0000,,RPC export, via a Python script on your\Nlaptop, you can reach something like 500
Dialogue: 0,0:51:22.58,0:51:27.03,Default,,0000,0000,0000,,fuzz cases per second, if you inject SMS,\Nwhich are quite processing intensive
Dialogue: 0,0:51:27.03,0:51:33.14,Default,,0000,0000,0000,,payload. Or, if you just do the same\Nthing and if you just run this inbound
Dialogue: 0,0:51:33.14,0:51:36.72,Default,,0000,0000,0000,,message callback in a loop, locally with\NJavaScript, without any external Python
Dialogue: 0,0:51:36.72,0:51:42.97,Default,,0000,0000,0000,,script, then you would get 22.000 fuzz\Ncases per second on the very same device.
Dialogue: 0,0:51:42.97,0:51:49.15,Default,,0000,0000,0000,,So this is the speed difference that the\NJSON serialization, deserialization and
Dialogue: 0,0:51:49.15,0:51:57.71,Default,,0000,0000,0000,,the USB in between make. So, I did a few\Nmore measurements, and certainly on the
Dialogue: 0,0:51:57.71,0:52:03.22,Default,,0000,0000,0000,,iPhone 8, there is a bug that prevents me\Nfrom collecting coverage. But, what you
Dialogue: 0,0:52:03.22,0:52:09.70,Default,,0000,0000,0000,,can see is, so, the first part here is if\Nyou have just a bit flipper in a loop that
Dialogue: 0,0:52:09.70,0:52:14.24,Default,,0000,0000,0000,,calls the target function, you can get\N17.000 fuzz cases per second on an iPhone 7.
Dialogue: 0,0:52:14.24,0:52:19.83,Default,,0000,0000,0000,,As soon as you start collecting basic\Nblock coverage, not processing it, just
Dialogue: 0,0:52:19.83,0:52:25.59,Default,,0000,0000,0000,,collecting, you drop to 250 fuzz cases per\Nsecond. So, you need to ask yourself, if
Dialogue: 0,0:52:25.59,0:52:32.25,Default,,0000,0000,0000,,your fuzzer gets really that much better\Nfrom collecting coverage. And another
Dialogue: 0,0:52:32.25,0:52:37.66,Default,,0000,0000,0000,,thing is - that's this line above - so, if you\Njust print the packet, that you fuzzed or
Dialogue: 0,0:52:37.66,0:52:43.40,Default,,0000,0000,0000,,injected and print this via Python to your\Nlaptop, you also have a huge slow down,
Dialogue: 0,0:52:43.40,0:52:47.67,Default,,0000,0000,0000,,which is not as large as the coverage\Nslowdown. But still, you can see every
Dialogue: 0,0:52:47.67,0:52:52.96,Default,,0000,0000,0000,,print and every sending off a message in\Nbetween the Python script and JavaScript
Dialogue: 0,0:52:52.96,0:53:00.69,Default,,0000,0000,0000,,takes a lot of time. Now, if you have this\Nremote SMS injection that I had before,
Dialogue: 0,0:53:00.69,0:53:04.70,Default,,0000,0000,0000,,then you drop to 200 fuzz cases per\Nsecond. So it is a blind injection without
Dialogue: 0,0:53:04.70,0:53:11.65,Default,,0000,0000,0000,,any coverage. If you collect coverage but\Ndon't process coverage, then you are down
Dialogue: 0,0:53:11.65,0:53:15.97,Default,,0000,0000,0000,,to 100 fuzz cases per second. So, for the\Ninitial ToothPicker design, this would be
Dialogue: 0,0:53:15.97,0:53:20.76,Default,,0000,0000,0000,,the optimum. But, because the Radamsa\Nmutator is very slow and because you also
Dialogue: 0,0:53:20.76,0:53:27.54,Default,,0000,0000,0000,,need to process the coverage information,\Net cetera, that's down to 20 fuzz cases
Dialogue: 0,0:53:27.54,0:53:33.50,Default,,0000,0000,0000,,per second. So, this is the comparison\Nhere. And now you can imagine why
Dialogue: 0,0:53:33.50,0:53:39.70,Default,,0000,0000,0000,,collecting coverage probably isn't always\Nuseful and why also having your laptop
Dialogue: 0,0:53:39.70,0:53:45.82,Default,,0000,0000,0000,,calculating better mutation because it's\Neasier to write a mutator there, than
Dialogue: 0,0:53:45.82,0:53:51.85,Default,,0000,0000,0000,,directly in JavaScript, is not always the\Nbest idea. So let's watch one last demo
Dialogue: 0,0:53:51.85,0:53:55.47,Default,,0000,0000,0000,,video. What you can see here, is when you\Ntry to delete SMS, after all of the
Dialogue: 0,0:53:55.47,0:54:01.42,Default,,0000,0000,0000,,fuzzing, it really doesn't work neither\Nvia the settings nor via the SMS app. So,
Dialogue: 0,0:54:01.42,0:54:05.75,Default,,0000,0000,0000,,you really need to reset your iPhone after\Nfuzzing it for too long. No other chance
Dialogue: 0,0:54:05.75,0:54:12.05,Default,,0000,0000,0000,,than this to delete the messages. With\Nthis, we are already at the end of this
Dialogue: 0,0:54:12.05,0:54:17.56,Default,,0000,0000,0000,,talk, but of course, there will be a Q&A\Nsession and if you missed the Q&A session,
Dialogue: 0,0:54:17.56,0:54:22.62,Default,,0000,0000,0000,,you can also ask me on Twitter or write me\Nan email. Thanks for watching!
Dialogue: 0,0:54:31.76,0:54:45.06,Default,,0000,0000,0000,,{\i1}rC3 music{\i0}
Dialogue: 0,0:54:45.06,0:55:12.00,Default,,0000,0000,0000,,Subtitles created by c3subtitles.de\Nin the year 2020. Join, and help us!