Advanced Hexagon Diag
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Subtitle |
| |
Alternative Title |
| |
Title of Series | ||
Number of Parts | 275 | |
Author | ||
License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
Identifiers | 10.5446/52105 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
| |
Keywords |
00:00
Chi-squared distributionHexagonIndependence (probability theory)Row (database)Series (mathematics)Information securityVulnerability (computing)ModemCellular automatonPresentation of a groupSystem callRemote procedure callComputer animationMeeting/InterviewJSONXMLUML
00:56
CodePhysical systemCommunications protocolData managementModemHexagonEndliche ModelltheorieReverse engineeringDevice driverPresentation of a groupMathematical analysisData centerGoogle Street ViewLink (knot theory)Standard deviationService (economics)Bus (computing)Remote procedure callInternetworkingSoftware testingPhysical systemComplex systemWeb browserProjective planeMultiplication signKey (cryptography)Social classWindowSoftwareVulnerability (computing)Programmer (hardware)Staff (military)View (database)SpacetimeAreaImplementationCode division multiple accessBitFocus (optics)Data managementMereologyModemPresentation of a groupMaterialization (paranormal)FrequencyCodeAuditory maskingCommunications protocolCellular automatonPoint (geometry)GSM-Software-Management AGElectric generatorBranch (computer science)Software developerLevel (video gaming)Mobile WebCodeFlow separationAlgorithmFirmwareParsingComplete metric spaceInformation securityNumberDifferent (Kate Ryan album)Latent heatData structureHexagonType theoryExtension (kinesiology)Internet service providerPerspective (visual)FamilyException handlingMehrplatzsystemSpektrum <Mathematik>Field (computer science)Arithmetic meanSpectrum (functional analysis)Group actionOffice suiteMehrfachzugriffPeer-to-peerConstructor (object-oriented programming)Interface (computing)Product (business)Event horizonParticle systemSimilarity (geometry)Radical (chemistry)AnalogyObservational studyState of matterContent (media)EvoluteQueue (abstract data type)TouchscreenWaveExpert systemDivisorDecision theoryServer (computing)Condition numberInheritance (object-oriented programming)Commitment schemeMeeting/Interview
09:58
PeripheralDevice driverHypermediaStack (abstract data type)Data managementLink (knot theory)Read-only memoryCore dumpInterface (computing)Endliche ModelltheorieCoefficient of determinationExtension (kinesiology)NetzwerkschichtOSI modelOSI modelCodecCharge carrierMobile WebInjektivitätDebuggerKeilförmige AnordnungElectronic data processingSmartphoneParticle systemDiagramCartesian coordinate systemRight angleOperating systemSemiconductor memoryCellular automatonInformationFlow separationInformation securityTrailPhysical systemService (economics)Communications protocolRepresentation (politics)ImplementationSubsetProcess (computing)Observational studyOffice suite2 (number)Insertion lossCoprocessorCodeInterface (computing)MomentumPoint (geometry)CASE <Informatik>InternetworkingSystem callCondition numberData managementTask (computing)Stack (abstract data type)CuboidVulnerability (computing)Ocean currentBitQuicksortMereologyReal-time operating systemLatent heatLine (geometry)WebsiteProduct (business)Transport Layer SecurityConnected spaceIntegrated development environmentSurfaceThomas BayesBoss CorporationPersonal digital assistantCore dumpLevel (video gaming)PeripheralDevice driverComputer hardware1 (number)Time zoneModemView (database)outputPresentation of a groupAndroid (robot)Direction (geometry)ParsingBefehlsprozessorKernel (computing)Configuration spaceComputer animation
16:38
Communications protocolCartesian coordinate systemEndliche ModelltheorieSoftware developerConstraint (mathematics)ImplementationInheritance (object-oriented programming)Open sourceArithmetic meanWindowSoftware testingCircleSoftwareWritingLatent heatPhysical systemSurfaceComputer hardwareSoftware-defined radioQuicksortInstallation artNumberOrder (biology)PlanningGSM-Software-Management AGCellular automatonCode division multiple accessDiagram
18:41
Heat transfer coefficientHexagonBlock (periodic table)User interfaceDiagramStress (mechanics)Endliche ModelltheorieUsabilityMultiplication signGroup actionPower (physics)Level (video gaming)Flow separationStaff (military)Electronic mailing listCoprocessorAndroid (robot)Operating systemSubsetReal-time operating systemQuicksortVisualization (computer graphics)Artificial neural networkOffice suiteProcess (computing)HypermediaPerspective (visual)HexagonLatent heatModemPoint (geometry)Computer hardwareFunctional (mathematics)Core dumpBefehlsprozessorMaterialization (paranormal)PseudozufallszahlenComputer animation
20:58
HexagonThread (computing)Computer hardwareMultiplicationDigital signal processorShared memoryRegular graphPerspective (visual)Pairwise comparisonFlow separationPoint (geometry)Thread (computing)Execution unitComputer hardwareHexagonWebsiteLevel (video gaming)Programmer (hardware)Poisson-KlammerSlide ruleCycle (graph theory)Order (biology)Process (computing)Mathematical optimizationBitLatent heatInformationSingle-precision floating-point formatDistanceXMLUMLProgram flowchart
22:47
Digital signal processingHexagonDigital signal processorVideoconferencingHardy spaceCodecProcess (computing)Artificial neural networkControl flowInternet forumComputer hardwarePoint cloudCompact spaceMobile WebRational numberBefehlsprozessorSoftwareGraphics processing unitCore dumpProduct (business)Kernel (computing)Length of stayTuring testSystem callEvent horizonAsynchronous Transfer ModeComputer fileData storage deviceSoftwareMobile WebCASE <Informatik>AdditionComputer hardwarePoint (geometry)Product (business)Functional (mathematics)ImplementationKernel (computing)outputComputer animationSource codeXML
24:04
Kernel (computing)Time zoneMedical imagingBootingKernel (computing)PeripheralAdditionFirmwareConnectivity (graph theory)CodeProduct (business)CASE <Informatik>Android (robot)Vulnerability (computing)Source codeOpen sourceWater vaporMusical ensembleCellular automatonFlow separationMUDAuthentication
25:15
Sheaf (mathematics)Term (mathematics)CASE <Informatik>Event horizonFunctional (mathematics)Computer fileBinary codeTrailVulnerability (computing)Level (video gaming)BitMultiplication signLink (knot theory)Point (geometry)Generic programmingLatent heatSource codeGoogolPhysical systemTask (computing)Offenes KommunikationssystemHash functionData structureProjective planeProcess (computing)WebsiteData compressionConnectivity (graph theory)Flow separationPlug-in (computing)DebuggerRootFirmwareReverse engineeringCurveReal-time operating systemLeakCodeString (computer science)Module (mathematics)Scripting languageModemSoftwareSource codeJSON
29:13
Single sign-onMiniDiscHash functionMenu (computing)String (computer science)Level (video gaming)Linker (computing)outputEvent horizonDebuggerKernel (computing)Regular graphSource codeAbstractionModemMereologyFirmwareMereologyMessage passingString (computer science)Hash functionFirmwareComputer fileVector spaceFlash memoryProcedural programmingSinc functionSource codeCollatz conjectureSlide ruleBitFunctional (mathematics)Time zoneDifferent (Kate Ryan album)Revision controlSoftwareSoftware bugAdditionProduct (business)Kernel (computing)Information securityPhysical systemPosition operatorRandomizationNetwork topologyBeat (acoustics)Personal digital assistant1 (number)Projective planeCuboidCASE <Informatik>Similarity (geometry)Multiplication signVulnerability (computing)System callComputer animationTable
32:19
Functional (mathematics)Content (media)Power (physics)Latent heatParticle systemCASE <Informatik>Communications protocolPresentation of a groupExpected valueHexagonLocal ringBootingCartesian coordinate systemState observerCoprocessorDivisorSoftwareAsynchronous Transfer ModeConfiguration spaceSemiconductor memoryData managementInterface (computing)ModemSoftware testingOperating systemDebuggerChaos (cosmogony)Software bugLevel (video gaming)Finite differencePhysical systemBitInheritance (object-oriented programming)TelecommunicationProduct (business)Charge carrierVulnerability (computing)CodeSet (mathematics)Office suitePerspective (visual)Theory of everythingNP-hardCategory of beingCuboidGoogolMathematicsWebsiteImplementationProcess (computing)PixelInformationDirection (geometry)Software developerMoment (mathematics)Open sourceSystem callProjective planeLogical constantSource codeJSON
37:22
ModemReal-time operating systemTask (computing)Kernel (computing)System callDevice driverMessage passingParsingSerial portCartesian coordinate systemCoprocessorLoginReverse engineeringRing (mathematics)System callCommunications protocolOperator (mathematics)Message passingBuffer solutionTask (computing)DiagramDevice driverKernel (computing)Semiconductor memoryInterface (computing)Configuration spaceArrow of timeSlide ruleInterrupt <Informatik>Point (geometry)Token ringFunction (mathematics)Dependent and independent variablesShared memoryCASE <Informatik>ImplementationDataflowDatabasePhysical systemDirection (geometry)Software testingMereologyWebsiteNumberMultiplication signDemosceneGraph coloringThermal conductivityComputer virusSoftwareComputer animation
40:33
Kernel (computing)Interface (computing)Read-only memoryLatent heatImplementationDirection (geometry)Android (robot)Interface (computing)Kernel (computing)Configuration spaceDevice driverShared memoryMaxima and minimaFilter <Stochastik>Semiconductor memoryCore dumpLatent heatModemElectronic program guideUsabilityMultiplication signSoftware testingComputer animationSource codeJSON
42:14
PeripheralCore dumpInterface (computing)Coefficient of determinationData managementStack (abstract data type)Point (geometry)SicCommunications protocolRead-only memorySemiconductor memoryVector potentialSpacetimeNatural numberDirection (geometry)ImplementationCartesian coordinate systemLatent heatShared memoryDevice driverDiagramSurfaceDependent and independent variablesConfiguration spaceReading (process)TelecommunicationExpert systemPlanningMoment (mathematics)Auditory maskingOrder (biology)Exception handlingValidity (statistics)Core dumpPhysical systemDefault (computer science)Multiplication signRevision controlProcedural programming2 (number)Process (computing)MereologyAbstractionLoginCodeWritingModemOperating systemFunctional (mathematics)Asynchronous Transfer ModeInterface (computing)Computer animationSource codeJSON
45:50
Read-only memoryDevice driverReverse engineeringComa BerenicesElectronic mailing listRootShared memoryOrder (biology)Procedural programmingModemCartesian coordinate systemCoprocessorSemiconductor memoryPeripheralResource allocationSource codeCore dumpInterface (computing)Communications protocolMereologySoftware bugOpen setEntire functionCellular automatonDevice driverPhysical systemPhysical lawIRIS-TPartition (number theory)Multiplication signFerry CorstenCategory of beingProjective planeProcess (computing)CASE <Informatik>Stokes' theoremService (economics)Source code
48:44
Duality (mathematics)POKEParameter (computer programming)ModemFile formatTask (computing)Communications protocolCyclic redundancy checkOpen sourceParticle systemTouchscreenCommunications protocolCodierung <Programmierung>Hash functionToken ringMessage passingNumberFlow separationFile formatSource codeXMLJSON
49:43
Network switching subsystemDuality (mathematics)Cyclic redundancy checkModemReverse engineeringParameter (computer programming)File formatCommunications protocolTask (computing)Grand Unified TheoryInformationVariable (mathematics)LengthWrapper (data mining)Entire functionActive contour modelNumberPhysical systemExtension (kinesiology)Different (Kate Ryan album)1 (number)Communications protocolSource codeXMLJSON
50:54
Haar measureSpecial unitary groupCodeSystem callCrash (computing)Lattice (order)Communications protocolMessage passingRAIDString (computer science)ASCIIHash functionComputer data loggingCrash (computing)Physical systemSystem callData structureMessage passingProduct (business)NumberParameter (computer programming)CASE <Informatik>Wave packetComputer configurationMultiplication signRevision controlLatent heatCore dumpAuditory maskingField (computer science)MereologyPhysical lawThomas BayesString (computer science)Speech synthesisOrder (biology)Decision theoryWebsiteType theoryInformationMoment (mathematics)Arithmetic meanBlock (periodic table)Particle systemIdeal (ethics)Software frameworkInterface (computing)TimestampGoodness of fitSlide ruleState of matterFunctional (mathematics)Content (media)Direction (geometry)Hash functionToken ringComputer data logging2 (number)StapeldateiBuildingHexagonConfiguration spaceCommunications protocolSet (mathematics)CodeLine (geometry)File formatQuicksortImplementationBitSource codeXMLComputer animationJSON
58:23
Android (robot)Interface (computing)Software frameworkString (computer science)Message passingSampling (statistics)Pointer (computer programming)ParsingFirmwareComputer animationSource code
59:39
Physical systemDirection (geometry)Right angleGroup actionPhysicalismAxiom of choiceBasis <Mathematik>Office suiteReal numberOpen sourceInformation securityImplementationHexagonParticle systemEmulatorMoment (mathematics)Order (biology)Projective planeSoftwareBus (computing)Mathematical analysisSpacetimeCodeCartesian coordinate systemCoprocessorComputer hardwareField (computer science)Different (Kate Ryan album)BitVector spaceDebuggerCommunications protocolCode division multiple accessSource codeJSON
01:02:43
Operator (mathematics)TwitterMultiplication signHexagonProjective planePrimitive (album)Level (video gaming)Meeting/InterviewComputer animation
01:03:40
Arithmetic progressionConfidence intervalNumberPoint (geometry)Adventure gameMetropolitan area networkSemiconductor memoryGroup actionProduct (business)GoogolRule of inferencePhysical systemGoodness of fitInterface (computing)Shared memoryLevel (video gaming)ImplementationBitDevice driverPrinciple of maximum entropyPixelInformation securityDefault (computer science)1 (number)SpacetimePlastikkarteProcess (computing)Source code
01:05:34
Finite element methodFeedbackMoment (mathematics)Touch typingVideoconferencingHeat transferCoalitionMeeting/InterviewComputer animation
01:06:44
Computer animation
Transcript: English(auto-generated)
00:12
Our next speaker, Aliza Esage, is an independent vulnerability researcher and has a notable record of security research achievements such as the CR Day Initiative Silver Bounty
00:24
Hunter Award 2018. Aliza is going to present her latest research on the Qualcomm DX protocol, which is found abundantly in Qualcomm hexagon-based cellular modems. Aliza, we're looking forward to your talk now.
00:46
This is Aliza Esage. You're attending my presentation, Advanced Hexagon Diag at KAOS Communication Congress 2020 Remote Experience.
01:00
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 hyper-resource.
01:20
The project that I'm presenting today was a little side project that I made for destruction a couple of years ago. The name of this talk, Advanced Hexagon Diag, 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
01:46
of the talk will actually be devoted to general vulnerability research in basebands. But the primary focus of this talk is on the Hexagon Diag, also known as QCDM, Qualcomm Diagnostic Manager.
02:02
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 silicon with a custom instruction set architecture
02:24
named QDSP6 Hexagon. This is important because all the diag handlers that we will be dealing with are written in this instruction set architecture.
02:41
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 staff.
03:03
And the last part is more deep technical, and it would be mostly interesting to specialized vulnerability researchers and low-level programmers that somehow are related to this particular area.
03:23
Let's start from the top-level overview of cellular technology. This mindmap 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
03:44
that exist in this space. Also, this mindmap 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.
04:03
From the user perspective, this is simple. This is usually the short name, 3G, 4G, that you see on the mobile screen. But in reality, this simple name, that generation name encodes, may encode several different
04:22
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 generation. This is simple. This is simply 1G, 2G, and so on, the generic name of a family of protocols that are supported
04:47
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.
05:02
The second most important thing about cellular protocols is the air interface. This is the lowest-level protocol which defines how exactly the cellular signal is digitized and read from the electromagnetic wave, and how exactly the different players in this
05:25
field divide the space. Historically, there existed two main implementations of this low-level protocol, TDMA and CDMA. TDMA means Time Division Multiple Access, which basically divides the entire electromagnetic
05:41
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.
06:01
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 Code Division Multiple Access. And instead of dividing this picture by time slots and dividing the protocol in bursts,
06:26
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
06:46
equipments can talk on the same frequency without interrupting each other. Notable here is that CDMA was developed by Qualcomm, and it was mostly used in the United States.
07:00
So at the level of 2G, there were two main protocols, GSM based on the TDMA and CDMA-1 based on the CDMA. The third generation of mobile protocols, these two branches of development were continued. So GSM evolved into UMTS, while CDMA-1 evolved into CDMA-2000.
07:23
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.
07:43
And the same for the 5G. This is a bit important for us from the offensive perspective, because first of all, all of these technologies, including the air interfaces, represent separate bits of code
08:03
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 not obvious thing from the offensive security perspective here
08:23
is that because of this evolutionary development, the protocols are not actually completely distinct. So if you think about LTE, it is not a completely different protocol from GSM, but instead it is based largely on the same internal structures.
08:43
And in fact, if you look at the specifications, some of them are almost directly relevant, the specifications of the GSM2G, 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.
09:06
The cellular protocols are structured in a nested way, in layers. Layers is the official terminology adopted by the specifications,
09:22
with the exception of level 0. Here, I just added it for convenience. But in the specifications, layers start from 1 and proceed to 3. From the offensive perspective, the most interesting is level 3, 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.
09:44
This is the part of the protocol which actually contains interesting data structures with TLB values and so on. When people talk about attacking basements, they usually mean attacking basements over the air, the OTA attack factor,
10:04
which is definitely one of the most interesting. But let's take a step back and consider the entire big picture of the basement ecosystem. This diagram presents a unified view of a generalized architecture of a modern basement with attack surfaces.
10:28
First of all, there are two separate distant processors, the AP application processor and the MP, which is a mobile processor. It may be either a DSP or another CPU.
10:40
Usually, there are two separate processors, and each one of them runs a separate operating system. In case of the AP, it may be Android or iOS. And the basement processor would run some sort of a real-time operating system provided by the mobile vendor. Important point here that on modern implementations,
11:03
basements are actually protected by some sort of secure execution environment, maybe trust on androids or SAPOS on Apple devices, which means that the privilege boundary, which is depicted here on the left side, is dual-sided.
11:21
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 basement or somehow intersect with the separation, at least on the modern production smartphones. And the same goes around to the basement, which is not supposed to be able to access to application processor directly.
11:44
So these two are mutually distrusting entities that are separated from each other. And so there exists privilege boundary, which represents attack surface.
12:01
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 usually runs in several distant real-time operating system tasks.
12:31
This part of the attack surface handles all the layers of the protocol. There is a huge amount of parsing that happens here.
12:41
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 commons to the cellular modem.
13:04
A bit more interesting is the vendor-specific management protocols. One of them is the diag protocol. Because the modern basements are very complex, so vendors need some sort of specialized protocol
13:21
to enable configuration and diagnostics for the OMs. In case of Qualcomm, for example, diag 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,
13:43
such as the code which implements the interface to the application processor. On the side of the application operating system,
14:00
such as Android, there are also two attack surfaces that are attackable from the baseband. The first one is the peripheral drivers, because baseband is a separate hardware peripheral, so it requires some specialized drivers that handle IO and such things. And the second one is the attack surface
14:22
represented with various interface handlers. Because the baseband 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 these shared memory implementations are usually quite complex,
14:44
and they represent an attack surface on both sides. And finally, the third piece of this diagram is in the lowest part. I have depicted two grey boxes, which are related to the trust execution environment.
15:00
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 baseband offensive research. Here we can distinguish at least two large attack surfaces.
15:22
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,
15:41
the separate pieces of code which are executed and protected by the trust zone. On this diagram I have also added some information about data codecs. I'm not sure if they are supposed to be in the RTOS core,
16:03
because these things are directly accessible from the cellular stacks usually, especially ASN1, which I have seen some bugs reachable from the over-the-air interface. On this diagram I have shown some example of vulnerabilities.
16:22
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 view, you can find the write-ups on the internet. To discuss baseband offensive tools and approaches,
16:46
I have narrowed down the previous diagram to just one attack surface, the over-the-air attack surface. This is the attack surface which is represented by parsing implementations of various cellular protocols inside the baseband operating system.
17:01
And this is the attack surface that we can reach from the air interface. In order to accomplish that, we need a transceiver such as software-defined radio or a mobile tester, which is able to talk the specific cellular protocol
17:21
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 SRP or BladeRF, and install open source implementation of a base station such as OpenBTS or OpenBSC.
17:41
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.
18:00
And, in fact, when I tried to establish BTS with my USRP, it was quite simple. For UMTS and LT, there exists less number of software-based implementations, and also there are more constraints on the hardware.
18:20
For example, my model of the USRP does not support UMTS due to resource constraints. And the most interesting thing here is that there does not exist any software-based implementation on the CDMA that you can use to establish your base station.
18:46
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 pseudo-randomly when I was searching for some sort of visual diagram.
19:04
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.
19:25
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.
19:44
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.
20:08
Then there are the Adreno GPUs, and then there are several Hexagons. On the most recent models, there is not just one Hexagon processing unit, but several of them, and they are called respectively to their purposes.
20:24
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.
20:48
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.
21:14
First of all, Hexagon is specialized to parallel processing, and so the first concept
21:23
is variable-sized instruction packets. It means that the several instructions can execute simultaneously in separate execution units.
21:41
It also uses hardware multi-threading 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
22:07
instructions must be compatible in order to be able to use the distinct processing slots. And then there is the funny.new notation, which actually enables the instructions to
22:22
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 Hexagons specification on the
22:42
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
23:04
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
23:24
either software or hardware or both. It is quite common that these functionalities are only removed from software, while the hardware remains here, and in such case, we will eventually the researchers will come
23:42
up with their own software-based implementation of this functionality, as in case of 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.
24:06
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.
24:24
It uses a separate component. The basement uses a separate component named the MVA, which stands for the Modern Basic Authenticator, and this entire thing is run by the subsystem of Android kernel named PIL, the Peripheral Image Loader.
24:42
You can open the source code and investigate how exactly it looks. And the purpose of the MVA is to authenticate the modern firmware so that you would not be able to inject some arbitrary commands into the modern firmware.
25:01
This is another side of the hardening, 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.
25:21
During this project, I have reverse-engineered partially the hexagon-madome firmware from my Nexus 6P. The process of reverse-engineering is not very difficult. First of all, you need to download the firmware from the website, from Google's website in
25:43
this case. Then you need to find the binary which corresponds to the modern firmware. This binary is actually a compound binary that must be divided into separate binaries that represent specific sections inside the firmware.
26:04
And for that purpose, we can use the UniFi Trustlet script. After you have split the basement firmware into separate sections, you can load them into IDA Pro. There are several plugins available for IDA Pro that support hexagon.
26:21
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
26:40
at runtime, so you would not be able to reverse-engineer them unless you can decompress them, which is also a bit of a challenge because Qualcomm uses some internal compression algorithm for that. For the reverse-engineering, the main approach here is to get started with some root points.
27:04
For example, because this is a real-time operating system, we know that it should have some 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
27:21
lock strings. Even though you may locate something that looks like a task struct, but it's not clear which code does it actually represent. The first step here is to apply the lock strings that were removed from the binary by QShrink.
27:43
I think the only way to do it is by using the MST underscore hash txt file from the leak sources. This file is not supposed to be available neither on the mobile devices nor in some open ecosystem.
28:01
After you have applied these lock strings, you will be able to rename some functions based on these lock strings. Because the lock strings often contain the names of the source module from which the code was built, so it creates opportunity to understand what exactly this code is doing.
28:31
Debugging was completely unavailable in my case, and I realized that it would require some couple of months more work to make it work.
28:41
And the only way, I think, and the best way is to create a software-based debugger similar to ModKit, the publication that I will be referencing in the references, based on software vulnerability in either the modem itself or in some authenticator
29:05
or in the trust zone, so that we can inject 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 the lock string stripped out.
29:25
Here it 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 from the message hash file.
29:42
And here is what you can get after you have applied the textual messages. Rename some functions. In this case, you would be able to find some hundreds of procedures that are directly related to the diag subsystem. In a similar way, you can locate various subsystems related to over-the-air vectors
30:05
as well, but unfortunately, majority of the OTA vectors are located in the segments that are not immediately available in the firmware.
30:20
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 a regular cross-build.
30:40
Another commonly well-known offensive approach is firmware downgrades. When you take some old firmware that contains a well-known security vulnerability, flash it, and use the bug to create an exploit to achieve some additional functionality or
31:03
introspection into the system. This part definitely works. Downgrades are trivial, both on the entire firmware and the modem, as well as the trial zone. I did try to build the Qualcomm firmware from the leaked source codes.
31:20
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 leaked firmware is not directly relevant to finding new bugs in the production firmware, so I just set it aside for some
31:46
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.
32:09
This is when I remembered about the Qualcomm Diag. During the initial recognitions, I stumbled on some white papers and slides that mentioned
32:21
the Qualcomm diagnostic protocol. And it seemed like quite a powerful protocol, specifically with respect to reconfiguring the baseband. So I decided first of all to test it, in case that it would actually provide some advanced introspection functionality, and then probably to use the protocol for enabling locked
32:42
amps. Qualcomm Diag, or QCDM, is a proprietary protocol developed by Qualcomm, with the purposes of advanced baseband software configuration and diagnostics. It is mostly aimed for OEM developers, not for users.
33:04
The Qualcomm Diag protocol consists of around 200 commands, at least in theory, that some of them are quite powerful on paper, such as downloader mode and read-write memory. Initially, the Diag was partially reverse engineered around 2010, and included in the
33:29
open-source project, named Modem Manager. And then it was also exposed in a presentation at the Chaos Communication Progress, or Chaos Communication Congress, 2011, by Guillaume Delacrèle.
33:46
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
34:00
phones, but it does provide a high-level overview and general expectation of what you will have to deal with. From the offensive perspective, the Diag protocol represents a local attack factor from the application processor to the baseband.
34:20
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 Diag protocol, it may be possible to execute a code directly on the baseband and change some eternal settings.
34:42
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 Diag offensive can be useful is using it for injecting a
35:01
software-based debugger. If you can find a bug in Diag that enables read-write capability on the baseband, you can inject some debugging hooks and eventually connect it to a GDB stub. So, it enables to create a software-based debugger even when GTAC is not available.
35:30
What has changed in Diag 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
35:42
the Rex operating system. All modern Qualcomm basebands are based on Hexagon as opposed to 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.
36:04
Majority of super powerful commands of Diag such as download, remote, 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.
36:22
I hear that it's possible to enable the USB Diag channel by adding some special boot properties, but usually it's not, it wouldn't be available, it shouldn't be expected to be available on all devices.
36:42
So, these observations were based on my test device, Nexus 6P, and 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 hardened than that, especially on the Google side, because they take hardening
37:04
very seriously. As opposed to it on the other side of the spectrum, if you think about some known no-name modem sticks, these things can be more open and more easy to investigate.
37:22
The Diag 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 basement operator system.
37:42
Diag protocol actually works on both sides. It's not only commands that can be sent by the application processor to the basement, but it's also the messages that can be sent by the basement to the application processor. So Diag commands are not really commands, they're more like tokens that also can be used to encode messages.
38:02
The green arrows on this slide represent an example of a call flow, of a data flow. Originating from the basement and going to the application processor. So obviously in case of commands, there would be a reverse call flow or data flow.
38:26
Entity inside the operating system, basement operating system, responsible for Diag is the Diag task. It has a separate task which handles specifically various operations related to the Diag protocol.
38:44
The exchange of data between the Diag task and other tasks are done through the ring buffer. So for example, if some task needs to log something through the Diag, it will use
39:03
specialized login APIs, and it will in turn put logging data into the ring buffer. The ring buffer will be drained either on timer or on a software-based interrupt from the caller, and at this point the data will be wrapped into Diag protocol, and from
39:26
there it will go to see your task, the serial aisle, which is responsible for sending the output to a specific interface. This is based on the basement configuration.
39:49
The main interface that I was dealing with is the shared memory, which ends up in the Diag share driver inside the android kernel.
40:04
So in case of sending the commands from the android kernel to the basement, it will be the reverse flow. First, you will need to craft the Diag protocol data, send it through the Diag share driver. It will write to the shared memory interface, from there it will go to the specialized
40:24
task in the basement, and eventually end up in the Diag task and potentially in other responsible tasks.
40:40
On the android side, Diag is represented with the DevDiag device, which is implemented with the Diag share and Diag forward kernel drivers in the MSM kernel. The purpose of the Diag share driver is to support the Diag interface. It is quite complex in code, but functionally it's quite simple.
41:06
It contains some basic minimum of Diag commands that enable configuration of the interface on the basement side, and then it would be able to multiplex the Diag channel to either USB or memory device.
41:21
It also contains some ICTLs for configuration that can be accessed from the android user land. And finally, Diag share filters various Diag commands that it considers unnecessary. This is a bit important, because when you will try to do some tests and send some
41:46
arbitrary Diag commands through the Diag interface, you would be required to rebuild the Diag share driver to remove this masking, otherwise your commands will not make it to the basement side.
42:02
At the core, the Diag share driver is based on the SMD, shared memory device interface, which is a core interface specific to Qualcomm modem. So this is where Diag is.
42:21
The Diag share is on the diagram. The Diag driver itself is located in the application OS, vendor specific drivers, and then there is some shared memory implementation in the basement that handles this, and the
42:43
Diag implementation itself. Diag share driver is quite complex in code, but the functionality is quite simple. It does implement a handful of ICTLs that enable some configuration.
43:06
I didn't check what exactly these ICTLs are responsible for. It exposes the DevDiag device, which is available for reading and writing. However, by default, you are not able to access the Diag channel based on this device,
43:24
because in order to access it, there is a Diag switch login function, which switches the channel that is used for Diag communications. On this screen, there are several modes listed, but in practice, only two of them are supported,
43:43
the USB mode and the memory device mode. USB mode is the default, which is why if you just open the DevDiag device and try to read something from it, it won't work. In order to reconfigure it to use the memory device, you need to send a special
44:09
ICTL code. Notice the procedure named mask request validate, which employs quite a strict filtering on
44:24
the Diag 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, DiagCha driver uses the shared memory device to communicate with the baseband.
44:47
The SMD implementation is quite complex. It exposes SMD read API, which is used by DiagCha. For reading the data from the shared memory, one of the APIs, shared memory also operates
45:04
on the abstraction of channels, which are accessed through the API named SMD named open edge. So you can notice here that there are some specific channels that can be opened.
45:23
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
45:46
system. And in order to make it useful, you will need to create an exploit chain and add one more exploit based on that bug with the privilege escalation from the modem to the application
46:02
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 Qualcomm peripheral.
46:22
The specialized MSM driver will map it and here it's the name SNM RAM feeds. The base of the shared memory region. The shared memory region operates on the concepts of entries and channels.
46:47
So it's partitioned in distant parts that can be accessed through the procedure SMM get entry. One of these entries is SMM channel alloc TBL, which contains the list of available channels
47:07
that can be opened. From there, we can actually open the channels and use the shared memory interface. During this initial research project, it wasn't my goal to research the entire Qualcomm
47:27
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 GTAG
47:43
my region, which is presumably exposed by some Qualcomm system chips. In the drivers, this is mostly used to read only. And I suppose that it will not really work for writing, but it's worth checking probably.
48:02
And now finally, let's look at the diacrotical itself. One of the first things that I noticed when researching the diacrotical is that it's used in a few places, not only in libqCDM. A popular tool named SnubSnitch can enable protocol dumps, cellular protocol dumps on
48:24
rooted devices. And in order to accomplish this, SnubSnitch sends a bug 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.
48:43
But before we can look at the dump, let's understand the protocol. The diac protocol consists of around 200 of commands or tokens. Some of them are documented in the open source, but not all of them.
49:02
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
49:20
encoded hash lock 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.
49:44
It's missing in the open source, as you can see here. So the diac command is nested. The outer layer consists of this wrapper of 7e hexadecimal bytes. Then there is the main command. And then there is some variable length data that can contain even more subcommands.
50:05
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.
50:24
Basically, different subsystems in the basement can register their own diac system handlers, arbitrary ones. And there exists a special diac command, number 75, which simply instructs the diac system to forward this command to the respective subsystem.
50:42
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
51:05
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.
51:23
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.
51:42
Now let's take a look at specific examples of the diac protocol. This is the annotated snippet of the blob of commands from SnubSnitch. This blob actually consists of three large logical parts.
52:00
The first part is largely irrelevant. It's a bunch of commands that request various information from the basement, such as timestamp, version info, build ID, and so on. The second batch of commands starts with a command number 73 hexadecimal. This is diac command log config.
52:21
This is the command which enables protocol dumps and configures them. And the third part of this blob starts with the command number 70 hexadecimal. This is diac command x message config. This is actually the command that is supposed to enable textile message logging,
52:43
except that in the case of SnubSnitch it disables all logging altogether. So how do actually cellular protocol dumps work? In order to enable the cellular protocol dumps, we need diac command log config number 73 hexadecimal.
53:02
It is partially documented in the libqcdm. The structure of the packet would contain the code. And the subcommand that would be set mask in this case. It also needs an equipment ID, which corresponds to the specific protocol that we want to dump.
53:23
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 x message config.
53:40
This is the one which is supposed to enable textile message logs. The command format is undocumented, so let's take a closer look at it. The command consists of subcommand.
54:01
In this case it's subcommand number 4, the set mask. Then there are two 16-bit integers, SSID start and end. SSID is a subsystem ID, which is not the same as diac subsystems. And the last one is the mask.
54:23
So subsystem IDs 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
54:41
to a specific subsystem that you're interested in. The snippet of python code here is an example how to enable textile message logging for all subsystems. You need to set the mask to all ones, and this is quite a lot of logging in my experience.
55:11
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.
55:25
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 called it diac command log hash, number 92 hexadecimal.
55:42
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 .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 text logs.
56:04
On the lower part of the slide, there are two examples of hex numbs 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.
56:25
It's the number of arguments included. Next, there is the 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.
56:43
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.
57:03
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.
57:24
This is a diag 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.
57:40
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 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.
58:07
In order to accomplish this, I needed a very simple tool with basically two functions. First, direct is the access to the diag interface, ideally through some sort of Python shell,
58:21
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 devdiag interface in the Android kernel,
58:43
and with a Python harness. So on the left side, here is an example of some advanced parsing with some leaked values, and on the right side here is the example of the advanced message log,
59:01
which includes the log strings that were extracted, that were stripped out from the firmware. The log is quite fun, as I expect it to be. It has a lot of detailed data, such as, for example, GPS coordinates and various attempts of the baseband to connect to different channels,
59:28
and I think it's quite useful for offensive research purposes. It even contains sometimes raw pointers, as you can notice in the screenshot.
59:42
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 something.
01:00:00
as offensive rock. 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 rock.
01:00:25
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
01:00:42
diaprotocol. And then there is a requirement to create full system emulation based on QEMU, at least for some chips. And a big problem about the de-compiler, which is a major obstacle to any serious static analysis in the code.
01:01:08
And 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 JTAG fusing on the
01:01:23
other hand. Next there are explorations of the over-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 exists some interesting
01:01:44
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 of baseband and it is so outdated and there is and it is based on some really obscure
01:02:05
hardware. Another problem here is that it doesn't there doesn't exist any software-based CDMA implementation. Elisa, thank you very much for this nice
01:02:31
talk. There are some questions from the audience. So basically the first one is a little bit of an icebreaker. Do you use a mobile phone and do you trust it?
01:02:45
No, I don't really use a mobile phone, only for Twitter. Does anyone still use mobile phones nowadays? Well, no idea. Okay, another question
01:03:01
concerns the other Qualcomm chips. Did you have a look at the Qualcomm Wi-Fi 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.
01:03:23
I did notice that Qualcomm socks have Wi-Fi chip which is also based on Hexagon and more than that it also shares some of the same low-level technical primitives. So it's definitely worth looking but I didn't investigate it in details. Okay, thanks. Well then there is also
01:03:44
a pretty technical question here. So instead of having to go through the rigorous command checking for the DIAC card 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
01:04:05
goal is. Okay, so it really depends on your previous background and your goals. The point here is that by default the DIACure ecosystem does not allow to send arbitrary DIAC commands. So
01:04:23
either way you will have to hack something. One way to hack this is to rebuild the DIACure driver so you will be able to send the commands directly through the DIAC 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.
01:04:45
So I think that the easiest way would be actually to hack the DIACure driver and use the dev diac interface for this. Okay, yeah, thanks. Thanks. Well, there's one question which is
01:05:02
a little quick to read out. Maybe you can make sense of it. This is 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
01:05:24
things like Google Pixel 5 or the latest ones they will be even better hardened than the one that I discussed. Okay, yeah, thanks. Thanks, Dan. So it doesn't look like we have any more questions left. Anyway, so if you want to get in contact
01:05:43
with Aliza, no problem. There is the feedback tab below your video now at the moment. Just drop your questions over there and that's a way to get in touch with Aliza. Other than that, I would say we are
01:06:01
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.