Category: Uncategorized

Reversing Huawei routers, part 3

~ hucktech ~ Leave a comment

In part 2, Juan Carlos was interacting with the CLI in U-Boot. What will happen in episode 3? Spoiler alert: there is an episode 4 planned!

Practical Reverse Engineering Part 3 – Following the Data
Part 1: We found a door into the firmware in the form of a UART debug port
Part 2: We took a first look at the firmware, collected all sorts of data

The best thing about hardware hacking is having full access to very bare metal, and all the electrical signals that make the system work. With ingenuity and access to the right equipment we should be able to obtain any data we want. From simply sniffing traffic with a cheap logic analyser to using thousands of dollars worth of equipment to obtain private keys by measuring the power consumed by the device with enough precission (power analysis side channel attack); if the physics make sense, it’s likely to work given the right circumstances. In this post I’d like to discuss traffic sniffing and how we can use it to gather intel. Traffic sniffing at a practical level is used all the time for all sorts of purposes, from regular debugging during the delopment process to reversing the interface of gaming controllers, etc. It’s definitely worth a post of its own, even though this device can be reversed without it. […]

Post:

http://jcjc-dev.com/2016/05/23/reversing-huawei-3-sniffing/

Huawei HG533 reversing, part I

Reversing Huawei router part 2: U-Boot’s CLI

Petition for Intel to build a no-ME system

~ hucktech ~ Leave a comment

Here is where to sign:
https://puri.sm/posts/petition-for-intel-to-release-an-me-less-cpu-design/

I hope someone does a petition to get the Stateless Laptop built. If Intel builds a new ME-less system, it should also be building this Stateless system as part of it.

http://blog.invisiblethings.org/2015/12/23/state_harmful.html

AND… I don’t understand why OEMs are dancing around with tamper resistant screws. IMO, a system needs a lock, a good one, since lockpicking is a normal hacker sport, most locks are useless. A good laptop should have a lock to prevent casual evil maids. The Google Chromebox Pixel Developer Mode scew is nice, but an evil maid could also use that, no lock. Cars have locks. Houses have locks. Computer server rooms have locks. Data contained in laptops are often worth more than cars and houses. Why do modern expensive computers have no locks? Cost? Governments would not want them, harder to access boxes going through customs? I want a Stateless Laptop, with a secure metal enclosure and a good quality lock. Then I’ll keep the key and thumbdrives with me, and just deal with rubberhose attacks, not evil maid attacks.

ezFIO – NVMe SSD Benchmark Tool

~ hucktech ~ Leave a comment

Quoting the blog and readme:

ezFIO is a Linux and Windows wrapper for the cross-platform FIO IO testing tool. It always includes a repeatable preconditioning (also known as “seasoning”) stage, to help simulate the true long-term performance of eSSDs. A wide variation in IO sizes and parallelism is run automatically.

ezFIO also includes long-term performance stability measures, which allow for latency outliers and deviations to be numerically represented and graphically identified quickly. These new SSD metrics show Quality of Service, both at a Macro level (standard deviation over time) and Micro Level (measurement of minimum and maximum latency outliers). And, finally, ezFIO takes all these results and produces an Open Document formatted spreadsheet usable under Linux or Windows with embedded graphs and raw test results to make examining these results consistently derived and for any NVMe device to be compared.

This test script is intended to give a block-level based overview of SSD performance (SATA, SAS, and NVME) under real-world conditions by focusing on sustained performance at different block sizes and queue depths.  Both text-mode Linux and GUI and text-mode Windows versions are included.

http://www.nvmexpress.org/blog/ezfio-powerful-simple-nvme-ssd-benchmark-tool/
https://github.com/earlephilhower/ezfio

Security updates in Android N

~ hucktech ~ Leave a comment

Lucian Armasu has a story in Toms Hardware about Android N security changes, summarizing a presentation from Adrian Ludwig of Android at the recent Google I/O event. The story has a link to the Google I/O video, as well. Outline of Lucian’s story:

Hardware-Backed Keystore (Now Mandatory)
Fingerprint And Smart Lock Authentication
Secure Networking
Storage Encryption
Strictly Enforced Verified Boot
Checking Device Health
Sandboxing
Other System Restrictions & Improvements

“[…] Ludwig said that a major security feature of Android these days is the hardware-backed ‘keystore’, which is available in the vast majority of Android devices thanks to various implementations of ARM’s TrustZone. Although TrustZone has been mainly implemented by chip makers and OEMs to enable stricter DRM protection, Google started making it available to application developers in the past few years. […]”

“[…] If in Android M the phone would warn the user only that the boot was modified by unknown code, in version N the device will not boot if the boot process has been maliciously modified. Google also introduced bit-level error correction in the verified boot feature, which can erase changes that would, for instance, keep a device rooted after it’s been rooted. […]”

Full story:
http://www.tomshardware.com/news/google-android-n-security-improvements,31846.html

AFL support added to Linux Kernel

~ hucktech ~ Leave a comment

https://twitter.com/lcamtuf/status/734055720010670080

The Linux kernel just got a patch to add AFL support! I don’t believe FreeBSD has such a feature, yet…. 😐

[PATCH] kcov: add AFL-style tracing

AFL uses a fixed-size buffer (typically 64 KiB) where each byte is a counter representing how many times an A -> B branch was taken. Of course, since the buffer is fixed size, it’s a little imprecise in that e.g. two different branches could map to the same counter, but in practice it works well.

See afl:docs/technical_details.txt for more information.

http://lkml.iu.edu/hypermail/linux/kernel/1605.2/03665.html

PTSecurity on Disabling Intel Management Engine

~ hucktech ~ Leave a comment

N3mes1s points out an article from Maxim Goryachy and Mark Ermolov of PTSecurity, on disabling the Intel Management Engine (ME).

http://ptsecurity.com
https://github.com/ptresearch/

Click to access How%20to%20become%20the%20sole%20owner%20of%20your%20PC.pdf

Aclock-EFI: UEFI port of Unix Analog Clock tool

~ hucktech ~ Leave a comment

Claunia has written aclock-efi, a UEFI port of aclock, an analock clock.

Aclock is an analog clock program for text mode console displays, terminals, or terminal emulators. This program is obviously absolutely useless, except for turning your old, expensive mainframe or supercomputer into a wall clock. The UNIX source code compiles on everything from AIX to zOS without any changes. Available are Curses, Termcap and AAlib for more modern systems. Provided are also specific, non-unix ports. There is also a vector graphics version for Tektronix 4014/4010 or XTerm/Kermit Tek emulator. This version is a port from the Curses aclock version to EFI Boot Services.

https://github.com/claunia/aclock-efi

HackBGRT: changes Windows boot logo on UEFI systems

~ hucktech ~ 4 Comments

Metabolix has written HackBGRT, a tool that changes the Windows boot logo on UEFI systems. It works on Intel 64-bit UEFI systems, with Secure Boot disabled.

“HackBGRT is intended as a boot logo changer for UEFI-based Windows systems. When booting on a UEFI-based computer, Windows may show a vendor-defined logo which is stored on the UEFI firmware in a section called Boot Graphics Resource Table (BGRT). It’s usually very difficult to change the image permamently, but a custom UEFI application may be used to overwrite it during the boot. HackBGRT does exactly that. Important: If you mess up the installation, your system may become unbootable! Create a rescue disk before use. This software comes with no warranty. Use at your own risk.” […]

https://github.com/Metabolix/HackBGRT

DarkReading article on firmware protection

~ hucktech ~ Leave a comment

Yuriy and John of the Intel CHIPSEC team are quoted in a new Dark Reading article on firmware security.

[…] Yuriy Bulygin and John Loucaides, security researchers at Intel Security, point out that hackers attack firmware because they know many security and IT managers aren’t paying attention to it. They say security teams are so overwhelmed by the prevailing threat landscape, that they have their hands full just deploying the basics, like firewalls, intrusion prevention systems and sandboxes. […]

http://www.darkreading.com/iot/5-tips-for-protecting-firmware-from-attacks/d/d-id/1325604

Trapezoid

~ hucktech ~ Leave a comment

I recently learned about Trapezoid, a Florida-area company who apparently sells a commercial firmware product. Unclear which platform(s) and what cost, you have to contact them for any useful information.

Trapezoid® Firmware Integrity Verification Engine is the first integrity monitoring solution designed to detect and alert on attacks and malware affecting BIOS and firmware.

Detect: Trapezoid’s patented Marker tagging technology combines hardware specific data and user defined policy attributes to remotely attest to the identity and integrity of the monitored hardware, detect unauthorized changes to firmware, forensically map virtual machines to physical hardware, and define workload and data boundaries.

Analyze: Trapezoid’s Firmware Integrity Verification Engine proactively identifies and analyzes the integrity of physical devices in the IT infrastructure and creates a full audit trail of virtual assets that associated with those devices.

Remediate: Trapezoid integrates with leading security policy management and reporting tools allowing you to incorporate firmware integrity monitoring into your existing security and compliance framework to address unauthorized changes in firmware.

Our patented Trapezoid® Marker and flexible architecture supporting ANY type of firmware also make Trapezoid the ideal first line of firmware defense for OEMs.

The Trapezoid leadership team is comprised of seasoned security and legal professionals from Terremark (now a Verizon company) with extensive experience in incident response, data center security, security operations, cloud security, risk management and compliance.

Home

ubuntu-secure-boot package

~ hucktech ~ Leave a comment

James Johnson has a project to help make Secure Boot on Ubuntu. Excerpt of readme:

ubuntu-secure-boot package

The stock Ubuntu 15.10 installation only implements secure boot just enough to get a Microsoft-signed shim in place.  It does nothing to actually secure the boot process.  This package can help users do so.

Features of ubuntu-secure-boot:
* Self-signed bootloader files: take control over your boot process by stripping Canonical / Microsoft signatures from your boot files and signing everything yourself.
* Summary of files that are digitally signed and verified during the boot process are:
    * GRUB itself (self-signed)
    * GRUB configuration (self-signed)
    * GRUB modules and other external files (self-signed)
    * Linux kernel (self-signed)
    * Linux initramfs / initrd (self-signed)
    * Linux kernel modules (using existing Canonical signatures)
* Self-signed private keys are stored in /etc/ubuntu-secure-boot/keys and protected by a passphrase.
* UEFI Secure Boot self-signed key pairs are generated and used to sign the self-contained GRUB .efi image.  They can be imported into a UEFI firmware  to take full control over the secure boot process.
* The secure GRUB image is added as a boot option in EFI firmware.
* Digital signature support in GRUB is enabled to check signatures on any boot file that is loaded from disk.  The risk of loading an unsigned file from GRUB is eliminated (e.g. an unsigned kernel).
* GRUB is now deployed as a stand-alone .efi image that contains a memdisk with the full configuration and all loadable modules.  This eliminates the risk of tampering with the GRUB configuration.
* GRUB is automatically locked down with a password so that users cannot tamper with boot settings or use advanced boot options.
* Unsigned GRUB files in /boot remaining from the original GRUB packages are completely wiped (but restored upon uninstall of this package).
* Newly-installed kernels are automatically signed whenever they are installed. Existing Canonical .efi signatures in the linux-signed-image-* packages are stripped and replaced with your signature.
* The initramfs is automatically re-signed whenever update-initramfs is run.
* Linux kernel module signing enforcement is automatically enabled by default. This can be controlled from /etc/default/grub.d/ubuntu-secure-boot.cfg.

https://github.com/JohnstonJ/ubuntu-secure-boot

UEFIOP

~ hucktech ~ Leave a comment

Ivan Hu of Canonical has two related projects on Github, UEFIOP and EFI_runtime, the former app depends on the latter Linux kernel driver:

The uefiop is an application that allows users to manipulate UEFI runtime interfaces provided by Bios at runtime. Current capabilities:
 * set and delete uefi variables

The Efi_runtime kernel driver module aims to provide the interfaces for fwts (firmware test suite) to test the UEFI Runtime services provide by firmware. Current capabilities:
 * provide the RT service interfaces:
 * GetVariable
 * SetVariable
 * GetTime
 * SetTime
 * GetWakeupTime
 * SetWakeupTime
 * GetNextVariableName

https://github.com/Ivanhu5866/uefiop
https://github.com/Ivanhu5866/efi_runtime

Marvel Universe version of UEFI :-)

~ hucktech ~ Leave a comment

Marvel’s Agents of S.H.I.E.L.D. apparently has another form of UEFI:

“This is called a Unified Extensible Firmware Interface.”

Video clip:

Transcript:

Triton

~ hucktech ~ Leave a comment

“Triton is a dynamic binary analysis (DBA) framework. It provides internal components like a Dynamic Symbolic Execution (DSE) engine, a Taint Engine, AST representations of the x86 and the x86-64 instructions set semantics, SMT simplification passes, a SMT Solver Interface and, the last but not least, Python bindings. Based on these components, you are able to build program analysis tools, automate reverse engineering and perform software verification”

http://triton.quarkslab.com/blog/What-kind-of-semantics-information-Triton-can-provide/
http://triton.quarkslab.com/

FWTS 16.05.01 released

~ hucktech ~ Leave a comment

Alex Hung of Canonical has announced the 16.05.01 release of FWTS, the FirmWare Test Suite.

There are new ACPI and IPMI and TCG OVAL and Linux device-tree tests. In addition to new features, there’s an even larger list of bugfixes for most classes (UEFI, BIOS, ACPI, etc.) of tools, not excerpted below, see the full announcement for those.

New Features:
  * acpi: add MSCT table sanity check
  * acpi: add EINJ table sanity check
  * ACPICA: Update to version 20160318 (LP: #1559312)
  * Introduce olog scan, to check OPAL msglog.
  * Introduce IPMI BMC Info
  * devicetree: add infrastructure for device-tree tests
  * devicetree/dt_sysinfo: Add device tree system information tests
  * devicetree/dt_base: Add base device-tree validity checks
  * debian/control: change depends on libjson0-dev to libjson-c-dev
  * auto-packager: mkpackage.sh: add yakkety and remove vivid
  * debian/control: add back libjson0-dev for precise

http://fwts.ubuntu.com/release/fwts-V16.05.01.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/16.05.01
https://launchpad.net/ubuntu/+source/fwts

AMD’s IVRS ACPI table

~ hucktech ~ Leave a comment

I just noticed this March-era update to the UEFI list of ACPI specs. It is a large, well-written spec, compared to some of the recent ACPI specs I’ve looked at.

I/O Virtualization Reporting Structure (IVRS)

This document describes AMD I/O Virtualization Technology. AMD I/O Virtualization Technology is embodied in the system-level function called the I/O Memory Management Unit (IOMMU). This document provides the IOMMU behavioral definition and associated design notes. It is intended for the use of system designers, chipset designers, and programmers involved in the development of low-level BIOS (basic input/output system) functions, drivers, operating system kernel modules, and virtual machine monitor (VMM) software. The intended user should have prior experience in personal computer design, microprocessor programming, and legacy x86 and AMD64 microprocessor architecture.

Click to access 48882_IOMMU.pdf

http://uefi.org/acpi

PolyHook

~ hucktech ~ Leave a comment

It is great to see a new Capstone-based project, like this.

PolyHook – The C++11 x86/x64 Hooking Library: A modern, universal, c++ hooking library. It’s often useful to modify the behavior of an application at runtime when access to the source code is not available. To do this people have traditionally relied on libraries such as Microsoft Detours, Minhook, and a few others. Each of these libraries has significant drawbacks however. Detours is x86 only unless a ‘Professional’ liscense is used, but that costs USD $10000. Minhook is pretty good but i relies on pre crafted trampoline routines, sometimes fails to hook, and the source code is overly bloated. To me there was only one real solution, write my own library, on my own terms, with the goal of being the smallest, cleanest, easiest hooking library in existance! […]

https://github.com/stevemk14ebr/PolyHook
http://www.codeproject.com/Articles/1100579/PolyHook-The-Cplusplus-x-x-Hooking-Library

UEFI != DRM?

~ hucktech ~ 1 Comment

<soapbox>

https://twitter.com/Intel_UEFI/status/732295351672012800

 

LOL. 🙂

This argument is still happening because while UEFI may not explicitly be a mechanism of DRM, a UEFI vendor can use UEFI as a form of UEFI. Rubber hoses were designed for spraying water, but they are also used as a weapon. OS vendors who are also OEMs can use UEFI to bind their HW to their OS, something that could not be done with an earlier BIOS-based firmware, due to the additional security. UEFI’s Secure Boot security can be used to protect the manufacturer’s interests, or the  owner-user’s interests, and those are not the same. 😦

I think there should be 2 classes of systems, one which the owner can control (General Purpose Computing), and one which the manufacturer controls (Secure Specialized Systems). The latter systems can be used in banks and a subset of embedded systems. Citizen-consumers should be able to purchase a system that they can control. The NIST secure BIOS guidelines permit owners to control their own systems locally, but Secure Boot implementations often do not permit owners that same control.  Don’t let fear of malware let manufacturers develop systems you cannot control.

</soapbox>