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.



Intel ATR releases UEFI firmware training materials!

Good news: the Intel Advanced Threat Research (ATR) team has release some of their UEFI security training materials!

This repository contains materials for a hands-on training ‘Security of BIOS/UEFI System Firmware from Attacker and Defender Perspectives’. A variety of attacks targeting system firmware have been discussed publicly, drawing attention to the pre-boot and firmware components of the platform such as BIOS and SMM, OS loaders and secure booting. This training will detail and organize objectives, attack vectors, vulnerabilities and exploits against various types of system firmware such as legacy BIOS, SMI handlers and UEFI based firmware, mitigations as well as tools and methods available to analyze security of such firmware components. It will also detail protections available in hardware and in firmware such as Secure Boot implemented by modern operating systems against bootkits. The training includes theoretical material describing a structured approach to system firmware security analysis and mitigations as well as many hands-on exercises to test system firmware for vulnerabilities. After the training you should have basic understanding of platform hardware components and various types of system firmware, security objectives and attacks against system firmware, mitigations available in hardware and firmware. You should be able to apply this knowledge in practice to identify vulnerabilities in BIOS and perform forensic analysis of the firmware.

0 Introduction to Firmware Security
1 BIOS and UEFI Firmware Fundamentals
2 Bootkits and UEFI Secure Boot
3 Hands-On Platform Hardware and Firmware
4 System Firmware Attack Vectors
5 Hands-On EFI Environment
6 Mitigations
7 System Firmware Forensics
N Miscellaneous Materials



FWTS 17.05.00 released

Ivan Hu of Canonical announced the 17.05.00 release of FWTS.

New Features:
  * Support SMBIOS 3.1.1 tests
  * dmi: dmicheck: check new offset in spec 3.11
  * dmi: dmicheck: check reserved bits of Type 7 offset 0x5
  * dmi: dmicheck: check reserved bits of Type 7 offset 0xd
  * dmi: dmicheck: add a function to verify reserved bits
  * dmi: dmicheck: add a helper function to check word min/max value
  * dmi: dmicheck: check pci(e) slot and segment, bus and dev/func
  * dmi: dmicheck: check reserved bits of offset 0x5 in type 13
  * dmi: dmicheck: add a helper function to check a reserved offset
  * dmi: dmicheck: check reserved bits in type 15 & type 17
  * dmi: dmicheck: check reserved fields in type 22, 23, 30, 32, 38 and 39
  * dmi: dmicheck: add 64-bit integer to dmi_reserved_bits_check
  * dmi: dmicheck: add checks for new type 43
  * dmi: dmicheck: check reserved bits in Type 0
  * fwts/opal: Power management DT Validation tests.
  * fwts/opal: Reserved memory DT validation tests.
  * Add snapcraft rules to build a fwts snap

See the list of bugfixes in the full announcement.