Category: Uncategorized

FirmWalker and FirmDump

~ hucktech ~ Leave a comment

https://github.com/craigz28/firmwalker

firmwalker

A simple bash script for searching the extracted or mounted firmware file system.

It will search through the extracted or mounted firmware file system for things of interest such as:

    etc/shadow and etc/passwd
    list out the etc/ssl directory
    search for SSL related files such as .pem, .crt, etc.
    search for configuration files
    look for script files
    search for other .bin files
    look for keywords such as admin, password, remote, etc.
    search for common web servers used on IoT devices

firmdump (coming soon)

A script which attempts to extract the file system of a firmware file and then runs firmwalker to search for goodies in the extracted files system

https://github.com/craigz28/firmdump

 

Brian Richardson on UEFI hacker tools

~ hucktech ~ Leave a comment

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

Brian Richardson of Intel has a new blog out talking about UEFI hacking tools in general, and UEFI Tool in particular, and he mentions this blog! 🙂 (This reminds me, I need to create a list of tools that I promised earlier. Give me a few days and I’ll create a new blog on that…)

“This is where my friends in firmware development and validation need to pay attention, because these tools can be your friend or your enemy. It’s great to use UEFITool for testing firmware images, making sure contents are properly formatted and verifying changes between version updated. However, it’s also an easy way for someone you don’t like to try and insert malicious code into your product.”

http://blogs.intel.com/evangelists/2016/02/16/uefi-tools-theyre-not-just-for-hackers-anymore/

CHIPSEC training at TROOPERS

~ hucktech ~ Leave a comment

The Intel CHIPSEC team doesn’t get out much to give training to the public often, so this upcoming 2-day of CHIPSEC training at TROOPERS is nice!

Security below the OS with CHIPSEC framework
Oleksandr Bazhaniuk, Yuriy Bulygin

A variety of attacks targeting platform firmware have been discussed publicly, drawing attention to the pre-boot and firmware components of the platform such as BIOS and SMM, UEFI secure boot and OS loaders. This workshop provides a hands-on opportunity to learn how to use an open source CHIPSEC framework https://github.com/chipsec/chipsec to test systems for vulnerabilities in low-level platform firmware components, problems with firmware security protections as well as develop your own modules in CHIPSEC which test for known issues or implement tools identifying new issues. Agenda:

* Introduction to platform hardware and access with CHIPSEC
* Introduction to platform firmware such as BIOS, UEFI firmware, SMI handlers
* Overview of main components of CHIPSEC framework
* Analyzing main firmware components and configuration
* Assessing systems for vulnerabilities in the BIOS and other firmware
* Developing vulnerability testing modules
* Developing fuzzers for firmware interfaces and other security tools
* BIOS forensics with CHIPSEC

https://www.troopers.de/events/troopers16/567_security_below_the_os_with_chipsec_framework/

LUV gets network boot support

~ hucktech ~ Leave a comment

Ricardo Neri of Intel submitted a 13-part patch to LUV, to add network boot support. Hurray, remote boot option, instead of a local-only boot media! Excerpt from patch’s comments:

This patch series intend to add support to but LUV from the network. This is a fairly complex patchset and comprises several domains:

== Preparation work
Patch 01 prepares from the LUV test manager to boot from the network by removing all the assumptions that it was booting from a disk.

Patch 02. When booting from the network, BITS will not have a disk on which save its results. Thus, we drop support for results logging in physical disk and rely completely on CPIO archives passed to Linux as ramdisks [1]. This change should not impact disk boots.

== Support for shared memdisks
Patches [03-07]. The bulk of the work for network but is in provisioning GRUB to share a memkdisk. BITS runs as a chainloaded GRUB image from LUV GRUB. BITS saves its results on the disk that is then visible to LUV GRUB and Linux. When booting from the network, we don’t have a disk to which write and we must rely on a memdisk.

The EFI Loaded Image protocol interface structure described in the UEFI specification contains a LoadOptions member that can be used to obtain data that is relevant to the loaded image. On the LUV GRUB side, the EFI chainloader is modified to pass to the loaded image not only command-line parameters but binary data: a handle to the LUV GRUB memdisk. This is a safe operation since memory for the disk is allocated via the UEFI AllocatePages call and will also be visible to the chainloaded image. In the BITS GRUB side, functionalty is added to parse the contents of the LoadOptions member of the EFI Loaded Image protocyol structure. If a memdisk is added, it will be used.

== Support bitbake builds for both disk and network boot ==
Patches [08-13]. Images for network both and disk boot are built differently. For instance, when building for network boot, ‘(memdisk)’ needs to be used as root in GRUB. This is not needed for disk boots. Furthermore, when building a disk image, luv-live-image ‘bitbake’-depends on GRUB as the the latter needs to be present at the time of bulding the image. When building for netboot, the dependency is inverted: GRUB depends on the existence of the memdisk filesystem as it will be embedded into the GRUB image.Given all these different build-time configurations, a new distro configuration file is used: luv-netbot.conf. This configuration file is identical to luv.conf but adds the luv-netboot parameter as a DISTRO_FEATURES item to instruct different compilation the aforementioned components.

[1]. https://lists.01.org/pipermail/luv/2016-February/000852.html

More information:
https://lists.01.org/pipermail/luv/2016-February/000895.html

Firmware Mini-Summit announced

~ hucktech ~ Leave a comment

Al Stone of Red Hat has announced the next firmware mini-sumit at Linaro Connect, March in Bankok, Thailand. Excerpt of announcement:

Well, it’s that time of year again. If you’re going to be at Linaro Connect [0] in Bangkok, Thailand on the week of 7-11 March 2016, please drop in to the firmware mini-summit to be help Wednesday afternoon (9 March).  The exact time and location at Connect are still to be determined. We’ll have an hour, and so far the topic list is:

   * Update on current status of ACPI patches (PCI, NUMA, CPPC, plans for the next steps)
   * The new FW_OS_Forum mailing list
   * Progress in ACPI compliance testing in FWTS, and future plans
   * _DSD usage yet again
   * Others?

More information:
http://connect.linaro.org
http://lists.mailman.uefi.org/mailman/listinfo/fw_os_forum

GNU/GlibC vulnerable to network traffic

~ hucktech ~ Leave a comment

https://github.com/fjserna/CVE-2015-7547

https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

https://twitter.com/martin_prpic/status/699633897500442624

https://access.redhat.com/articles/2161461

https://twitter.com/msolnik/status/699646671659995136

This is why IoT devices need the ability to have software updates.

F-Secure concerns on IoT firmware

~ hucktech ~ Leave a comment

From Vincent Zimmer’s Twitter feed, there’s a new article by Tom Gaffney, a Security Advisor at F-Secure Corporation on IoT firmware security concerns:

Is Firmware Kryptonite for Routers and the IoT?

The Internet of Things (IoT) promises to capture people’s dreams for a “smart lifestyle” and turn them into a reality. As manufacturers create new devices and product lines that capitalize on the IoT opportunity, they’re coming across a question cyber security professionals ask everyday – how will device security evolve with the IoT? Skeptics have done a good job demonstrating how far there is to go. There’s no shortage of reports about hackable Internet-connected security cameras or smart cars. But looking at small office and home (SOHO) routers can provide the most useful insights into the security issues facing IoT device manufacturers.  […]

This article has a very broad definition for firmware, any software that is on a device. I wish that people would stop using that, and refer to the system firmware, the various peripheral firmware, and the remaining OS/app software on the embedded device.

Full post:

http://www.cedmagazine.com/article/2016/02/firmware-kryptonite-routers-and-iot

 

William Leara reviews UEFI Tool

~ hucktech ~ Leave a comment

William Leara, a firmware engineer at Dell, has a new blog post on Nikolaj Schlej’s UEFI Tool. He shows how to use it, starting with using Intel’s Flash Programing Tool (FPT) to acquire a BIOS image. Lots of screenshots of the various menu UI components of this GUI tool.

“It is extremely useful for interrogating and manipulating the components of a UEFI BIOS image.  Download it and give it a test drive today!”

Full post:
http://www.basicinputoutput.com/2016/02/uefitool.html

efitools now available for ARM

~ hucktech ~ Leave a comment

James Bottomley has a few new blog posts, two on efitools availability for ARM, and another on a container model for UEFI.

efitools for arm released

efitools arm 32 bit build fixed

Constructing Architecture Emulation Containers

[…] the problem: how to build and test efitools for arm and aarch64 while not possessing any physical hardware.  The solution is to build an architecture emulation container using qemu and mount namespaces such that when its entered you find yourself in your home directory but with the rest of Linux running natively (well emulated natively via qemu) as a new architecture.  […] However, there’s a problem here: the installed binary emulator usually runs as /usr/bin/qemu-${arch}, so if you’re running a full operating system container, you can’t install any package that would overwrite that.  Unfortunately for me, the openSUSE Build Service package osc requires qemu-linux-user and would cause the overwrite of the emulator and the failure of the container.  The solution to this was to bind mount the required emulator into the / directory, where it wouldn’t be overwritten and to adjust the binfmt_misc paths accordingly. […]

Constructing Architecture Emulation Containers

build-container

FPMurphy on TPM access via UEFI

~ hucktech ~ Leave a comment

Finnbarr P. Murphy does not blog often, but each post is usually very well written, and often focused on using some UEFI Shell commands to do some specific task. In the current post, the topic is accessing TPM’s features from the UEFI Shell, and it is called “part 1”, with more to come!

“Why an I writing this series of posts? Because there are few published examples of working UEFI code that interacts with a TPM. Such example code is useful to security researchers and computer forensics practitioners.”

http://blog.fpmurphy.com/2016/02/accessing-tpm-functionality-from-uefi-shell-part-1.html

Google’s new People API

~ hucktech ~ Leave a comment

Perhaps slightly off-topic, but I suspect it’ll be used by multiple IoT devices… Excerpting from Eric Zeman’sProgrammableWeb article:

Google today announced the People API, a single API it hopes will eventually be able to replace both the existing Google+ APITrack this API and Google Contacts APITrack this API. The People API will allow developers to snag connection data from authenticated Google users with a single call, rather than multiple calls — and that’s good news for everyone. As Google explains it, the People API will eclipse the Google+ and Contacts APIs because it uses the newest protocols and technologies. The Contacts API, for example, uses the somewhat dated GData protocol. The People API can reach into users’ private contact lists (as long as permitted) to see if those contacts are linked to other, public profiles. Google says properly granted scopes will return results as a people.connections.list object, which can then be used to snag more data about the person in question. In other words, it will allow developers to connect more of the dots that exist between Google users. […]

https://developers.google.com/people/api/rest/
https://people.googleapis.com
https://developers.google.com/people/

Google’s new People API, htop2.0, and OIC’s new developer toolkit—SD Times news digest: Feb. 11, 2016


http://m.androidcentral.com/androids-new-people-api-helps-developers-more-easily-tap-contact-data
https://developers.google.com/+/web/api/rest/latest/people
http://www.programmableweb.com/news/google-people-api-lets-devs-poke-through-users-contacts/2016/02/10

OIC acquires UPnP Forum

~ hucktech ~ Leave a comment

This is not new news, this is old news, from November 2015 I am just catching up to… 😦

“Effective January 1, 2016 the Open Interconnect Consortium (OIC) acquired the assets of the UPnP Forum. The agreement will streamline and consolidate efforts around both organizations’ technologies and infrastructure, leading to increased alignment on standardization for the IoT. As part of the asset transfer, UPnP activities will continue to be advanced within OIC including the UPnP certification program.”

http://openinterconnect.org/
http://www.upnp.org/
http://openinterconnect.org/upnptransfer-faq/
http://openinterconnect.org/oic-news-releases/open-interconnect-consortium-increases-membership-with-upnp-forum-agreement/

Now that standards are the new way for companies to compete, it is fun to watch standards bodies getting acquired. 😐

ARM at EmbeddedWorld

~ hucktech ~ Leave a comment

ARM has a new article out, covering their latest technology they’re showcasing at Embedded World in Germany shortly. There are “26 sessions and 15 classes” on ARM technologies at Embedded World. Even if you aren’t attending this event, the article is a good roadmap to upcoming products by ARM and ARM’s partners.

https://community.arm.com/groups/embedded/blog/2016/02/09/arm-at-embedded-world-2016-a-guide

rappel: assembly REPL

~ hucktech ~ Leave a comment

“Rappel is a pretty janky assembly REPL. It works by creating a shell ELF, starting it under ptrace, then continiously rewriting/running the .text section, while showing the register states. It’s maybe half done right now, and supports Linux x86, amd64, and armv7 (no thumb) at the moment.”

https://github.com/yrp604/rappel

FreeBSD 10.3.beta2’s UEFI changes

~ hucktech ~ Leave a comment

Excerpting Phoronix:

Over the past week were some fixes/improvements around FreeBSD’s UEFI support, “The UEFI ZFS loader has been updated to support the latest ZFS Boot Environment (BE) loader menu features” and “The UEFI boot loader received several improvements: /boot/config and /boot.config files now are adhered to, multi device boot support works and command line argument parsing has been added.”

http://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-10.3-Beta-2
https://lists.freebsd.org/pipermail/freebsd-stable/2016-February/084145.html
https://www.freebsd.org/relnotes/10-STABLE/relnotes/article.html

new EFI-headers project

~ hucktech ~ Leave a comment

teodori-serge has created a new Github project called “EFI-headers” (for C language), with a comment of “EFI headers” (that was the entire comment, no excerpting). It appears to be a new implementation of headers to define UEFI’s interface, not tied to Tianocore’s EDKII or GNU-EFI’s headers. These might become useful if you have to build EFI code outside of EDK2 or GNU-EFI. Maybe one day we’ll figure out what plans teodori-serge has for these…

https://github.com/teodori-serge/efi-headers

Intel Linux Perf team’s 0-Day project

~ hucktech ~ Leave a comment

The Intel open source site, 01.org, hosts the Linux Kernel Perf project, and they have a 0-Day project.

https://twitter.com/mcgrof/status/698175557423362049

[…] The infrastructure we developed to test the Linux kernel is called 0-Day.  It is a service and test framework for automated regression-testing that intercepts kernel development at its earliest stages, and is available to the worldwide Linux kernel community. This project provides a further “shift-left” by testing key developers’ trees before patches move forward in the development process. Some key features of 0-Day are:

* Provides 1-hour response time around the clock, hence the 0-Day name.
* Performs patch-by-patch tests
* Covers all branches of a developer’s tree
* Performs kernel build and static semantics-level testing using industry static source code analyzers
* Performs boot tests, functional and performance tests on a variety of IA-based platforms in our labs
* Bisects code automatically when tests fail, or when performance regresses, enabling us to identify which patch caused the failure.

More info:
https://lists.01.org/mailman/listinfo/lkp
https://01.org/lkp

I just learned about this, and don’t know much about it yet, It sounds interesting, “performs boot tests”. Maybe it is the Intel version of ARM/Linaro’s LAVA?

Matthew Chapman on Lenovo laptop internals

~ hucktech ~ Leave a comment

Matthew Chapman has a nice set of blog posts that go into detail about Lenovo internals, including some firmware and ACPI details, all because of a new battery:

Unlocking my Lenovo laptop, parts 1-3

Two months ago, I bought a new battery for my Lenovo laptop (a ThinkPad X230T). I was about to go away on holidays and wanted a battery that could last me through a plane flight; the original battery was by then barely lasting ten minutes. Little did I know that I was about to […]

In part 1, we looked at the communication between a Lenovo Thinkpad X230T laptop and battery, and discovered that there a challenge-response protocol used to authenticate ‘genuine’ Lenovo batteries. On the laptop side, this – and battery communication in general – is implemented in a component known as the embedded controller (EC). […]

In part 2, we discovered that a embedded controller update is performed by uploading a small ‘flasher’ program to the EC. This flasher program is then responsible for programming a new firmware image to the EC’s internal flash memory. However, both the flasher program and part of the firmware image are encrypted: the old (currently running) EC firmware decrypts the flasher program, and the flasher program then decrypts the new firmware update. This creates a bit of a chicken-and-egg problem that prevents discovering the encryption algorithm from firmware update files alone. […]

Blog series:

Unlocking my Lenovo laptop, part 1

Unlocking my Lenovo laptop, part 2

Unlocking my Lenovo laptop, part 3

Motorola bootlocker unlocking

~ hucktech ~ Leave a comment

Unlocking the Motorola Bootloader

In this blog post, we’ll explore the Motorola bootloader on recent Qualcomm Snapdragon devices. Our goal will be to unlock the bootloader of a Moto X (2nd Gen), by using the TrustZone kernel code execution vulnerability from the previous blog posts. Note that although we will show the complete unlocking process for this specific device, it should be general enough to work at-least for most modern Motorola devices. […]

Full post:
http://bits-please.blogspot.com/2016/02/unlocking-motorola-bootloader.html