[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:13.05,Default,,0000,0000,0000,,{\i1}rC3 preroll music{\i0}
Dialogue: 0,0:00:13.05,0:00:17.73,Default,,0000,0000,0000,,Herald: Our next speaker, Alisa Esage, is\Nan independent vulnerability researcher
Dialogue: 0,0:00:17.73,0:00:22.64,Default,,0000,0000,0000,,and has a notable record of security\Nresearch achievements such as this year,
Dialogue: 0,0:00:22.64,0:00:29.77,Default,,0000,0000,0000,,the initiative Silver Bounty Hunter Awards\N2018. Alisa is going to present her latest
Dialogue: 0,0:00:29.77,0:00:36.01,Default,,0000,0000,0000,,research on the Qualcomm DIAG protocol,\Nwhich is found abundantly in Qualcomm
Dialogue: 0,0:00:36.01,0:00:46.50,Default,,0000,0000,0000,,Hexagon based cellular modems. Alisa,\Nwe're looking forward to your talk now.
Dialogue: 0,0:00:46.50,0:00:49.70,Default,,0000,0000,0000,,Alisa Esage: This is Alisa Esage, you're\Nattending my presentation about Advanced
Dialogue: 0,0:00:49.70,0:01:01.01,Default,,0000,0000,0000,,Hexagon DIAG at Chaos Communication\NCongress 2020 remote experience. My main
Dialogue: 0,0:01:01.01,0:01:06.25,Default,,0000,0000,0000,,interest as advanced vulnerability\Nresearcher is complex systems and hardened
Dialogue: 0,0:01:06.25,0:01:11.92,Default,,0000,0000,0000,,systems. For the last 10 years I have been\Nresearching various classes of software
Dialogue: 0,0:01:11.92,0:01:16.28,Default,,0000,0000,0000,,such as Windows kernel, browsers,\NJavaScript engines. And for the last three
Dialogue: 0,0:01:16.28,0:01:21.88,Default,,0000,0000,0000,,years I was focusing mostly on\NHypervisors. The project that I'm
Dialogue: 0,0:01:21.88,0:01:27.97,Default,,0000,0000,0000,,presenting today was a little side project\Nthat I made for distraction a couple years
Dialogue: 0,0:01:27.97,0:01:37.56,Default,,0000,0000,0000,,ago. The name of this talk Advanced\NHexagon DIAG is a bit of an understatement
Dialogue: 0,0:01:37.56,0:01:45.29,Default,,0000,0000,0000,,in the attempt to keep this talk a little\Nbit low key in the general internet,
Dialogue: 0,0:01:45.29,0:01:50.84,Default,,0000,0000,0000,,because a big part of the talk will\Nactually be devoted to a general
Dialogue: 0,0:01:50.84,0:01:56.71,Default,,0000,0000,0000,,vulnerability research in basebands. But\Nthe primary focus of this talk is on the
Dialogue: 0,0:01:56.71,0:02:02.90,Default,,0000,0000,0000,,Hexagon DIAG, also known as QCDM Qualcomm\Ndiagnostic manager. This is a proprietary
Dialogue: 0,0:02:02.90,0:02:09.23,Default,,0000,0000,0000,,protocol developed by Qualcomm for use in\Ntheir basebands, and it is included on all
Dialogue: 0,0:02:09.23,0:02:18.40,Default,,0000,0000,0000,,Snapdragon SoCs and modem chips produced\Nby Qualcomm. More than Qualcomm chips run
Dialogue: 0,0:02:18.40,0:02:24.30,Default,,0000,0000,0000,,on custom silicone with a custom\Ninstruction set architecture and named
Dialogue: 0,0:02:24.30,0:02:30.93,Default,,0000,0000,0000,,QDSP6 Hexagon. This is important because\Nall the DIAG handlers that we will be
Dialogue: 0,0:02:30.93,0:02:41.70,Default,,0000,0000,0000,,dealing with are written in this\Ninstruction set architecture. As usually
Dialogue: 0,0:02:41.70,0:02:47.77,Default,,0000,0000,0000,,with my talks, I have adjusted the\Nmaterials of this presentation for various
Dialogue: 0,0:02:47.77,0:02:52.66,Default,,0000,0000,0000,,audiences, for the full spectrum of\Naudiences, specifically the first part of
Dialogue: 0,0:02:52.66,0:03:00.70,Default,,0000,0000,0000,,the presentation is mostly specialized for\Nresearch directors and high level
Dialogue: 0,0:03:00.70,0:03:06.72,Default,,0000,0000,0000,,technical staff. And the last part is more\Ndeep technical. And it would be mostly
Dialogue: 0,0:03:06.72,0:03:14.51,Default,,0000,0000,0000,,interesting to specialized vulnerability\Nresearchers and low level programmers that
Dialogue: 0,0:03:14.51,0:03:25.40,Default,,0000,0000,0000,,somehow are related to this particular\Narea. Let's start from the top level
Dialogue: 0,0:03:25.40,0:03:31.54,Default,,0000,0000,0000,,overview of cellular technology. This mind\Nmap presents a simplified view of various
Dialogue: 0,0:03:31.54,0:03:36.74,Default,,0000,0000,0000,,types of entities that we'd have to deal\Nwith with respect to basebands. It's not a
Dialogue: 0,0:03:36.74,0:03:44.66,Default,,0000,0000,0000,,complete diagram, of course, but it only\Npresents the classes of entities that
Dialogue: 0,0:03:44.66,0:03:51.54,Default,,0000,0000,0000,,exist in this space. Also, this mind map\Nis specific to the clean site equipment,
Dialogue: 0,0:03:51.54,0:03:57.11,Default,,0000,0000,0000,,the user equipment and it completely omits\Nany server side considerations which are a
Dialogue: 0,0:03:57.11,0:04:02.29,Default,,0000,0000,0000,,world in their own. There exists quite a\Nlarge number of cellular protocols on the
Dialogue: 0,0:04:02.29,0:04:08.20,Default,,0000,0000,0000,,planet. From the user perspective, this is\Nsimple. This is usually the shared name
Dialogue: 0,0:04:08.20,0:04:15.47,Default,,0000,0000,0000,,3G, 4G that you see on the mobile screen.\NBut in reality, this simple name, that
Dialogue: 0,0:04:15.47,0:04:27.41,Default,,0000,0000,0000,,generation name encodes - may encode\Nseveral different distinct technologies.
Dialogue: 0,0:04:27.41,0:04:32.62,Default,,0000,0000,0000,,There are a few key points about cellular\Nprotocols that are crucial to understand
Dialogue: 0,0:04:32.62,0:04:38.86,Default,,0000,0000,0000,,before starting to approach this area. The\Nfirst one is the concept of a generation.
Dialogue: 0,0:04:38.86,0:04:45.38,Default,,0000,0000,0000,,This is simple. This is simply 1G, 2G and\Nso on. The generic name of the family of
Dialogue: 0,0:04:45.38,0:04:49.91,Default,,0000,0000,0000,,protocols that are supported in a\Nparticular generation. Generation is
Dialogue: 0,0:04:49.91,0:04:55.54,Default,,0000,0000,0000,,simply a marketing name, for users. It\Ndoesn't really have any strict technical
Dialogue: 0,0:04:55.54,0:05:02.20,Default,,0000,0000,0000,,meaning. And generations represent the\Nevolution of cellular protocols in time.
Dialogue: 0,0:05:02.20,0:05:06.84,Default,,0000,0000,0000,,The second most important thing about\Ncellular protocols is the air interface.
Dialogue: 0,0:05:06.84,0:05:13.63,Default,,0000,0000,0000,,This is.. or the protocol, which actually..\Nthis is the lowest level protocol which
Dialogue: 0,0:05:13.63,0:05:20.27,Default,,0000,0000,0000,,defines how exactly the cellular \Nsignal is digitized and read from the
Dialogue: 0,0:05:20.27,0:05:26.70,Default,,0000,0000,0000,,electromagnetic wave and how exactly the\Ndifferent players in this field divide the
Dialogue: 0,0:05:26.70,0:05:32.99,Default,,0000,0000,0000,,space. Historically, there existed two\Nmain implementations of this low level
Dialogue: 0,0:05:32.99,0:05:39.33,Default,,0000,0000,0000,,code called TDMA and CDMA. TDMA means time\Ndivision multiple access, which basically
Dialogue: 0,0:05:39.33,0:05:43.67,Default,,0000,0000,0000,,divides the entire electromagnetic\Nspectrum within the radio band into time
Dialogue: 0,0:05:43.67,0:05:51.49,Default,,0000,0000,0000,,slots that are rotated in a round robin\Nmanner by various mobile phones so that
Dialogue: 0,0:05:51.49,0:06:04.32,Default,,0000,0000,0000,,they speak in turns. TDMA was the base for\Nthe GSM technology. And GSM was the main
Dialogue: 0,0:06:04.32,0:06:09.92,Default,,0000,0000,0000,,protocol used on this planet for a long\Ntime. Another low level implementation is
Dialogue: 0,0:06:09.92,0:06:16.69,Default,,0000,0000,0000,,CDMA. It was a little bit more complex\Nfrom the beginning. It's decoded as coded
Dialogue: 0,0:06:16.69,0:06:24.30,Default,,0000,0000,0000,,division multiple access. And instead of\Ndividing the spectrum in time slots and
Dialogue: 0,0:06:24.30,0:06:32.58,Default,,0000,0000,0000,,dividing the protocol in bursts, CDMA uses\Nrandom codes that are assigned to mobile
Dialogue: 0,0:06:32.58,0:06:43.06,Default,,0000,0000,0000,,phones so that this code can be used as an\Nadditional randomizing mask against the
Dialogue: 0,0:06:43.06,0:06:48.40,Default,,0000,0000,0000,,modulation protocol. And multiple user\Nequipments can talk on the same frequency
Dialogue: 0,0:06:48.40,0:06:57.11,Default,,0000,0000,0000,,without interrupting each other. Note here\Nthat CDMA was developed by Qualcomm and it
Dialogue: 0,0:06:57.11,0:07:03.16,Default,,0000,0000,0000,,was mostly used in the United States. So\Nat the level of 2G, there were two main
Dialogue: 0,0:07:03.16,0:07:11.58,Default,,0000,0000,0000,,protocols, GSM based on the TDMA and the\NcdmaOne based on the CDMA. On the third
Dialogue: 0,0:07:11.58,0:07:17.92,Default,,0000,0000,0000,,generation of mobile protocols these two\Nbranches of development were continued. So
Dialogue: 0,0:07:17.92,0:07:24.16,Default,,0000,0000,0000,,GSM evolved into UMTS, while cdmaOne\Nevolved into CDMA2000. The important point
Dialogue: 0,0:07:24.16,0:07:31.03,Default,,0000,0000,0000,,here is that UMTS has at this point\Nalready adopted the low level air
Dialogue: 0,0:07:31.03,0:07:37.34,Default,,0000,0000,0000,,interface protocol from the CDMA and\Neventually at the fourth generation of
Dialogue: 0,0:07:37.34,0:07:41.24,Default,,0000,0000,0000,,protocols these two branches of\Ndevelopment come together to create the
Dialogue: 0,0:07:41.24,0:07:52.68,Default,,0000,0000,0000,,LTE technology and the same for the 5G.\NThis is a bit important for us as from the
Dialogue: 0,0:07:52.68,0:07:57.91,Default,,0000,0000,0000,,offensive perspective, because first of\Nall, all of this technologies including
Dialogue: 0,0:07:57.91,0:08:04.100,Default,,0000,0000,0000,,the air interfaces represents separate\Nbits of code with separate parsing
Dialogue: 0,0:08:04.100,0:08:09.90,Default,,0000,0000,0000,,algorithms within the baseband firmware.\NAnd all of them are usually presented in
Dialogue: 0,0:08:09.90,0:08:15.10,Default,,0000,0000,0000,,each baseband, regardless of which one you\Nactually use. Does your mobile provider
Dialogue: 0,0:08:15.10,0:08:20.92,Default,,0000,0000,0000,,actually support. Another important and\Nnot obvious thing from the offensive
Dialogue: 0,0:08:20.92,0:08:29.94,Default,,0000,0000,0000,,security perspective here is that because\Nof this, evolutionary development of the..
Dialogue: 0,0:08:29.94,0:08:34.67,Default,,0000,0000,0000,,protocols are not actually completely\Ndistinct. So if you think about LTE, it is
Dialogue: 0,0:08:34.67,0:08:39.29,Default,,0000,0000,0000,,not a completely different protocol from\NGSM, but instead it is based largely on
Dialogue: 0,0:08:39.29,0:08:47.60,Default,,0000,0000,0000,,the same internal structures. And in fact,\Nif you look at the specifications, some of
Dialogue: 0,0:08:47.60,0:08:53.56,Default,,0000,0000,0000,,them are almost directly relevant. The\Nspecifications of the GSM 2G, some of them
Dialogue: 0,0:08:53.56,0:08:59.81,Default,,0000,0000,0000,,are still directly relevant to some extent\Nto LTE. This is also important when you
Dialogue: 0,0:08:59.81,0:09:06.35,Default,,0000,0000,0000,,start analyzing protocols from the\Noffensive perspective. The cellular
Dialogue: 0,0:09:06.35,0:09:17.46,Default,,0000,0000,0000,,protocols are structured in a nested \Nway, in layers. Layers is the official
Dialogue: 0,0:09:17.46,0:09:25.12,Default,,0000,0000,0000,,terminology adopted by the specifications\Nwith the exception of level zero. Here I
Dialogue: 0,0:09:25.12,0:09:29.98,Default,,0000,0000,0000,,just edited it for convenience, but it's\Nin the specifications layer start from one
Dialogue: 0,0:09:29.98,0:09:34.65,Default,,0000,0000,0000,,and proceed to three. From the offensive\Nperspective, the most interesting is level
Dialogue: 0,0:09:34.65,0:09:39.05,Default,,0000,0000,0000,,three, as you can see from the screenshot\Nof the specifications, because it encodes
Dialogue: 0,0:09:39.05,0:09:45.26,Default,,0000,0000,0000,,most of the high level protocol data, such\Nas handling SMS and GSM. This is the part
Dialogue: 0,0:09:45.26,0:09:49.83,Default,,0000,0000,0000,,of the protocol which actually contains\Ninteresting data structures with TLV
Dialogue: 0,0:09:49.83,0:09:58.55,Default,,0000,0000,0000,,values and so on. When people talk about\Nattack in basebands, they usually mean
Dialogue: 0,0:09:58.55,0:10:06.01,Default,,0000,0000,0000,,attack in baseband over the air. Their OTA\Nattack vector, which is definitely one of
Dialogue: 0,0:10:06.01,0:10:11.93,Default,,0000,0000,0000,,the most interesting. But let's take a\Nstep back and consider the entire big
Dialogue: 0,0:10:11.93,0:10:21.07,Default,,0000,0000,0000,,picture of the baseband ecosystem. This\Ndiagram presents a unified view of
Dialogue: 0,0:10:21.07,0:10:28.01,Default,,0000,0000,0000,,generalized architecture of a modern\Nbaseband with attack surfaces. First of
Dialogue: 0,0:10:28.01,0:10:34.68,Default,,0000,0000,0000,,all, there are two separate distinct\Nprocessors: the AP, application processor,
Dialogue: 0,0:10:34.68,0:10:40.14,Default,,0000,0000,0000,,and the MP, which is mobile processor. It\Nmay be either a DSP or another CPU.
Dialogue: 0,0:10:40.14,0:10:45.29,Default,,0000,0000,0000,,Usually there are two separate processors\Nand each one of them runs a separate
Dialogue: 0,0:10:45.29,0:10:51.31,Default,,0000,0000,0000,,operating system. In case of the AP, it\Nmay be Android or iOS and the baseband
Dialogue: 0,0:10:51.31,0:10:55.94,Default,,0000,0000,0000,,processor will draw on some sort of real-\Ntime operating system provided by the
Dialogue: 0,0:10:55.94,0:11:03.40,Default,,0000,0000,0000,,mobile vendor. Important point here that\Non modern implementations, baseband
Dialogue: 0,0:11:03.40,0:11:08.65,Default,,0000,0000,0000,,actually protected by some sort of secure\Nexecution environment, maybe TrustZone on
Dialogue: 0,0:11:08.65,0:11:17.10,Default,,0000,0000,0000,,Androids or SEPOS on Apple devices. Which\Nmeans that the privilege boundary which is
Dialogue: 0,0:11:17.10,0:11:22.82,Default,,0000,0000,0000,,depicted here on the left side is dual\Nsided. So even if you have kernel access
Dialogue: 0,0:11:22.82,0:11:29.74,Default,,0000,0000,0000,,to the Android kernel, you still are not\Nsupposed to be able to read the memory of
Dialogue: 0,0:11:29.74,0:11:33.62,Default,,0000,0000,0000,,the baseband or somehow intersect with its\Noperation, at least on the modern
Dialogue: 0,0:11:33.62,0:11:38.56,Default,,0000,0000,0000,,production smartphones. And the same goes\Naround to the baseband, which is not
Dialogue: 0,0:11:38.56,0:11:45.54,Default,,0000,0000,0000,,supposed to be able to access to application\Nprocessor directly. So these two are
Dialogue: 0,0:11:45.54,0:11:50.19,Default,,0000,0000,0000,,mutually distrusting entities that are\Nseparated from each other. And so there
Dialogue: 0,0:11:50.19,0:12:01.89,Default,,0000,0000,0000,,exists privilege boundary, which is -\Nwhich represents attack surface. Within
Dialogue: 0,0:12:01.89,0:12:07.39,Default,,0000,0000,0000,,the real-time operating systems, there are\Nthree large attack surfaces. Starting from
Dialogue: 0,0:12:07.39,0:12:14.18,Default,,0000,0000,0000,,right to left: the rightmost gray box\Nrepresents the attack surface of the
Dialogue: 0,0:12:14.18,0:12:20.64,Default,,0000,0000,0000,,cellular stacks. This is the code which\Nactually parses the cellular protocols.
Dialogue: 0,0:12:20.64,0:12:31.70,Default,,0000,0000,0000,,It's usually runs in several distant real-\Ntime operating system tasks. And this part
Dialogue: 0,0:12:31.70,0:12:38.52,Default,,0000,0000,0000,,of the attack surface handles all the\Nlayers of the protocol. There is a huge
Dialogue: 0,0:12:38.52,0:12:44.07,Default,,0000,0000,0000,,amount of parsing that happens here. The\Nsecond box represents the various
Dialogue: 0,0:12:44.07,0:12:50.98,Default,,0000,0000,0000,,management protocols. The simplest one to\Nthink about is the AT command protocol. It
Dialogue: 0,0:12:50.98,0:12:56.70,Default,,0000,0000,0000,,is still widely included in all basebands,\Nand it's even usually exposed in some way
Dialogue: 0,0:12:56.70,0:13:01.28,Default,,0000,0000,0000,,to the application processor. So you can\Nactually send some AT commands to the
Dialogue: 0,0:13:01.28,0:13:09.00,Default,,0000,0000,0000,,cellular modem. About a bit more interesting\Nis the vendor specific management
Dialogue: 0,0:13:09.00,0:13:16.68,Default,,0000,0000,0000,,protocols, one of them is the DIAG\Nprotocol. Because the modern basebands are
Dialogue: 0,0:13:16.68,0:13:22.57,Default,,0000,0000,0000,,very complex. So vendors need some sort of\Nspecialized protocol to enable
Dialogue: 0,0:13:22.57,0:13:28.91,Default,,0000,0000,0000,,configuration and diagnostics for the\NOEM's. In case of Qualcomm, for example,
Dialogue: 0,0:13:28.91,0:13:37.17,Default,,0000,0000,0000,,DIAG is just one of the many diagnostic\Nprotocols involved. The third box is what
Dialogue: 0,0:13:37.17,0:13:45.35,Default,,0000,0000,0000,,I call the RTOS core, it is various\Ncore level functionality, such as the
Dialogue: 0,0:13:45.35,0:13:57.77,Default,,0000,0000,0000,,code, which implements that interface to\Nthe application processor. On the side of
Dialogue: 0,0:13:57.77,0:14:04.02,Default,,0000,0000,0000,,the application operating system such as\NAndroid, there are also 2 attack surfaces
Dialogue: 0,0:14:04.02,0:14:10.37,Default,,0000,0000,0000,,that are attackable from the baseband. The\Nfirst one is the peripheral drivers,
Dialogue: 0,0:14:10.37,0:14:13.58,Default,,0000,0000,0000,,because the basement is a separate part of\Nperipherals. So it requires some
Dialogue: 0,0:14:13.58,0:14:21.11,Default,,0000,0000,0000,,specialized drivers that handle I/O and\Nsuch things. And the second one is the
Dialogue: 0,0:14:21.11,0:14:29.00,Default,,0000,0000,0000,,dark surface represented with various\Ninterface handlers because the baseband
Dialogue: 0,0:14:29.00,0:14:34.80,Default,,0000,0000,0000,,and the main operating system cannot\Ncommunicate directly. They use some sort
Dialogue: 0,0:14:34.80,0:14:39.84,Default,,0000,0000,0000,,of a specialized interface to do that. In\Ncase of Qualcomm this is shared memory.
Dialogue: 0,0:14:39.84,0:14:44.67,Default,,0000,0000,0000,,And so this shared memory implementations\Nare usually quite complex and they
Dialogue: 0,0:14:44.67,0:14:51.46,Default,,0000,0000,0000,,represent an attack surface on the both \Nsides. And finally, the third piece of this
Dialogue: 0,0:14:51.46,0:14:57.32,Default,,0000,0000,0000,,diagram is in the lowest part. I have\Ndepicted two grey boxes which are related
Dialogue: 0,0:14:57.32,0:15:03.14,Default,,0000,0000,0000,,to the trusted execution environment.\NBecause typically a modem runs as a
Dialogue: 0,0:15:03.14,0:15:11.38,Default,,0000,0000,0000,,Trustled in a secure environment. So\Ntechnically, the attack surfaces that
Dialogue: 0,0:15:11.38,0:15:16.55,Default,,0000,0000,0000,,exists within TrustZone or related to it\Nalso can be useful for baseband offensive
Dialogue: 0,0:15:16.55,0:15:22.89,Default,,0000,0000,0000,,research. Here we can distinguish at least\Ntwo large attack surfaces. The first one
Dialogue: 0,0:15:22.89,0:15:31.49,Default,,0000,0000,0000,,is the secure manager of call handlers, \Nwhich is the core interface that
Dialogue: 0,0:15:31.49,0:15:36.96,Default,,0000,0000,0000,,handles calls from the application\Nprocessor to the TrustZone. And the second
Dialogue: 0,0:15:36.96,0:15:44.81,Default,,0000,0000,0000,,one are the Trustlets. They are separate\Npieces of code which are executed and
Dialogue: 0,0:15:44.81,0:15:56.79,Default,,0000,0000,0000,,protected by the TrustZone. On this\Ndiagram, I have also added some
Dialogue: 0,0:15:56.79,0:16:02.84,Default,,0000,0000,0000,,information about data codex, I'm not sure\Nif they are supposed to be in the RTOS
Dialogue: 0,0:16:02.84,0:16:06.32,Default,,0000,0000,0000,,core because these things are directly\Naccessible from the cellular stacks
Dialogue: 0,0:16:06.32,0:16:14.96,Default,,0000,0000,0000,,usually, especially ASN. 1, which I have\Nseen some bugs reachable from the over the
Dialogue: 0,0:16:14.96,0:16:23.01,Default,,0000,0000,0000,,air interface. On this diagram, I have\Nshown some example of vulnerabilities. I
Dialogue: 0,0:16:23.01,0:16:26.77,Default,,0000,0000,0000,,will not discuss them in details here\Nsince it's not the point of the
Dialogue: 0,0:16:26.77,0:16:32.48,Default,,0000,0000,0000,,presentation, but at least the ones from\NBaodong, you can find the writeups on
Dialogue: 0,0:16:32.48,0:16:46.59,Default,,0000,0000,0000,,the Internet. To discuss baseband\Noffensive tools and approaches, I have
Dialogue: 0,0:16:46.59,0:16:50.72,Default,,0000,0000,0000,,narrowed down the previous diagram to just\None attack surface, the over the air
Dialogue: 0,0:16:50.72,0:16:55.62,Default,,0000,0000,0000,,attack surface. This is the attack\Nsurface, which is represented by parsing
Dialogue: 0,0:16:55.62,0:16:59.48,Default,,0000,0000,0000,,implementations of various cellular\Nprotocols inside the baseband operating
Dialogue: 0,0:16:59.48,0:17:06.61,Default,,0000,0000,0000,,system. And this is the attack surface\Nthat we can reach from the air interface.
Dialogue: 0,0:17:06.61,0:17:13.39,Default,,0000,0000,0000,,In order to accomplish that, we need a\Ntransceiver such as software defined radio
Dialogue: 0,0:17:13.39,0:17:21.17,Default,,0000,0000,0000,,or a mobile tester, which is able to talk\Nthe specific cellular protocol that we're
Dialogue: 0,0:17:21.17,0:17:28.78,Default,,0000,0000,0000,,planning to attack. The simplest way to\Naccomplish this is use some sort of a
Dialogue: 0,0:17:28.78,0:17:34.73,Default,,0000,0000,0000,,software defined radio, such as Ettus\Nresearch USRP or blade RF and install open
Dialogue: 0,0:17:34.73,0:17:41.24,Default,,0000,0000,0000,,source implementation of a base station\Nsuch as OpenBTS or OpenBSC. The thing to
Dialogue: 0,0:17:41.24,0:17:50.05,Default,,0000,0000,0000,,note here is that the software based\Nimplementations actually lagged behind the
Dialogue: 0,0:17:50.05,0:17:54.97,Default,,0000,0000,0000,,development of technologies.\NImplementations of GSM base stations are
Dialogue: 0,0:17:54.97,0:18:03.63,Default,,0000,0000,0000,,very well established and popular, such as\NOpenBTS. And in fact, when I tried to
Dialogue: 0,0:18:03.63,0:18:15.14,Default,,0000,0000,0000,,establish BTS with my USRP, it was quite\Nsimple. For UMTS and LTE, there exists less
Dialogue: 0,0:18:15.14,0:18:19.95,Default,,0000,0000,0000,,number of software based implementations\Nand also there are more constraints on the
Dialogue: 0,0:18:19.95,0:18:26.31,Default,,0000,0000,0000,,hardware. For example, my model of the\NUSRP does not support UMTS due to resource
Dialogue: 0,0:18:26.31,0:18:31.69,Default,,0000,0000,0000,,constraints. And the most interesting\Nthing here is that there does not exist
Dialogue: 0,0:18:31.69,0:18:36.58,Default,,0000,0000,0000,,any software based implementation on the\NCDMA that you can use to establish a base
Dialogue: 0,0:18:36.58,0:18:53.27,Default,,0000,0000,0000,,station. This is a pseudorandom diagram of\None of the Snapdragon chips. There exists
Dialogue: 0,0:18:53.27,0:18:58.82,Default,,0000,0000,0000,,a huge amount of various models of\NSnapdragons. This one I have chosen
Dialogue: 0,0:18:58.82,0:19:05.68,Default,,0000,0000,0000,,pseudorandomly when I was searching for\Nsome sort of visual diagram. Qualcomm used
Dialogue: 0,0:19:05.68,0:19:12.03,Default,,0000,0000,0000,,to include some high level diagrams of the\Narchitecture in their marketing materials
Dialogue: 0,0:19:12.03,0:19:19.40,Default,,0000,0000,0000,,previously. But since they don't do this\Nanymore. And this particular diagram is
Dialogue: 0,0:19:19.40,0:19:26.82,Default,,0000,0000,0000,,from a technical specification of a\Nparticular model 820. Also this particular
Dialogue: 0,0:19:26.82,0:19:34.42,Default,,0000,0000,0000,,model Snapdragon is... a bit interesting\Nbecause it is the first one that included
Dialogue: 0,0:19:34.42,0:19:44.79,Default,,0000,0000,0000,,the artificial intelligence agent, which\Nis also based on Hexagon. For all
Dialogue: 0,0:19:44.79,0:19:52.89,Default,,0000,0000,0000,,purposes, the main interest here are the\Nprocessors. Majority of snapdragons
Dialogue: 0,0:19:52.89,0:19:59.63,Default,,0000,0000,0000,,include quite a long list of processors.\NThere are at least 4 ARM-based Kryo-CPUs
Dialogue: 0,0:19:59.63,0:20:11.48,Default,,0000,0000,0000,,that actually run the Android operating\Nsystem. Then there are the Adreno GPUs and
Dialogue: 0,0:20:11.48,0:20:16.38,Default,,0000,0000,0000,,then there are several Hexagons. On the\Nmost recent models there is not just one
Dialogue: 0,0:20:16.38,0:20:23.36,Default,,0000,0000,0000,,Hexagon processing unit, but several of\Nthem. And they are called respectively to
Dialogue: 0,0:20:23.36,0:20:28.03,Default,,0000,0000,0000,,their purposes. Each one of them, each one\Nof these Hexagon cores is responsible for
Dialogue: 0,0:20:28.03,0:20:35.77,Default,,0000,0000,0000,,handling a specific functionality. For\Nexample, MDSB handles modem and runs the
Dialogue: 0,0:20:35.77,0:20:44.26,Default,,0000,0000,0000,,real-time operating system. The ADSP\Nhandles media and the CDSP handles
Dialogue: 0,0:20:44.26,0:20:52.54,Default,,0000,0000,0000,,compute. So the Hexagons actually\Nrepresent around one half of the
Dialogue: 0,0:20:52.54,0:21:08.77,Default,,0000,0000,0000,,processing power, more than Snapdragons.\NThere are two key points about the Hexagon
Dialogue: 0,0:21:08.77,0:21:17.50,Default,,0000,0000,0000,,architecture from the hardware\Nperspective. First of all, it is- Hexagon
Dialogue: 0,0:21:17.50,0:21:25.41,Default,,0000,0000,0000,,is specialized to parallel processing. And\Nso the first concept is variable size
Dialogue: 0,0:21:25.41,0:21:31.00,Default,,0000,0000,0000,,destruction packets. It means that\Nseveral instructions can execute
Dialogue: 0,0:21:31.00,0:21:42.33,Default,,0000,0000,0000,,simultaneously in separate execution\Nunits. It also uses hardware
Dialogue: 0,0:21:42.33,0:21:48.99,Default,,0000,0000,0000,,multithreading for the same purposes. On\Nthe right side of the slide here is some
Dialogue: 0,0:21:48.99,0:22:00.63,Default,,0000,0000,0000,,example of the Hexagon assembly. It is\Nquite funny at times. This curly brackets
Dialogue: 0,0:22:00.63,0:22:07.16,Default,,0000,0000,0000,,should present the instructions that are\Nexecuted simultaneously. And these
Dialogue: 0,0:22:07.16,0:22:15.50,Default,,0000,0000,0000,,instructions must be compactable in order\Nto be able to use that distant processing
Dialogue: 0,0:22:15.50,0:22:21.04,Default,,0000,0000,0000,,slots. And then there is the funny .new\Nnotation which actually enables the
Dialogue: 0,0:22:21.04,0:22:26.05,Default,,0000,0000,0000,,instructions to use both the old and the\Nnew value of a particular register within
Dialogue: 0,0:22:26.05,0:22:32.85,Default,,0000,0000,0000,,the same instruction cycle. This provides\Nquite a bit of optimization on the lower
Dialogue: 0,0:22:32.85,0:22:41.20,Default,,0000,0000,0000,,level. For more information, I can direct\Nyou to the Hexagon Specification and
Dialogue: 0,0:22:41.20,0:22:53.83,Default,,0000,0000,0000,,programmers reference manual, which is\Navailable from the Qualcomm website. The
Dialogue: 0,0:22:53.83,0:22:59.27,Default,,0000,0000,0000,,concept of production fusing is quite\Ncommon. As I said previously, it's a
Dialogue: 0,0:22:59.27,0:23:05.59,Default,,0000,0000,0000,,common practice from mobile device vendors\Nto lock down the devices before they enter
Dialogue: 0,0:23:05.59,0:23:11.54,Default,,0000,0000,0000,,the market to prevent modifications and\Ntinkering. And for the purposes of this
Dialogue: 0,0:23:11.54,0:23:17.30,Default,,0000,0000,0000,,locking down, they usually- there are\Nseveral ways how this can be accomplished.
Dialogue: 0,0:23:17.30,0:23:24.36,Default,,0000,0000,0000,,Usually various advanced diagnostic and\Ndebugging functionalities are removed from
Dialogue: 0,0:23:24.36,0:23:30.82,Default,,0000,0000,0000,,either software or hardware or both. It is\Nquite common that this functionalities are
Dialogue: 0,0:23:30.82,0:23:37.18,Default,,0000,0000,0000,,only removed from software while the\Nhardware remains here. And in such case,
Dialogue: 0,0:23:37.18,0:23:43.87,Default,,0000,0000,0000,,we will- eventually the researchers will\Ncome up with their own software based
Dialogue: 0,0:23:43.87,0:23:50.05,Default,,0000,0000,0000,,implementation. All this functionality as\Nin case with some custom iOS kernel
Dialogue: 0,0:23:50.05,0:23:55.91,Default,,0000,0000,0000,,debuggers, for example. In case of\NQualcomm, there was at some point a leaked
Dialogue: 0,0:23:55.91,0:24:02.42,Default,,0000,0000,0000,,internal memo which discusses what exactly\Nthey are doing for production fusing the
Dialogue: 0,0:24:02.42,0:24:15.73,Default,,0000,0000,0000,,devices. In addition to our production\Nfusing in case of modern Androids, the
Dialogue: 0,0:24:15.73,0:24:22.86,Default,,0000,0000,0000,,baseband runs within the trust zone. And\Non my implementation, it is already quite
Dialogue: 0,0:24:22.86,0:24:28.68,Default,,0000,0000,0000,,locked down. It uses a separate component.\NThe baseband uses a separate component
Dialogue: 0,0:24:28.68,0:24:36.51,Default,,0000,0000,0000,,named the MBA this stands for the modem\Nbasic authenticator. And this entire thing
Dialogue: 0,0:24:36.51,0:24:42.21,Default,,0000,0000,0000,,is run by the subsystem of Android kernel\Nnamed PILO, the peripheral image loader.
Dialogue: 0,0:24:42.21,0:24:50.82,Default,,0000,0000,0000,,You can open the source code and\Ninvestigate how exactly it looks. And the
Dialogue: 0,0:24:50.82,0:24:57.43,Default,,0000,0000,0000,,purpose of the MBA is to authenticate the\Nmodem firmware so that you would not be
Dialogue: 0,0:24:57.43,0:25:04.00,Default,,0000,0000,0000,,able to inject some arbitrary commands\Ninto the modem firmware and flash it. This
Dialogue: 0,0:25:04.00,0:25:09.25,Default,,0000,0000,0000,,is another side of the hardening, which\Nmakes it very difficult to inject any
Dialogue: 0,0:25:09.25,0:25:13.26,Default,,0000,0000,0000,,arbitrary code into the baseband.\NBasically, the only way to do this is
Dialogue: 0,0:25:13.26,0:25:23.13,Default,,0000,0000,0000,,through a software vulnerability. During\Nthis project I have reverse engineered
Dialogue: 0,0:25:23.13,0:25:33.36,Default,,0000,0000,0000,,partially the Hexagon modem firmware from\Nmy implementation, from my Nexus 6b. The
Dialogue: 0,0:25:33.36,0:25:38.77,Default,,0000,0000,0000,,process of reverse engineering is not very\Ndifficult because all you need is to
Dialogue: 0,0:25:38.77,0:25:44.95,Default,,0000,0000,0000,,download the firmware from the website,\NGoogles website in this case. Then you
Dialogue: 0,0:25:44.95,0:25:50.96,Default,,0000,0000,0000,,need to find the binary which corresponds\Nto the modem firmware. This binary is
Dialogue: 0,0:25:50.96,0:25:57.68,Default,,0000,0000,0000,,actually a compound binary that must be\Ndivided into separate binaries that
Dialogue: 0,0:25:57.68,0:26:04.94,Default,,0000,0000,0000,,represent specific sections inside the\Nfirmware. And for that purpose we can use
Dialogue: 0,0:26:04.94,0:26:11.41,Default,,0000,0000,0000,,the unified Trustlet script. After you\Nhave split the baseband firmware into separate
Dialogue: 0,0:26:11.41,0:26:18.27,Default,,0000,0000,0000,,sections, you can load them into IDA Pro.\NThere are several plugins available for
Dialogue: 0,0:26:18.27,0:26:26.11,Default,,0000,0000,0000,,IDA Pro that support Hexagon. I have tried\None of them. I think it was GSMK and it
Dialogue: 0,0:26:26.11,0:26:35.65,Default,,0000,0000,0000,,works quite good for basic reverse\Nengineering purposes. Notable here is that
Dialogue: 0,0:26:35.65,0:26:41.66,Default,,0000,0000,0000,,some sections of the modem firmware are\Ncompressed and relocated at runtime, so
Dialogue: 0,0:26:41.66,0:26:48.35,Default,,0000,0000,0000,,you would not be able to reverse engineer\Nthem. And unless you can decompress them,
Dialogue: 0,0:26:48.35,0:26:52.27,Default,,0000,0000,0000,,which is also a bit of a challenge because\Nthe Qualcomm uses some internal
Dialogue: 0,0:26:52.27,0:27:02.00,Default,,0000,0000,0000,,compression algorithm for that. For the\Nreverse engineering the main approach here
Dialogue: 0,0:27:02.00,0:27:06.01,Default,,0000,0000,0000,,is to get started with some root points,\Nfor example, because this is a real time
Dialogue: 0,0:27:06.01,0:27:11.29,Default,,0000,0000,0000,,operating system, we know that it should\Nhave some task structures and task
Dialogue: 0,0:27:11.29,0:27:16.34,Default,,0000,0000,0000,,structures that we can locate. And from\Nthere we can locate some interesting code.
Dialogue: 0,0:27:16.34,0:27:20.16,Default,,0000,0000,0000,,In case of Hexagon this is a bit non-\Ntrivial because, as I said, it doesn't
Dialogue: 0,0:27:20.16,0:27:24.93,Default,,0000,0000,0000,,have any log strings. So even though you\Nmay locate something that looks like a
Dialogue: 0,0:27:24.93,0:27:30.53,Default,,0000,0000,0000,,task struct, but it's not clear which code\Ndoes it actually represent. So the first
Dialogue: 0,0:27:30.53,0:27:43.36,Default,,0000,0000,0000,,step here is to apply the log strings that\Nwere removed from the binary by Qshrink. I
Dialogue: 0,0:27:43.36,0:27:51.92,Default,,0000,0000,0000,,think the only way to do it is by using\Nthat msg_hash.txt file from the leaked
Dialogue: 0,0:27:51.92,0:27:57.59,Default,,0000,0000,0000,,sources. This file is not supposed to be\Navailable neither on the mobile devices
Dialogue: 0,0:27:57.59,0:28:05.47,Default,,0000,0000,0000,,nor in some open ecosystem. And after you\Nhave applied these log strings, you will
Dialogue: 0,0:28:05.47,0:28:10.84,Default,,0000,0000,0000,,be able to rename some functions. And\Nbased on these log strings and because the
Dialogue: 0,0:28:10.84,0:28:17.42,Default,,0000,0000,0000,,log strings often contain the names of the\Nsource file, source module from which the
Dialogue: 0,0:28:17.42,0:28:27.09,Default,,0000,0000,0000,,code was built. So it creates opportunity\Nto understand what exactly this code is
Dialogue: 0,0:28:27.09,0:28:34.92,Default,,0000,0000,0000,,doing. Debugging was completely\Nunavailable in my case, and I realized
Dialogue: 0,0:28:34.92,0:28:44.82,Default,,0000,0000,0000,,that it would require some couple of\Nmonths more work to make it work and the
Dialogue: 0,0:28:44.82,0:28:49.49,Default,,0000,0000,0000,,only way I think, and the best way is to\Ncreate a software based debugger similar
Dialogue: 0,0:28:49.49,0:28:57.10,Default,,0000,0000,0000,,to modkit, the publication that I will be\Nreferencing in the references, based on
Dialogue: 0,0:28:57.10,0:29:05.52,Default,,0000,0000,0000,,software vulnerability in either the modem\Nitself or in some authenticator or in the
Dialogue: 0,0:29:05.52,0:29:09.70,Default,,0000,0000,0000,,trust zone so that we can inject a\Nsoftware debugger callbacks into the
Dialogue: 0,0:29:09.70,0:29:20.18,Default,,0000,0000,0000,,baseband and connect it to the GDB stop.\NThis is how the part of the firmware looks
Dialogue: 0,0:29:20.18,0:29:28.04,Default,,0000,0000,0000,,that has log strings stripped out. Here it\Nalready has some names applied using IDA
Dialogue: 0,0:29:28.04,0:29:32.94,Default,,0000,0000,0000,,script. So of course there was no such\Nnames initially, only the hashes. Each one
Dialogue: 0,0:29:32.94,0:29:38.45,Default,,0000,0000,0000,,of these hashes represent a log string\Nthat you can take in from the message hash
Dialogue: 0,0:29:38.45,0:29:48.72,Default,,0000,0000,0000,,file. And here is what you can get after\Nyou have applied the textual messages and
Dialogue: 0,0:29:48.72,0:29:54.12,Default,,0000,0000,0000,,renamed some functions. In this case, you\Nwould be able to find some hundreds of
Dialogue: 0,0:29:54.12,0:29:59.60,Default,,0000,0000,0000,,procedures that are directly related to\Nthe DIAG subsystem. And in a similar way
Dialogue: 0,0:29:59.60,0:30:07.46,Default,,0000,0000,0000,,you can locate various subsystems related\Nto over the air vectors as well. But
Dialogue: 0,0:30:07.46,0:30:17.65,Default,,0000,0000,0000,,unfortunately, majority of the OTA vectors\Nare located in the segments that are not
Dialogue: 0,0:30:17.65,0:30:23.19,Default,,0000,0000,0000,,immediately available in the firmware, the\Nones that are compressed and relocated.
Dialogue: 0,0:30:23.19,0:30:31.36,Default,,0000,0000,0000,,Meanwhile, I have tried many different\Nthings during this project. The things
Dialogue: 0,0:30:31.36,0:30:37.36,Default,,0000,0000,0000,,that definitely worked is building the MSM\Nkernel. There is nothing special about
Dialogue: 0,0:30:37.36,0:30:44.98,Default,,0000,0000,0000,,this, just a regular cross-build. Another\Ncommonly well known offensive approach is
Dialogue: 0,0:30:44.98,0:30:50.28,Default,,0000,0000,0000,,firmware downgrades. When you take some\Nold firmware that contains a well-known
Dialogue: 0,0:30:50.28,0:30:56.07,Default,,0000,0000,0000,,security vulnerability and flash it and\Nuse the bug to create and exploit to
Dialogue: 0,0:30:56.07,0:31:06.68,Default,,0000,0000,0000,,achieve some additional functionality or\Nintrospection into the system. This part
Dialogue: 0,0:31:06.68,0:31:13.39,Default,,0000,0000,0000,,definitely works, downgrades are trivial\Nboth on the entire firmware and a modem as
Dialogue: 0,0:31:13.39,0:31:18.87,Default,,0000,0000,0000,,well as the trust zone. I did try to build\Nthe Qualcomm firmware from the leaked
Dialogue: 0,0:31:18.87,0:31:23.42,Default,,0000,0000,0000,,source codes. I assigned just a few days\Nto the task since it's not mission-
Dialogue: 0,0:31:23.42,0:31:29.70,Default,,0000,0000,0000,,critical and I have run out of time,\Nprobably was a different version of sorce
Dialogue: 0,0:31:29.70,0:31:37.82,Default,,0000,0000,0000,,codes. But actually, this is not a\Ncritical project because building leaked
Dialogue: 0,0:31:37.82,0:31:42.25,Default,,0000,0000,0000,,firmware is not directly relevant to\Nfinding new bugs in the production
Dialogue: 0,0:31:42.25,0:31:53.14,Default,,0000,0000,0000,,firmware. So I just said it aside for some\Nlater investigation. I have also
Dialogue: 0,0:31:53.14,0:31:58.38,Default,,0000,0000,0000,,investigated the ramdump's ecosystem a\Nlittle bit on the software side at least.
Dialogue: 0,0:31:58.38,0:32:10.64,Default,,0000,0000,0000,,And it seems that it's also fused quite\Nreliably. This is when I remembered about
Dialogue: 0,0:32:10.64,0:32:16.89,Default,,0000,0000,0000,,the Qualcomm DIAG. During the initial\Nreconnaisance I stumbled on some
Dialogue: 0,0:32:16.89,0:32:23.72,Default,,0000,0000,0000,,whitepapers and slides that mentioned the\NQualcomm diagnostic protocol. And it
Dialogue: 0,0:32:23.72,0:32:27.96,Default,,0000,0000,0000,,seemed like quite a powerful protocol,\Nspecifically with respect to reconfiguring
Dialogue: 0,0:32:27.96,0:32:33.91,Default,,0000,0000,0000,,the baseband. So I decided to, first of\Nall, to test it in case that it would
Dialogue: 0,0:32:33.91,0:32:37.81,Default,,0000,0000,0000,,actually provide some advanced\Nintrospection functionality and then
Dialogue: 0,0:32:37.81,0:32:48.79,Default,,0000,0000,0000,,probably to use it.. to use the protocol for\Nenabling log dumps. Qualcomm DIAG or QCDM
Dialogue: 0,0:32:48.79,0:32:53.29,Default,,0000,0000,0000,,is a proprietary protocol developed by\NQualcomm with the purposes of advanced
Dialogue: 0,0:32:53.29,0:32:59.91,Default,,0000,0000,0000,,baseband software configuration and\Ndiagnostics. It is mostly aimed for OEM
Dialogue: 0,0:32:59.91,0:33:07.41,Default,,0000,0000,0000,,developers, not for users. The Qualcomm\NDIAG protocol consists of around 200
Dialogue: 0,0:33:07.41,0:33:14.66,Default,,0000,0000,0000,,commands at least in theory. Some of them\Nare quite powerful on paper such as
Dialogue: 0,0:33:14.66,0:33:25.45,Default,,0000,0000,0000,,downloader mode and read/write memory.\NInitially the DIAG was partially reverse
Dialogue: 0,0:33:25.45,0:33:33.58,Default,,0000,0000,0000,,engineered around 2010 and included in the\Nopen source project named Modem Manager.
Dialogue: 0,0:33:33.58,0:33:39.68,Default,,0000,0000,0000,,And then it was also exposed in a\Npresentation at the Chaos Communication
Dialogue: 0,0:33:39.68,0:33:49.84,Default,,0000,0000,0000,,Congress 2011 by Guillaume Delugré. I\Nthink this presentation popularized it and
Dialogue: 0,0:33:49.84,0:33:55.05,Default,,0000,0000,0000,,this is the one that introduced me to this\Nprotocol. Unfortunately, that presentation
Dialogue: 0,0:33:55.05,0:34:01.77,Default,,0000,0000,0000,,is not really relevant - majority of it -\Nto modern production phones, but it does
Dialogue: 0,0:34:01.77,0:34:08.20,Default,,0000,0000,0000,,provide a high level overview and a\Ngeneral expectation of what you will have
Dialogue: 0,0:34:08.20,0:34:15.15,Default,,0000,0000,0000,,to deal with. From the offensive\Nperspective, the DIAG protocol represents
Dialogue: 0,0:34:15.15,0:34:21.24,Default,,0000,0000,0000,,a local attack vector from the application\Nprocessor to the baseband. A common
Dialogue: 0,0:34:21.24,0:34:27.32,Default,,0000,0000,0000,,scenario of how it can be useful is\Nunlocking mobile phones which are locked
Dialogue: 0,0:34:27.32,0:34:33.27,Default,,0000,0000,0000,,to a particular mobile carrier. If we find\Na memory corruption vulnerability in DIAG
Dialogue: 0,0:34:33.27,0:34:40.83,Default,,0000,0000,0000,,protocol, it may be possible to execute a\Ncall directly on the baseband and change
Dialogue: 0,0:34:40.83,0:34:45.09,Default,,0000,0000,0000,,some internal settings. This is usually\Naccomplished historically through the IT
Dialogue: 0,0:34:45.09,0:34:51.43,Default,,0000,0000,0000,,common handlers, but internal proprietary\Nprotocols are also very convenient for
Dialogue: 0,0:34:51.43,0:34:59.74,Default,,0000,0000,0000,,that. The second scenario how that diag\Noffensive can be useful is using it for
Dialogue: 0,0:34:59.74,0:35:08.75,Default,,0000,0000,0000,,injecting a software based debugger. If\Nyou can find a bug in DIAG that enables
Dialogue: 0,0:35:08.75,0:35:14.44,Default,,0000,0000,0000,,read/write capability on the baseband, you\Ncan inject some debugging hooks and
Dialogue: 0,0:35:14.44,0:35:22.51,Default,,0000,0000,0000,,eventually connect it to a GDB stop. So it\Nenables to create a software based
Dialogue: 0,0:35:22.51,0:35:32.45,Default,,0000,0000,0000,,debugger even when GTAG is not available.\NWhat has changed in DIAG in 10 years based
Dialogue: 0,0:35:32.45,0:35:37.75,Default,,0000,0000,0000,,on some cursory investigation that I did.\NFirst of all, the original publication
Dialogue: 0,0:35:37.75,0:35:46.39,Default,,0000,0000,0000,,mentioned Qualcomm baseband based on ARM\Nand with a Rex operating system. All modern
Dialogue: 0,0:35:46.39,0:35:50.77,Default,,0000,0000,0000,,Qualcomm basements are based on\NHexagon as opposed to ARM. And the Rex
Dialogue: 0,0:35:50.77,0:35:57.47,Default,,0000,0000,0000,,operating system was replaced with Kirt,\Nwhich I think is still has some bits of
Dialogue: 0,0:35:57.47,0:36:05.36,Default,,0000,0000,0000,,Rex, but in general it's a different\Noperating system. Majority of super
Dialogue: 0,0:36:05.36,0:36:09.92,Default,,0000,0000,0000,,powerful commands of DIAG such as\Ndownloader mode and memory read/write were
Dialogue: 0,0:36:09.92,0:36:17.37,Default,,0000,0000,0000,,removed, at least on my device. And also\Nit does not expose any immediately
Dialogue: 0,0:36:17.37,0:36:25.58,Default,,0000,0000,0000,,available interfaces such as USB channel.\NI hear that it's possible to enable the
Dialogue: 0,0:36:25.58,0:36:37.04,Default,,0000,0000,0000,,USB DIAG channel by adding some special\Nboot properties, but usually it's not, it
Dialogue: 0,0:36:37.04,0:36:42.65,Default,,0000,0000,0000,,wouldn't be available. It shouldn't be\Nexpected to be available on all devices.
Dialogue: 0,0:36:42.65,0:36:48.60,Default,,0000,0000,0000,,So this observations are based on my test\Ndevice, Nexus 6b. And this this should be
Dialogue: 0,0:36:48.60,0:36:57.15,Default,,0000,0000,0000,,around medium level of hardening. More\Nmodern devices such as Google pixels, the
Dialogue: 0,0:36:57.15,0:37:02.80,Default,,0000,0000,0000,,modern ones should be expected to be even\Nmore hardened than that. Especially on the
Dialogue: 0,0:37:02.80,0:37:07.72,Default,,0000,0000,0000,,Google side, because they take hardening\Nvery seriously. As opposed to it on the
Dialogue: 0,0:37:07.72,0:37:14.63,Default,,0000,0000,0000,,other side of the spectrum if you think\Nabout some no name modem sticks, these
Dialogue: 0,0:37:14.63,0:37:24.33,Default,,0000,0000,0000,,things can be more open and more easy to\Ninvestigate. The DIAG implementation
Dialogue: 0,0:37:24.33,0:37:29.12,Default,,0000,0000,0000,,architecture is relatively simple. This\Ndiagram is based roughly on the same
Dialogue: 0,0:37:29.12,0:37:34.32,Default,,0000,0000,0000,,diagram that I presented in the beginning\Nof talk. On the left side there is the
Dialogue: 0,0:37:34.32,0:37:42.10,Default,,0000,0000,0000,,Android kernel and on the right side there\Nis the baseband operating system. DIAG
Dialogue: 0,0:37:42.10,0:37:47.16,Default,,0000,0000,0000,,protocol actually it works in both sides.\NIt's not only commands that can be sent by
Dialogue: 0,0:37:47.16,0:37:51.00,Default,,0000,0000,0000,,the application processor to the baseband,\Nbut it's also the messages that can be
Dialogue: 0,0:37:51.00,0:37:55.73,Default,,0000,0000,0000,,sent by the baseband to the application\Nprocessor. So DIAG comments are not really
Dialogue: 0,0:37:55.73,0:38:02.15,Default,,0000,0000,0000,,comments - they're more like tokens that\Nalso can be used to encode messages. The
Dialogue: 0,0:38:02.15,0:38:10.27,Default,,0000,0000,0000,,green arrows on this slide represents an\Nexample of call flow, of the data flow
Dialogue: 0,0:38:10.27,0:38:14.61,Default,,0000,0000,0000,,originating from the baseband and going to\Nthe application processor. So obviously,
Dialogue: 0,0:38:14.61,0:38:25.82,Default,,0000,0000,0000,,in case of commands there would be a\Nreverse call flow or data flow. The main
Dialogue: 0,0:38:25.82,0:38:29.81,Default,,0000,0000,0000,,entity inside the operating system,\Nbaseband operating system responsible for
Dialogue: 0,0:38:29.81,0:38:37.23,Default,,0000,0000,0000,,DIAG is the DIAG task. It has a separate\Ntask which handles specifically various
Dialogue: 0,0:38:37.23,0:38:47.21,Default,,0000,0000,0000,,operations related to the DIAG protocol.\NThe exchange of data between the DIAG task
Dialogue: 0,0:38:47.21,0:38:55.39,Default,,0000,0000,0000,,and other tasks are done through the ring\Nbuffer. So, for example, if some tasks
Dialogue: 0,0:38:55.39,0:39:05.73,Default,,0000,0000,0000,,needs to log something through the DIAG,\Nit will use specialized logging APIs that
Dialogue: 0,0:39:05.73,0:39:10.93,Default,,0000,0000,0000,,will in turn put logging data into the\Nring buffer. The ring buffer will be
Dialogue: 0,0:39:10.93,0:39:20.33,Default,,0000,0000,0000,,drained either on timer or on a software\Nbased interrupt from the caller. And at
Dialogue: 0,0:39:20.33,0:39:28.48,Default,,0000,0000,0000,,this point the data will be wrapped into\NDIAG protocol and from there it will go to
Dialogue: 0,0:39:28.48,0:39:37.12,Default,,0000,0000,0000,,sI/O task, this Serial I/O which is\Nresponsible to send in the output to a
Dialogue: 0,0:39:37.12,0:39:49.53,Default,,0000,0000,0000,,specific interface. This is based on the\Nmodem, on the baseband configuration. The
Dialogue: 0,0:39:49.53,0:39:56.55,Default,,0000,0000,0000,,main interface that I was dealing with is\Nthe shared memory, which ends up in the
Dialogue: 0,0:39:56.55,0:40:06.13,Default,,0000,0000,0000,,DIAG shared driver inside the Android\Nkernel. So in case of sending the commands
Dialogue: 0,0:40:06.13,0:40:11.81,Default,,0000,0000,0000,,from the Android kernel to the baseband,\Nit will be the reverse flow. First, you
Dialogue: 0,0:40:11.81,0:40:17.42,Default,,0000,0000,0000,,will need to send some- to craft the DIAG\Nprotocol data, send it through the DIAG
Dialogue: 0,0:40:17.42,0:40:21.92,Default,,0000,0000,0000,,shared driver that will write to the\Nshared memory interface. From there, it
Dialogue: 0,0:40:21.92,0:40:28.11,Default,,0000,0000,0000,,will go to the specialized task in the\Nbasement and eventually end up in the DIAG
Dialogue: 0,0:40:28.11,0:40:42.40,Default,,0000,0000,0000,,task and potentially other responsible\Ntask. On the Android side, DIAG is
Dialogue: 0,0:40:42.40,0:40:47.97,Default,,0000,0000,0000,,represented with the /dev/diag device,\Nwhich is implemented with the diagchar,
Dialogue: 0,0:40:47.97,0:40:54.98,Default,,0000,0000,0000,,and diagfwd kernel drivers in the MSM\Nkernel. The purpose of the DIAG shared
Dialogue: 0,0:40:54.98,0:41:02.91,Default,,0000,0000,0000,,driver is to support the DIAG interface.\NIt is quite complex in code, but
Dialogue: 0,0:41:02.91,0:41:09.57,Default,,0000,0000,0000,,functionally it's quite simple. It\Ncontains some basic minimum of DIAG
Dialogue: 0,0:41:09.57,0:41:15.31,Default,,0000,0000,0000,,commands that enable configuration of the\Ninterface on the baseband side. And then
Dialogue: 0,0:41:15.31,0:41:20.61,Default,,0000,0000,0000,,it would be able to multiplex the DIAG\Nchannel to either USB or a memory device.
Dialogue: 0,0:41:20.61,0:41:29.68,Default,,0000,0000,0000,,It also contains some IOCTLs for\Nconfiguration that can be accessed from
Dialogue: 0,0:41:29.68,0:41:36.03,Default,,0000,0000,0000,,the Android user land. And finally, the\NIOCTL filters various DIAG commands that
Dialogue: 0,0:41:36.03,0:41:43.89,Default,,0000,0000,0000,,it considers unnecessary. This is a bit\Nimportant because when you will start,
Dialogue: 0,0:41:43.89,0:41:47.97,Default,,0000,0000,0000,,when you'll try to do some tests and send\Nsome arbitrary DIAG comments with the DIAG
Dialogue: 0,0:41:47.97,0:41:54.98,Default,,0000,0000,0000,,interface, you would be required to\Nrebuild the actual driver to remove this
Dialogue: 0,0:41:54.98,0:42:03.25,Default,,0000,0000,0000,,masking, otherwise your commands will not\Nmake it to the baseband side. At the core,
Dialogue: 0,0:42:03.25,0:42:09.30,Default,,0000,0000,0000,,the DIAG shared driver is based on the SMD\Nshared memory device interface, which is a
Dialogue: 0,0:42:09.30,0:42:21.47,Default,,0000,0000,0000,,core interface specific to Qualcomm modem.\NSo this is where DIAG is, diagchar
Dialogue: 0,0:42:21.47,0:42:29.06,Default,,0000,0000,0000,,is on the diagram. The diagchar\Ndriver itself is located in the
Dialogue: 0,0:42:29.06,0:42:39.04,Default,,0000,0000,0000,,application OS's vendor specific drivers.\NAnd then there is some shared memory
Dialogue: 0,0:42:39.04,0:42:43.76,Default,,0000,0000,0000,,implementation in the baseband that\Nhandles this and the DIAG implementation
Dialogue: 0,0:42:43.76,0:42:56.59,Default,,0000,0000,0000,,itself. diagchar driver is quite complex\Nin code, but the functionality is quite
Dialogue: 0,0:42:56.59,0:43:06.87,Default,,0000,0000,0000,,simple. It does implement a handful of\NCTLs that enables some configuration. I
Dialogue: 0,0:43:06.87,0:43:14.53,Default,,0000,0000,0000,,didn't check what exactly this IOCTLs are\Nresponsible for. It exposes the /dev/diag
Dialogue: 0,0:43:14.53,0:43:19.43,Default,,0000,0000,0000,,device which is available for it in the\Nwriting. However, by default, you are not
Dialogue: 0,0:43:19.43,0:43:25.38,Default,,0000,0000,0000,,able to access the DIAG channel based \Non- for this device, because in order to
Dialogue: 0,0:43:25.38,0:43:33.22,Default,,0000,0000,0000,,access it, there is diag_switch_logging\Nfunction, which switches the channel that
Dialogue: 0,0:43:33.22,0:43:41.23,Default,,0000,0000,0000,,is used for DIAG communications. On the\Nscreen there are several modes listed, but
Dialogue: 0,0:43:41.23,0:43:45.01,Default,,0000,0000,0000,,in practice only two of them are\Nsupported. The USB mode and the memory
Dialogue: 0,0:43:45.01,0:43:53.00,Default,,0000,0000,0000,,device mode. USB mode is the default, so\Nwhich is why if you just open, the
Dialogue: 0,0:43:53.00,0:43:58.27,Default,,0000,0000,0000,,/dev/diag driver, dev/diag device and try\Nto read something from it, it won't work,
Dialogue: 0,0:43:58.27,0:44:07.56,Default,,0000,0000,0000,,is tied to USB. And in order to\Nreconfigure it to use the memory device,
Dialogue: 0,0:44:07.56,0:44:17.28,Default,,0000,0000,0000,,you need to send a special IOCTL code.\NNotice the procedure named
Dialogue: 0,0:44:17.28,0:44:24.95,Default,,0000,0000,0000,,mask_request_validate, which employs a\Nquite strict filtering on the DIAG commands
Dialogue: 0,0:44:24.95,0:44:31.62,Default,,0000,0000,0000,,that you try to send through this\Ninterface. So it filters out basically
Dialogue: 0,0:44:31.62,0:44:40.07,Default,,0000,0000,0000,,everything with the exception of some\Nbasic configuration requests. At the core,
Dialogue: 0,0:44:40.07,0:44:46.99,Default,,0000,0000,0000,,DIAG shared driver use the shared memory\Ndevice to communicate with the baseband.
Dialogue: 0,0:44:46.99,0:44:55.08,Default,,0000,0000,0000,,The SMD implementation is quite complex.\NIt exposes SMD Read API, which is used by
Dialogue: 0,0:44:55.08,0:45:02.68,Default,,0000,0000,0000,,DIAG share for reading the data from the\Nshared memory, one of the APIs. Shared
Dialogue: 0,0:45:02.68,0:45:14.31,Default,,0000,0000,0000,,memory also operates on the abstraction of\Nchannels which are accessed through the
Dialogue: 0,0:45:14.31,0:45:19.62,Default,,0000,0000,0000,,API named smd_named_open_on_edge. So you\Ncan notice here that there are some DIAG
Dialogue: 0,0:45:19.62,0:45:25.12,Default,,0000,0000,0000,,specific channels that can be opened. \NNow, let's take a look at the SMD
Dialogue: 0,0:45:25.12,0:45:29.73,Default,,0000,0000,0000,,implementation. This is a bit important\Nbecause a shared memory device represents
Dialogue: 0,0:45:29.73,0:45:33.42,Default,,0000,0000,0000,,a part of the attack surface for\Nescalation from the modem to the
Dialogue: 0,0:45:33.42,0:45:37.88,Default,,0000,0000,0000,,application processor. This is a very\Nimportant attack surface because if you
Dialogue: 0,0:45:37.88,0:45:42.51,Default,,0000,0000,0000,,just achieve code execution on the\Nbaseband, it's mostly useless because it
Dialogue: 0,0:45:42.51,0:45:49.48,Default,,0000,0000,0000,,cannot access the main operating system.\NAnd in order to make it useful, you'll
Dialogue: 0,0:45:49.48,0:45:59.12,Default,,0000,0000,0000,,need to create and exploit chain and add\None more exploit based on that bug with
Dialogue: 0,0:45:59.12,0:46:04.21,Default,,0000,0000,0000,,privilege escalation from the modem to the\Napplication processor. So shared memory
Dialogue: 0,0:46:04.21,0:46:10.56,Default,,0000,0000,0000,,device is one of the attack surfaces for\Nthis. The shared memory device is
Dialogue: 0,0:46:10.56,0:46:22.16,Default,,0000,0000,0000,,implemented as exposed memory region\Nexposed by the Qualcomm peripheral. The
Dialogue: 0,0:46:22.16,0:46:28.62,Default,,0000,0000,0000,,specialized MSM driver will map it and\Nhere it's the name is smem_ram_phys, the
Dialogue: 0,0:46:28.62,0:46:40.10,Default,,0000,0000,0000,,base of the shared memory region. The\Nshared memory region operates on the
Dialogue: 0,0:46:40.10,0:46:50.52,Default,,0000,0000,0000,,concept of entries and channels, so it's\Npartitioned in distant parts that can be
Dialogue: 0,0:46:50.52,0:47:00.47,Default,,0000,0000,0000,,accessed through the procedure,\Nsmem_get_entry and one of these entries is
Dialogue: 0,0:47:00.47,0:47:08.07,Default,,0000,0000,0000,,SMEM_CHANNEL_ALLOC_TBL, which contains the\Nlist of available channels that can be
Dialogue: 0,0:47:08.07,0:47:13.74,Default,,0000,0000,0000,,opened. From there, we can actually open\Nthe channels and use the shared memory
Dialogue: 0,0:47:13.74,0:47:25.70,Default,,0000,0000,0000,,interface. During this initial research\Nproject, it wasn't my goal to research the
Dialogue: 0,0:47:25.70,0:47:32.46,Default,,0000,0000,0000,,entire Qualcomm ecosystem, so while I was\Npreparing for this talk, I have noticed
Dialogue: 0,0:47:32.46,0:47:37.57,Default,,0000,0000,0000,,some more interesting things in the source\Ncodes, such as, for example, the
Dialogue: 0,0:47:37.57,0:47:45.86,Default,,0000,0000,0000,,specialized driver that handles GTAG\Nmemory region, which is presumably exposed
Dialogue: 0,0:47:45.86,0:47:53.14,Default,,0000,0000,0000,,by some Qualcomm system of chips. In the\Ndrivers this is mostly used read only, and
Dialogue: 0,0:47:53.14,0:47:58.61,Default,,0000,0000,0000,,I suppose that will not really work for\Nwriting, but it's worth checking probably.
Dialogue: 0,0:47:58.61,0:48:07.85,Default,,0000,0000,0000,,And now, finally, let's take a look at the\NDIAG protocol itself. One of the first
Dialogue: 0,0:48:07.85,0:48:13.12,Default,,0000,0000,0000,,things that I noticed when researching the\NDIAG protocol is that it's actually used
Dialogue: 0,0:48:13.12,0:48:21.46,Default,,0000,0000,0000,,in a few places, not only in libqcdm. A\Npopular tool named SnoopSnitch can enable
Dialogue: 0,0:48:21.46,0:48:27.46,Default,,0000,0000,0000,,protocol dumps, so there are protocol\Ndumps on rooted devices. And in order to
Dialogue: 0,0:48:27.46,0:48:33.35,Default,,0000,0000,0000,,accomplish this, it's SnoopSnitch sends an\Nopaque blob of the commands to the mobile
Dialogue: 0,0:48:33.35,0:48:40.35,Default,,0000,0000,0000,,device through the DIAG interface. This is\Nblob is not documented. So it got me
Dialogue: 0,0:48:40.35,0:48:46.74,Default,,0000,0000,0000,,curious what exactly these commands are\Ndoing. But before we can look at the dump,
Dialogue: 0,0:48:46.74,0:48:53.78,Default,,0000,0000,0000,,let's understand the protocol. The DIAG\Nprotocol consists of around 200 of commands
Dialogue: 0,0:48:53.78,0:49:02.36,Default,,0000,0000,0000,,or tokens. Some of them are documented in\Nthe open source, but not all of them. So
Dialogue: 0,0:49:02.36,0:49:07.63,Default,,0000,0000,0000,,you can notice on the screenshots, some of\Nthe commands are missing. And one of the
Dialogue: 0,0:49:07.63,0:49:21.68,Default,,0000,0000,0000,,missing commands is actually the token 0x92 \Nhexadecimal, which represents an encoded hash log
Dialogue: 0,0:49:21.68,0:49:34.07,Default,,0000,0000,0000,,message. The common format is quite\Nsimple. The best pritimitive here is the
Dialogue: 0,0:49:34.07,0:49:42.82,Default,,0000,0000,0000,,DIAG token number 0x7E, it's not really a\Ndelimiter, it's a separate DIAG command
Dialogue: 0,0:49:42.82,0:49:49.52,Default,,0000,0000,0000,,126. It's missing in the open source, as\Nyou can see here. So the DIAG command is
Dialogue: 0,0:49:49.52,0:49:57.87,Default,,0000,0000,0000,,nested. The outer layer consists of this\Nwrapper of 0x7e hexadecimal bytes. Then
Dialogue: 0,0:49:57.87,0:50:02.33,Default,,0000,0000,0000,,there is the main command and then there\Nis some variable length data that can
Dialogue: 0,0:50:02.33,0:50:10.84,Default,,0000,0000,0000,,contain even more subcommands. This entire\Nthing is verified using the CRC and some
Dialogue: 0,0:50:10.84,0:50:16.86,Default,,0000,0000,0000,,bytes are escaped. Specifically, as you\Ncan see on the snippet. One interesting
Dialogue: 0,0:50:16.86,0:50:24.54,Default,,0000,0000,0000,,thing about the DIAG protocol is that it\Nsupports subsystem extensions. Basically,
Dialogue: 0,0:50:24.54,0:50:29.82,Default,,0000,0000,0000,,different subsystems in the baseband can\Nregister their own DIAG system handlers,
Dialogue: 0,0:50:29.82,0:50:38.12,Default,,0000,0000,0000,,arbitrary ones. And there is a special DIAG\Ncommand number 75, which simply forwards..
Dialogue: 0,0:50:38.12,0:50:43.42,Default,,0000,0000,0000,,instructs the DIAG system to forward this\Ncommand to the respective subsystem. And
Dialogue: 0,0:50:43.42,0:50:56.85,Default,,0000,0000,0000,,then it will be parsed there. There exists\Nquite a large number of subsystems. Not
Dialogue: 0,0:50:56.85,0:51:01.48,Default,,0000,0000,0000,,all of them are documented, and when I\Nstarted investigating this, I noticed that
Dialogue: 0,0:51:01.48,0:51:08.36,Default,,0000,0000,0000,,there actually exists a DIAG subsystem-\Nsubsystem and debugging subsystem. The
Dialogue: 0,0:51:08.36,0:51:15.09,Default,,0000,0000,0000,,later one immediately interested me\Nbecause I was hoping that it would enable
Dialogue: 0,0:51:15.09,0:51:19.70,Default,,0000,0000,0000,,some more advanced introspection through\Nthis debugging subsystem. But it turned
Dialogue: 0,0:51:19.70,0:51:25.91,Default,,0000,0000,0000,,out that the debugging subsystem is quite\Nsimple. It only supported one command:
Dialogue: 0,0:51:25.91,0:51:35.47,Default,,0000,0000,0000,,inject crash. So you can send a special\NDIAG comment that will inject the crash
Dialogue: 0,0:51:35.47,0:51:43.97,Default,,0000,0000,0000,,into the baseband. I will talk later about\Nthis. Now, let's take a look at specific
Dialogue: 0,0:51:43.97,0:51:52.41,Default,,0000,0000,0000,,examples of the DIAG protocol. This is the\Nannotated snippet of the blob of commands
Dialogue: 0,0:51:52.41,0:52:00.72,Default,,0000,0000,0000,,from SnoopSnitch. This blob actually\Nconsists of three large logical parts. The
Dialogue: 0,0:52:00.72,0:52:04.47,Default,,0000,0000,0000,,first part is largely irrelevant. It's a\Nbunch of commands that request various
Dialogue: 0,0:52:04.47,0:52:10.25,Default,,0000,0000,0000,,informations from the baseband, such as\Ntimestamp, version info, build id and so
Dialogue: 0,0:52:10.25,0:52:16.84,Default,,0000,0000,0000,,on. The second batch of commands starts\Nwith a command Number 0x73 hexadecimal.
Dialogue: 0,0:52:16.84,0:52:26.53,Default,,0000,0000,0000,,This is DIAG common log config. This is the\Ncommand which enables protocol dumps and
Dialogue: 0,0:52:26.53,0:52:34.39,Default,,0000,0000,0000,,configures them. And third part of this\Nblob starts with the command number 0x7D
Dialogue: 0,0:52:34.39,0:52:38.46,Default,,0000,0000,0000,,hexadecimal. This is the\NCMD_EXT_MESSAGE_CONFIG. This is actually
Dialogue: 0,0:52:38.46,0:52:43.41,Default,,0000,0000,0000,,the command that is supposed to enable\Ntextual message logging, except that in
Dialogue: 0,0:52:43.41,0:52:51.68,Default,,0000,0000,0000,,case of SnoopSnitch it disables all of the\Nlogging altogether. So how do you actually
Dialogue: 0,0:52:51.68,0:52:57.39,Default,,0000,0000,0000,,cellular protocol dumps work? In order to\Nenable the cellular product dumps, we need
Dialogue: 0,0:52:57.39,0:53:04.21,Default,,0000,0000,0000,,DIAG_CMD_LOG_CONFIG, number 0x73\Nhexadecimal. It is partially documented in
Dialogue: 0,0:53:04.21,0:53:12.64,Default,,0000,0000,0000,,the libqcdm. The structure of the packet\Nwould contain the code and the subcommand,
Dialogue: 0,0:53:12.64,0:53:18.08,Default,,0000,0000,0000,,that would be set mask in this case. It\Nalso needs an equipment ID, which
Dialogue: 0,0:53:18.08,0:53:25.23,Default,,0000,0000,0000,,corresponds to the specific protocol that\Nwe want to dump. And finally, the masks
Dialogue: 0,0:53:25.23,0:53:33.37,Default,,0000,0000,0000,,that are applied to filter some\Nparts of the dump. This is relatively
Dialogue: 0,0:53:33.37,0:53:41.02,Default,,0000,0000,0000,,straightforward. And now the second command, DIAG_CMD_EXT_MESSAGE_CONFIG. This
Dialogue: 0,0:53:41.02,0:53:48.36,Default,,0000,0000,0000,,is the one which is supposed to enable\Ntextual message logs. The command format
Dialogue: 0,0:53:48.36,0:54:00.13,Default,,0000,0000,0000,,is undocumented. So let's take a closer\Nlook at it. The command consists of a
Dialogue: 0,0:54:00.13,0:54:06.72,Default,,0000,0000,0000,,subcommand. In this case, it's subcommand\Nnumber 4, the set mask. And then there are
Dialogue: 0,0:54:06.72,0:54:15.82,Default,,0000,0000,0000,,two 16 bit integers. SSID start and end.\NSSID is subsystem ID, which is not the
Dialogue: 0,0:54:15.82,0:54:26.10,Default,,0000,0000,0000,,same as DIAG subsystems. And the last one\Nis the mask, so subsystem IDs are used to
Dialogue: 0,0:54:26.10,0:54:31.86,Default,,0000,0000,0000,,filter the messages based on a specific\Nsubsystem, because there is a huge amount
Dialogue: 0,0:54:31.86,0:54:35.97,Default,,0000,0000,0000,,of subsystems in the baseband. And if all\Nof them start logging, this is a huge
Dialogue: 0,0:54:35.97,0:54:41.72,Default,,0000,0000,0000,,amount of data. So DIAG provides this\Ncapability to filter a little bit, to a
Dialogue: 0,0:54:41.72,0:54:49.57,Default,,0000,0000,0000,,specific subsystem that you're interested\Nin. The snippet of Python code here is an
Dialogue: 0,0:54:49.57,0:54:58.44,Default,,0000,0000,0000,,example how to enable textual message logging\Nfor all subsystems. You need to set the
Dialogue: 0,0:54:58.44,0:55:12.68,Default,,0000,0000,0000,,mask to all 1s. And this is quite a lot of\Nlogging in my experience. Now for parsing
Dialogue: 0,0:55:12.68,0:55:18.04,Default,,0000,0000,0000,,the incoming log messages, there are two\Ntypes of DIAG tokens, both of them are
Dialogue: 0,0:55:18.04,0:55:26.40,Default,,0000,0000,0000,,undocumented. The first one is a legacy\Nmessage number 0x79 hexadecimal. This is a
Dialogue: 0,0:55:26.40,0:55:32.42,Default,,0000,0000,0000,,simple ASCII based message that arrives\Nthrough the DIAG interface so you can
Dialogue: 0,0:55:32.42,0:55:38.51,Default,,0000,0000,0000,,parse it quite straightforwardly. The\Nsecond one is I called it
Dialogue: 0,0:55:38.51,0:55:43.64,Default,,0000,0000,0000,,DIAG_CMD_LOG_HASH, it's number 0x92\Nhexadecimal. This is the token which
Dialogue: 0,0:55:43.64,0:55:50.65,Default,,0000,0000,0000,,encodes the log messages that contain only\Nthe hashes. This is the one that if you
Dialogue: 0,0:55:50.65,0:55:57.58,Default,,0000,0000,0000,,have the msg_hash.txt file, you can\Ncorrespond the hash that was arrived to
Dialogue: 0,0:55:57.58,0:56:02.17,Default,,0000,0000,0000,,this command to the messages provided in\Nthe text file. And you can get the textual
Dialogue: 0,0:56:02.17,0:56:08.90,Default,,0000,0000,0000,,logs. On the lower part of the slide there\Nare two examples of hexdumps from both
Dialogue: 0,0:56:08.90,0:56:16.02,Default,,0000,0000,0000,,commands. Both of them have a similar\Nstructure. First, there are 4 bytes
Dialogue: 0,0:56:16.02,0:56:23.57,Default,,0000,0000,0000,,that are essential. The first one is the\Ncommand itself. And the third byte is
Dialogue: 0,0:56:23.57,0:56:30.95,Default,,0000,0000,0000,,quite interesting is the number of\Narguments included. Next there is 64 bit
Dialogue: 0,0:56:30.95,0:56:40.47,Default,,0000,0000,0000,,value of timestamp. Next there is the SSID\Nvalue, 16 bit. Some line number, and I'm
Dialogue: 0,0:56:40.47,0:56:48.51,Default,,0000,0000,0000,,not sure what is the next argument. And\Nfinally, after that, there is either ASCII
Dialogue: 0,0:56:48.51,0:56:59.38,Default,,0000,0000,0000,,encoded log string in plain text or hash\Nof the log string. And optionally there
Dialogue: 0,0:56:59.38,0:57:06.06,Default,,0000,0000,0000,,may be included some arguments, though, in\Ncase of the first legacy command. The
Dialogue: 0,0:57:06.06,0:57:10.40,Default,,0000,0000,0000,,arguments are included before the log\Nmessage and in case of the second command
Dialogue: 0,0:57:10.40,0:57:16.67,Default,,0000,0000,0000,,they are included after the MD5 hash in\Nthe log message, at least in my version of
Dialogue: 0,0:57:16.67,0:57:29.11,Default,,0000,0000,0000,,this implementation. And this is the DIAG\Npacket that enables you to inject a crash
Dialogue: 0,0:57:29.11,0:57:36.97,Default,,0000,0000,0000,,into the baseband, at least in theory.\NBecause in my case it did not work. And by
Dialogue: 0,0:57:36.97,0:57:41.41,Default,,0000,0000,0000,,not working, I mean that it did simply not\Nenter the baseband. Normally, I would
Dialogue: 0,0:57:41.41,0:57:46.47,Default,,0000,0000,0000,,expect that on production device it should\Njust reset the baseband. You will not get
Dialogue: 0,0:57:46.47,0:57:53.03,Default,,0000,0000,0000,,a crash dump or anything like that, just a\Nreset. So I suppose that it still should
Dialogue: 0,0:57:53.03,0:57:58.15,Default,,0000,0000,0000,,be working on some other devices. So it's\Nworth of checking. There are a few types of
Dialogue: 0,0:57:58.15,0:58:09.79,Default,,0000,0000,0000,,crashes that you can request in this way.\NIn order to accomplish this, I needed a
Dialogue: 0,0:58:09.79,0:58:17.12,Default,,0000,0000,0000,,very simple tool with basically two\Nfunctions. first, direct easy access to
Dialogue: 0,0:58:17.12,0:58:22.84,Default,,0000,0000,0000,,the DIAG interface, ideally through some\Nsort of python shell. And second is the
Dialogue: 0,0:58:22.84,0:58:29.78,Default,,0000,0000,0000,,ability to read and parse data with\Nadvanced log strings. For that purpose. I
Dialogue: 0,0:58:29.78,0:58:37.100,Default,,0000,0000,0000,,wrote a simple framework that I named\Ndiagtalk, which is based directly on the
Dialogue: 0,0:58:37.100,0:58:49.35,Default,,0000,0000,0000,,diag interface in the Android kernel and\Nor with a Python harness. So on the left
Dialogue: 0,0:58:49.35,0:58:56.97,Default,,0000,0000,0000,,side, here is the example of some advanced\Nparsing with some leaked values. And on
Dialogue: 0,0:58:56.97,0:59:02.01,Default,,0000,0000,0000,,the right side, here is the example of the\Nadvanced message log, which includes the
Dialogue: 0,0:59:02.01,0:59:10.59,Default,,0000,0000,0000,,log strings that were extracted.. that were\Nstripped out from the firmware. The log is
Dialogue: 0,0:59:10.59,0:59:16.79,Default,,0000,0000,0000,,quite fun, as I expected it to be, it has\Na lot of detailed data, such as, for
Dialogue: 0,0:59:16.79,0:59:22.80,Default,,0000,0000,0000,,example, GPS coordinates and various\Nattempts of the basement to connect to
Dialogue: 0,0:59:22.80,0:59:34.54,Default,,0000,0000,0000,,different channels. And I think it's quite\Nuseful for offensive research purposes,
Dialogue: 0,0:59:34.54,0:59:42.96,Default,,0000,0000,0000,,it's even contained sometimes raw pointers\Nas you can notice on the screenshot. So in
Dialogue: 0,0:59:42.96,0:59:50.07,Default,,0000,0000,0000,,this project, my conclusion was that\Nindeed I was reassured that it was the
Dialogue: 0,0:59:50.07,0:59:56.66,Default,,0000,0000,0000,,right choice and Hexagon seems to be a\Nquite a challenging target, and it would
Dialogue: 0,0:59:56.66,1:00:00.94,Default,,0000,0000,0000,,probably need several more months of work\Nto even begin to do some serious offensive
Dialogue: 0,1:00:00.94,1:00:08.50,Default,,0000,0000,0000,,work. I also started to think about\Nwriting a software debugger because it
Dialogue: 0,1:00:08.50,1:00:15.64,Default,,0000,0000,0000,,seems to be the most.. probably the most\Nreliable way to achieve debugging
Dialogue: 0,1:00:15.64,1:00:22.14,Default,,0000,0000,0000,,introspection. And also, I noticed some\Nblank spaces in the field that may require
Dialogue: 0,1:00:22.14,1:00:27.84,Default,,0000,0000,0000,,future work. For Qualcomm Hexagon\Nspecifically, there is a lot of things
Dialogue: 0,1:00:27.84,1:00:35.54,Default,,0000,0000,0000,,that can be done. For example, you can\Ntake a look at other Qualcomm proprietary
Dialogue: 0,1:00:35.54,1:00:40.61,Default,,0000,0000,0000,,diagnostic protocols of which there are a\Nfew, such as QMI for example, I think they
Dialogue: 0,1:00:40.61,1:00:49.40,Default,,0000,0000,0000,,are lesser known than DIAG protocol. And\Nthen there is a requirement to create a
Dialogue: 0,1:00:49.40,1:00:58.57,Default,,0000,0000,0000,,full system emulation based on QEMU at\Nleast for some chips. And a big problem
Dialogue: 0,1:00:58.57,1:01:04.14,Default,,0000,0000,0000,,about the decompiler, which is a major\Nobstacle to any serious static analysis in
Dialogue: 0,1:01:04.14,1:01:14.98,Default,,0000,0000,0000,,the code and for the offensive research,\Nthere are 3 large directions. First one is
Dialogue: 0,1:01:14.98,1:01:18.92,Default,,0000,0000,0000,,enabling debugging. There are different\Nways for that. For example, software based
Dialogue: 0,1:01:18.92,1:01:25.94,Default,,0000,0000,0000,,debugging or bypassing JTAG fusing, on the\Nother hand. Next, there are explorations
Dialogue: 0,1:01:25.94,1:01:33.00,Default,,0000,0000,0000,,of the over the air attack vectors. And\Nthe 3rd one is escalation from the baseband
Dialogue: 0,1:01:33.00,1:01:39.37,Default,,0000,0000,0000,,to the application processor. These are\Nthe 3 large offensive research vectors.
Dialogue: 0,1:01:39.37,1:01:44.67,Default,,0000,0000,0000,,And for the basebands in general, there\Nalso exists some interesting directions of
Dialogue: 0,1:01:44.67,1:01:54.14,Default,,0000,0000,0000,,future work. First of all, the OsmocommBB.\NIt definitely deserves some update a
Dialogue: 0,1:01:54.14,1:01:59.99,Default,,0000,0000,0000,,little bit. It is the only one open source\Nimplementation of a baseband. And it is so
Dialogue: 0,1:01:59.99,1:02:09.04,Default,,0000,0000,0000,,outdated. And there is, and it is based on\Nsome real obscure hardwares. Another
Dialogue: 0,1:02:09.04,1:02:17.68,Default,,0000,0000,0000,,problem here is that there doesn't exist\Nany software based CDMA implementation.
Dialogue: 0,1:02:17.68,1:02:28.66,Default,,0000,0000,0000,,{\i1}No sound{\i0}
Dialogue: 0,1:02:28.66,1:02:34.07,Default,,0000,0000,0000,,Herald: Alisa, thank you very much for\Nthis nice talk. Um, there are some
Dialogue: 0,1:02:34.07,1:02:39.03,Default,,0000,0000,0000,,questions from the audience. So basically\Nthe first one is a little bit of an
Dialogue: 0,1:02:39.03,1:02:46.36,Default,,0000,0000,0000,,icebreaker: Do you use a mobile phone? \NAnd do you trust it?
Dialogue: 0,1:02:46.36,1:02:51.77,Default,,0000,0000,0000,,Alisa: No, I don't try to use a mobile\Nphone only for Twitter. Does anyone still
Dialogue: 0,1:02:51.77,1:03:00.06,Default,,0000,0000,0000,,use mobile phones nowadays?\NH: {\i1}laughs{\i0} Well, no idea. Another
Dialogue: 0,1:03:00.06,1:03:07.98,Default,,0000,0000,0000,,question concerns the other Qualcomm\Nchips. Did you have a look at the Qualcom
Dialogue: 0,1:03:07.98,1:03:15.96,Default,,0000,0000,0000,,Wi-Fi chips sets?\NA: As I mentioned during the talk, I had
Dialogue: 0,1:03:15.96,1:03:20.51,Default,,0000,0000,0000,,only one month. It was like a short\Nreconnaissance project, so I didn't really
Dialogue: 0,1:03:20.51,1:03:27.02,Default,,0000,0000,0000,,have time to investigate everything. I did\Nnotice that Qualcomm socks have a Wi-Fi
Dialogue: 0,1:03:27.02,1:03:32.37,Default,,0000,0000,0000,,chip, which is also based on Hexagon. And\Nmore than that, it also shares some of the
Dialogue: 0,1:03:32.37,1:03:38.54,Default,,0000,0000,0000,,same low level technical primitives. So\Nit's definitely worth looking, but I didn't
Dialogue: 0,1:03:38.54,1:03:45.02,Default,,0000,0000,0000,,investigate it in details.\NH: OK, OK, thanks. There is also a pretty
Dialogue: 0,1:03:45.02,1:03:50.82,Default,,0000,0000,0000,,technical question here, so instead of\Nhaving to go through the rigorous command
Dialogue: 0,1:03:50.82,1:03:57.60,Default,,0000,0000,0000,,checking for the DIAG card driver,\Nwouldn't it be possible to nmap /dev/mem
Dialogue: 0,1:03:57.60,1:04:04.60,Default,,0000,0000,0000,,into userspace process and send over\Ncommands directly so. Depends a little bit
Dialogue: 0,1:04:04.60,1:04:11.80,Default,,0000,0000,0000,,on what the goal is.\NA: OK, so it really depends on your
Dialogue: 0,1:04:11.80,1:04:16.87,Default,,0000,0000,0000,,previous background and your goals. The\Npoint here is that by default, the DIAG
Dialogue: 0,1:04:16.87,1:04:23.42,Default,,0000,0000,0000,,shared ecosystem does not allow to send\Narbitrary DIAG commands. So either way,
Dialogue: 0,1:04:23.42,1:04:28.75,Default,,0000,0000,0000,,you will have to hack something. One way\Nto hack this is to rebuild the actual
Dialogue: 0,1:04:28.75,1:04:33.53,Default,,0000,0000,0000,,driver. So you would be able to send the\Ncommands directly through that DIAG
Dialogue: 0,1:04:33.53,1:04:37.86,Default,,0000,0000,0000,,interface. Another way would be to access\Nthe shared memory directly, for example.
Dialogue: 0,1:04:37.86,1:04:42.08,Default,,0000,0000,0000,,But I think it would be more complex\Nbecause the Qualcomm shared memory
Dialogue: 0,1:04:42.08,1:04:47.44,Default,,0000,0000,0000,,implementation is quite complex. So I\Nthink that the easiest way would be
Dialogue: 0,1:04:47.44,1:04:52.79,Default,,0000,0000,0000,,actually to hack the DIAG shared driver\Nand use the deb. DIAG interface for this.
Dialogue: 0,1:04:52.79,1:05:00.27,Default,,0000,0000,0000,,H: OK, thanks. Thanks. There is one\Nquestion which I'm going to read out,
Dialogue: 0,1:05:00.27,1:05:14.87,Default,,0000,0000,0000,,maybe you can make sense of it: is this\Ntypically {\i1}[unclear]{\i0} security fall mobile phones?
Dialogue: 0,1:05:14.87,1:05:19.29,Default,,0000,0000,0000,,A: This level of hardening that I\Npresented, I think is around medium level.
Dialogue: 0,1:05:19.29,1:05:24.27,Default,,0000,0000,0000,,So usually production falls are even more\Nhardened. If you take a look at things
Dialogue: 0,1:05:24.27,1:05:31.25,Default,,0000,0000,0000,,like Google Pixel5 or the latest iPhones,\Nthey will be even better, hardened than
Dialogue: 0,1:05:31.25,1:05:38.64,Default,,0000,0000,0000,,the one that I discussed.\NH: Oh, OK. Yeah, thanks. Thanks then. So it
Dialogue: 0,1:05:38.64,1:05:42.90,Default,,0000,0000,0000,,doesn't look like we have any more\Nquestions left. Anyway, so if you want to
Dialogue: 0,1:05:42.90,1:05:49.12,Default,,0000,0000,0000,,get in contact with Alisa, no problem.\NThere is the feedback tab below your
Dialogue: 0,1:05:49.12,1:05:56.89,Default,,0000,0000,0000,,video now at the moment, just drop your\Nquestions over there. And that's a way to
Dialogue: 0,1:05:56.89,1:06:02.74,Default,,0000,0000,0000,,get in touch with Alisa. Other than that I\Nwould say we're done for today for this
Dialogue: 0,1:06:02.74,1:06:07.41,Default,,0000,0000,0000,,session. Thank you very, very much Alisa\Nfor this really nice presentation once
Dialogue: 0,1:06:07.41,1:06:14.16,Default,,0000,0000,0000,,again. Applause And I'll transfer now over\Nto the Herald News Show.
Dialogue: 0,1:06:14.16,1:06:33.64,Default,,0000,0000,0000,,{\i1}postroll music{\i0}
Dialogue: 0,1:06:33.64,1:06:54.00,Default,,0000,0000,0000,,Subtitles created by c3subtitles.de\Nin the year 2021. Join, and help us!