https://aur.archlinux.org/packages/chipsec-dkms-git/
https://aur.archlinux.org/packages/chipsec-git/
Category: Uncategorized
Matthew Garrett leaves CoreOS, joins Google
Matthew Garrett is leaving CoreOS and has gone to Google!
https://coreos.com/blog/working-on-container-linux.html
Physically Unclonable Function (PUF) research
“[…]Building a hardware product that cannot be copied is hard. Especially small integrated chips make it hard to distinguishing between a knockoff device and a real one. But this is not only a copyright concern, but also important to ensure trust in a device’s origin. For example a chip could be replaced in the manufacturing chain with a backdoored version. A good example to understand the problem is to look at smart cards, especially the ones used for decrypting premium TV channels. The whole business model relies on a shared secret key, embedded inside of the chips. It’s obviously in the interest of the company, that nobody can crate a working copy of such a card. But once the secret key is extracted through various hardware attack techniques, creating a copy of a smart card is trivial. Is there a way how hardware could be manufactured, such that it’s practically impossible to copy – and not just very expensive to copy? Physically Unclonable Function (short: PUF) is a concept that attempts to exploit (utilize) physical impurities, which are different for each device, to make exact physical copies impossible to manufacture. In practice this is often used to verify, that a particular hardware (a chip) is not counterfeit. This is usually implemented with a challenge and response protocol. A vendor can collect valid responses for random challenges of a chip, and the customer can verify later, that the device bought, was really made by that manufacturer. While creating an exact copy of the chip might be impossible, one could try to understand the mathematical model underlaying the behavior and therefor is able to create a device that emulates the behavior of the original chip. Will every PUF have this flaw, that math can describe it’s behavior, or are there PUFs that are truly random and thus unpredictable? – that is an unsolved question. With the experiments I conducted, we tried to understand a certain PUF family better, whose underlaying mathematical model is unknown. […]
http://smrrd.de/br-puf-analysis.html
SuperMicro on using IPMI in a home lab
Here’s advice from a few months ago by SuperMicro on how to use IPMI in a network environment:
“If you are utilizing Supermicro in your lab environment, there is a great feature that comes with Supermicro boards that allows BMC IPMI management of the server. It is basically an out of band management of the server much like a switch OOB management interface. I wanted to post some screenshots of most of the various areas of control you have with the IPMI console of a Supermicro box. It is fairly comprehensive. Let’s take a look at Supermicro IPMI management walkthrough.”
http://www.virtualizationhowto.com/2016/05/supermicro-ipmi-management-walkthrough/
DFIR toolset links
Mark McCurdy of HP has a nice set of links for DF
https://github.com/marcurdy/dfir-toolset
It is sort of like an ‘awesome forensics’ page, so related to lists like:
https://github.com/Cugu/awesome-forensics
https://github.com/sbilly/awesome-security
https://github.com/rshipp/awesome-malware-analysis
https://github.com/apsdehal/awesome-ctf
https://github.com/onlurking/awesome-infosec
https://github.com/tylerph3/awesome-reversing
https://github.com/paragonie/awesome-appsec
https://github.com/meirwah/awesome-incident-response
etc.
European coreboot conference 2017
OEMs: please note!
Carl-Daniel Hailfinger posted an announcement to the upcoming European coreboot conference 2017 to the coreboot-announce list:
We are currently planning to host a coreboot conference in Germany with 2 days of talks and an additional 2 days of hacking. The date will probably either be October 19-22 or October 26-29, i.e. directly before or after Embedded Linux Conference Europe and LinuxCon Europe. Ticket prices haven’t been decided yet and depend on the location and venue availability. The location will be either in Bonn or Bochum. Both Bochum and Bonn offer a variety of interesting activities for conference participants. Bochum is reachable by public transport from Frankfurt Airport within 120 minutes, from Dusseldorf Airport within 40 minutes and from Cologne Airport within 80 minutes. Bonn is reachable by public transport from Frankfurt Airport within 70 minutes, from Dusseldorf Airport within 70 minutes and from Cologne Airport within 30 minutes.
YOUR ACTION NEEDED!
Please fill out the application and subscribe to the newsletter if you are planning to join us!
https://www.coreboot.org/events/ecc2017
Full announcement:
https://www.coreboot.org/pipermail/coreboot-announce/2017-January/000024.html
grap
grap: define and match graph patterns within binaries:
grap takes patterns and binary files, uses a Casptone-based disassembler to obtain the control flow graphs from the binaries, then matches the patterns against them. Patterns are user-defined graphs with instruction conditions (“opcode is xor and arg1 is eax”) and repetition conditions (3 identical instructions, basic blocks…). grap is both available as a standalone tool with a disassembler and as an IDA plugin which takes advantage of the disassembly done by IDA and the reverser.
Intel Processor Trace driver for Windows
“This driver implements the Intel Processor Trace functionality in Intel Skylake architecture for Microsoft Windows. “
https://github.com/intelpt/WindowsIntelPT
There’s also the Talos driver:
and libIPT:
Windows kernel resources site
Microsoft Updates OEM Device/Credential Guard requirements
Microsoft just updated this page:
No list of what’s changed, it seems that would be a reasonable thing for a large list of requirements… I’ll leave you to figure out what changed. 🙂
(If someone knows of a good way to diff this page against the same page a few weeks ago (without archive.org), please leave a Comment on this blog post. Thanks.)
Jan Lübbe on eLinux security
Jan Lübbe of Pengutronix e.K. gave a talk at ELCE’16 (Embedded Linux Conference Europe 2016) called: “Long-Term Maintenance, or How to (Mis-)Manage Embedded Systems for 10+ Years”.
“Hardware vendors don’t care about security or maintenance.”
https://www.linux.com/news/event/ELCE/2017/long-term-embedded-linux-maintenance-made-easier
Keeping Linux devices secure with rigorous long-term maintenance
http://elinux.org/ELC_Europe_2016_Presentations
Click to access Long-Term_Maintenance.pdf
UEFI support for DragonFlyBSD
https://www.dragonflydigest.com/2017/01/05/19139.html
http://lists.dragonflybsd.org/pipermail/users/2017-January/313193.html
http://apollo.backplane.com/DFlyMisc/uefi.txt
https://www.dragonflydigest.com/2017/01/17/19208.html
http://lists.dragonflybsd.org/pipermail/commits/2017-January/625352.html
https://leaf.dragonflybsd.org/cgi/web-man?command=uefi§ion=ANY
No Secure Boot support yet.
OpenSynergy hypervisor for ARM Cortex-R52
Quoting the press release:
Automotive safety hypervisor announced for ARM Cortex-R52
OpenSynergy paves way for next-generation autonomous devices with virtualization for ARM’s most advanced real-time processor
Berlin, Germany and Cambridge, UK, January 18, 2017. OpenSynergy is developing the industry’s first software hypervisor for the ARM® Cortex®-R52 processor, ARM’s most advanced real-time safety processor. The hypervisor turns any chip based on the Cortex-R52 into several virtual machines capable of simultaneously executing separate software tasks. To address increasing software complexity in devices such as autonomous vehicles and industrial control systems, this approach allows for the isolation of safety-critical functions from those that require less stringent control. In addition, it enables the consolidation of applications onto fewer electronic control units (ECUs) to both manage complexity and reduce cost. “Mass-market autonomous vehicles will be engineered with greatly enhanced ECU compute capabilities and the ability to safely manage far more complex software stacks,” said Richard York, vice president of embedded marketing, ARM. “The Cortex-R52 was purpose-built for this task, with hypervisor-enabled software separation protecting critical safety features while ensuring fast task execution. This will enable highly performant vehicles that can be fully trusted to take over from the driver.” “The ARM Cortex-R52 processor will bring virtualization technology to a much wider set of devices in the automotive market,” said Stefaan Sonck Thiebaut, CEO, OpenSynergy. “In doing so, we look forward to enabling the next generation of vehicle architecture.” The Cortex-R52 introduces hardware support for virtualization to the Cortex-R family of processors while maintaining all the functionality required for hard real-time systems. The ability to maintain deterministic execution within a hypervisor provides an ideal solution to the challenge of concurrent real-time systems in a wide array of robotic applications. OpenSynergy’s software architecture targets microcontrollers such as domain controllers. The hypervisor technology enables several real-time operating systems and AUTOSAR systems at different ASIL levels to run in parallel on the Cortex-R52.
Full PR:
https://www.arm.com/about/newsroom/automotive-safety-hypervisor-announced-for-arm-cortex-r52.php
bootcode_parser
bootcode_parser.py is a Python script designed to perform a quick offline analysis of the boot records used by BIOS based systems (UEFI is not supported). It is intended to help the analyst triaging individual boot record dumps or whole disk images. The latter is preferred since it allows the script to perform additional checks that would not be possible on individual dumps alone. This script only detects anomalies that have to be manually investigated by an analyst. Because it works with a whitelist mechanism it will be able to detect a wide range of malicious codes, but it will also detect legitimate (encryption software, etc…) or benign modification of the boot records. This topic has been presented during a talk at the French conference CORI&IN 2017.
[…]
usage:
bootcode_parser.py [-h] –type {VBR,MBR,IPL,IMG} –input INPUT [INPUT …] [–offset OFFSET] [–sector-size SECTOR_SIZE] [–whitelist WHITELIST] [–logLevel {DEBUG,INFO,WARNING,ERROR,CRITICAL}]
-h, –help — show this help message and exit
–type {VBR,MBR,IPL,IMG} — Type of boot record: MBR, VBR or IPL. Or whole disk image.
–input INPUT [INPUT …] — Input file(s) to check
–offset OFFSET — Offset in bytes at which the boot record was dumped. Required only for VBR. Without it, some heuristics to detect malicious VBR will not work.
–sector-size SECTOR_SIZE — Disk sector size in bytes. Only applies for disk image input. Defaults to 512.
–whitelist WHITELIST — CSV file containing whitelisted boot record signatures. Without it, the boot record will always be flagged as suspicious. Defaults to ./data/bootrecord_whitelist.csv
–logLevel {DEBUG,INFO,WARNING,ERROR,CRITICAL} — Show debug messages according to the level provided.
DMTF Releases Redfish Host Interface Specification
Quoting their press release:
“DMTF’s innovative Redfish standard continues its fast progression, thanks to the dedicated efforts of the Scalable Platforms Management Forum (SPMF). To date, Redfish has focused on defining a TCP/IP-based out-of-band interface between a client and a management controller. Today, the newly available Redfish Host Interface Specification expands these capabilities to allow applications and tools running on an Operating System – including in the pre-boot (firmware) stage – to communicate with the Redfish management service. Every device exposes an interface to the host software (Operating System or Hypervisor). Management controllers are no different, and this standard modernizes this interface to equalize the capabilities of “in-band” or “host-based” applications with remote applications using Redfish. To learn more about Redfish or to download the Redfish Host Interface specification, please the Redfish web site. Developers can also visit the Redfish Developer Hub, a one-stop, in-depth technical resource with all the files, tools, community support and education you may need to help you use Redfish. To participate in the Host Interface Task Force, please join the DMTF’s SPMF.”
http://www.dmtf.org/standards/redfish/
http://www.dmtf.org/standards/spmf/
http://redfish.dmtf.org/
Asset Intertech on debugging Minnowboard firmware
Asset Intertech has a blog series on debugging Minnowboard firmware using their debugger product. Even if you can’t afford their product, you can still learn about debugging UEFI firmware from this post. 🙂
The Minnowboard Chronicles – Episode 3
As I continue the journey to learn about the internals of UEFI and to debug it with SourcePoint, I encounter some issues doing the firmware build. Last week, I played around with the UEFI shell, and then updated the firmware on my Minnowboard to the latest release (v0.94). Then, I used SourcePoint to look at disassembled code when the platform was sitting in the UEFI shell, waiting for keyboard input. From last time, we can see a number of “INT 3” instructions, with opcode CC. […]
http://blog.asset-intertech.com/test_data_out/2017/01/the-minnowboard-chronicles-episode-2.html
http://blog.asset-intertech.com/test_data_out/2017/01/the-minnowboard-chronicles-episode-3.html
AMI announces UEFI 2.6 and ACPI 6.1 support
AMI announced that their UEFI implementation, Aptio V, supports UEFI 2.6 and ACPI 6.1
American Megatrends Announces Aptio V Compliance with UEFI 2.6 and ACPI v6.1
AMI is proud to announce Aptio® V support and compliance for UEFI 2.6 and ACPI v6.1 specifications. As a leader in the BIOS/UEFI firmware industry and board member in the UEFI community, AMI keeps up with the latest upgrades and specifications to better serve its customers in the technology industry. Aptio® V, AMI’s flagship UEFI firmware, is developed according to UEFI specifications and the added support for UEFI 2.6 and ACPI v6.1 gives manufacturers the ability to enhance select platforms based on the latest UEFI specifications. The newest specifications, announced this past March, keeps up with the increasing expectations of the market, providing OEMs and ODMs greater manageability across various user systems and creating more expansive support for newer platforms and designs. By integrating and expanding support for UEFI 2.6 and ACPI v6.1 on its core UEFI firmware, Aptio V, AMI standardizes operating systems booting and optimizes pre-boot applications for its customers.
Full PR:
https://ami.com/news/press-releases/?PressReleaseID=373
newrock: Hypervisor for x86-64, UEFI platforms
newrock: Hypervisor for x86-64, UEFI platforms
This project would be maintained in Russian language
https://github.com/skvl/newrock
I only saw docs, no code. But for those who are into hypervisors, keep watching this site!
YAUB: Yet Another UEFI Bootloader
Here’s the complete documentation:
Yet Another UEFI Bootloader
For more info, see the source code. The project is only 4 hours old, maybe some docs will show up…
eficheck
https://twitter.com/osxreverser/status/824284477878845441
https://twitter.com/osxreverser/status/824271973127692288
https://twitter.com/osxreverser/status/824270614601101313
Sounds exciting, but I don’t know where to get eficheck. If someone knows, please leave a Comment to this post. Thanks!
Firmware Security 
You must be logged in to post a comment.