Vape Pens: source of USB attacks

If you have a vaping device, make sure it supports Verified/Secure/Trusted/etc Boot. 🙂

[…]Take this as the weirdest example yet that you should never plug random devices into your USB ports. […] While FourOctets has no ill-intent, it is easy to imagine someone less scrupulous loading a computer with something not quite as funny. Like, say, a keylogger. Or ransomware.[…]


A related presentation, as suggested from a poster in the above twitter thread:

Holy smokes, how to vape yourself to root
Ross Bevington
Abstract: We all know that smoking is bad for your health, but what about you or your organisations security? I’ll show you that an eCig isn’t just a glorified smoke machine but a low power, battery operated, exploitation platform. I’ll show you how easy it is to decrypt the firmware, write your own functionality and use this to pwn some systems. Turning your eCig into everything from a keyboard to a USB stick. On the way we’ll do a bit of reverse engineering, write a bit of code and show how you can do most of this on a shoe string budget. Looking for ways to defend against attacks like this? I have some options. Consider this talk if you want another reason to ban smoking at your organisation.




Does ‘power trio’ apply to training companies, as well as rock bands? 🙂

“Combined, we have over 25 years of experience teaching hardware security trainings and we have taught hundreds of classes. We have helped leading tech companies build their security teams and taught thousands of hardware security engineers the skills necessary for their day to day work. Our unique experience is unparalleled in the industry.”









Nintendo 3DS

A few links to Nintendo 3DS firmware. The first tweet below hints of Nintendo having a response (ban?) to custom firmware.



sighax is a BootROM exploit (revealed at 33c3) for the Nintendo 3DS/2DS/New3DS. It exploits a vulnerability in the RSA signature parser and allows you to run fake-signed firmware on any console.



“Keyshuffling Attack for Persistent Early Code Execution in the Nintendo 3DS Secure Bootchain”



A complete guide to developer 3DS custom firmware, from stock to boot9strap.




A tool to parse, extract, and builds 3DS firmware files



Luma3DS is a program to patch the system software of (New) Nintendo 3DS handheld consoles “on the fly”, adding features (such as per-game language settings and debugging capabilities for developers) and removing restrictions enforced by Nintendo (such as the region lock). It also allows you to run unauthorized (“homebrew”) content by removing signature checks. To use it, you will need a console capable of running homebrew software on the ARM9 processor. We recommend Plailect’s guide for details on how to get your system ready.




AGESA update info from AMD

[…]Beginning this month, as we promised to you, we began beta testing a new AGESA (v1.0.0.6) that is largely focused on aiding the stability of overclocked DRAM (>DDR4-2667). We are now at the point where that testing can begin transitioning into release candidate and/or production BIOSes for you to download. Depending on the QA/testing practices of your motherboard vendor, full BIOSes based on this code could be available for your motherboard starting in mid to late June. Some customers may already be in luck, however, as there are motherboards—like my Gigabyte GA-AX370-Gaming5 and ASUS Crosshair VI—that already have public betas.
If you’re the kind of user that just needs (or loves!) virtualization every day, then AGESA firmware will be a blessing for you thanks to fresh support for PCI Express Access Control Services (ACS). ACS primarily enables support for manual assignment of PCIe graphics cards within logical containers called “IOMMU groups.” The hardware resources of an IOMMU group can then be dedicated to a virtual machine. This capability is especially useful for users that want 3D-accelerated graphics inside a virtual machine. With ACS support, it is possible to split a 2-GPU system such that a host Linux® OS and a Windows VM both have a dedicated graphics cards. The virtual machine can access all the capabilities of the dedicated GPU, and run games inside the virtual machine at near-native performance.[…]





DMTF updates MCTP SMBus/I2C Transport Binding spec

DMTF Releases Updated MCTP SMBus/I2C Transport Binding Specification
The DMTF’s Platform Management Components Intercommunication (PMCI) Working Group defines standards to address “inside the box” communication and functional interfaces between the components of the platform management subsystem (e.g., management controllers, managed devices, etc.). PMCI’s Management Component Transport Protocol (MCTP) over SMBus/I2C Transport Binding Specification is now available in version 1.1.0 . This specification addresses how MCTP packets are delivered over a physical SMBus or I2C medium using SMBus transactions. It defines how physical addresses are used, how fixed addresses are accommodated, how physical address assignment is accomplished for hot-plug or other devices that require dynamic physical address assignment, and how MCTP support is discovered. In addition, timing specifications for bus and MCTP control operations are included, and a “fairness” protocol is defined for the purpose of avoiding deadlock and starvation/lockout situations among MCTP endpoints. The binding has been designed to be able to share the same bus as devices communicating using earlier SMBus/I2C management protocols, such as Alert Standard Format (ASF) and Intelligent Platform Management (IPMI), and with vendor-specific devices using SMBus/I2C protocols. The specification also allows a given device to incorporate non-MCTP SMBus functions alongside MCTP.




Analyzing ECU firmware

How They Did It: An Ana­ly­sis of Emis­si­on De­feat De­vices in Mo­dern Au­to­mo­bi­les
Mo­dern ve­hi­cles are re­qui­red to com­ply with a range of en­vi­ron­men­tal re­gu­la­ti­ons li­mi­t­ing the level of emis­si­ons for va­rious green­hou­se gases, to­xins and par­ti­cu­la­te mat­ter. To en­su­re com­pli­an­ce, re­gu­la­tors test ve­hi­cles in con­trol­led set­tings and em­pi­ri­cal­ly me­a­su­re their emis­si­ons at the tail­pipe. Howe­ver, the black box na­tu­re of this tes­ting and the stan­dar­diza­t­i­on of its forms have crea­ted an op­por­tu­ni­ty for eva­si­on. Using mo­dern elec­tro­nic en­gi­ne con­trol­lers, ma­nu­fac­tu­rers can pro- gram­ma­ti­cal­ly infer when a car is un­der­go­ing an emis­si­on test and alter the be­ha­vi­or of the ve­hi­cle to com­ply with emis­si­on stan­dards, while ex­cee­ding them du­ring nor­mal dri­ving in favor of im­pro­ved per­for­mance. While the use of such a de­feat de­vice by Volks­wa­gen has brought the issue of emis­si­ons chea­ting to the pu­blic’s at­ten­ti­on, there have been few de­tails about the pre­cise na­tu­re of the de­feat de­vice, how it came to be, and its ef­fect on ve­hi­cle be­ha­vi­or. In this paper, we pre­sent our ana­ly­sis of two fa­mi­lies of soft­ware de­feat de­vices for die­sel en­gi­nes: one used by the Volks­wa­gen Group to pass emis­si­ons tests in the US and Eu­ro­pe, and a se­cond that we have found in Fiat Chrys­ler Au­to­mo­bi­les. To carry out this ana­ly­sis, we de­ve­lo­ped new sta­tic ana­ly­sis firm­ware fo­ren­sics tech­ni­ques ne­cessa­ry to au­to­ma­ti­cal­ly iden­ti­fy known de­feat de­vices and con­firm their func­tion. We tested about 900 firm­ware ima­ges and were able to de­tect a po­ten­ti­al de­feat de­vice in more than 400 firm­ware ima­ges span­ning eight years. We de­scri­be the pre­cise con­di­ti­ons used by the firm­ware to de­tect a test cycle and how it af­fects en­gi­ne be­ha­vi­or. This work fra­mes the tech­ni­cal chal­len­ges faced by re­gu­la­tors going for­ward and high­lights the im­portant re­se­arch agen­da in pro­vi­ding fo­cu­sed soft­ware as­suran­ce in the pre­sence of ad­ver­sa­ri­al ma­nu­fac­tu­rers.