Month: March 2017

John Deere tractors and cracked firmware

~ hucktech ~ Leave a comment

US farmers are asking for open source tractor hardware and firmware, resorting to using aftermarket firmware:

[…]A license agreement John Deere required farmers to sign in October forbids nearly all repair and modification to farming equipment, and prevents farmers from suing for “crop loss, lost profits, loss of goodwill, loss of use of equipment … arising from the performance or non-performance of any aspect of the software.” The agreement applies to anyone who turns the key or otherwise uses a John Deere tractor with embedded software. It means that only John Deere dealerships and “authorized” repair shops can work on newer tractors.[…]

[…]  I went searching for one of the forums where pirated John Deere firmware is sold. After I found it, I couldn’t do much of anything without joining. I was sent an email with instructions, which required me to buy a $25 dummy diagnostic part from a third-party website. Instead of the part, I was sent a code to join the forum. Once I was on it, I found dozens of threads from farmers desperate to fix and modify their own tractors. According to people on the forums and the farmers who use it, much of the software is cracked in Eastern European countries such as Poland and Ukraine and then sold back to farmers in the United States.[…]

[…] Farmers worry what will happen if John Deere is bought by another company, or what will happen if the company decides to stop servicing its tractors. And so they have taken matters into their own hands by taking control of the software themselves. “What happens in 20 years when there’s a new tractor out and John Deere doesn’t want to fix these anymore?” the farmer using Ukrainian software told me. “Are we supposed to throw the tractor in the garbage, or what?”[…]

https://motherboard.vice.com/en_us/article/why-american-farmers-are-hacking-their-tractors-with-ukrainian-firmware

Companies actively contributing to U-Boot

~ hucktech ~ Leave a comment

Here are some statistics on the U-Boot project, from a U-Boot list posting by Wolfgang Denk of DENX Software Engineering. The Full List is at the below URL. The subset list below are just the top contributing companies. The posting by Wolfgang also shows the top individuals.

Processed 664 csets from 126 developers
26 employers found
A total of 41330 lines added, 31385 removed (delta 9945)

Top changeset contributors by employer
(Unknown)                  170 (25.6%)
Socionext Inc.             105 (15.8%)
Google, Inc.                88 (13.3%)
NXP                         80 (12.0%)
Konsulko Group              42 (6.3%)
Texas Instruments           28 (4.2%)
Samsung                     26 (3.9%)
Xilinx                      26 (3.9%)
ARM                         20 (3.0%)
DENX Software Engineering   14 (2.1%)
…

Top lines changed by employer
Konsulko Group            21331 (35.5%)
(Unknown)                 8685 (14.4%)
Socionext Inc.            8227 (13.7%)
NXP                       8112 (13.5%)
Google, Inc.              5308 (8.8%)
DENX Software Engineering 1904 (3.2%)
ST Microelectronics       1801 (3.0%)
Openedev                  1105 (1.8%)
Samsung                    866 (1.4%)
CompuLab                   844 (1.4%)
…

Employers with the most signoffs (total 111)
NXP                         28 (25.2%)
Xilinx                      16 (14.4%)
DENX Software Engineering   15 (13.5%)
Samsung                     13 (11.7%)
(Unknown)                    9 (8.1%)
Google, Inc.                 9 (8.1%)
Collabora Ltd.               6 (5.4%)
ARM                          5 (4.5%)
Intel                        4 (3.6%)
Socionext Inc.               3 (2.7%)
…

Employers with the most hackers (total 128)
(Unknown)                   65 (50.8%)
NXP                         17 (13.3%)
Texas Instruments            7 (5.5%)
Xilinx                       4 (3.1%)
DENX Software Engineering    4 (3.1%)
Google, Inc.                 3 (2.3%)
Intel                        3 (2.3%)
Socionext Inc.               3 (2.3%)
Samsung                      2 (1.6%)
Collabora Ltd.               2 (1.6%)
…

More info:

http://www.denx.de/wiki/U-Boot/UbootStat_2017_03
https://lists.denx.de/listinfo/u-boot

Intel Optane

~ hucktech ~ Leave a comment

Intel launched Optane hardware recently, and there are a few Optane-related blog posts on Intel.com:

https://newsroom.intel.com/news/intel-introduces-worlds-most-responsive-data-center-solid-state-drive/

“New era of memory and it’s not a DRAM. I believe March 19th, 2017 is one of the most exiting days in the Non-Volatile industry when Intel® Optane™ SSD DC P4800X was introduced.[…]”

http://itpeernetwork.intel.com/optane-intel-memory-drive-technology

http://itpeernetwork.intel.com/intel-optane-ssds-aerospike-new-level-fast

http://itpeernetwork.intel.com/applying-intel-optane-ssds-to-mysql-part-1-fast-storage/

http://www.intel.com/content/www/us/en/architecture-and-technology/intel-optane-technology.html

mcuboot

~ hucktech ~ Leave a comment

MCUBoot is a secure bootloader for 32-bit MCUs. The goal of MCUBoot is to define a common infrastructure for the bootloader, system flash layout on microcontroller systems, and to provide a secure bootloader that enables easy software upgrade. MCUboot is operating system and hardware independent, and relies on hardware porting layers from the operating system it works with. Currently mcuboot works with both the Apache Mynewt, and Zephyr operating systems, but more ports are planned in the future. The MCUBoot project was originally taken from the Apache Mynewt operating system, which had secure boot and software upgrade functionality instrinsic to it. Currently development is heads down on a first release of MCUboot that works across both the Zephyr operating system and Apache Mynewt operating system.[…]

https://github.com/runtimeco/mcuboot

http://connect.linaro.org/resource/bud17/bud17-100/

AMD updated AGESA?

~ hucktech ~ Leave a comment

There are news reports that AMD AGESA has been updated. AMD has a developer section on their web site, but I wish they included a section with news on AGESA, like Intel FSP site does.

https://www.dvhardware.net/article66244.html
https://www.bit-tech.net/news/hardware/2017/03/21/amd-ryzen-fma3-fix-promise/1
https://www.overclock3d.net/news/cpu_mainboard/amd_has_reportedly_released_new_agesa_microcode_for_ryzen/1
https://www.hardocp.com/news/2017/03/20/new_amd_agesa_microcode_in_wild_uefi

https://en.wikipedia.org/wiki/AGESA

New AMD AGESA Microcode in the Wild & New UEFI
byu/5larm inAmd

airline industry and device physical security

~ hucktech ~ Leave a comment

Welcome to Travel 2.0, where all devices are now required to go through a potential Evil Maid Attack by the TSA equivalent of government of each travel you visit, starting with the US. 😦

http://gizmodo.com/the-us-may-have-banned-electronics-on-middle-eastern-fl-1793457809

http://onemileatatime.boardingarea.com/2017/03/20/airplane-electronics-ban/

http://www.usatoday.com/story/travel/flights/todayinthesky/2017/03/20/airline-electronic-devices-prohibited-cabin/99417832/

http://www.marketwatch.com/story/most-electronic-devices-banned-on-certain-us-flights-from-middle-east-africa-2017-03-20

http://www.reuters.com/article/us-usa-airlines-electronics-idUSKBN16R2JN

 

Intel Israel seeks Security Researcher

~ hucktech ~ Leave a comment

[…] Do you want to get your hands on the most cutting edge technology before it reaches the Market? Intel’s SW group is looking for a talented Security Researcher. In this position you will work on ensuring security aspects of Intel software and firmware products. You will be a member of the security evaluation team, located in Haifa, encompassing all aspects of the architecture, design and implementation. How your day will look like (when you are not working on your own personal initiatives) :Identify flaws and vulnerabilities in complex secure systems.Reverse engineering and white box SW analysis.Working with software, hardware, embedded systems, cryptography etc. […]

http://jobs.intel.com/ShowJob/Id/1038620/Security%20Researcher%20%20Software%20Group

LUV announces v2.1-rc2 release

~ hucktech ~ Leave a comment

Ricardo Neri of Intel posted a LONG announcement about LUV V2.1-rc2, most of which included here. There are a LOT of new features in this LUV release!

This is to announce the release of LUV v2.1-rc2. It has been a while since the last time of our last release. This is not the ideal release cadence are working to make changes. We will now release more frequently. We aim to release a new version every 4-5 weeks with the content we accumulate over that period of time. Given the large number of new features and changes in this release, it made sense to release it as rc2 of v2.1 to allow for issues to arise and stabilize towards the next release cycle.

This release include the client side of our telemetrics solution. This solution is based on the implementation done for Clear Linux[1]; abiding Intel privacy policies[2]. Please note that telemetrics is an opt-in feature and is disabled by default and only works for systems within Intel networks. We will work now on the server side of the solution.

In this release we have migrated from systemV to systemd, which is inline with most Linux distributions. Also, our telemetrics client needed it to function. Megha Dey did all the heavy lifting to migrate to systemd; which was not an easy task (kudos to her!). She worked on stabilizing network and revamping our splash screen, which now uses plymouth.

Sai Praneeth Prakhya extended our existing implementation to detect illegal access to UEFI Boot Services memory regions after boot. His extension now allows to detect such access to also conventional memory. Likewise, it now detects these acceses at runtime and long after UEFI SetVirtualAddressMap. This has been quite useful recently to detect bugs related to UEFI capsules in certain firmware implementations.

Gayatri Kammela worked on providing tools to make the netboot images more useful. She completed a reference implementation of an HTTP server to collect test results in a test farm. The documentation of this implementation can be found here[2]; we don’t provide collection services. Of course, the client-side implementation of this solution is part of this release. Along with this solution, she wrote a script to customize a netboot binary (an EFI application) to work with her reference implementation[4].

Naresh Bhat updated the kernel configuration for aarch64. He also worked on providing a more clean, unified and structured kernel command line for all the supported CPU architectures. He also enabled support of netboot images for aarch64.

Fathi Boudra kindly reworked the kernel configuration fragments to avoid unnecessary duplications.

Matt Hart added a new luv.poweroff option.

Configuration of LUV has been simplified by moving all the parameters that the user might configure a LUV.cfg file found in the boot partition of the disk image. No more meddling with the grub.cfg configuration file.

We now provide images built for both GPT and MBR partition schemes.

Updated test suites: We include FWTS V17.03.00, CHIPSEC v1.2.5 plus all the changes available as of this week towards the release of v.1.2.6, which should be coming soon. BITS was bumped to v2079. We use Linux v4.10. This release is based on the Morty version of the Yocto Project.

meta-oe and updates to the build process: Our build process changed a bit. We now include certain components from the  meta-oe layer[5]. Such layer has been added to our repository, but it still need to be added locally to the build/conf/bblayers.conf file when building.

Binary images for x86: A announcement to download binary images for x86 will be sent this week.

See rest of announcement for list of Known Issues, and Fixed Issues.

[1] https://clearlinux.org/features/telemetry
[2] http://www.intel.com/content/www/us/en/privacy/intel-privacy.html
[3] https://github.com/01org/luv-yocto/wiki/Send–LUV-test-results-to-an-HTTP-server
[4] https://github.com/01org/luv-yocto/wiki/Using-LUV-Script-modify_luv_netboot_efi.py
[5] https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/

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

proposed driver model for U-Boot init

~ hucktech ~ Leave a comment

Simon Glass of Chromium posted an 16-part patch to the U-Boot list, adding a driver model to the U-Boot init sequence.

[PATCH 00/16] RFC: Board init using driver model

At present we have a lot of ad-hoc init functions related to boards, for example board_early_init_f(), board_misc_init_f() and dram_init(). There are used in different ways by different boards as useful hooks to do the required init and sequence it correctly. Some functions are always enabled but have a __weak default. Some are controlled by the existence of a CONFIG. There are two main init sequences: board_init_f() (f for running from read-only flash) which runs before relocation and board_init_r() (r for relocated) which runs afterwards. One problem with the current sequence is that it has a lot of arch-specific #ifdefs around various functions. There are also #ifdefs for various features. There has been quite a bit of discussion about how to tidy this up and at least one RFC series[1].

Now that we have driver model we can use this to deal with the init sequences. This approach has several advantages:
– We have a path to remove the #ifdefs
– It is easy for multiple parts of the code to implement the same hook
– We can track what is called and what is not
– We don’t need weak functions
– We can eventually adjust the sequence to improve naming or to add new init phases
– It provides a model for how we might deal with ft_board_setup() and friends

This series starts the process of replacing the pre-relocation init sequence with a driver-model solution. It defines a uclass, adds tests and converts sandbox and a few x86 boards over to use this new setup. This series is not ready for use yet as the rest of the init sequence hooks need to be converted. But there is enough here to show the idea.

Comments welcome.

[1] https://lists.denx.de/pipermail/u-boot/2011-August/098718.html

37 files changed, 980 insertions(+), 45 deletions(-)
[…]
create mode 100644 doc/driver-model/board-info.txt
[…]

More information:
https://lists.denx.de/listinfo/u-boot

SELoader: Secure EFI Loader

~ hucktech ~ Leave a comment

Secure EFI Loader
The SELoader is designed to authenticate the non-PE files which cannot be verified by the MOK verify protocol supplied by shim loader, such as grub configuration, initrd, grub modules and so on. The SELoader employs PKCS7 Verify Protocol available since UEFI Specification version 2.5 to verify the signature to prove the integrity of checked file. If BIOS doesn’t support it, a pre-built Pkcs7VerifyDxe driver is provided. In order to estabilish the chain of trust, the SELoader is required to be signed by a private key corresponding to a DB certificate, the shim certificate, the vendor certificate or a shim MOK certificate. The specifical key is determined by the Secure Boot scheme you will use. Using UEFI Secure Boot, MOK verify protocol and SELoader Secure Boot together, the boot process will be completely trustworthy.

https://github.com/jiazhang0/SELoader

CHIPSEC gets new MMIO BAR module

~ hucktech ~ Leave a comment

Experimental module that may help checking SMM firmware for MMIO BAR hijacking
vulnerabilities described in the following presentation:
`BARing the System: New vulnerabilities in Coreboot & UEFI based systems <http://www.intelsecurity.com/advanced-threat-research/content/data/REConBrussels2017_BARing_the_system.pdf&gt;`_ by Intel Advanced Threat Research team at RECon Brussels 2017
Usage:
  “chipsec_main -m tools.smm.rogue_mmio_bar [-a <smi_start:smi_end>,<b:d.f>]“
 
– “smi_start:smi_end“: range of SMI codes (written to IO port 0xB2)
– “b:d.f“: PCIe bus/device/function in b:d.f format (in hex)
Example:
    >>> chipsec_main.py -m tools.smm.rogue_mmio_bar -a 0x00:0x80
    >>> chipsec_main.py -m tools.smm.rogue_mmio_bar -a 0x00:0xFF,0:1C.0

 

EFI TBOOT

~ hucktech ~ Leave a comment

The EFI TBOOT project is currently under development! EFI TBOOT is mostly a proof of concept at this point. It is not currently functional. It can be built and installed as an EFI boot loader. It only works in conjunction with Xen at the moment. The current development work is being done on Fedora 25 x64. The status as of March 14, 2017 is:
 – EFI TBOOT will boot, but it needs a few key strokes to get going (this is for debugging purposes).
 – EFI TBOOT will relocate itself to EFI runtime memory and setup a shared runtime variable with Xen.
 – EFI related configuration setup is done as well as standard TBOOT pre-launch configuration.
 – Xen is launched and has code to call EFI TBOOT back after EBS.
 – EFI TBOOT then does the SENTER successfully in the callback.
 – The post launch entry point is reached but the switch back to long mode is not working.
[…]
EFI TBOOT needs a number of platform support files used with TXT (called Authenticated Code Modules or ACMs). For convenience the packages can be gotten from the OpenXT mirror:
http://mirror.openxt.org/
[…]

https://github.com/rossphilipson/efi-tboot

Hardware.io 2017 CFP is open

~ hucktech ~ Leave a comment

Security Conference is a platform for hardware and security community where researchers showcase and discuss their innovative research on attacking and defending hardware. The objective of the conference revolves around four key concerns in hardware, firmware and related protocols i.e. backdoors, exploits, trust and attacks (BETA).

Training: 19th – 20th Sept 2017
Conference: 21st – 22nd Sept 2017
http://hardwear.io/

 

FWTS 17.03.00 released

~ hucktech ~ Leave a comment

Ivan Hu of Canonical announced the release of FWTS 17.03.00. There’s a new SBBR test, and a slew of bugfixes.

New Features :
  * ACPICA: Update to version 20170224
  * sbbr: Add “–sbbr” flag to support running SBBR Tests.
  * acpi: iort: Add support for SMMUv3

http://fwts.ubuntu.com/release/fwts-V17.03.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/17.03.00
https://launchpad.net/ubuntu/+source/fwts
https://lists.01.org/mailman/listinfo/luv

https://community.arm.com/iot/b/blog/posts/arm-server-standards-part-2-sbbr-specification-released