 Our next speaker, Aliza Essage, is an independent vulnerability researcher and has a notable record of security research achievements such as this year's initiative Silver Bounty Hunter Award 2018. Aliza is going to present her latest research on the Qualcomm Direct Protocol which is found abundantly in Qualcomm hexagon-based solar modems. Aliza, we're looking forward to your talk now. This is Aliza Essage. You're attending my presentation, Advanced Hexagon Direct at Chaos Communication Congress 2020 remote experience. My main interest as an advanced vulnerability researcher is complex system and hardened systems. For the last 10 years, I have been researching various classes of software such as Windows kernel, browsers, JavaScript engines and for the last three years I was focusing mostly on hyperusers. The project that I'm presented today was a little side project that I made for destruction a couple of years ago. The name of this talk, Advanced Hexagon Direct, is a bit of an understatement in the attempt to keep this talk a little bit low key in the general internet because a big part of the talk will actually be devoted to general vulnerability research in basebands. But the primary focus of this talk is on the hexagon direct, also known as QCDM, Qualcomm diagnostic manager. This is a proprietary protocol developed by Qualcomm for use in their basebands and it is included on all Snapdragon socks and modem chips produced by Qualcomm. Modern Qualcomm chips run on a custom silicone with a custom instruction set architecture named QDSP6 hexagon. This is important because all the diacandlers that we will be dealing with are written in this instruction set architecture. As usually with my talks I have adjusted the materials of this presentation for various audiences, for the full spectrum of audiences. Specifically the first part of the presentation is mostly specialized for research directors and high-level technical stuff. And the last part is more deep technical and it would be mostly interesting to do specialized vulnerability researchers and low-level programmers that somehow are related to this particular area. Let's start from the top level overview of cellular technology. This mind map presents a simplified view of various types of entities that we have to deal with with respect to basebands. It's not a complete diagram of course but it only presents the classes of entities that exist in this space. Also this mind map is specific to the clean side equipment, the user equipment and it completely omits any server side considerations which are enrolled in their own. There exists quite a large number of cellular protocols on the planet. From the user perspective this is simple. This is usually the short name 3g4g that you see on the mobile screen. But in reality this simple name that generation name encodes may encode several different distant technologies. There are a few key points about cellular protocols that are crucial to understand before starting to approach this area. The first one is the concept of a generation. This is simple. This is simply the 1g2g and so on. The generic name of a family of protocols that are supported at a particular generation. Generation is simply a marketing name for users. It doesn't really have any strict technical meaning and generations represent the evolution of cellular protocols in time. The second most important thing about cellular protocols is the air interface. This is or the protocol which actually this is the lowest level protocol which defines how exactly that cellular signal is digitized and read from the electromagnetic wave and how exactly the different players in this field divide the space. Historically there existed two main implementations of this low-level protocol, TDMA and CDMA. TDMA means time division multiple axis which basically divides the entire electromagnetic spectrum within the radio band into time slots that are rotated in a round robin manner by various mobile phones so that they speak in turns. TDMA was the base for the GSM technology and GSM was the main protocol used on this planet for a long time. Another low-level implementation is CDMA. It was a little bit more complex from the beginning. It's decoded as co-division multiple axis and instead of dividing the spectrum by in time slots and dividing the protocol in bursts, CDMA uses pseudo-random codes that are assigned to mobile phones so that this code can be used as an additional randomizing mask against the modulation protocol and multiple user equipments can talk on the same frequency without interrupting each other. Notable here that CDMA was developed by Qualcomm and it was mostly used in the United States. So at the level of 2G there were two main protocols GSM based on the TDMA and CDMA1 based on the CDMA. The third generation of mobile protocols, these two branches of development were continued so GSM evolved into UMTS while CDMA1 evolved into CDMA2000. The important point here is that UMTS have at this point already adopted the low-level air interface protocol from the CDMA and eventually at the fourth generation of protocols these two branches of development come together to create the LTE technology and same for the 5G. This is a bit important for us as from the offensive perspective because first of all all these technologies including the air interfaces represent separate bits of code with separate parsing algorithms within the baseband firmware and all of them are usually presented in each baseband regardless of which one do you actually use does your mobile provider actually support. Another important and non-obvious thing from the offensive security perspective here is that because of this evolutionary development the protocols are not actually completely distinct. So if you think about LTE it is not completely different protocol from GSM but instead it is based largely on the same internal structures and in fact if you look at the specifications they some of them are almost directly relevant the specifications of the GSM to G some of them are still directly relevant to some extent to LTE. This is also important when you start analyzing protocols from the offensive perspective. The cellular protocols are structured in a nested way in layers. Layers is the official terminology adopted by the specifications. With the exception of level zero here I just edited for convenience but in the specifications layers start from one and proceed to three. From the offensive perspective the most interesting is level three as you can see from the screenshot of the specifications because it encodes most of the high-level protocol data such as handling SMS and GSM. This is the part of the protocol which actually contains interesting data structures with TLV values and so on. When people talk about attacking basebands they usually mean attacking baseband over the air the OTA attack vector which is definitely one of the most interesting but let's take a step back and consider the entire big picture of the baseband ecosystem. This diagram presents a unified view of generalized architecture of a modern baseband with attack surfaces. First of all there are two separate distant processors the AP application processor and the MP which is mobile processor it may be in either a DSP or another CPU. Usually there are two separate processors and each one of them runs as separate operating system. In case of the AP it may be Android or iOS and the baseband processor will run some sort of a real-time operating system provided by the mobile vendor. Important point here that on modern implementations baseband are usually protected by some sort of secure execution environment maybe trust on androids or servers on Apple devices which means that the privileged boundary which is depicted here on the left side is dual-sided so even if you have kernel access to the Android kernel you still are not supposed to be able to read the memory of the baseband or somehow intersect with the separation at least on the modern production smartphones and the same goes around to the baseband which is not supposed to be able to access to application processor directly. So these two are mutually distrusting entities that are separated from each other and so there exists a privileged boundary which is which represents an attack attack surface. Within the real-time operating systems there are three large attack surfaces starting from right to left the rightmost gray box represents the attack surface of the cellular stacks. This is the code which actually parses the cellular protocols. It's usually runs in several distant real-time operating system tasks. This part of the attack surface handles all the layers of the protocol. There is a huge amount of parsing that happens here. The second box represents various management protocols. The simplest one to think about is the AT common protocol. It is still widely included in all basements and it's even usually exposed in some way to the application processor so you can actually send some AT commands to the cellular madam. A bit more interesting is the vendor-specific management protocols. One of them is the DIAC protocol. Because the basements, modern basements are very complex so vendors need some sort of specialized protocol to enable configuration and diagnostics for the OMS. In case of Qualcomm for example DIAC is just one of the many diagnostic protocols involved. The third box is what I call the RTO score. It is various core level functionality such as the code which implements the interface to the application processor. On the side of the application operating system such as Android there are also two attack surfaces that are attackable from the basement. The first one is the peripheral drivers because the basement is a separate hardware peripheral so it requires some specialized drivers that handle IO and such things. And the second one is the dark surface represented with various interface handlers because the basement and the main operating system cannot communicate directly. They use some sort of a specialized interface to do that. In case of Qualcomm this is shared memory and so this shared memory implementations are usually quite complex and they represent an attack surface on the both sides. And finally the third piece of this diagram is in the lowest part I have depicted two great boxes which are related to a trusted execution environment because typically Modem runs as a trustlet in a secure environment. So technically the attack surfaces that exist within the trust zone or related to it also can be useful for basement offensive research. Here we can distinguish at least two large attack surfaces. The first one is the secure manager call handlers which is the core interface that handles calls from the application processor to the trust zone. And the second one are the trustlets the pieces of separate pieces of code which are executed and protected by the trust. On this diagram I have also added some information about data codecs. I'm not sure if they are supposed to be in the R2S core because these things are directly accessible from the cell or stacks usually. Especially ASN1 which I have seen some bugs or reachable from the over the air interface. On this diagram I have shown some example of vulnerabilities. I will not discuss them in details here since it's not the point of the presentation. But at least the ones from the point of all you can find the write-ups on the internet. To discuss basement offensive tools and approaches I have narrowed down the previous diagram to just one attack surface that over the air attack surface. This is the attack surface which is represented by parsing implementations of various cellular protocols inside the basement operating system. And this is the attack surface that we can reach from the air interface. In order to accomplish that we need transceivers such as software-defined radio or a mobile tester which is able to talk the specific cellular protocol that we're planning to attack. The simplest way to accomplish this is use some sort of a software-defined radio such as Atos Research Resort P or Blade RF and install open source implementation of a base station such as OpenBTS or OpenBSC. The thing to note here is that the software-based implementations actually lag behind the development of technologies. The implementations of GSM base stations are very well established and popular such as OpenBTS. And in fact when I tried to establish BTS with my usrp it was quite simple. For UMTS and LT there exist less number of software-based implementations and also there are more constraints on the hardware. For example my model of the usrp does not support UMTS due to resource constraints and the most interesting thing here is that there it does not exist any software-based implementation of the CDMA that you can use to establish a base station. This is a pseudo-random diagram of one of the snapdragon chips. There exists a huge amount of various models of snapdragons. This one I have chosen to sell randomly when I was searching for some sort of visual diagram. Qualcomm used to include some high-level diagrams of the architecture in their marketing materials previously but it seems that they don't do this anymore. And this particular diagram is from a technical specification of a particular model 820. Also this particular model of snapdragon is a bit interesting because it is the first one that included the artificial intelligence agent which is also based on hexagon. For purposes the main interest here are the processors. Majority of snapdragons include quite a long list of processors. There are at least four ARM-based cryo CPUs that actually run the Android operating system. Then there are the Adreno GPUs and then there are several hexagons. On the most recent models there is not just one hexalon processing unit but several of them and they are called respectively to their purposes. Each one of them, each one of these hexagon cores is responsible for handling a specific functionality. For example MDSP handles modem and runs the real-time operating system. The ADSP handles media and the CDSP handles compute. So the hexagons actually represent around one half of the processing power on modern snapdragons. There are two key points about the hexagon architecture from the hardware perspective. First of all it is a hexagon is specialized to parallel processing and so the first concept is variable-sized instruction packets. It means that the several instructions can execute simultaneously on inseparate execution units. It also uses hardware multithreading for the same purposes. On the right side of the slide here is some example of the hexagon assembly. It is quite funny at times these curly brackets represent the instructions that are executed simultaneously and these instructions must be compatible in order to be able to use the different processing slots. And then there is the funny.new notation which actually enables the instructions to use both the old and the new value of a particular register within the same instruction cycle. This provides quite a bit of optimization on the low level. For more information I can direct you to the hexagon specification of programmer's reference manual which is available from the Qualcomm website. The concept of production fusing is quite common. As I said previously it's a common practice from mobile device vendors to lock down the devices before they enter the market to prevent modifications and tinkering. And for the purposes of this locking down there are several ways how this can be accomplished. Usually various advanced diagnostic and debugging functionalities are removed from either software or hardware on both. It is quite common that these functionalities are only removed from software while the hardware remains here. And in such a case we will eventually the researchers will come up with their own software based implementation of this functionality as in case with some custom ios kernel debuggers for example. In case of Qualcomm there was at some point a leaked internal memo which discusses what exactly they are doing for production fusing the devices. In addition to production fusing in case of modern androids the basement runs within the trust zone and on my implementation it is already quite locked down it uses a separate component the basement uses a separate component named the MBA which stands from the modern basic authenticator. And this entire thing is run by the subsystem of android kernel named Peel the peripheral image logger you can open the source code and investigate how exactly it looks. And the purpose of the MBA is to authenticate the modern firmware so that you would not be able to inject some arbitrary commands into the modern firmware and flash it. This is another side of the hardening so which makes it very difficult to inject any arbitrary code into the basement. Basically the only way to do this is through a software vulnerability. During this project I have reverse engineered partially the hexagon modern firmware from my implementation or from my Nexus 6B. The process of reverse engineering is not very difficult first of all you need to download the firmware from the website from the google website in this case then you need to find the binary which corresponds to the modern firmware the this binary is actually a compound binary as corresponds that must be divided into separate binaries that represent specific sections inside the inside the firmware. And for that purpose we can use the unified translate script. After you have split the basement firmware into separate sections you can load them into idapro. There are several plugins available for idapro that support hexagon. I have tried one of them I think it was gsmk and it works quite good for basic curves engineering purposes. Notably here is that some sections of the modern firmware are compressed and relocated at runtime so you would not be able to reverse engineer them and unless you can decompress them which is also a bit of a challenge because the Coilcom uses some internal compression algorithm for that. For the reverse engineering the main approach here is to get started with some root points for example because this is a real-time operating system we know that it should have some task structures and task structures that we can locate and from there we can locate some interesting code. In case of hexagon this is a bit non-trivial because as I said it doesn't have any lock strings so even though you may locate something that looks like a task slot but it's not clear which code does it actually represent. So the first step here is to apply the lock strings that were removed from the binary by Q-Shrink. I think the only way to do it is by using the mst underscore hash txt file from the link sources. This file is not supposed to be available neither on the mobile devices nor in some open ecosystem and after you have applied these lock strings you will be able to rename some functions and basically these lock strings and because the lock strings often contain the names of the source file source module from which the code was built so it creates an opportunity to understand what exactly this code is doing. Debugging was not was completely unavailable in my case and I realized that it would require some couple of months more work to make it work and the only way I think and the best way is to create a software-based debugger similar to modkit that the publication that I will be referencing in the references based on software vulnerability in either the modem itself or in some authentic authenticator or in the trust zone so that we can eject a software debugger callbacks into the baseband and connect it to the gdb stop. This is how the part of the firmware looks that has lock strings stripped out. Here it's already has some names applied using edascript so of course there was no such names initially only the hashes each one of these hashes represent a lock string that you can take in the from the message hash file and here is what you can get after you have applied the textual messages and rename some functions in this case you would be able to find some hundred of procedures that are directly related to the DIAC subsystem and in a similar way you can locate various subsystems related to over-the-air vectors as well but unfortunately majority of the OTA OTA vectors are located in the segments that are not immediately available in the firmware the ones that are compressed and relocated meanwhile I have tried many different things during this project the things that definitely worked is building the MSM kernel there is nothing special about this just to wriggle across build another common commonly well-known offensive approach is firmware downgrades when you take some old firmware that contains a well-known security vulnerability and flash it and use the bug to create an exploit to achieve some additional functionality or introspection into the system this part definitely works downgrades a trivial both on the entire firmware and modem as well as the trust zone I did try to build the Qualcomm firmware from the leaked source codes I assigned just a few days to this task since it's not mission critical and I have run out of time probably was different version of source codes but actually this is not a critical project because building a leaked firmware is not directly relevant to find a new box in the production firmware so I just set it aside for some later investigation also investigated the RAM dumps ecosystem a little bit on the software side at least and it seems that it's also fused quite reliably this is when I remembered about the Qualcomm diagram during the initial reconnaissance I stumbled on some white papers and slides that mentioned the Qualcomm diagnostic protocol and it seemed like quite a powerful protocol specifically with respect to reconfiguring the baseband so I decided to first of all to test it in case that it would actually provide some advanced introspection functionality and then probably to use it to use the protocol for enabling love love dumps Qualcomm DIAC or QCDM is a proprietary protocol developed by Qualcomm with the purposes of advanced baseband software configuration and diagnostics it is mostly aimed for OM developers not for users the Qualcomm DIAC protocol consists of around 200 commands it is in theory that some of them are quite powerful on paper such as download or mode and read write memory initially the DIAC was partially reverse engineered around 2010 and included in the open source project named modem manager and then it was also exposed in a presentation at the caos communication progress or caos communication congress 2011 by Guillaume de l'Occret I think this presentation popularized it and this is the one that introduced me to this protocol unfortunately that presentation is not really relevant majority of it to modern production phones but it does provide a high level overview and a general expectation of what you will have to deal with from the offensive perspective the DIAC protocol represents a local attack factor from the application processor to the baseband a common scenario of how it can be useful is unlocking mobile phones which are locked to a particular mobile carrier if we find a memory corruption vulnerability in DIAC protocol it may be possible to execute a code directly on the baseband and change some internal settings this is usually accomplished historically through the 80 command handlers but internal proprietary protocols are also very convenient for that the second scenario how the DIAC offensive can be useful is using it for ejecting a software-based debugger if you can find a bug in DIAC that enables read write capability on the baseband you can inject some debugging hooks and eventually connect it to a gdb stop so it enables to create a software-based debugger even when gtech is not available what has changed in DIAC in 10 years based on some cursory investigation that i did first of all the original publication mentioned Qualcomm baseband based on ARM and with rex operating system all modern Qualcomm basebands are based on hexagon as a post-arm and the rex operating system was replaced with curt which i think it still has some bits of rex but in general it's a different operating system majority of super powerful commands of DIAC such as download or mode and memory read write were removed at least on my device and also it does not expose any immediately available interfaces such as usb channel i hear that it's possible to enable the usb DIAC channel by Edinson's special boot properties but usually it's not it wouldn't be available it shouldn't be expected to be available on all devices so these observations were based on my test device Nexus XP and this this should be around a medium level of hardening more modern devices such as google pixels the modern ones should be expected to be even more harder than that especially on the google side because they take hardening very seriously as i post to it on the other side of the spectrum if you think about some no-name modem sticks these things can be more open and more easy to investigate the DIAC implementation architecture is relatively simple this diagram is based roughly on the same diagram that i presented in the beginning of the talk on the left side there is the android kernel and on the right side there is the baseband operating system DIAC protocol actually it works in both sides it's not only commands that can be sent by the application processor to the baseband but it's also the messages that can be sent by the baseband to the application processor so DIAC commands are not really commands they're more like tokens that also can be used to encode messages the green arrows on this slide represents an example of a code flow of a data flow originating from the baseband and going to the application processor so obviously in case of commands there would be a reverse code flow data flow an entity inside the operating system baseband operating system responsible for DIAC is the DIAC task it has a separate task which handles specifically various operations related to the DIAC protocol the the exchange of data between the DIAC task and other tasks are done through the ring buffer so for example if if some tasks if some task needs to log log something through the DIAC it will use specialized login APIs that will in turn put login data into the ring buffer the ring buffer will be drained either on timer or on a software based interrupt from from the caller and at this point the data will be wrapped into DIAC protocol and from there it will go to CEO task the serial isle which is responsible to sending the output to a specific interface this is based on the on the baseband configuration the main interface that i was dealing with is the shared memory which ends up in the DIAC share driver inside the android kernel so in case of sending the commands from the android kernel to the baseband it will be the reverse flow there first you will need to send some to craft the DIAC protocol data send it through the DIAC share driver that will write to the shared memory interface from there it will go to the specialized specialized task in the baseband and eventually end up in the DIAC task and potentially in other responsible tasks on the android side DIAC is represented with the DIAC device which is implemented with the DIAC share and DIAC forward kernel drivers in the msm kernel the purpose of the DIAC share driver is to support the DIAC interface it is quite it's quite complex in code but functionally it's quite simple it contains some basic minimum of DIAC commands that enable configuration of the interface on the baseband side and then it would be able to multiplex the DIAC channel to either usb or memory device it also contains some ioctls for configuration that can be accessed from the android user land and finally DIAC share filters various DIAC commands that it considers unnecessary this is a bit important because when you will start when you will try to do some tests and send some arbitrary DIAC commands through the DIAC interface you would be required to rebuild the DIAC share driver to remove to remove this masking otherwise your commands will not make it to the baseband side at the core the DIAC share driver is based on the SMD share memory device interface which is a core interface specific to Qualcomm modem so this is where DIAC is the DIAC share is on the diagram the DIAC share driver itself is located in the application os vendor specific drivers and then there is the some shared memory implementation in the baseband that handles this and the DIAC implementation itself the DIAC share driver is quite complex in code but the functionality is quite simple it does implement a handful of ioctls that enable some configuration i i didn't check what exactly these ioctls are responsible for it exposes the devdiac device which is available for it in writing however by default you are not able to access the DIAC channel based on for this device because in order to access it there is a DIAC switch login function which switches the channel to that is used for dial communications on this screen there are several modes listed but in practice only two of them are supported the usb mode and the memory device mode usb mode is the default so which is why if you just open the devdiac driver devdiac device and try to read something from it it won't work it's tied to usb and in order to reconfigure it to use the memory device you need to send a special ioctl code notice the procedure in a mass request validate which employs a quite strict filtering on the DIAC commands that you try to send through this interface so it filters out basically everything with the exception of some basic configuration requests at the core DIAC share driver uses the shared memory device to communicate with the baseband the smd implementation is quite complex it exposes smd read api which is used by the accher for reading the data from the shared memory so one of the apis shared memory also operates on the obstruction of channels which are accessed through the api named smd named open and edge so you can notice here that there are some DIAC specific channels that can be opened now let's take a look at the smd implementation this is a bit important because the shared memory device represents a part of the attack surface for escalation from the modem to the application processor this is a very important attack surface because if you just achieve code execution on the baseband it's mostly useless because it cannot access the main operating system and in order to make it useful you will need to chain them to create an exploit chain and add one more exploit based on a bug with the privilege escalation from the modem to the application processor so shared memory device is one of the attack surfaces for this the shared memory device is implemented as exposed my region exposed by the qualcom peripheral the specialized msm driver will map it and here is the name smd ramfis the base of the shared memory region the shared memory region is operates on the concepts of entries and channels so it's partitioned in distant parts that can be accessed through the procedure smm get entry one of these entries is smm channel analog tbl which contains the list of available channels that can be opened from there we can actually open the channels and and use the shared memory interface during this initial research project it wasn't my goal to to research the entire qualcom ecosystem so while i was preparing for this talk i have noticed some more interesting things in the source codes such as for example the specialized driver that handles g-tag my region which is presumably exposed by some qualcom system on chips in the drivers this is mostly used read only and i suppose that it will not really work for writing but it's worth checking probably and now finally let's look at the diac protocol itself one of the first things that i noticed when researching the diac protocol is that it's actually used in a few places not only in libqcdm popular tool named snobsnitch can enable protocol dumps sell our protocol dumps on routed devices and in order to accomplish this snobsnitch sends a pack blob of diac commands to the mobile device through the diac interface this blob is not documented so it got me curious what exactly these commands are doing but before we can look at the dump let's understand protocol the diac protocol consists of around 200s of commands or tokens some of them are documented in the open source but not all of them so you can notice on the screenshots some of the commands are missing and one of the missing commands is actually the token 92 in hexadecimal which represents a encoded hash log message the command format is quite simple the base primitive here is the diac token number 7e it's not really a delimiter it's a separate diac command 126 it's missing in the open source as you can see here so the diac command is nested the outer layer consists of the this wrapper of 7e hexadecimal bytes then there is the main command and then there is the some variable land data that can contain even more subcommands this entire thing is verified using the crc and some bytes are escaped specifically as you can see on the snippet one interesting thing about the diac protocol is that it supports subsystem extensions basically different subsystems in the basement can register their own diac system handlers arbitrary ones and there is a special diac command number 75 which simply forwards instructs the diac system to forward this command to the respective subsystem and then it will be parsed there there exists quite a large number of subsystems not all of them are documented and when i started investigating this i noticed that there actually exists a diac subsystem subsystem and debugging subsystem the latter one immediately interested me because i was hoping that it would enable some more advanced introspection through this debugging subsystem but it turned out that the debugging subsystem is quite simple it only supported one command inject crash so you can send a special diac command that will inject the crash into the basement i will talk later about this now let's take a look at specific examples of the diac protocol this is the annotated snippet of the block of commands from snoopsnitch this block actually consists of three large logical parts the first part is largely irrelevant it's a bunch of commands that request various informations from the baseband such as timestamp version and for boot id and so on the second batch of commands starts with a command number 73 hexadecimal this is a diac command log config this is the command which enables protocol dumps and configures them and third part of this blob starts with the command number 7d hexadecimal this is diac command xmessage config this is actually the command that is supposed to enable textal message logging except that in the case of the snoopsnitch it disables all logging altogether so how do actually uh solar protocol dumps work in order to enable the solar protocol dumps we need a diac command log config number 73 hexadecimal it is partially documented in the libqcdm the structure of the packet would contain the code and the sub command that would be setmask in this case it also needs an equipment id which corresponds to the specific protocol that we want to dump and finally the masks that are applied to filter some parts of the dump this is relatively straightforward and now the second command diac command xmessage config this is the one which is supposed to enable textal message logs this the command format is undocumented so let's take a closer look at it the the command consists of a sub command in this case it's sub command number for the setmask and then there are two 16-bit integers ssid start and end ssid is a subsystem id which is not the same as the diac systems and the last one is the mask so subsystem id's are used to filter the messages based on a specific subsystem because there is a huge amount of subsystems in the basement and if all of them start logging this is a huge amount of data so diac provides this capability to filter a little bit to a specific subsystems that you're interested in the snippet of python code here is an example how to enable textal message logging for all subsystems you need to set the masks to all ones and this is quite a lot of logging in my experience now for parsing the incoming log messages there are two types of diac tokens both of them are undocumented the first one is a legacy message number 79 hexadecimal this is a simple ascii-based message that arrives through the diac interface so you can parse it quite straightforwardly the second one is i-coded diac command log hash is number 92 hexadecimal this is the token which encodes the log messages that contain only the hashes this is the one that if you have the message hash message hash.txt file you can correspond the hash that was arrived through this command to the messages provided in the text file and you can get the textal logs on the lower part of the slide there are two examples of hexams for both commands both of them have a similar structure first there are four bytes that are essential the first one is the command itself and the third byte is quite interesting is the number of arguments included next there is a 64-bit value of timestamp next there is the SSID value 16-bit some line number and i'm not sure what is the next argument and finally after that there is either a ascii-encoded log string in plain text or a hash of the log string and optionally there may be included some arguments so in case of the first legacy command the arguments are included before the log message and in case of the second command they are included after the md5 hash of the log message at least in my version of this implementation this is a direct packet that enables you to inject a crash into the baseband at least in theory because in my case it did not work and by not working i mean that it did simply nothing to the baseband normally i would expect that on production device it should just reset the baseband you will not get a crash dump or anything like that it's just just a reset so i suppose that it still should be working on some other devices so it's worth checking there are a few types of crashes that you can request in this way in order to accomplish this i needed a very simple tool with basically two functions first direct is the access to the diac interface ideally through some sort of python shell and second is the ability to read and parse data with advanced log strings for that purpose i wrote a simple framework that i named diag talk which is based directly on the dev diag interface in the android kernel and with a python harness so on the left side here is an example of some advanced parsing with some liquid values and on the right side here is the example of the advanced message log which includes the log strings that were extracted that were stripped out from the firmware the log is quite fun as i expected to be it has a lot of that detailed data such as for example gps coordinates and various attempts of the baseband to connect to different channels and i think is quite useful for offensive research purposes it's even contains sometimes raw pointers as you can notice on the screenshot so in this project my conclusion was that indeed i was reassured that it was the right choice and hexagon seems to be quite a challenging target and it would probably need several more months of work to even begin to do some serious offensive work i also started to think about writing a software debugger because it seems to be the most probably the most reliable way to achieve debugging introspection and also i noticed some blank spaces in the field that may require future work for Qualcomm hexagon specifically there is a lot of things that can be done for example you can take a look at other Qualcomm proprietary diagnostic protocols on which there are few such as QMI for example i think they are lesser known than die protocol then there is a requirement to create a full system emulation based on camo at least for some chips and a big problem about the decompiler which is a major obstacle to any serious static analysis in the code for the offensive research there are three large directions first one is enabling debugging there are different ways for that for example software based debugging or bypassing the j tag fusing on the other hand next there are explorations of the of the air attack vectors and the third one is escalation from the baseband to the application processor these are the three large offensive research vectors and for the basements in general there also exist some interesting directions of future work first of all the osmo combi b it definitely deserves some update a little bit it is the only one open source implementation on the baseband and it is so outdated and there is and it is based on some really obscure hardware another problem here is that it doesn't there it doesn't exist any software based cdma implementation please thank you very much for this nice talk there are some questions from the audience so basically the first one is a little bit of icebreaker do you use a mobile phone and do you trust it no i don't really use a mobile phone only for twitter does anyone still use mobile phones nowadays well yeah okay another question concerns the other qualcomm chips um do you did you have a look at the qualcomm wifi chipset as i mentioned during the talk i had only one month it was like a short reconnaissance project so i didn't really have time to investigate everything i didn't notice that the qualcomm socks have um wifi chip which is also based on hexagon and more than that it also shares some all the same low-level technical primitives so it's definitely worth looking but i didn't investigate it in details okay okay thanks well then there is also a pretty technical question here so instead of having to go through the rigorous command checking for the dyke car driver wouldn't it be possible to end map def mem into user space process and send over commands directly so it depends a little bit on what the goal is okay so it really depends on your previous background and your goals the point here is that by default the dyke sure ecosystem does not allow to send arbitrary dyke commands so either way you will have to hack something one way to hack this is to rebuild the dyke car driver so you would be able to send the commands directly through the dyke interface another way would be to access the shared memory directly for example but i think it would be more complex because the qualcomm shared memory implementation is quite complex so i think that the easiest way would be actually to hack the dyke car driver and use the dyke interface for this okay yeah thanks thanks um well is this there's one question which is a little bit tricky to read out maybe you can make sense of it is this typically good security for mobile phones so this level of hardening that i presented i think is around medium level so usually production falls are even more hardened if you take a look at things like google pixel five or the latest idols they would be even better hardened than the one that i discussed okay yeah thanks thanks then so it doesn't look like we have any more questions left anyway so if you want to get in contact with aliza no problem there is the feedback of tap below your video now at the moment just drop your questions over there and that's a way to get in touch with aliza for that i would say we are done for today for this session thank you very very much aliza for this really nice presentation once again i've lost and i'll transfer now over to the herald news show