< Return to Video

#rC3 - Advanced Hexagon Diag

  • 0:00 - 0:13
    rC3 preroll music
  • 0:13 - 0:18
    Herald: Our next speaker, Alisa Esage, is
    an independent vulnerability researcher
  • 0:18 - 0:23
    and has a notable record of security
    research achievements such as this year,
  • 0:23 - 0:30
    the initiative Silver Bounty Hunter Awards
    2018. Alisa is going to present her latest
  • 0:30 - 0:36
    research on the Qualcomm DIAG protocol,
    which is found abundantly in Qualcomm
  • 0:36 - 0:46
    Hexagon based cellular modems. Alisa,
    we're looking forward to your talk now.
  • 0:46 - 0:50
    Alisa Esage: This is Alisa Esage, you're
    attending my presentation about Advanced
  • 0:50 - 1:01
    Hexagon DIAG at Chaos Communication
    Congress 2020 remote experience. My main
  • 1:01 - 1:06
    interest as advanced vulnerability
    researcher is complex systems and hardened
  • 1:06 - 1:12
    systems. For the last 10 years I have been
    researching various classes of software
  • 1:12 - 1:16
    such as Windows kernel, browsers,
    JavaScript engines. And for the last three
  • 1:16 - 1:22
    years I was focusing mostly on
    Hypervisors. The project that I'm
  • 1:22 - 1:28
    presenting today was a little side project
    that I made for distraction a couple years
  • 1:28 - 1:38
    ago. The name of this talk Advanced
    Hexagon DIAG is a bit of an understatement
  • 1:38 - 1:45
    in the attempt to keep this talk a little
    bit low key in the general internet,
  • 1:45 - 1:51
    because a big part of the talk will
    actually be devoted to a general
  • 1:51 - 1:57
    vulnerability research in basebands. But
    the primary focus of this talk is on the
  • 1:57 - 2:03
    Hexagon DIAG, also known as QCDM Qualcomm
    diagnostic manager. This is a proprietary
  • 2:03 - 2:09
    protocol developed by Qualcomm for use in
    their basebands, and it is included on all
  • 2:09 - 2:18
    Snapdragon SoCs and modem chips produced
    by Qualcomm. More than Qualcomm chips run
  • 2:18 - 2:24
    on custom silicone with a custom
    instruction set architecture and named
  • 2:24 - 2:31
    QDSP6 Hexagon. This is important because
    all the DIAG handlers that we will be
  • 2:31 - 2:42
    dealing with are written in this
    instruction set architecture. As usually
  • 2:42 - 2:48
    with my talks, I have adjusted the
    materials of this presentation for various
  • 2:48 - 2:53
    audiences, for the full spectrum of
    audiences, specifically the first part of
  • 2:53 - 3:01
    the presentation is mostly specialized for
    research directors and high level
  • 3:01 - 3:07
    technical staff. And the last part is more
    deep technical. And it would be mostly
  • 3:07 - 3:15
    interesting to specialized vulnerability
    researchers and low level programmers that
  • 3:15 - 3:25
    somehow are related to this particular
    area. Let's start from the top level
  • 3:25 - 3:32
    overview of cellular technology. This mind
    map presents a simplified view of various
  • 3:32 - 3:37
    types of entities that we'd have to deal
    with with respect to basebands. It's not a
  • 3:37 - 3:45
    complete diagram, of course, but it only
    presents the classes of entities that
  • 3:45 - 3:52
    exist in this space. Also, this mind map
    is specific to the clean site equipment,
  • 3:52 - 3:57
    the user equipment and it completely omits
    any server side considerations which are a
  • 3:57 - 4:02
    world in their own. There exists quite a
    large number of cellular protocols on the
  • 4:02 - 4:08
    planet. From the user perspective, this is
    simple. This is usually the shared name
  • 4:08 - 4:15
    3G, 4G that you see on the mobile screen.
    But in reality, this simple name, that
  • 4:15 - 4:27
    generation name encodes - may encode
    several different distinct technologies.
  • 4:27 - 4:33
    There are a few key points about cellular
    protocols that are crucial to understand
  • 4:33 - 4:39
    before starting to approach this area. The
    first one is the concept of a generation.
  • 4:39 - 4:45
    This is simple. This is simply 1G, 2G and
    so on. The generic name of the family of
  • 4:45 - 4:50
    protocols that are supported in a
    particular generation. Generation is
  • 4:50 - 4:56
    simply a marketing name, for users. It
    doesn't really have any strict technical
  • 4:56 - 5:02
    meaning. And generations represent the
    evolution of cellular protocols in time.
  • 5:02 - 5:07
    The second most important thing about
    cellular protocols is the air interface.
  • 5:07 - 5:14
    This is.. or the protocol, which actually..
    this is the lowest level protocol which
  • 5:14 - 5:20
    defines how exactly the cellular
    signal is digitized and read from the
  • 5:20 - 5:27
    electromagnetic wave and how exactly the
    different players in this field divide the
  • 5:27 - 5:33
    space. Historically, there existed two
    main implementations of this low level
  • 5:33 - 5:39
    code called TDMA and CDMA. TDMA means time
    division multiple access, which basically
  • 5:39 - 5:44
    divides the entire electromagnetic
    spectrum within the radio band into time
  • 5:44 - 5:51
    slots that are rotated in a round robin
    manner by various mobile phones so that
  • 5:51 - 6:04
    they speak in turns. TDMA was the base for
    the GSM technology. And GSM was the main
  • 6:04 - 6:10
    protocol used on this planet for a long
    time. Another low level implementation is
  • 6:10 - 6:17
    CDMA. It was a little bit more complex
    from the beginning. It's decoded as coded
  • 6:17 - 6:24
    division multiple access. And instead of
    dividing the spectrum in time slots and
  • 6:24 - 6:33
    dividing the protocol in bursts, CDMA uses
    random codes that are assigned to mobile
  • 6:33 - 6:43
    phones so that this code can be used as an
    additional randomizing mask against the
  • 6:43 - 6:48
    modulation protocol. And multiple user
    equipments can talk on the same frequency
  • 6:48 - 6:57
    without interrupting each other. Note here
    that CDMA was developed by Qualcomm and it
  • 6:57 - 7:03
    was mostly used in the United States. So
    at the level of 2G, there were two main
  • 7:03 - 7:12
    protocols, GSM based on the TDMA and the
    cdmaOne based on the CDMA. On the third
  • 7:12 - 7:18
    generation of mobile protocols these two
    branches of development were continued. So
  • 7:18 - 7:24
    GSM evolved into UMTS, while cdmaOne
    evolved into CDMA2000. The important point
  • 7:24 - 7:31
    here is that UMTS has at this point
    already adopted the low level air
  • 7:31 - 7:37
    interface protocol from the CDMA and
    eventually at the fourth generation of
  • 7:37 - 7:41
    protocols these two branches of
    development come together to create the
  • 7:41 - 7:53
    LTE technology and the same for the 5G.
    This is a bit important for us as from the
  • 7:53 - 7:58
    offensive perspective, because first of
    all, all of this technologies including
  • 7:58 - 8:05
    the air interfaces represents separate
    bits of code with separate parsing
  • 8:05 - 8:10
    algorithms within the baseband firmware.
    And all of them are usually presented in
  • 8:10 - 8:15
    each baseband, regardless of which one you
    actually use. Does your mobile provider
  • 8:15 - 8:21
    actually support. Another important and
    not obvious thing from the offensive
  • 8:21 - 8:30
    security perspective here is that because
    of this, evolutionary development of the..
  • 8:30 - 8:35
    protocols are not actually completely
    distinct. So if you think about LTE, it is
  • 8:35 - 8:39
    not a completely different protocol from
    GSM, but instead it is based largely on
  • 8:39 - 8:48
    the same internal structures. And in fact,
    if you look at the specifications, some of
  • 8:48 - 8:54
    them are almost directly relevant. The
    specifications of the GSM 2G, some of them
  • 8:54 - 9:00
    are still directly relevant to some extent
    to LTE. This is also important when you
  • 9:00 - 9:06
    start analyzing protocols from the
    offensive perspective. The cellular
  • 9:06 - 9:17
    protocols are structured in a nested
    way, in layers. Layers is the official
  • 9:17 - 9:25
    terminology adopted by the specifications
    with the exception of level zero. Here I
  • 9:25 - 9:30
    just edited it for convenience, but it's
    in the specifications layer start from one
  • 9:30 - 9:35
    and proceed to three. From the offensive
    perspective, the most interesting is level
  • 9:35 - 9:39
    three, as you can see from the screenshot
    of the specifications, because it encodes
  • 9:39 - 9:45
    most of the high level protocol data, such
    as handling SMS and GSM. This is the part
  • 9:45 - 9:50
    of the protocol which actually contains
    interesting data structures with TLV
  • 9:50 - 9:59
    values and so on. When people talk about
    attack in basebands, they usually mean
  • 9:59 - 10:06
    attack in baseband over the air. Their OTA
    attack vector, which is definitely one of
  • 10:06 - 10:12
    the most interesting. But let's take a
    step back and consider the entire big
  • 10:12 - 10:21
    picture of the baseband ecosystem. This
    diagram presents a unified view of
  • 10:21 - 10:28
    generalized architecture of a modern
    baseband with attack surfaces. First of
  • 10:28 - 10:35
    all, there are two separate distinct
    processors: the AP, application processor,
  • 10:35 - 10:40
    and the MP, which is mobile processor. It
    may be either a DSP or another CPU.
  • 10:40 - 10:45
    Usually there are two separate processors
    and each one of them runs a separate
  • 10:45 - 10:51
    operating system. In case of the AP, it
    may be Android or iOS and the baseband
  • 10:51 - 10:56
    processor will draw on some sort of real-
    time operating system provided by the
  • 10:56 - 11:03
    mobile vendor. Important point here that
    on modern implementations, baseband
  • 11:03 - 11:09
    actually protected by some sort of secure
    execution environment, maybe TrustZone on
  • 11:09 - 11:17
    Androids or SEPOS on Apple devices. Which
    means that the privilege boundary which is
  • 11:17 - 11:23
    depicted here on the left side is dual
    sided. So even if you have kernel access
  • 11:23 - 11:30
    to the Android kernel, you still are not
    supposed to be able to read the memory of
  • 11:30 - 11:34
    the baseband or somehow intersect with its
    operation, at least on the modern
  • 11:34 - 11:39
    production smartphones. And the same goes
    around to the baseband, which is not
  • 11:39 - 11:46
    supposed to be able to access to application
    processor directly. So these two are
  • 11:46 - 11:50
    mutually distrusting entities that are
    separated from each other. And so there
  • 11:50 - 12:02
    exists privilege boundary, which is -
    which represents attack surface. Within
  • 12:02 - 12:07
    the real-time operating systems, there are
    three large attack surfaces. Starting from
  • 12:07 - 12:14
    right to left: the rightmost gray box
    represents the attack surface of the
  • 12:14 - 12:21
    cellular stacks. This is the code which
    actually parses the cellular protocols.
  • 12:21 - 12:32
    It's usually runs in several distant real-
    time operating system tasks. And this part
  • 12:32 - 12:39
    of the attack surface handles all the
    layers of the protocol. There is a huge
  • 12:39 - 12:44
    amount of parsing that happens here. The
    second box represents the various
  • 12:44 - 12:51
    management protocols. The simplest one to
    think about is the AT command protocol. It
  • 12:51 - 12:57
    is still widely included in all basebands,
    and it's even usually exposed in some way
  • 12:57 - 13:01
    to the application processor. So you can
    actually send some AT commands to the
  • 13:01 - 13:09
    cellular modem. About a bit more interesting
    is the vendor specific management
  • 13:09 - 13:17
    protocols, one of them is the DIAG
    protocol. Because the modern basebands are
  • 13:17 - 13:23
    very complex. So vendors need some sort of
    specialized protocol to enable
  • 13:23 - 13:29
    configuration and diagnostics for the
    OEM's. In case of Qualcomm, for example,
  • 13:29 - 13:37
    DIAG is just one of the many diagnostic
    protocols involved. The third box is what
  • 13:37 - 13:45
    I call the RTOS core, it is various
    core level functionality, such as the
  • 13:45 - 13:58
    code, which implements that interface to
    the application processor. On the side of
  • 13:58 - 14:04
    the application operating system such as
    Android, there are also 2 attack surfaces
  • 14:04 - 14:10
    that are attackable from the baseband. The
    first one is the peripheral drivers,
  • 14:10 - 14:14
    because the basement is a separate part of
    peripherals. So it requires some
  • 14:14 - 14:21
    specialized drivers that handle I/O and
    such things. And the second one is the
  • 14:21 - 14:29
    dark surface represented with various
    interface handlers because the baseband
  • 14:29 - 14:35
    and the main operating system cannot
    communicate directly. They use some sort
  • 14:35 - 14:40
    of a specialized interface to do that. In
    case of Qualcomm this is shared memory.
  • 14:40 - 14:45
    And so this shared memory implementations
    are usually quite complex and they
  • 14:45 - 14:51
    represent an attack surface on the both
    sides. And finally, the third piece of this
  • 14:51 - 14:57
    diagram is in the lowest part. I have
    depicted two grey boxes which are related
  • 14:57 - 15:03
    to the trusted execution environment.
    Because typically a modem runs as a
  • 15:03 - 15:11
    Trustled in a secure environment. So
    technically, the attack surfaces that
  • 15:11 - 15:17
    exists within TrustZone or related to it
    also can be useful for baseband offensive
  • 15:17 - 15:23
    research. Here we can distinguish at least
    two large attack surfaces. The first one
  • 15:23 - 15:31
    is the secure manager of call handlers,
    which is the core interface that
  • 15:31 - 15:37
    handles calls from the application
    processor to the TrustZone. And the second
  • 15:37 - 15:45
    one are the Trustlets. They are separate
    pieces of code which are executed and
  • 15:45 - 15:57
    protected by the TrustZone. On this
    diagram, I have also added some
  • 15:57 - 16:03
    information about data codex, I'm not sure
    if they are supposed to be in the RTOS
  • 16:03 - 16:06
    core because these things are directly
    accessible from the cellular stacks
  • 16:06 - 16:15
    usually, especially ASN. 1, which I have
    seen some bugs reachable from the over the
  • 16:15 - 16:23
    air interface. On this diagram, I have
    shown some example of vulnerabilities. I
  • 16:23 - 16:27
    will not discuss them in details here
    since it's not the point of the
  • 16:27 - 16:32
    presentation, but at least the ones from
    Baodong, you can find the writeups on
  • 16:32 - 16:47
    the Internet. To discuss baseband
    offensive tools and approaches, I have
  • 16:47 - 16:51
    narrowed down the previous diagram to just
    one attack surface, the over the air
  • 16:51 - 16:56
    attack surface. This is the attack
    surface, which is represented by parsing
  • 16:56 - 16:59
    implementations of various cellular
    protocols inside the baseband operating
  • 16:59 - 17:07
    system. And this is the attack surface
    that we can reach from the air interface.
  • 17:07 - 17:13
    In order to accomplish that, we need a
    transceiver such as software defined radio
  • 17:13 - 17:21
    or a mobile tester, which is able to talk
    the specific cellular protocol that we're
  • 17:21 - 17:29
    planning to attack. The simplest way to
    accomplish this is use some sort of a
  • 17:29 - 17:35
    software defined radio, such as Ettus
    research USRP or blade RF and install open
  • 17:35 - 17:41
    source implementation of a base station
    such as OpenBTS or OpenBSC. The thing to
  • 17:41 - 17:50
    note here is that the software based
    implementations actually lagged behind the
  • 17:50 - 17:55
    development of technologies.
    Implementations of GSM base stations are
  • 17:55 - 18:04
    very well established and popular, such as
    OpenBTS. And in fact, when I tried to
  • 18:04 - 18:15
    establish BTS with my USRP, it was quite
    simple. For UMTS and LTE, there exists less
  • 18:15 - 18:20
    number of software based implementations
    and also there are more constraints on the
  • 18:20 - 18:26
    hardware. For example, my model of the
    USRP does not support UMTS due to resource
  • 18:26 - 18:32
    constraints. And the most interesting
    thing here is that there does not exist
  • 18:32 - 18:37
    any software based implementation on the
    CDMA that you can use to establish a base
  • 18:37 - 18:53
    station. This is a pseudorandom diagram of
    one of the Snapdragon chips. There exists
  • 18:53 - 18:59
    a huge amount of various models of
    Snapdragons. This one I have chosen
  • 18:59 - 19:06
    pseudorandomly when I was searching for
    some sort of visual diagram. Qualcomm used
  • 19:06 - 19:12
    to include some high level diagrams of the
    architecture in their marketing materials
  • 19:12 - 19:19
    previously. But since they don't do this
    anymore. And this particular diagram is
  • 19:19 - 19:27
    from a technical specification of a
    particular model 820. Also this particular
  • 19:27 - 19:34
    model Snapdragon is... a bit interesting
    because it is the first one that included
  • 19:34 - 19:45
    the artificial intelligence agent, which
    is also based on Hexagon. For all
  • 19:45 - 19:53
    purposes, the main interest here are the
    processors. Majority of snapdragons
  • 19:53 - 20:00
    include quite a long list of processors.
    There are at least 4 ARM-based Kryo-CPUs
  • 20:00 - 20:11
    that actually run the Android operating
    system. Then there are the Adreno GPUs and
  • 20:11 - 20:16
    then there are several Hexagons. On the
    most recent models there is not just one
  • 20:16 - 20:23
    Hexagon processing unit, but several of
    them. And they are called respectively to
  • 20:23 - 20:28
    their purposes. Each one of them, each one
    of these Hexagon cores is responsible for
  • 20:28 - 20:36
    handling a specific functionality. For
    example, MDSB handles modem and runs the
  • 20:36 - 20:44
    real-time operating system. The ADSP
    handles media and the CDSP handles
  • 20:44 - 20:53
    compute. So the Hexagons actually
    represent around one half of the
  • 20:53 - 21:09
    processing power, more than Snapdragons.
    There are two key points about the Hexagon
  • 21:09 - 21:18
    architecture from the hardware
    perspective. First of all, it is- Hexagon
  • 21:18 - 21:25
    is specialized to parallel processing. And
    so the first concept is variable size
  • 21:25 - 21:31
    destruction packets. It means that
    several instructions can execute
  • 21:31 - 21:42
    simultaneously in separate execution
    units. It also uses hardware
  • 21:42 - 21:49
    multithreading for the same purposes. On
    the right side of the slide here is some
  • 21:49 - 22:01
    example of the Hexagon assembly. It is
    quite funny at times. This curly brackets
  • 22:01 - 22:07
    should present the instructions that are
    executed simultaneously. And these
  • 22:07 - 22:16
    instructions must be compactable in order
    to be able to use that distant processing
  • 22:16 - 22:21
    slots. And then there is the funny .new
    notation which actually enables the
  • 22:21 - 22:26
    instructions to use both the old and the
    new value of a particular register within
  • 22:26 - 22:33
    the same instruction cycle. This provides
    quite a bit of optimization on the lower
  • 22:33 - 22:41
    level. For more information, I can direct
    you to the Hexagon Specification and
  • 22:41 - 22:54
    programmers reference manual, which is
    available from the Qualcomm website. The
  • 22:54 - 22:59
    concept of production fusing is quite
    common. As I said previously, it's a
  • 22:59 - 23:06
    common practice from mobile device vendors
    to lock down the devices before they enter
  • 23:06 - 23:12
    the market to prevent modifications and
    tinkering. And for the purposes of this
  • 23:12 - 23:17
    locking down, they usually- there are
    several ways how this can be accomplished.
  • 23:17 - 23:24
    Usually various advanced diagnostic and
    debugging functionalities are removed from
  • 23:24 - 23:31
    either software or hardware or both. It is
    quite common that this functionalities are
  • 23:31 - 23:37
    only removed from software while the
    hardware remains here. And in such case,
  • 23:37 - 23:44
    we will- eventually the researchers will
    come up with their own software based
  • 23:44 - 23:50
    implementation. All this functionality as
    in case with some custom iOS kernel
  • 23:50 - 23:56
    debuggers, for example. In case of
    Qualcomm, there was at some point a leaked
  • 23:56 - 24:02
    internal memo which discusses what exactly
    they are doing for production fusing the
  • 24:02 - 24:16
    devices. In addition to our production
    fusing in case of modern Androids, the
  • 24:16 - 24:23
    baseband runs within the trust zone. And
    on my implementation, it is already quite
  • 24:23 - 24:29
    locked down. It uses a separate component.
    The baseband uses a separate component
  • 24:29 - 24:37
    named the MBA this stands for the modem
    basic authenticator. And this entire thing
  • 24:37 - 24:42
    is run by the subsystem of Android kernel
    named PILO, the peripheral image loader.
  • 24:42 - 24:51
    You can open the source code and
    investigate how exactly it looks. And the
  • 24:51 - 24:57
    purpose of the MBA is to authenticate the
    modem firmware so that you would not be
  • 24:57 - 25:04
    able to inject some arbitrary commands
    into the modem firmware and flash it. This
  • 25:04 - 25:09
    is another side of the hardening, which
    makes it very difficult to inject any
  • 25:09 - 25:13
    arbitrary code into the baseband.
    Basically, the only way to do this is
  • 25:13 - 25:23
    through a software vulnerability. During
    this project I have reverse engineered
  • 25:23 - 25:33
    partially the Hexagon modem firmware from
    my implementation, from my Nexus 6b. The
  • 25:33 - 25:39
    process of reverse engineering is not very
    difficult because all you need is to
  • 25:39 - 25:45
    download the firmware from the website,
    Googles website in this case. Then you
  • 25:45 - 25:51
    need to find the binary which corresponds
    to the modem firmware. This binary is
  • 25:51 - 25:58
    actually a compound binary that must be
    divided into separate binaries that
  • 25:58 - 26:05
    represent specific sections inside the
    firmware. And for that purpose we can use
  • 26:05 - 26:11
    the unified Trustlet script. After you
    have split the baseband firmware into separate
  • 26:11 - 26:18
    sections, you can load them into IDA Pro.
    There are several plugins available for
  • 26:18 - 26:26
    IDA Pro that support Hexagon. I have tried
    one of them. I think it was GSMK and it
  • 26:26 - 26:36
    works quite good for basic reverse
    engineering purposes. Notable here is that
  • 26:36 - 26:42
    some sections of the modem firmware are
    compressed and relocated at runtime, so
  • 26:42 - 26:48
    you would not be able to reverse engineer
    them. And unless you can decompress them,
  • 26:48 - 26:52
    which is also a bit of a challenge because
    the Qualcomm uses some internal
  • 26:52 - 27:02
    compression algorithm for that. For the
    reverse engineering the main approach here
  • 27:02 - 27:06
    is to get started with some root points,
    for example, because this is a real time
  • 27:06 - 27:11
    operating system, we know that it should
    have some task structures and task
  • 27:11 - 27:16
    structures that we can locate. And from
    there we can locate some interesting code.
  • 27:16 - 27:20
    In case of Hexagon this is a bit non-
    trivial because, as I said, it doesn't
  • 27:20 - 27:25
    have any log strings. So even though you
    may locate something that looks like a
  • 27:25 - 27:31
    task struct, but it's not clear which code
    does it actually represent. So the first
  • 27:31 - 27:43
    step here is to apply the log strings that
    were removed from the binary by Qshrink. I
  • 27:43 - 27:52
    think the only way to do it is by using
    that msg_hash.txt file from the leaked
  • 27:52 - 27:58
    sources. This file is not supposed to be
    available neither on the mobile devices
  • 27:58 - 28:05
    nor in some open ecosystem. And after you
    have applied these log strings, you will
  • 28:05 - 28:11
    be able to rename some functions. And
    based on these log strings and because the
  • 28:11 - 28:17
    log strings often contain the names of the
    source file, source module from which the
  • 28:17 - 28:27
    code was built. So it creates opportunity
    to understand what exactly this code is
  • 28:27 - 28:35
    doing. Debugging was completely
    unavailable in my case, and I realized
  • 28:35 - 28:45
    that it would require some couple of
    months more work to make it work and the
  • 28:45 - 28:49
    only way I think, and the best way is to
    create a software based debugger similar
  • 28:49 - 28:57
    to modkit, the publication that I will be
    referencing in the references, based on
  • 28:57 - 29:06
    software vulnerability in either the modem
    itself or in some authenticator or in the
  • 29:06 - 29:10
    trust zone so that we can inject a
    software debugger callbacks into the
  • 29:10 - 29:20
    baseband and connect it to the GDB stop.
    This is how the part of the firmware looks
  • 29:20 - 29:28
    that has log strings stripped out. Here it
    already has some names applied using IDA
  • 29:28 - 29:33
    script. So of course there was no such
    names initially, only the hashes. Each one
  • 29:33 - 29:38
    of these hashes represent a log string
    that you can take in from the message hash
  • 29:38 - 29:49
    file. And here is what you can get after
    you have applied the textual messages and
  • 29:49 - 29:54
    renamed some functions. In this case, you
    would be able to find some hundreds of
  • 29:54 - 30:00
    procedures that are directly related to
    the DIAG subsystem. And in a similar way
  • 30:00 - 30:07
    you can locate various subsystems related
    to over the air vectors as well. But
  • 30:07 - 30:18
    unfortunately, majority of the OTA vectors
    are located in the segments that are not
  • 30:18 - 30:23
    immediately available in the firmware, the
    ones that are compressed and relocated.
  • 30:23 - 30:31
    Meanwhile, I have tried many different
    things during this project. The things
  • 30:31 - 30:37
    that definitely worked is building the MSM
    kernel. There is nothing special about
  • 30:37 - 30:45
    this, just a regular cross-build. Another
    commonly well known offensive approach is
  • 30:45 - 30:50
    firmware downgrades. When you take some
    old firmware that contains a well-known
  • 30:50 - 30:56
    security vulnerability and flash it and
    use the bug to create and exploit to
  • 30:56 - 31:07
    achieve some additional functionality or
    introspection into the system. This part
  • 31:07 - 31:13
    definitely works, downgrades are trivial
    both on the entire firmware and a modem as
  • 31:13 - 31:19
    well as the trust zone. I did try to build
    the Qualcomm firmware from the leaked
  • 31:19 - 31:23
    source codes. I assigned just a few days
    to the task since it's not mission-
  • 31:23 - 31:30
    critical and I have run out of time,
    probably was a different version of sorce
  • 31:30 - 31:38
    codes. But actually, this is not a
    critical project because building leaked
  • 31:38 - 31:42
    firmware is not directly relevant to
    finding new bugs in the production
  • 31:42 - 31:53
    firmware. So I just said it aside for some
    later investigation. I have also
  • 31:53 - 31:58
    investigated the ramdump's ecosystem a
    little bit on the software side at least.
  • 31:58 - 32:11
    And it seems that it's also fused quite
    reliably. This is when I remembered about
  • 32:11 - 32:17
    the Qualcomm DIAG. During the initial
    reconnaisance I stumbled on some
  • 32:17 - 32:24
    whitepapers and slides that mentioned the
    Qualcomm diagnostic protocol. And it
  • 32:24 - 32:28
    seemed like quite a powerful protocol,
    specifically with respect to reconfiguring
  • 32:28 - 32:34
    the baseband. So I decided to, first of
    all, to test it in case that it would
  • 32:34 - 32:38
    actually provide some advanced
    introspection functionality and then
  • 32:38 - 32:49
    probably to use it.. to use the protocol for
    enabling log dumps. Qualcomm DIAG or QCDM
  • 32:49 - 32:53
    is a proprietary protocol developed by
    Qualcomm with the purposes of advanced
  • 32:53 - 33:00
    baseband software configuration and
    diagnostics. It is mostly aimed for OEM
  • 33:00 - 33:07
    developers, not for users. The Qualcomm
    DIAG protocol consists of around 200
  • 33:07 - 33:15
    commands at least in theory. Some of them
    are quite powerful on paper such as
  • 33:15 - 33:25
    downloader mode and read/write memory.
    Initially the DIAG was partially reverse
  • 33:25 - 33:34
    engineered around 2010 and included in the
    open source project named Modem Manager.
  • 33:34 - 33:40
    And then it was also exposed in a
    presentation at the Chaos Communication
  • 33:40 - 33:50
    Congress 2011 by Guillaume Delugré. I
    think this presentation popularized it and
  • 33:50 - 33:55
    this is the one that introduced me to this
    protocol. Unfortunately, that presentation
  • 33:55 - 34:02
    is not really relevant - majority of it -
    to modern production phones, but it does
  • 34:02 - 34:08
    provide a high level overview and a
    general expectation of what you will have
  • 34:08 - 34:15
    to deal with. From the offensive
    perspective, the DIAG protocol represents
  • 34:15 - 34:21
    a local attack vector from the application
    processor to the baseband. A common
  • 34:21 - 34:27
    scenario of how it can be useful is
    unlocking mobile phones which are locked
  • 34:27 - 34:33
    to a particular mobile carrier. If we find
    a memory corruption vulnerability in DIAG
  • 34:33 - 34:41
    protocol, it may be possible to execute a
    call directly on the baseband and change
  • 34:41 - 34:45
    some internal settings. This is usually
    accomplished historically through the IT
  • 34:45 - 34:51
    common handlers, but internal proprietary
    protocols are also very convenient for
  • 34:51 - 35:00
    that. The second scenario how that diag
    offensive can be useful is using it for
  • 35:00 - 35:09
    injecting a software based debugger. If
    you can find a bug in DIAG that enables
  • 35:09 - 35:14
    read/write capability on the baseband, you
    can inject some debugging hooks and
  • 35:14 - 35:23
    eventually connect it to a GDB stop. So it
    enables to create a software based
  • 35:23 - 35:32
    debugger even when GTAG is not available.
    What has changed in DIAG in 10 years based
  • 35:32 - 35:38
    on some cursory investigation that I did.
    First of all, the original publication
  • 35:38 - 35:46
    mentioned Qualcomm baseband based on ARM
    and with a Rex operating system. All modern
  • 35:46 - 35:51
    Qualcomm basements are based on
    Hexagon as opposed to ARM. And the Rex
  • 35:51 - 35:57
    operating system was replaced with Kirt,
    which I think is still has some bits of
  • 35:57 - 36:05
    Rex, but in general it's a different
    operating system. Majority of super
  • 36:05 - 36:10
    powerful commands of DIAG such as
    downloader mode and memory read/write were
  • 36:10 - 36:17
    removed, at least on my device. And also
    it does not expose any immediately
  • 36:17 - 36:26
    available interfaces such as USB channel.
    I hear that it's possible to enable the
  • 36:26 - 36:37
    USB DIAG channel by adding some special
    boot properties, but usually it's not, it
  • 36:37 - 36:43
    wouldn't be available. It shouldn't be
    expected to be available on all devices.
  • 36:43 - 36:49
    So this observations are based on my test
    device, Nexus 6b. And this this should be
  • 36:49 - 36:57
    around medium level of hardening. More
    modern devices such as Google pixels, the
  • 36:57 - 37:03
    modern ones should be expected to be even
    more hardened than that. Especially on the
  • 37:03 - 37:08
    Google side, because they take hardening
    very seriously. As opposed to it on the
  • 37:08 - 37:15
    other side of the spectrum if you think
    about some no name modem sticks, these
  • 37:15 - 37:24
    things can be more open and more easy to
    investigate. The DIAG implementation
  • 37:24 - 37:29
    architecture is relatively simple. This
    diagram is based roughly on the same
  • 37:29 - 37:34
    diagram that I presented in the beginning
    of talk. On the left side there is the
  • 37:34 - 37:42
    Android kernel and on the right side there
    is the baseband operating system. DIAG
  • 37:42 - 37:47
    protocol actually it works in both sides.
    It's not only commands that can be sent by
  • 37:47 - 37:51
    the application processor to the baseband,
    but it's also the messages that can be
  • 37:51 - 37:56
    sent by the baseband to the application
    processor. So DIAG comments are not really
  • 37:56 - 38:02
    comments - they're more like tokens that
    also can be used to encode messages. The
  • 38:02 - 38:10
    green arrows on this slide represents an
    example of call flow, of the data flow
  • 38:10 - 38:15
    originating from the baseband and going to
    the application processor. So obviously,
  • 38:15 - 38:26
    in case of commands there would be a
    reverse call flow or data flow. The main
  • 38:26 - 38:30
    entity inside the operating system,
    baseband operating system responsible for
  • 38:30 - 38:37
    DIAG is the DIAG task. It has a separate
    task which handles specifically various
  • 38:37 - 38:47
    operations related to the DIAG protocol.
    The exchange of data between the DIAG task
  • 38:47 - 38:55
    and other tasks are done through the ring
    buffer. So, for example, if some tasks
  • 38:55 - 39:06
    needs to log something through the DIAG,
    it will use specialized logging APIs that
  • 39:06 - 39:11
    will in turn put logging data into the
    ring buffer. The ring buffer will be
  • 39:11 - 39:20
    drained either on timer or on a software
    based interrupt from the caller. And at
  • 39:20 - 39:28
    this point the data will be wrapped into
    DIAG protocol and from there it will go to
  • 39:28 - 39:37
    sI/O task, this Serial I/O which is
    responsible to send in the output to a
  • 39:37 - 39:50
    specific interface. This is based on the
    modem, on the baseband configuration. The
  • 39:50 - 39:57
    main interface that I was dealing with is
    the shared memory, which ends up in the
  • 39:57 - 40:06
    DIAG shared driver inside the Android
    kernel. So in case of sending the commands
  • 40:06 - 40:12
    from the Android kernel to the baseband,
    it will be the reverse flow. First, you
  • 40:12 - 40:17
    will need to send some- to craft the DIAG
    protocol data, send it through the DIAG
  • 40:17 - 40:22
    shared driver that will write to the
    shared memory interface. From there, it
  • 40:22 - 40:28
    will go to the specialized task in the
    basement and eventually end up in the DIAG
  • 40:28 - 40:42
    task and potentially other responsible
    task. On the Android side, DIAG is
  • 40:42 - 40:48
    represented with the /dev/diag device,
    which is implemented with the diagchar,
  • 40:48 - 40:55
    and diagfwd kernel drivers in the MSM
    kernel. The purpose of the DIAG shared
  • 40:55 - 41:03
    driver is to support the DIAG interface.
    It is quite complex in code, but
  • 41:03 - 41:10
    functionally it's quite simple. It
    contains some basic minimum of DIAG
  • 41:10 - 41:15
    commands that enable configuration of the
    interface on the baseband side. And then
  • 41:15 - 41:21
    it would be able to multiplex the DIAG
    channel to either USB or a memory device.
  • 41:21 - 41:30
    It also contains some IOCTLs for
    configuration that can be accessed from
  • 41:30 - 41:36
    the Android user land. And finally, the
    IOCTL filters various DIAG commands that
  • 41:36 - 41:44
    it considers unnecessary. This is a bit
    important because when you will start,
  • 41:44 - 41:48
    when you'll try to do some tests and send
    some arbitrary DIAG comments with the DIAG
  • 41:48 - 41:55
    interface, you would be required to
    rebuild the actual driver to remove this
  • 41:55 - 42:03
    masking, otherwise your commands will not
    make it to the baseband side. At the core,
  • 42:03 - 42:09
    the DIAG shared driver is based on the SMD
    shared memory device interface, which is a
  • 42:09 - 42:21
    core interface specific to Qualcomm modem.
    So this is where DIAG is, diagchar
  • 42:21 - 42:29
    is on the diagram. The diagchar
    driver itself is located in the
  • 42:29 - 42:39
    application OS's vendor specific drivers.
    And then there is some shared memory
  • 42:39 - 42:44
    implementation in the baseband that
    handles this and the DIAG implementation
  • 42:44 - 42:57
    itself. diagchar driver is quite complex
    in code, but the functionality is quite
  • 42:57 - 43:07
    simple. It does implement a handful of
    CTLs that enables some configuration. I
  • 43:07 - 43:15
    didn't check what exactly this IOCTLs are
    responsible for. It exposes the /dev/diag
  • 43:15 - 43:19
    device which is available for it in the
    writing. However, by default, you are not
  • 43:19 - 43:25
    able to access the DIAG channel based
    on- for this device, because in order to
  • 43:25 - 43:33
    access it, there is diag_switch_logging
    function, which switches the channel that
  • 43:33 - 43:41
    is used for DIAG communications. On the
    screen there are several modes listed, but
  • 43:41 - 43:45
    in practice only two of them are
    supported. The USB mode and the memory
  • 43:45 - 43:53
    device mode. USB mode is the default, so
    which is why if you just open, the
  • 43:53 - 43:58
    /dev/diag driver, dev/diag device and try
    to read something from it, it won't work,
  • 43:58 - 44:08
    is tied to USB. And in order to
    reconfigure it to use the memory device,
  • 44:08 - 44:17
    you need to send a special IOCTL code.
    Notice the procedure named
  • 44:17 - 44:25
    mask_request_validate, which employs a
    quite strict filtering on the DIAG commands
  • 44:25 - 44:32
    that you try to send through this
    interface. So it filters out basically
  • 44:32 - 44:40
    everything with the exception of some
    basic configuration requests. At the core,
  • 44:40 - 44:47
    DIAG shared driver use the shared memory
    device to communicate with the baseband.
  • 44:47 - 44:55
    The SMD implementation is quite complex.
    It exposes SMD Read API, which is used by
  • 44:55 - 45:03
    DIAG share for reading the data from the
    shared memory, one of the APIs. Shared
  • 45:03 - 45:14
    memory also operates on the abstraction of
    channels which are accessed through the
  • 45:14 - 45:20
    API named smd_named_open_on_edge. So you
    can notice here that there are some DIAG
  • 45:20 - 45:25
    specific channels that can be opened.
    Now, let's take a look at the SMD
  • 45:25 - 45:30
    implementation. This is a bit important
    because a shared memory device represents
  • 45:30 - 45:33
    a part of the attack surface for
    escalation from the modem to the
  • 45:33 - 45:38
    application processor. This is a very
    important attack surface because if you
  • 45:38 - 45:43
    just achieve code execution on the
    baseband, it's mostly useless because it
  • 45:43 - 45:49
    cannot access the main operating system.
    And in order to make it useful, you'll
  • 45:49 - 45:59
    need to create and exploit chain and add
    one more exploit based on that bug with
  • 45:59 - 46:04
    privilege escalation from the modem to the
    application processor. So shared memory
  • 46:04 - 46:11
    device is one of the attack surfaces for
    this. The shared memory device is
  • 46:11 - 46:22
    implemented as exposed memory region
    exposed by the Qualcomm peripheral. The
  • 46:22 - 46:29
    specialized MSM driver will map it and
    here it's the name is smem_ram_phys, the
  • 46:29 - 46:40
    base of the shared memory region. The
    shared memory region operates on the
  • 46:40 - 46:51
    concept of entries and channels, so it's
    partitioned in distant parts that can be
  • 46:51 - 47:00
    accessed through the procedure,
    smem_get_entry and one of these entries is
  • 47:00 - 47:08
    SMEM_CHANNEL_ALLOC_TBL, which contains the
    list of available channels that can be
  • 47:08 - 47:14
    opened. From there, we can actually open
    the channels and use the shared memory
  • 47:14 - 47:26
    interface. During this initial research
    project, it wasn't my goal to research the
  • 47:26 - 47:32
    entire Qualcomm ecosystem, so while I was
    preparing for this talk, I have noticed
  • 47:32 - 47:38
    some more interesting things in the source
    codes, such as, for example, the
  • 47:38 - 47:46
    specialized driver that handles GTAG
    memory region, which is presumably exposed
  • 47:46 - 47:53
    by some Qualcomm system of chips. In the
    drivers this is mostly used read only, and
  • 47:53 - 47:59
    I suppose that will not really work for
    writing, but it's worth checking probably.
  • 47:59 - 48:08
    And now, finally, let's take a look at the
    DIAG protocol itself. One of the first
  • 48:08 - 48:13
    things that I noticed when researching the
    DIAG protocol is that it's actually used
  • 48:13 - 48:21
    in a few places, not only in libqcdm. A
    popular tool named SnoopSnitch can enable
  • 48:21 - 48:27
    protocol dumps, so there are protocol
    dumps on rooted devices. And in order to
  • 48:27 - 48:33
    accomplish this, it's SnoopSnitch sends an
    opaque blob of the commands to the mobile
  • 48:33 - 48:40
    device through the DIAG interface. This is
    blob is not documented. So it got me
  • 48:40 - 48:47
    curious what exactly these commands are
    doing. But before we can look at the dump,
  • 48:47 - 48:54
    let's understand the protocol. The DIAG
    protocol consists of around 200 of commands
  • 48:54 - 49:02
    or tokens. Some of them are documented in
    the open source, but not all of them. So
  • 49:02 - 49:08
    you can notice on the screenshots, some of
    the commands are missing. And one of the
  • 49:08 - 49:22
    missing commands is actually the token 0x92
    hexadecimal, which represents an encoded hash log
  • 49:22 - 49:34
    message. The common format is quite
    simple. The best pritimitive here is the
  • 49:34 - 49:43
    DIAG token number 0x7E, it's not really a
    delimiter, it's a separate DIAG command
  • 49:43 - 49:50
    126. It's missing in the open source, as
    you can see here. So the DIAG command is
  • 49:50 - 49:58
    nested. The outer layer consists of this
    wrapper of 0x7e hexadecimal bytes. Then
  • 49:58 - 50:02
    there is the main command and then there
    is some variable length data that can
  • 50:02 - 50:11
    contain even more subcommands. This entire
    thing is verified using the CRC and some
  • 50:11 - 50:17
    bytes are escaped. Specifically, as you
    can see on the snippet. One interesting
  • 50:17 - 50:25
    thing about the DIAG protocol is that it
    supports subsystem extensions. Basically,
  • 50:25 - 50:30
    different subsystems in the baseband can
    register their own DIAG system handlers,
  • 50:30 - 50:38
    arbitrary ones. And there is a special DIAG
    command number 75, which simply forwards..
  • 50:38 - 50:43
    instructs the DIAG system to forward this
    command to the respective subsystem. And
  • 50:43 - 50:57
    then it will be parsed there. There exists
    quite a large number of subsystems. Not
  • 50:57 - 51:01
    all of them are documented, and when I
    started investigating this, I noticed that
  • 51:01 - 51:08
    there actually exists a DIAG subsystem-
    subsystem and debugging subsystem. The
  • 51:08 - 51:15
    later one immediately interested me
    because I was hoping that it would enable
  • 51:15 - 51:20
    some more advanced introspection through
    this debugging subsystem. But it turned
  • 51:20 - 51:26
    out that the debugging subsystem is quite
    simple. It only supported one command:
  • 51:26 - 51:35
    inject crash. So you can send a special
    DIAG comment that will inject the crash
  • 51:35 - 51:44
    into the baseband. I will talk later about
    this. Now, let's take a look at specific
  • 51:44 - 51:52
    examples of the DIAG protocol. This is the
    annotated snippet of the blob of commands
  • 51:52 - 52:01
    from SnoopSnitch. This blob actually
    consists of three large logical parts. The
  • 52:01 - 52:04
    first part is largely irrelevant. It's a
    bunch of commands that request various
  • 52:04 - 52:10
    informations from the baseband, such as
    timestamp, version info, build id and so
  • 52:10 - 52:17
    on. The second batch of commands starts
    with a command Number 0x73 hexadecimal.
  • 52:17 - 52:27
    This is DIAG common log config. This is the
    command which enables protocol dumps and
  • 52:27 - 52:34
    configures them. And third part of this
    blob starts with the command number 0x7D
  • 52:34 - 52:38
    hexadecimal. This is the
    CMD_EXT_MESSAGE_CONFIG. This is actually
  • 52:38 - 52:43
    the command that is supposed to enable
    textual message logging, except that in
  • 52:43 - 52:52
    case of SnoopSnitch it disables all of the
    logging altogether. So how do you actually
  • 52:52 - 52:57
    cellular protocol dumps work? In order to
    enable the cellular product dumps, we need
  • 52:57 - 53:04
    DIAG_CMD_LOG_CONFIG, number 0x73
    hexadecimal. It is partially documented in
  • 53:04 - 53:13
    the libqcdm. The structure of the packet
    would contain the code and the subcommand,
  • 53:13 - 53:18
    that would be set mask in this case. It
    also needs an equipment ID, which
  • 53:18 - 53:25
    corresponds to the specific protocol that
    we want to dump. And finally, the masks
  • 53:25 - 53:33
    that are applied to filter some
    parts of the dump. This is relatively
  • 53:33 - 53:41
    straightforward. And now the second command, DIAG_CMD_EXT_MESSAGE_CONFIG. This
  • 53:41 - 53:48
    is the one which is supposed to enable
    textual message logs. The command format
  • 53:48 - 54:00
    is undocumented. So let's take a closer
    look at it. The command consists of a
  • 54:00 - 54:07
    subcommand. In this case, it's subcommand
    number 4, the set mask. And then there are
  • 54:07 - 54:16
    two 16 bit integers. SSID start and end.
    SSID is subsystem ID, which is not the
  • 54:16 - 54:26
    same as DIAG subsystems. And the last one
    is the mask, so subsystem IDs are used to
  • 54:26 - 54:32
    filter the messages based on a specific
    subsystem, because there is a huge amount
  • 54:32 - 54:36
    of subsystems in the baseband. And if all
    of them start logging, this is a huge
  • 54:36 - 54:42
    amount of data. So DIAG provides this
    capability to filter a little bit, to a
  • 54:42 - 54:50
    specific subsystem that you're interested
    in. The snippet of Python code here is an
  • 54:50 - 54:58
    example how to enable textual message logging
    for all subsystems. You need to set the
  • 54:58 - 55:13
    mask to all 1s. And this is quite a lot of
    logging in my experience. Now for parsing
  • 55:13 - 55:18
    the incoming log messages, there are two
    types of DIAG tokens, both of them are
  • 55:18 - 55:26
    undocumented. The first one is a legacy
    message number 0x79 hexadecimal. This is a
  • 55:26 - 55:32
    simple ASCII based message that arrives
    through the DIAG interface so you can
  • 55:32 - 55:39
    parse it quite straightforwardly. The
    second one is I called it
  • 55:39 - 55:44
    DIAG_CMD_LOG_HASH, it's number 0x92
    hexadecimal. This is the token which
  • 55:44 - 55:51
    encodes the log messages that contain only
    the hashes. This is the one that if you
  • 55:51 - 55:58
    have the msg_hash.txt file, you can
    correspond the hash that was arrived to
  • 55:58 - 56:02
    this command to the messages provided in
    the text file. And you can get the textual
  • 56:02 - 56:09
    logs. On the lower part of the slide there
    are two examples of hexdumps from both
  • 56:09 - 56:16
    commands. Both of them have a similar
    structure. First, there are 4 bytes
  • 56:16 - 56:24
    that are essential. The first one is the
    command itself. And the third byte is
  • 56:24 - 56:31
    quite interesting is the number of
    arguments included. Next there is 64 bit
  • 56:31 - 56:40
    value of timestamp. Next there is the SSID
    value, 16 bit. Some line number, and I'm
  • 56:40 - 56:49
    not sure what is the next argument. And
    finally, after that, there is either ASCII
  • 56:49 - 56:59
    encoded log string in plain text or hash
    of the log string. And optionally there
  • 56:59 - 57:06
    may be included some arguments, though, in
    case of the first legacy command. The
  • 57:06 - 57:10
    arguments are included before the log
    message and in case of the second command
  • 57:10 - 57:17
    they are included after the MD5 hash in
    the log message, at least in my version of
  • 57:17 - 57:29
    this implementation. And this is the DIAG
    packet that enables you to inject a crash
  • 57:29 - 57:37
    into the baseband, at least in theory.
    Because in my case it did not work. And by
  • 57:37 - 57:41
    not working, I mean that it did simply not
    enter the baseband. Normally, I would
  • 57:41 - 57:46
    expect that on production device it should
    just reset the baseband. You will not get
  • 57:46 - 57:53
    a crash dump or anything like that, just a
    reset. So I suppose that it still should
  • 57:53 - 57:58
    be working on some other devices. So it's
    worth of checking. There are a few types of
  • 57:58 - 58:10
    crashes that you can request in this way.
    In order to accomplish this, I needed a
  • 58:10 - 58:17
    very simple tool with basically two
    functions. first, direct easy access to
  • 58:17 - 58:23
    the DIAG interface, ideally through some
    sort of python shell. And second is the
  • 58:23 - 58:30
    ability to read and parse data with
    advanced log strings. For that purpose. I
  • 58:30 - 58:38
    wrote a simple framework that I named
    diagtalk, which is based directly on the
  • 58:38 - 58:49
    diag interface in the Android kernel and
    or with a Python harness. So on the left
  • 58:49 - 58:57
    side, here is the example of some advanced
    parsing with some leaked values. And on
  • 58:57 - 59:02
    the right side, here is the example of the
    advanced message log, which includes the
  • 59:02 - 59:11
    log strings that were extracted.. that were
    stripped out from the firmware. The log is
  • 59:11 - 59:17
    quite fun, as I expected it to be, it has
    a lot of detailed data, such as, for
  • 59:17 - 59:23
    example, GPS coordinates and various
    attempts of the basement to connect to
  • 59:23 - 59:35
    different channels. And I think it's quite
    useful for offensive research purposes,
  • 59:35 - 59:43
    it's even contained sometimes raw pointers
    as you can notice on the screenshot. So in
  • 59:43 - 59:50
    this project, my conclusion was that
    indeed I was reassured that it was the
  • 59:50 - 59:57
    right choice and Hexagon seems to be a
    quite a challenging target, and it would
  • 59:57 - 60:01
    probably need several more months of work
    to even begin to do some serious offensive
  • 60:01 - 60:08
    work. I also started to think about
    writing a software debugger because it
  • 60:08 - 60:16
    seems to be the most.. probably the most
    reliable way to achieve debugging
  • 60:16 - 60:22
    introspection. And also, I noticed some
    blank spaces in the field that may require
  • 60:22 - 60:28
    future work. For Qualcomm Hexagon
    specifically, there is a lot of things
  • 60:28 - 60:36
    that can be done. For example, you can
    take a look at other Qualcomm proprietary
  • 60:36 - 60:41
    diagnostic protocols of which there are a
    few, such as QMI for example, I think they
  • 60:41 - 60:49
    are lesser known than DIAG protocol. And
    then there is a requirement to create a
  • 60:49 - 60:59
    full system emulation based on QEMU at
    least for some chips. And a big problem
  • 60:59 - 61:04
    about the decompiler, which is a major
    obstacle to any serious static analysis in
  • 61:04 - 61:15
    the code and for the offensive research,
    there are 3 large directions. First one is
  • 61:15 - 61:19
    enabling debugging. There are different
    ways for that. For example, software based
  • 61:19 - 61:26
    debugging or bypassing JTAG fusing, on the
    other hand. Next, there are explorations
  • 61:26 - 61:33
    of the over the air attack vectors. And
    the 3rd one is escalation from the baseband
  • 61:33 - 61:39
    to the application processor. These are
    the 3 large offensive research vectors.
  • 61:39 - 61:45
    And for the basebands in general, there
    also exists some interesting directions of
  • 61:45 - 61:54
    future work. First of all, the OsmocommBB.
    It definitely deserves some update a
  • 61:54 - 62:00
    little bit. It is the only one open source
    implementation of a baseband. And it is so
  • 62:00 - 62:09
    outdated. And there is, and it is based on
    some real obscure hardwares. Another
  • 62:09 - 62:18
    problem here is that there doesn't exist
    any software based CDMA implementation.
  • 62:18 - 62:29
    No sound
  • 62:29 - 62:34
    Herald: Alisa, thank you very much for
    this nice talk. Um, there are some
  • 62:34 - 62:39
    questions from the audience. So basically
    the first one is a little bit of an
  • 62:39 - 62:46
    icebreaker: Do you use a mobile phone?
    And do you trust it?
  • 62:46 - 62:52
    Alisa: No, I don't try to use a mobile
    phone only for Twitter. Does anyone still
  • 62:52 - 63:00
    use mobile phones nowadays?
    H: laughs Well, no idea. Another
  • 63:00 - 63:08
    question concerns the other Qualcomm
    chips. Did you have a look at the Qualcom
  • 63:08 - 63:16
    Wi-Fi chips sets?
    A: As I mentioned during the talk, I had
  • 63:16 - 63:21
    only one month. It was like a short
    reconnaissance project, so I didn't really
  • 63:21 - 63:27
    have time to investigate everything. I did
    notice that Qualcomm socks have a Wi-Fi
  • 63:27 - 63:32
    chip, which is also based on Hexagon. And
    more than that, it also shares some of the
  • 63:32 - 63:39
    same low level technical primitives. So
    it's definitely worth looking, but I didn't
  • 63:39 - 63:45
    investigate it in details.
    H: OK, OK, thanks. There is also a pretty
  • 63:45 - 63:51
    technical question here, so instead of
    having to go through the rigorous command
  • 63:51 - 63:58
    checking for the DIAG card driver,
    wouldn't it be possible to nmap /dev/mem
  • 63:58 - 64:05
    into userspace process and send over
    commands directly so. Depends a little bit
  • 64:05 - 64:12
    on what the goal is.
    A: OK, so it really depends on your
  • 64:12 - 64:17
    previous background and your goals. The
    point here is that by default, the DIAG
  • 64:17 - 64:23
    shared ecosystem does not allow to send
    arbitrary DIAG commands. So either way,
  • 64:23 - 64:29
    you will have to hack something. One way
    to hack this is to rebuild the actual
  • 64:29 - 64:34
    driver. So you would be able to send the
    commands directly through that DIAG
  • 64:34 - 64:38
    interface. Another way would be to access
    the shared memory directly, for example.
  • 64:38 - 64:42
    But I think it would be more complex
    because the Qualcomm shared memory
  • 64:42 - 64:47
    implementation is quite complex. So I
    think that the easiest way would be
  • 64:47 - 64:53
    actually to hack the DIAG shared driver
    and use the deb. DIAG interface for this.
  • 64:53 - 65:00
    H: OK, thanks. Thanks. There is one
    question which I'm going to read out,
  • 65:00 - 65:15
    maybe you can make sense of it: is this
    typically [unclear] security fall mobile phones?
  • 65:15 - 65:19
    A: This level of hardening that I
    presented, I think is around medium level.
  • 65:19 - 65:24
    So usually production falls are even more
    hardened. If you take a look at things
  • 65:24 - 65:31
    like Google Pixel5 or the latest iPhones,
    they will be even better, hardened than
  • 65:31 - 65:39
    the one that I discussed.
    H: Oh, OK. Yeah, thanks. Thanks then. So it
  • 65:39 - 65:43
    doesn't look like we have any more
    questions left. Anyway, so if you want to
  • 65:43 - 65:49
    get in contact with Alisa, no problem.
    There is the feedback tab below your
  • 65:49 - 65:57
    video now at the moment, just drop your
    questions over there. And that's a way to
  • 65:57 - 66:03
    get in touch with Alisa. Other than that I
    would say we're done for today for this
  • 66:03 - 66:07
    session. Thank you very, very much Alisa
    for this really nice presentation once
  • 66:07 - 66:14
    again. Applause And I'll transfer now over
    to the Herald News Show.
  • 66:14 - 66:34
    postroll music
  • 66:34 - 66:54
    Subtitles created by c3subtitles.de
    in the year 2021. Join, and help us!
Title:
#rC3 - Advanced Hexagon Diag
Description:

more » « less
Video Language:
English
Duration:
01:06:54

English subtitles

Revisions