Qualcomm seeks server firmware engineer

The position requires systemic understanding of server firmware, software, and hardware, and the ability to solve issues across a broad range of technologies. Job duties include: Customer support, including: – Support design and bringup of server systems implementing Qualcomms Centriq server processors – Debug and resolution of customer hardware, firmware, and software issues – Analyze and replicate reported customer-reported problems in Qualcomm labs, for root cause analysis, working in conjunction with software, firmware, and chip design teams – Support customer BIOS / firmware bring-up and customization – Provide performance optimization support for system software – Support server platform validation, performance analysis, and power measurement tools – Delivery of customer training – Creation and support of customer-facing documentation – Create and edit documentation such as device specifications, data sheets, and user manuals – Write application notes and reference code – Creation of training materials.

Detailed knowledge of server processor architecture and system-level features including:
– CPU and system-level caches
– High performance DDR memory systems
– Server system SoC and system-level interfaces, including coherent system interconnects, PCIe, SATA, USB, Ethernet
– Memory management units
– Interrupt controllers and hardware timers
– Power management features
– System clocks and their management
– CPU and system performance monitor hardware
– Debug and trace hardware
– Security features
– System management controller hardware, firmware, and software
– Understanding of system-level programming UEFI, system initialization firmware, etc.
– C programming, preferably for embedded systems or drivers (ARM preferred)
– Familiarity with JTAG based debug tools and environments (Lauterbach Trace-32 preferred)
– Experience using hardware performance monitors for system debug and optimization
– Experience using a configuration management system, e.g. CVS, ClearCase, Git
– Experience using a defect tracking system, e.g. ClearQuest, Bugzilla, JIRA
– Excellent system debugging skills
– Knowledge of multi-agent coherent systems
– Knowledge of power management features, including voltage/frequency scaling and sleep modes
– Experience with ARM RVDS, ARM Development Studio, and GNU tools
– Experience with documentation applications such as Microsoft Word and Excel
– Working knowledge of digital oscilloscopes, logic analyzers, etc.



Aleph Security: Secure Boot vuln in Qualcomm OnePlus 2

OnePlus 2 Lack of SBL1 Validation Broken Secure Boot
Aleph Research Advisory

OnePlus 2 (a 2015 Qualcomm Snapdragon 810 device) successfully boots with a tampered Secondary Bootloader (sbl1) partition although it is digitally-signed, hence it is not validated by its Primary Bootloader (PBL), maybe due to lenient hardware configuration. Attackers capable of tampering with the sbl1 partition can then disable the signature validation of the rest of the bootloader chain and other SBL-validated partitions such as TrustZone and ABOOT.[…]





Trust Issues: Exploiting TrustZone TEEs

by Gal Beniamini, Project Zero

Mobile devices are becoming an increasingly privacy-sensitive platform. Nowadays, devices process a wide range of personal and private information of a sensitive nature, such as biometric identifiers, payment data and cryptographic keys. Additionally, modern content protection schemes demand a high degree of confidentiality, requiring stricter guarantees than those offered by the “regular” operating system. In response to these use-cases and more, mobile device manufacturers have opted for the creation of a “Trusted Execution Environment” (TEE), which can be used to safeguard the information processed within it. In the Android ecosystem, two major TEE implementations exist – Qualcomm’s QSEE and Trustonic’s Kinibi (formerly <t-base). Both of these implementations rely on ARM TrustZone security extensions in order to facilitate a small “secure” operating system, within which “Trusted Applications” (TAs) may be executed. In this blog post we’ll explore the security properties of the two major TEEs present on Android devices. We’ll see how, despite their highly sensitive vantage point, these operating systems currently lag behind modern operating systems in terms of security mitigations and practices. Additionally, we’ll discover and exploit a major design issue which affects the security of most devices utilising both platforms. Lastly, we’ll see why the integrity of TEEs is crucial to the overall security of the device, making a case for the need to increase their defences. […]




Qualcomm seeks Firmware Security Researcher

I’m going to try and start to post the occasional relevant interesting job postings for security researchers or developers. I will try to use ‘job-posting” for the tag for all of them. If you think it’s a bad idea for this blog, or if you get the job based on this blog, leave a Comment. 😉

[…]Qualcomm Hardware Security team is looking for a Firmware Security Researcher to help drive security efforts in our System-On-Chip (SOC) solutions. In this role, the Firmware Security Researcher will work closely with the Hardware Design Team, Hardware Verification team, and the Software team to help find vulnerabilities in our products. This role entails using best practices to evaluate, asses, and report vulnerabilities in QUALCOMM products. A systematic approach to vulnerability discovery is essential. Knowledge gained will leverage into new security mitigations for our SOC solutions used in a wide range of products, including mobile devices, IOT, automotive, consumer networking gear, wearables, and embedded medical devices. As a firmware security researcher, it is essential that the candidate be able to develop proof-of-concepts to demonstrate the impact of the vulnerabilities that are discovered, to enable proper prioritization and communication of issues to internal teams and external customers. Communication skills are highly valued as the role will entail cross-department coordination with the various groups involved in Cybersecurity initiatives, and possibly presenting findings at security conferences.[…]



aboot-parser: Android bootloader parser

Script to parse Android bootloader (aboot) images, extract certificates and verify image signature. May not work on aboot from latest devices. Signature verification follows the ‘Secure Boot and Image Authentication Technical Overview’ whitepaper by Qualcomm. Cf.  https://www.qualcomm.com/documents/secure-boot-and-image-authentication-technical-overview/ Aboot header format as described in  http://newandroidbook.com/Articles/aboot.html See above article for more details about aboot. Inspired by https://github.com/kayrus/kc_s701_break_free



Qualcomm Secure Boot whitepaper released

This whitepaper provides an in-depth look at our signed ELF images format, the process of loading and authenticating those images, certificate chain contents, and supported signature algorithms.




QualComm TrustZone MasterKeys extracted?

Kindly pointed out by a reader of the blog, laginimaineb has some more research going on for QualComm TrustZone, sounds non-trivial:

[Grr, when I paste an URL of a Twitter tweet, WordPress usually renders it, today, it is not, maybe it will before it posts it, unsure. I’ve extracted the text from the Tweets in case it does not.]

Just managed to extract the Qualcomm KeyMaster keys directly from TrustZone! Writeup coming soon 🙂 (1/2)

And wrote a script to decrypt all keystore keys. This can also be used to bruteforce the FDE passphrase off the device! (2/2)

This specifically is done on the Nexus 6, but I’ve also dabbled w/ the Nexus 5 and Moto X 2nd Gen


More info: