Peerlyst: List of Car Security Tools

https://www.peerlyst.com/posts/resource-list-of-car-hacking-tools-car-security-tools-and-car-security-resources-ben-ferris

PS: ‘ve not been good at tags connecting car-related posts (I will henceforth use “car hacking” for this), so here are the nearest-related posts; the last one is  a similar list of car security links:

The Car Hacker’s Handbook

The Most Hackable Cars

Awesome Vehicle Security list created

Using Radare to emulate BIOS

(There’s a Twitter URL for it, but I’ve lost it, sorry.)
Emulating a simple bootloader

Generally speaking, emulating a bootloader is simpler than it is for regular binaries, because they lack external libraries and usually have direct access to memory and hardware. In this case, the bootloader is a binary for x86 architecture which runs in 16-bits real mode using BIOS calls to perform its loading duties and textual input/output. The idea here is to emulate Cropta1 crackme using radare2 ESIL emulation, providing the needed BIOS via a trivial quick & dirty python implementation of just what it’s needed to run the crackme code. There are several ways to do it, I tried two of them and here is the story. […]

http://radare.today/posts/emulating-simple-bootloader/

 

Reversing U-Boot-based BHU WiFi uRouter

https://twitter.com/pauldanckaert/status/768088971477852161

Tao Sauvage of IOActive has a blog post on reversing the U-Boot-based BHU WiFi uRouter to find multiple vulnerabilities:

[…] The BHU WiFi uRouter, manufactured and sold in China, looks great – and it contains multiple critical vulnerabilities. An unauthenticated attacker could bypass authentication, access sensitive information stored in its system logs, and in the worst case, execute OS commands on the router with root privileges. In addition, the uRouter ships with hidden users, SSH enabled by default and a hardcoded root password…and injects a third-party JavaScript file into all users’ HTTP traffic. In this blog post, we cover the main security issues found on the router, and describe how to exploit the UART debug pins to extract the firmware and find security vulnerabilities. […]

http://blog.ioactive.com/2016/08/multiple-vulnerabilities-in-bhu-wifi.html

U-Boot v2016.09-rc2 released

Tom Rini of Konsulko announced the v2016.09-rc2 release of U-Boot. Excerpting most of his announcement:

It’s release day and v2016.09-rc2 is out now.  […]

A short list of changes to come in now are:
– More and various SoC and architecture updates
– Various DM updates and conversions
– PSCI updates
– MAKEALL is gone, buildman is for use by all
– We now have xtensa support
– DT overlays

A non-code change is that now I have Jenkins setup to automatically poll my WIP branches and run test/py/test.py on a few real boards along with sandbox.  I still have some more configuring and cabling to do, and a few more boards I can get setup.

For more info, see the announcement on the u-boot mailing list.

AMD Secure Encrypted Virtualization (SEV) patch for Linux kernel

Brijesh Singh of AMD submitted a 28-part patch to the Linux-(kernel,efi,kvm,…) mailing lists, with a patch for the the Linux kernel to support AMD’s Secure Encrypted Virtualization (SEV), which relies on the recent AMD Secure Memory Encryption (SME) patch by Tom Lendacky of AMD. I’m excerpting the intro text from part 1/28:

[RFC PATCH v1 00/28] x86: Secure Encrypted Virtualization (AMD)

This RFC series provides support for AMD’s new Secure Encrypted Virtualization (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFC.

SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. When enabled, SEV hardware tags all code and data with its VM ASID which indicates which VM the data originated from or is intended for. This tag is kept with the data at all times when inside the SOC, and prevents that data from being used by anyone other than the owner. While the tag protects VM data inside the SOC, AES with 128 bit encryption protects data outside the SOC. When data leaves or enters the SOC, it is encrypted/decrypted respectively by hardware with a key based on the associated tag.

SEV guest VMs have the concept of private and shared memory.  Private memory is encrypted with the  guest-specific key, while shared memory may be encrypted with hypervisor key.  Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. For data memory, SEV guest VMs can choose which pages they would like to be private. The choice is done using the standard CPU page tables using the C-bit, and is fully controlled by the guest. Due to security reasons all the DMA operations inside the  guest must be performed on shared pages (C-bit clear).  Note that since C-bit is only controllable by the guest OS when it is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware forces the C-bit to a 1.

SEV is designed to protect guest VMs from a benign but vulnerable (i.e. not fully malicious) hypervisor. In particular, it reduces the attack surface of guest VMs and can prevent certain types of VM-escape bugs (e.g. hypervisor read-anywhere) from being used to steal guest data.

The RFC series also includes a crypto driver (psp.ko) which communicates with SEV firmware that runs within the AMD secure processor provides a secure key management interfaces. The hypervisor uses this interface to enable SEV for secure guest and perform common hypervisor activities such as launching, running, snapshotting , migrating and debugging a  guest. A new ioctl (KVM_SEV_ISSUE_CMD) is introduced which will enable Qemu to send commands to the SEV firmware during guest life cycle.

The RFC series also includes patches required in guest OS to enable SEV feature. A guest OS can check SEV support by calling KVM_FEATURE cpuid  instruction.

The following links provide additional details:

AMD Memory Encryption whitepaper:

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer’s Manual:
http://support.amd.com/TechDocs/24593.pdf
SME is section 7.10
SEV is section 15.34

Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf

See the full patch for more information.
https://lkml.org/lkml/2016/8/22/960

William reviews CrScreenshotDxe

William has done another tool review, this time of Nikolaj’s CrScreenshotDxe tool. He does must longer blog posts on tool reviews than me, so it is always nice to see another review from him. 🙂

[…] “Nikolaj did us all a great service by posting this utility on Github.  It was easy to integrate and worked flawlessly.” […]

http://www.basicinputoutput.com/2016/08/the-joy-of-crscreenshotdxe.html

https://github.com/LongSoft/CrScreenshotDxe

screenshot-taking UEFI DXE driver

more info for AMD Secure Memory Encryption (SME) for Linux

A follow-up to:

AMD’s Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV)

Tom Lendacky of AMD posted v2 of a 20-part patch to most of the linux-kernel (and other) lists, adding support for AMD Secure Memory Encryption (SME), adding more documentation about AMD SME.

Secure Memory Encryption (SME) is a feature found on AMD processors.
SME provides the ability to mark individual pages of memory as encrypted using the standard x86 page tables.  A page that is marked encrpyted will be automatically decrypted when read from DRAM and encrypted when written to DRAM.  SME can therefore be used to protect the contents of DRAM from physical attacks on the system.
[…]
BOOT data (such as EFI related data) is not encyrpted when the system is booted and needs to be accessed as non-encrypted.  Add support to the early_memremap API to identify the type of data being accessed so that the proper encryption attribute can be applied.  Currently, two types of data are defined, KERNEL_DATA and BOOT_DATA.
[…]
Documentation/x86/amd-memory-encryption.txt

http://vger.kernel.org/majordomo-info.html

Also check out the older v1 patch posting on the lists, there was some interesting technical discussion. The above previous blog post has a pointer to that discussion, as well as some other AMD specs.

CHIPSEC adds blacklist database of UEFI modules

CHIPSEC 1.2.4 was recently released:

CHIPSEC 1.2.4 released

One new feature is a blacklist database of bad UEFI modules, and a new CHIPSEC security module to test for them, see the modules/tools/uefi/blacklist.py source for more details.

https://github.com/chipsec/chipsec/commit/bb9c9963547aae91a416be695c7f8b97fa61a3e8

Look at some of Yuriy’s more recent Twitter posts for a few new features not listed in the previous 1.2.4 release blog post, in addition to this blacklist.

Intel to license ARM tech

[…] Intel, will now manufacture chips for other companies such as ARM. To be more precise, it will be licensing technology from Britain’s ARM holdings. […]

I wonder what this means for Intel and ARM?? I’ve deleted a few paragraphs of speculation, to save you time, as I have no clue. 🙂

I hope that Intel also releases a version of a RISC-V chip!

http://wccftech.com/intel-manufacture-arm-chips/

ME Analyzer switches from closed-source to open-source

Great news, the tool “ME Analyzer” — for analyzing the Intel Management Engine (ME) — has switched from closed-source freeware to open source!!

 

Plutomaniac’s ME Analyzer

VBoxHardenedLoader

[…]What we will target:
– DMI Information;
– IDE/AHCI devices (harddisks, cd-rom’s);
– ACPI OEM Information;
– Ethernet Adapter MAC address;
– PXE Boot data;
– ACPI DSDT (Differentiated System Description Table);
– ACPI SSDT (Secondary System Descriptor Table);
– VGA Video BIOS data;
– BIOS data;
– VM splashscreen (optional, just for nice looking).
[…]

https://github.com/hfiref0x/VBoxHardenedLoader

http://www.kernelmode.info/forum/viewtopic.php?f=11&t=3478

It requires Visual Studio and only targets Microsoft Windows. No Linux, FreeBSD, Mac OS X support. 😦

Somewhat related, there are also these 2 projects:

UEFI VirtualBox tutorial

VirtualBox hardened loader

UEFI-Tool (not UEFITool)

There’s another new UEFI tool project on Github called “UEFI-tool”, not to be confused with UEFITool. This “UEFI-tool” contains a few tools, in a “UEFI-Tools” (plural) directory,

Documentation are source comments.

Project description:
“I write those tools reference by EDK2. Hope you guys will like it.”

Here’s the list of apps:
AHCI.c
DMA.c
GetPIDVID.c
GetSMBIOS.c
HDD.c
PCI-E.c
SMBus.c
SPI ROM.c

Yes, there’s a space in that last filename. 🙂

https://github.com/EdisonHsien/UEFI-tool

AMD Zen

Click on tweet for video of event:

http://www.amd.com/en-us/innovations/software-technologies/zen-cpu
http://www.amd.com/en-us/press-releases/Pages/zen-processor-core-2016aug18.aspx
https://community.amd.com/thread/204259

AMD Demonstrates Breakthrough Performance of Next-Generation “Zen” Processor Core

[…] At an event last night in San Francisco, AMD (NASDAQ: AMD) provided additional architectural details and a first look at the performance of its next-generation, high-performance “Zen” processor core. AMD demonstrated the “Zen” core achieving a 40% generational improvement in instructions per clock, delivering a landmark increase in processor performance. During the event, AMD demonstrated an 8-core, 16-thread “Summit Ridge” desktop processor (featuring AMD’s “Zen” core) outperforming a similarly configured 8-core, 16-thread Intel “Broadwell-E” processor1 when running the multi-threaded Blender rendering software with both CPUs set to the same clock speed. AMD also conducted the first public demonstration of its upcoming 32-core, 64-thread “Zen”-based server processor, codenamed “Naples,” in a dual processor server running the Windows® Server operating system. […]

 

UEFI Forum updates Secure Boot revocation database?

I wish I knew some more authoritative sources of news for this Microsoft Secure Boot story… 😦 The below post implies that the UEFI Forum’s Secure Boot recovation list file has been updated in response to recent news.

I REALLY wish the UEFI Forum would *announce* when they update their Secure Boot revocation list, and include version history to the changes, and keep older releases available for diffing against current one. It seems something this important should not be under public version control so you can see when keys come and go, and why. The current web page on this database should include information about the entries in the current database, and show changes and why. The page for this database should include end-user information for sysadmins to apply this to their systems, I see no real documentation on this page on how to properly use this database.
http://uefi.org/revocationlistfile

excerpt from https://blog.uncooperative.org/blog/2016/08/18/secure-boot-failures-and-mitigation/

[…] In response, UEFI is distributing an updated version of the Secure Boot revocation list, aka dbx. dbx is used to remove previously granted access from a UEFI driver or application, or from a signing certificate, declaring that signature invalid or signatures with the blacklisted certificate to be invalid. This update adds 64 new new individual signature entries into dbx, raising the total to 77.  […]