Category: Uncategorized

ARM assembly syntax (and REtools)

~ hucktech ~ Leave a comment

Bidirectional ARM Assembly Syntax Specifications

One of the tantalising pieces of information contained in ARM’s machine readable specifications is a specification of the assembly syntax. A few years ago (on an earlier) version of the specification, Wojciech Meyer and I decided to try to transform this specification into assemblers and disassemblers. At the time, this was not very useful to ARM because we already had assemblers and disassemblers so, although technically successful, the project died and the code has been slowly bitrotting ever since. In a few days time, I will be giving a talk at the 34th Chaos Communication Congress in Leipzig about practical things you can do with ARM’s specification and I thought it would be a good idea to suggest that someone creates a similar tool. But maybe it would be a good idea if I showed you what Wojciech and I did to get you started? Let’s start by digging into the HTML rendering of the ARM spec with the ADD instruction. The assembly syntax is in four parts. The first two parts show you the opcode diagram and the overall assembly syntax and is almost directly usable as a specification.[…]

https://alastairreid.github.io/bidirectional-assemblers/

https://events.ccc.de/congress/2017/Fahrplan/events/8915.html

See the above tweet for a thread about a related tool:

retools: a reverse engineering toolkit for normies

Collection of tools (disassembler, emulator, binary parser) aimed at reverse enginering tasks, more specifically, bug finding related. Currently we target ARMv7 and Mach-O though in the future more architectures and formats are planned. retools is somewhat unique in that most of the semantics for relevant instructions are parsed out of the specification PDFs as opposed to being generated by hand. Currently the disassembler, emulator, and binary parsers are partially done, with a symbolic execution engine and instrumentation/hooking framework to come as I get more time.

https://github.com/agustingianni/retools

 

VbiosFinder and rom-parser

~ hucktech ~ Leave a comment

VBiosFinder: extract a VBIOS from a BIOS update.

This tool attempts to extract a VBIOS from a bios update.

Dependencies include: UEFIDump and rom-parser.

https://github.com/coderobe/VBiosFinder

—–

UEFIDump, of course, is included with UEFITool. But rom-parser is new to me.

To view ROM contents:
usage: rom-parser [ROM file]

This program does not have support for reading the ROM from pci-sysfs, please do this manually in advance, ex:
cd /sys/bus/pci/devices/0000:01:00.0/
echo 1 > rom
cat rom > /tmp/image.rom
echo 0 > rom

Pass the resulting image file as the argument to this program.
To modify ROM conents:
usage: rom-fixer [ROM file]
Obtain ROM as above, program prompts for modifying ROM vendor and device IDs and invalid checksums.
IMPORTANT: rom-fixer will update the ROM file in place. Make a backup!

https://github.com/awilliam/rom-parser

Resolvit seeks CHIPSEC-savvy Pentester

~ hucktech ~ Leave a comment

It is still rare enough to see “CHIPSEC” in a job posting, that I still point them out.

Given job posting is a pentest role, this is also a ‘leading indicator’ that pentesters are starting to attack your firmware. 🙂

Penetration Tester – Product
Join Resolvit as a Penetration Tester and be part of a creative, forward-thinking team. Our success at deploying skilled, highly knowledgeable experts has landed us on the Inc. 5000 list of America’s fastest-growing companies four times – and we’re just getting started. As the Penetration Tester, you will configure security test targets such as servers, storage, and networking environments; perform product security assessments; create assessment reports; and work with global product teams to review assessment results.[…]
Experience with multiple of these security assessment tools: AppAudit, Arachni, Burp Suite Pro, CHIPSEC, nmap, Nessus, Protecode SC, and Metasploit
[…]

http://careers.resolvit.com/Careers/tabid/55/jobid/21807/Penetration-Tester–Product-Morrisville-North-Carolina.aspx

SymbiFlow and Project X-Ray: Xilinx FGPA

~ hucktech ~ Leave a comment

SymbiFlow:
will be a FOSS Verilog-to-Bitstream FGPA synthesis flow for Xilinx 7-Series FPGAs and iCE40. It is under construction.

Project X-Ray:
aims at documenting the Xilinx 7-series bit-stream format, a prerequisite to building Open Source tools to generate bit-streams for those devices. The information currently on this page is a sneak preview for the kind of information Project X-Ray will provide. Currently the work focuses on the Artix-7 xc7a50tfgg484-1 device. But we hope to be able to provide documentation for all Xilinx 7-Series, UltraScale, and UltraScale+ devices in the long term. Right now we focus on the region SLICE_X12Y100:SLICE_X27Y149 on the xc7a50tfgg484-1 device (configuration frames 0x00020500:0x000208ff). The immediate goal of the project is to provide tools to create bit-streams for partial reconfiguration of this region only.

https://symbiflow.github.io/
https://symbiflow.github.io/prjxray-db/artix7/
https://github.com/SymbiFlow/

https://www.xilinx.com/products/silicon-devices/fpga.html

 

Microsoft adds more enterprise security features to Windows 10

~ hucktech ~ Leave a comment

Enable virtualization-based protection of code integrity
11/28/2017
Contributors: Brian Lich Justinha Nick Brower Jason Gerend Jeffrey Sutherland

Virtualization-based protection of code integrity (herein referred to as Hypervisor-protected Code Integrity, or HVCI) is a powerful system mitigation that leverages hardware virtualization and the Windows Hyper-V hypervisor to protect Windows kernel-mode processes against the injection and execution of malicious or unverified code. Code integrity validation is performed in a secure environment that is resistant to attack from malicious software, and page permissions for kernel mode are set and maintained by the Hyper-V hypervisor. Some applications, including device drivers, may be incompatible with HVCI. This can cause devices or software to malfunction and in rare cases may result in a Blue Screen. Such issues may occur after HVCI has been turned on or during the enablement process itself. If this happens, see Troubleshooting for remediation steps.[…]

https://docs.microsoft.com/en-us/windows/device-security/enable-virtualization-based-protection-of-code-integrity

 

swsusp2bin: Utility to decompress Linux swsusp hibernation file

~ hucktech ~ Leave a comment

Comaeio Technologies has created a new tool to help with Linux forensics:

https://twitter.com/msuiche/status/942985467217268737

swsusp (Software Suspend) is a kernel feature/program which is part of power management framework in the Linux kernel. It’s the default suspend framework as of kernel 3.8. To hibernate the system, type the following at a shell prompt as root: “systemctl hibernate”. This command saves the system state on the hard disk drive and powers off the machine. When you turn the machine back on, the system then restores its state from the saved data without having to boot again. Because the system state is saved on the hard disk and not in RAM, the machine does not have to maintain electrical power to the RAM module, but as a consequence, restoring the system from hibernation is significantly slower than restoring it from suspend mode.[…]

https://github.com/comaeio/swsusp2bin

https://www.comae.io/

Environment variable whitelisting patch for U-Boot

~ hucktech ~ Leave a comment

Quentin Schulz of Free Electrons submitted a patch to U-Boot, adding whitelisting of variables, based on a patch by Maxim Ripard of Free Electrons.

[PATCH 00/11] Introduce variables whitelisting in environment

This patch series is based on a patch series from Maxime. This is an RFC. It’s been only tested in a specific use case on a custom i.MX6 board. It’s known to break compilation on a few boards. I have a use case where we want some variables from a first environment to be overriden by variables from a second environment. For example, we want to load variables from the default env (ENV_IS_NOWHERE) and then load only a handful of other variables from, e.g., NAND. In our use case, we basically can be sure that the default env in the U-Boot binary is secure but we want only a few variables to be modified, thus keeping control over the overall behaviour of U-Boot in secure mode. It works in that way:
– from highest to lowest priority, the first environment that can be loaded (that has successfully init and whose load function has returned no errors) will be the main environment,
– then, all the following environment that could be successfully loaded (same conditions as the main environment) are secondary environment. The env variables that are defined both in CONFIG_ENV_VAR_WHITELIST_LIST and in the secondary environments override the ones in the main environment,
– for saving, we save the whole environment to all environments available, be they main or secondary (it does not matter to save the whole environment on secondary environments as only the whitelisted variables will be overriden in the loading process
[…]

[1] https://patchwork.ozlabs.org/cover/842057/

For more info, see full email/patch on:
https://lists.denx.de/listinfo/u-boot

Dell releases Redfish-based OpenUSM, has firmware-update feature

~ hucktech ~ Leave a comment

” OpenUSM – Let Docker Containers Manage Your Datacenter
OpenUSM is a suite of tools and utilities which configures and manage the lifecycle of system management. OpenUSM has a capability to perform the following functions:
* BIOS Token Change
* Firmware Update
[…]”

https://github.com/openusm/openusm

http://en.community.dell.com/techcenter/dell_emc_custom_solutions_engineering/b/blog/archive/2017/10/03/dell-emc_2c00_-redfish-and-docker-_3a00_-simplifying-modern-datacenter-management

alt text

Amazon Hardware Security team seeks senior TPM

~ hucktech ~ Leave a comment

The AWS Hardware Infrastructure Security Team is looking for an experienced, Senior Security Program Manager to help ensure the global infrastructure supporting AWS is designed and implemented to the highest possible security standards.
[…]
* Minimum of 6 years of experience with two or more of the following categories:
— Data center internals (leaf/spine networking, power/cooling, NTP, DHCP, DNS, IPMI/iLO)
— Hardware security technologies (TPM, TrustZone, Secure Boot, UEFI, HSM, ROM, etc)
* Intermediate knowledge of crypto security (e.g. certificate handling, attestation, TPM/HSM)
* Intermediate knowledge of Windows, Linux, and hypervisor security (especially in cloud)
* Intermediate knowledge of common security protocols (e.g. RDP, TLS, SNMP, SSH, IPMI)

https://us-amazon.icims.com/jobs/603604/senior-security-technical-program-manager/job

Ubuntu 17.10 corrupting BIOS – many Lenovo laptops models (and Acer and Toshiba)

~ hucktech ~ 2 Comments

“Canonical has pulled downloads for its Ubuntu 17.10 Linux distribution following reports that it can trigger a bug in the UEFI firmware of selected Lenovo, Acer, and Toshiba laptops, corrupting the BIOS and disabling the ability to boot from USB Drives.”

https://www.bit-tech.net/news/tech/software/canonical-pulls-ubuntu-1710-over-uefi-corruption-issue/1/

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147

Judith Myerson of NIST on firmware security

~ hucktech ~ Leave a comment

http://searchsecurity.techtarget.com/answer/How-can-platform-firmware-be-protected-from-attacks?

How can platform firmware be protected from attacks?
by Judith Myerson
The NIST published guidance on building up platform firmware resiliency. Expert Judith Myerson looks at the NIST guidelines and the major takeaways for enterprises. The National Institute of Standards and Technology, or NIST, published a draft version of the Platform Firmware…

You have to give TechTarget.com your email addres to read the article.

Apple KB article on Secure Boot

~ hucktech ~ 1 Comment

Apple has a support article about their new Secure Boot. Interesting to see how Windows works with it, under Boot Camp. I wish Apple would also support Linux with Bootcamp, not just Windows.

https://support.apple.com/en-us/HT208330

 

LUV 2.2-rc2 released

~ hucktech ~ Leave a comment

Megha Dey of Intel announced the v2.2-rc2 release of LUV, Linux UEFI Validation. Excerpts of announcement below, for full announcement, see LUV mailing list post.

Two main new features:

Dump list of Device-Specific Methods:
DSM (Device Specific Method) as defined in ACPI spec is a control method that enables devices to provide device specific control functions that are consumed by the device driver. DSM’s are optional on a platform and they are optional to be consumed by OS. Both these points mean that a kernel developer might be unaware of these DSM’s and hence might never use them in their device driver. By adding this feature, LUV could be used as a vehicle to educate kernel developers about these DSM’s. A device driver developer, from the list of DSM’s provided by LUV, could then evaluate the usefulness of a DSM and then decide if it needs to be used or left as an option.

Add tests in bits to detect Machine Check Errors:
Machine Check Error (MCE) test is a way to find the errors generated by the hardware or any specific subsystem(s). The value of these tests is that it detects any MCEs that might have occurred before Linux starts to boot. Hence, if detected, they were caused by hardware or possibly BIOS.

https://01.org/linux-uefi-validation/v2.2

https://lists.01.org/mailman/listinfo/luv

Intel releases Firmware Engine for Linux and Windows

~ hucktech ~ Leave a comment

Previously the Intel Firmware Engine was a Windows-only thing, and I’d usually mention the lack of Linux support when posting about each Windows release. This time they’ve ported it to Linux!!! Thanks, Intel!

https://firmware.intel.com/blog/intel-firmware-engine-40-release

Posted by BrianRichardson on 12/18/2017

The Intel® Firmware Engine 4.0 release is now available. Intel Firmware Engine enables rapid firmware configuration and customization using a graphical interface, without the need for source modifications. Customers start from a validated Intel reference design, allowing developers to configure firmware features based on their product customizations. This development process accelerates adding & removing firmware features not found in reference platform, adding 3rd party components, and integration of custom boot payloads.

Intel Firmware Engine 4.0 (Linux)

Intel Firmware Engine 4.0 adds application support for Ubuntu* Linux*, in addition to existing support for Microsoft* Windows operating systems. This release also updates the firmware core, based on the UDK2017 release available from tianocore.org, and improves deployment of microcode patch updates.

 

Intel Firmware Engine 4.0 (Linux)