Tag Archives: UEFI

CVE-2017-9457: CompuLab Intense PC lacks firmware signature validation

CompuLab have not enabled signature checking of firmware updates for the Intense PC product line. This allows anyone in possession of the Phoenix UEFI update program to write a modified UEFI firmware to system flash. DOS/Windows versions of the Phoenix utility are easily obtained online, allowing a local or remote attacker to install a persistent firmware level rootkit to the computer, or to corrupt the system firmware, causing a denial of service.

Installation of a modified firmware can occur entirely in the background, without any user interaction, and once performed is virtually impossible to difficult to detect using operating system utilities. Physical access is not required.

Product description
The CompuLab Intense PC is fanless mini-PC. A model pre-installed with Linux Mint is also marketed under the name MintBox 2. The system firmware is the same for the Intense PC and MintBox 2. CompuLab also sell the Intense PC with an extended temperature range for industrial applications.

The product was introduced in mid-2013 and is still being sold through Amazon US, Amazon Canada, Amazon Germany, Amazon Spain, and directly from CompuLab.

Affected products

  • Intense PC (Intense PC Value, Intense PC Business, Intense PC Pro)
  • MintBox 2

Any software running with local administrator privileges has unrestricted access to read and write the system’s firmware.

An attacker can modify the contents of the system firmware to install a persistent rootkit/bootkit, or to corrupt the firmware causing the computer to cease functioning.

The attack only requires local administrator privileges, and can be executed either by using an existing OS-level exploit to gain local administrator, or via tricking the user into running an executable (e.g. via an attachment in a phishing email).

Proof of Concept
The proof of concept provided for CVE-2017-8083 can be leveraged for this vulnerability as well. The proof of concept uses the Phoenix UEFI Winflash utility to write a modified firmware to flash. Please refer to the article about CVE-2017-8083 for a detailed description of the proof of concept.

The latest CompuLab firmware for the Intense PC (20170521) modified with the upstream EDKII shell can be downloaded here.

At this time there is no means for the end user to enable Capsule Signature verification or to prevent the Phoenix update utility from updating the system firmware.

Therefore Intense PC owners should consider the following options:

  • Ensure your operating system is up to date with the latest security patches. Do not run software from untrusted sources.
  • Do not connect your Intense PC to any networks with internet access (i.e. air-gap the computer).
  • Discontinue your use of the Intense PC and consider replacing the computer with one from a different manufacturer who implements signature validation for firmware updates.

Should CompuLab decide to improve the security of the Intense PC firmware by enabling Capsule Signature validation, then the above recommendations would no longer apply. However, in my communication with CompuLab regarding this issue no indication was given that they have any plans to enable Capsule Signature verification in a future update. Therefore, it seems very unlikely to me CompuLab will issue an update which enables Capsule Signature verification.

Disclosure timeline:
6 June 2017: Issue reported to CompuLab
6 June 2017: CompuLab confirms that “Default settings of this source tree [Phoenix SecureCore Tiano Enhanced Intel Ivy Bridge CPU Panther Point M] has disabled Capsule Signature option.”
6 June 2017: Issue is reported to MITRE
6 June 2017: Vulnerability is assigned CVE-2017-9457
7 June 2017: CompuLab are informed that the vulnerability has been assigned CVE-2017-9457 and details of the vulnerability will be published after 45 days

CVE-2017-8083: Intense PC lacks BIOS Write Protection

CompuLab Intense PC and MintBox 2 fail to properly write protect flash regions, allowing an attacker with local administrator privileges to write arbitrary code to the platform firmware. This could allow a remote attacker to install a persistent firmware level rootkit to the computer, or to erase the system firmware, causing a denial of service.

Installation of a modified firmware can occur entirely in the background, without any user interaction, and once performed is virtually impossible to difficult to detect using operating system utilities. Physical access is not required.

Product description
The CompuLab Intense PC is fanless mini-PC. A model pre-installed with Linux Mint is also marketed under the name MintBox 2. The system firmware is the same for the Intense PC and MintBox 2. CompuLab also sell the Intense PC with an extended temperature range for industrial applications.

The product was introduced in mid-2013 and is still being sold through Amazon US, Amazon Canada, Amazon Germany, Amazon Spain, and directly from CompuLab.

Affected products

  • Intense PC (Intense PC Value, Intense PC Business, Intense PC Pro)
  • MintBox 2

At the time of discovery in March 2017, the latest firmware for CompuLab was dated 21 June 2016, and did not enable write protection on any flash regions.

Any software running with local administrator privileges has unrestricted access to read and write the system’s firmware.

An attacker can modify the contents of the system firmware to install a persistent rootkit/bootkit, or to corrupt the firmware causing the computer to cease functioning.

The attack only requires local administrator privileges, and can be executed either by using an existing OS-level exploit to gain local administrator, or via tricking the user into running an executable (e.g. via an attachment in a phishing email).

Proof of Concept
The firmware update from CompuLab was downloaded, decompressed, and loaded into UEFITool.

The default UEFI shell provided in Phoenix SecureCore was replaced with a newer version of the UEFI shell from EDK2:

The Phoenix SecureCore UEFI Shell was replaced with the EDK2 UEFI Shell.

The modified update was then written to the system firmware using the Phoenix UEFI Winflash utility:

Phoenix UEFI Winflash

It was later realized that the Phoenix UEFI Winflash utility includes a flag enabling a silent firmware update from the command line:

Phoenix UEFI Winflash supports silently updating the firmware from the command line

Using the /remote2 option removes all visual notifications that a firmware update is in progress. Additionally, when used with /console or /remote2 options, the Winflash utility does not reboot the platform when finished. The system continues to function normally, and there is no indication to the user that a firmware update has taken place at all.

Additional information
Output of the chipsec utility:

python chipsec_main.py -m common.bios_wp
## ##
## CHIPSEC: Platform Hardware Security Assessment Framework ##
## ##
[CHIPSEC] Version 1.3.0
[CHIPSEC] Arguments: -m common.bios_wp

WARNING: *******************************************************************
WARNING: Chipsec should only be used on test systems!
WARNING: It should not be installed/deployed on production end-user systems.
WARNING: *******************************************************************

[CHIPSEC] API mode: using CHIPSEC kernel module API
[CHIPSEC] OS : Windows 8.1 6.3.9600 AMD64
[CHIPSEC] Platform: Mobile 3rd Generation Core Processor (Ivy Bridge CPU / Panth
er Point PCH)

[+] loaded chipsec.modules.common.bios_wp
[*] running loaded modules ..

[*] running module: chipsec.modules.common.bios_wp
[x][ =======================================================================
[x][ Module: BIOS Region Write Protection
[x][ =======================================================================
[*] BC = 0x08 << BIOS Control (b:d.f 00:31.0 + 0xDC)
[00] BIOSWE = 0 << BIOS Write Enable
[01] BLE = 0 << BIOS Lock Enable
[02] SRC = 2 << SPI Read Configuration
[04] TSS = 0 << Top Swap Status
[05] SMM_BWP = 0 << SMM BIOS Write Protection
[-] BIOS region write protection is disabled!

[*] BIOS Region: Base = 0x00D00000, Limit = 0x00FFFFFF
SPI Protected Ranges
PRx (offset) | Value | Base | Limit | WP? | RP?
PR0 (74) | 00000000 | 00000000 | 00000000 | 0 | 0
PR1 (78) | 00000000 | 00000000 | 00000000 | 0 | 0
PR2 (7C) | 00000000 | 00000000 | 00000000 | 0 | 0
PR3 (80) | 00000000 | 00000000 | 00000000 | 0 | 0
PR4 (84) | 00000000 | 00000000 | 00000000 | 0 | 0

[!] None of the SPI protected ranges write-protect BIOS region

[!] BIOS should enable all available SMM based write protection mechanisms or co
nfigure SPI protected ranges to protect the entire BIOS region
[-] FAILED: BIOS is NOT protected completely

Output of the Intel Flash Programming Tool (FPT):

Intel’s fpt utility showing full write access to flash regions on the Intense PC

Through my discussion with CompuLab support, it has emerged that the issue is due to CompuLab not running CloseMnf prior to shipping. CloseMnf stands for “Close of Manufacturing” and hardens the system by setting write-protect flags for the various flash regions in the Master Access Section of the Descriptor Region.

Intel documentation regarding CloseMnf:

Disclosure timeline:
1 March 2017: Vulnerability is reported to CompuLab via their support email address
2 March 2017: CompuLab replies they will create a beta BIOS to address the vulnerability
6 March 2017: I request a timeline to fix the issue
7 March 2017: CompuLab replies they will create a beta BIOS for testing and they “will provide an official public release in the future”
8 March 2017: CompuLab replies with instructions to run closemnf via the Intel FPT tool
8 March 2017: I inform CompuLab I am waiting for the official BIOS update to resolve the issue
8 March 2017: CompuLab replies with copy of Intel FPT tool and requests “not to publish or disclose this information”
8 March 2017: CompuLab is informed that details of the vulnerability will be published on 4 June 2017
23 April 2017: Issue is reported to MITRE
24 April 2017: Vulnerability is assigned CVE-2017-8083
3 May 2017: CompuLab communicates that they will delay fixing this vulnerability until Intel provides an updated ME firmware to address CVE-2017-5689
4 May 2017: I inform CompuLab that details of this vulnerability will be published on 4 June 2017 as previously discussed
11 May 2017: CompuLab sends a proposed fix for testing, the update script fails due to invalid command syntax for flashrom
14 May 2017: I inform CompuLab of the invalid syntax and provide the correct usage, and confirm that the fix enables write-protection on the ME/BIOS/GbE regions of flash
15 May 2017: CompuLab replies with a revised update script
15 May 2017: I inform CompuLab that the syntax of the revised script is correct, however my unit has already been updated so I cannot re-test
4 June 2017: Details of the vulnerability are published.

CompuLab have provided an update to address the issue.

I can confirm that the Phoenix update utility still functions so it is still possible to update the BIOS even after the FDR has been locked.

Disabling Secure Boot on Intel Quark “secure SKU” silicon

Secure Boot is a bit like SELinux: people who use it really like it, and tell all their friends to use it. For everyone else, apart from those who don’t know about or even notice Secure Boot, it’s an annoyance that they almost immediately disable.

We’ve looked at the Intel DK200 from a hardware perspective before. Now it’s time to look at it from a software perspective. “Internet of Things Gateway” is pretty generic, so what can it actually do?

Following the instructions, I tried to register the system on Intel’s website so I could download the Wind River Intelligent Device Platform XT 2.0 SDK. I didn’t get very far:

No WindRiver SDK for you

Stormtrooper #1: This is not the product you’re looking for

Yeah… I guess this is what Mouser meant when they said the DK200 was End of Life.

Since this ships with the Linux Kernel, which is GPLv2 licensed, I believe Intel may be violating the GPL. Specifically:

Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange

But I am not a lawyer, and I am not really that interested in starting a legal battle over the source code for an ancient version of Wind River Linux I am not interested in using anyway.

So let’s go try to build Yocto. The Intel rep did say there was a Yocto BSP coming “soon” but “soon” in Intel time seems kind of variable.

After some hiccups (Yocto needs python2 and GCC <6) I had built a Yocto image and put it on an SD card. Does it boot?



So we can’t boot Yocto because this is a “secure SKU” which means Secure Boot is enabled. Is there some way we can disable Secure Boot? What about updating the BSP to a newer version with Secure Boot disabled?

Back to hardware
If I’ve learned anything from messing around with electronics, you want to make a backup before you start modifying things. This is doubly so if the data in question is related to the booting process. It sucks to end up with a brick, so make a backup!

Taking a backup of flash

Taking a backup of flash

The Intel Quark guide mentions using a Dediprog SF100 to flash EDKII. I don’t have a Dediprog, but I do have an SPI programmer. Unfortunately, none of the Intel documentation I could find mentions the Dediprog header on the DK200, so I had to go hunting.

I traced the pins from the Winbond flash to header J23. J23 is only 8 pins, so trial and error with a multimeter to find the pin mapping wasn’t terrible:

J23 pinout

J23 pinout

Here’s the pinout of J23 in text form:

J23 pin 25Q64 pin Pin description
1 8 VCC
2 4 GND
3 1 /CS
4 6 CLK
5 2 DO
6 5 DI
7 Not connected
8 Not connected

/WP and HOLD pins on the 25Q64FV are not routed to J23, but they aren’t required for flashing.

With the pinout known, I could attach the SPI programmer to the header instead of using the chip clip:

J23 to ch341a SPI programmer

J23 to ch341a SPI programmer

I took a dump of the Winbond 25Q64FV and then for good measure desoldered the chip and read it again to confirm the images were exactly the same. It was strange because the image from the chip clip wasn’t identical. But, the image from the desoldered chip was identical to the image taken from J23, so we’re done here. I wrote the image to a new 25Q64FV and soldered that back onto the board.

Firmware disassembly
Disassembling the firmware which shipped on my DK200, we see that a Secure Boot certificate was created by WindRiver.

I assume that had I been able to download the WindRiver SDK, I would have been able to build and sign Secure Boot with my own certificates. Given that industrial customers spend a lot of time and money worrying about security, I was surprised to see that the Secure Boot certificate in the firmware was created by WindRiver China.

I did try to load up the image in IDA, but not being a power user of IDA, I couldn’t figure out how to get it to analyze the SPI dump, and gave up to try and compile the firmware from source.

Building the BSP

Being Intel, there are hundreds of pages you can read about developing for EDK2 and other really fun things, probably. I didn’t read them.

A document which I did end up reading religiously was the Intel ® QuarkTM SoC X1000 Board Support Package (BSP) Build and Software User Guide [PDF] which describes how to build all the firmware components needed to bring up the X1000 SoC. I found out there is actually a newer version of this document (1.2.1 instead of 1.1) and there are some important differences between the documents I want to get to later.

By building the firmware, we’re hoping for one of two outcomes:

  1. A firmware with our own Secure Boot certificates, or
  2. A firmware which has Secure Boot disabled

Version 1.1 of the BSP Build and Software User Guide includes a section on pages 29 and 30 on how to bundle your own db, kek, and pk certificates:

Page 29 and 30 condensed

Unfortunately if you follow the instructions and try to use a layout.conf which specifies these files, you’ll get an error because there’s no address specified for this data in the image:

I do have a reference file from WindRiver with Secure Boot certificates, so if I was really interested in making Secure Boot work as intended, I could have reverse engineered the address to store the certificates.

The certificates section of layout.conf was removed from the 1.2.1 revision of the BSP Build and Software User Guide. I guess since it no longer works, Intel decided to remove it from the documentation.

So, we can’t install our own Secure Boot certificates in the firmware. What happens if we just leave out the certificates section entirely and build it?

Error 37: Quark signature file not found

Right, so even though there’s now no certificate in the firmware bundle, we still can’t boot.

Interestingly, if you don’t partition the uSD or USB stick correctly, you end up with this pretty screen:

I never saw that in the stock firmware.

Hacking GRUB
So it seems that we can’t include our own Secure Boot certificate in the firmware, due to the sample layout.conf file missing the certificates section, and not knowing the appropriate address to store the certificates.

What if we dig into Error 37: Quark signature file not found a bit more?

If you look in the grub source code included in the BSP, you can see a giant ~1000KB patch that Intel has made to the original upstream code to support the Quark platform.

If you grep for “Quark signature file not found” you’ll find it was added in stage2/common.c:
diff --git a/stage2/common.c b/stage2/common.c
index e96bec2..e122745 100644
--- a/stage2/common.c
+++ b/stage2/common.c
@@ -88,6 +88,8 @@ char *err_list[] =
[ERR_UNRECOGNIZED] = "Unrecognized command",
[ERR_WONT_FIT] = "Selected item cannot fit into memory",
[ERR_WRITE] = "Disk write error",
+ [ERR_QUARK_VERIFICATION] = "Quark signature verification failed",
+ [ERR_SGN_FILE_NOT_FOUND] = "Quark signature file not found",

If you grep for ERR_SGN_FILE_NOT_FOUND you’ll find it’s in the following files:
./work/efi/ia32/loader/linux.c:410: errnum = ERR_SGN_FILE_NOT_FOUND;
./work/efi/ia32/loader/linux.c:732: errnum = ERR_SGN_FILE_NOT_FOUND;
./work/efi/quark/boot_settings.c:190: errnum = ERR_SGN_FILE_NOT_FOUND;

Going back to Intel’s modifications to grub, we can see what they added:

It takes a bit of searching, but if you strip out all of the grub_quark_secure logic from linux.c and boot_settings.c, you end up with…

Ta-da! I can boot Yocto Linux

No more Secure Boot!

At the end of the day, the Quark X1000 is an x86: “secure SKU” is nothing but a fuse setting.

The comment should read:

Determine whether or not grub should enforce Secure Boot.

In our case, this is not a mandatory option 😉

Special offer for DK200 owners
As shown above, it is possible to modify the Intel sources to disable Secure Boot. If there are other people have a DK200 from Intel and are interested in running a firmware without Secure Boot, leave a comment with your contact details. Upon request, I can provide a firmware image* with generic Ethernet MAC addresses for you to flash. Note that this firmware is specific to the DK200 (Clanton Hill) hardware.

* No warranty, express or implied, provided for said firmware image. You flash at your own risk!

Reassembling a firmware from pieces

Working on firmware is always interesting. Modern x86 computers are incredibly complicated, due to the evolution of the architecture over the last 40 years, and it’s difficult to debug issues past “Well it doesn’t POST, better try something else.”

Unlike most ARM/MIPS systems, where you have a UART console or something to see output from u-boot, if you mess up the firmware on an x86, you’ll have a non-communicative brick on your hands.

Of course you can also have firmware issues on ARM/MIPS, if you manage to corrupt u-boot on SPI flash, but since u-boot is open and not proprietary it’s easy to rebuild it from source and flash it again to recover.

Not so in the PC world. UEFI is horrendously complex compared to u-boot, and Intel’s reference implementation known as TianoCore is usually “improved” by several middlemen before going into the final product.

Trammel Hudson’s excellent talk from 33c3 (slides) on Bootstrapping a slightly more secure laptop highlights the situation with UEFI quite well:

Farm to table firmware

In this case, we’ve got TianoCore from Intel, insyde adds some magic fairy dust, this goes to Compal (the ODM of this laptop), and finally Dell (who would probably also claim to add magic fairy dust). In the end there’s a lot of proprietary fairy dust floating around, and we probably wouldn’t be able to boot the laptop if we just build TianoCore from source.

TianoCore itself is open source and BSD licensed, which is why all the vendors use it. Intel manages porting TianoCore to their new platforms, and since it’s BSD licensed, it means that someone like insyde can take the working base from Intel and add their proprietary fairy dust without having to release the modified source code.

SPI flash
The start of flash contains a region called the Flash Descriptor (PDF; page 3) which is programmed at system manufacture and tells the system where different firmware components are present on flash. Think of it as a partition table for the system flash. Under normal circumstances, the flash descriptor prevents the user from reading and/or writing portions of ROM. If you try to use tools to read or write the ME regions of flash, you’ll get a error similar to this:

Error 26: The host CPU does not have read access to the target flash area. To en
able read access for this operation you must modify the descriptor settings to g
ive host access to this region.

And this makes sense. If the system allowed unrestricted write access it would be trivial for some malware to write itself into the system firmware, and then you’d have a persistent rootkit. In my opinion, blocking the ability to read portions of the firmware serves no purpose except to discourage reverse engineering attempts.

Thankfully, there is a method known as Flash Descriptor Security Override Strap which can be used to disable the flash descriptor protection.

The first step is to locate the ME_FWP pin in the circuit diagram:
Override Strap

Now that we’ve located the pin on the logical diagram, we need to find the HDA chip itself so we can see which pins we need to bridge to disable the flash descriptor lock on the ME region:

In this case, it’s most convenient for us to short pins 5 and 9:

You could also short pins 1 and 5, but this requires a very steady hand and small instrument. However pins 5 and 9 are connected to surface mount components located away from the chip. These components (a capacitor and a pad) are much easier to access with a wire:

Amazingly, this area can be accessed without completely disassembling the laptop. Just taking off the palm rest and keyboard, which is about 8 screws, is enough to access the pins. They’re right under the LVDS cable to the display. Thanks, Compal!

At this point, I have two options:

  1. Find or buy an SPI dump online and flash that
  2. Find a way to dump the firmware from the working laptop without soldering

As you read in the previous post, I only managed to find an E6320 SPI dump online, and ended up with a laptop that worked-ish. I tried for many hours, but I wasn’t able to find any free SPI dumps for the E6230 online. After seeing many forums promising to sell you the firmware for outrageous prices, I finally found one that wanted only 8 złoty ($2) to download the SPI dump for the E6230. Principles be damned, I’ve wasted enough time trying to get this to work. I paid up and downloaded the files for the 4MB and 8MB chips.

Did I really get a valid firmware for $2? Yes!

But it’s BIOS A12, the current version is A16, but none of the Dell update utilities work! I installed Windows to try the update tool from Dell, but the laptop just rebooted without updating the firmware. I tried from FreeDOS and again, the laptop would just reboot when it got to flashing. Hrmm…

So, at this point I’m going to cheat a little: I have a working E6230, but I decided when I started this that I would not touch it with a soldering iron or heat gun. If it ain’t broke, don’t fix it!

Can I get a full firmware dump from the working E6230?

Intel FPT

Intel FPT is a proprietary command-line utility created by Intel for flashing firmware files through the computer’s internal SPI flashing interface.

Alright, let’s go dump the firmware! First you need to remember to apply the Flash Descriptor Security Override Strap, or the CPU will block your read attempt to the ME region.

However, once we’ve done that, FPT will allow us to dump regions of flash to a file.

At first I tried to dump just the ME and BIOS, using the A12 firmware from above, I reflashed these regions using the FPT utility from FreeDOS. The verification of the BIOS region failed, and when I rebooted I had a brick again.

But, the FPT tool lets you dump all the regions at once! I dumped the entire flash, but now we’ve got a 12MB file and I don’t know where the split is between the 8MB and 4MB flash chips.

After more searching, I found the Intel ME System Tools, including a utility called Flash Image Tool, which allows you to import the firmware image file created by FPT.

Well, the flash component density matches what’s in the laptop, so I guess this is correct.

Flash Image Tool also lets you build a new firmware image:

Writing ROM image file “C:\Users\hmartin\Documents\MESYS\Flash Image Tool\v8.1.10.1286\Build\outimage.bin”.
Writing file “C:\Users\hmartin\Documents\MESYS\Flash Image Tool\v8.1.10.1286\Build\outimage(1).bin” (size = 8388608)
Writing file “C:\Users\hmartin\Documents\MESYS\Flash Image Tool\v8.1.10.1286\Build\outimage(2).bin” (size = 4194304)
Writing MAP file “C:\Users\hmartin\Documents\MESYS\Flash Image Tool\v8.1.10.1286\Build\outimage.map”.

Image size = 0xC00000 bytes

Interesting… outimage(1).bin is exactly 8192KB, and outimage(2).bin is exactly 4096KB. I wrote these two images to the respective chips and put them into the laptop. The moment of truth had arrived.

It boots!

When you’re trying to work through firmware issues, it’s really helpful to have the flash chip in a socket. Soldering and desoldering gets really old when you have to do it more than a couple of times.

Thoughts on the sale of firmware images

I’m against the sale of these firmware images. I realize that it takes a non-zero amount of time to get the image, but the whole experience of BIOS forums just leaves you feeling dirty. You have no way to verify before payment that the files they’re providing even work. Combine this with the fact that most websites want $10-$20 for the SPI dump, the experience leaves a bad taste in your mouth.

Is it worth it to pay? It depends entirely on your willingness to pay. Is this your only computer? Do you need it working now? How much of your own time are you willing to invest to learn about UEFI firmware? I’ve probably put 20 hours into this project, and I still don’t understand the internals of UEFI.

The wrong way to clear a BIOS password

I was browsing on eBay and ran into a listing for a Dell E6230. By now you might guess where this is leading:

Dell Latitude E6230 12.5″ i3-2350M 2.3GHz 4GB RAM Admin Pass Set AS IS READ!


The whole laptop, everything working perfectly, except… it has a firmware password set, and the seller doesn’t know the password. Well no bother, it’s cheap (83 EUR), I know how to flash SPI chips. Should be a piece of cake to clear this password! I also had an E6230 motherboard with a Core i5-3320M which I had found on eBay for 40 EUR, so my plan was to swap the boards, and then work on clearing the password.

These boards contain two flash chips: Winbond 64Mbit (8MB, U52) and Winbond 32Mbit (4MB, U53) located to the left of the SIM card slot.


The first step was to dump the SPI flash from U52 and U53 on both boards as a backup before flashing anything. This seemingly went well, but when I flashed the i5-3320M firmware dumps to the board with the i3-2350M, I had a brick.

It turns out that several of the pins to each chip are connected to the same pins in the PCH. Important pins like Data Out, Clock, and Data In are shared:

PCH SPI wiring

U52 and U53 share data out, data in, and clock lines to the PCH

I’m not sure exactly what happened, but my guess is that by leaving the flash soldered to the board, I somehow managed to get data from both chips. Alarms should have been going off in my head when my SPI reader dumped 8MB from a 4MB chip.

Not wanting to risk wrecking the i5-3320M board by desoldering the flash, I turned to the internet and discovered the terrible world of BIOS image dumps. It’s nearly impossible to find any website offering SPI dumps for free. Of course you can download the firmware update tool from the manufacturer, but those are meant to be run only on the intended hardware, and they only contain regions of the SPI flash like the UEFI firmware and Intel Management Engine.

I was able to find an SPI dump of the E6320, which is a 13.3″ laptop one generation previous to the E6230 (12.5″). As I had nothing to lose, I desoldered U52 and U53 and flashed the E6320 images to each chip. To my great surprise, the board passed POST, albeit with a warning about unsupported hardware. I was even able to enter the UEFI setup utility.

But now I am running a firmware intended for a completely different laptop. The E6320 has a QM67 (6 series) chipset, and the E6320 has a QM77 (7 series) chipset. The USB 3 ports on the side don’t work, the internal SATA port doesn’t work, and PXE booting doesn’t work. The only port that seems to work, at all, is a Mini PCIe USB port:


My next thought was to try the Dell E6230 BIOS update tool, which can run from DOS. I put FreeDOS on a USB stick in the above adapter and installed that in the WWAN Mini PCIe slot. Unfortunately for me, Dell has put checks into the update utility to check that it’s running on the correct hardware. This makes total sense, if a user downloads the wrong update for their laptop, they shouldn’t end up with a brick.

However, it didn’t suit my purpose. I wanted Dell’s BIOS update utility to ignore the fact that it was running on an “E6320” and instead flash the firmware for the E6230, the actual hardware.

Having been foiled by Dell’s checks, I decided to load up the utility in IDA Pro to see if I could bypass the check. A bit of string searching and I found the target, a jnz:

Changing this check to a jz and I tried again. This time the utility didn’t complain about the machine being an E6320, but as soon as the flashing process started, the laptop shut off. So what happened? My best guess is that Management Engine shut down the platform.

Management Engine
The Intel ME has existed since the mid-2000’s, and is now deeply integrated into all of Intel’s modern x86 SKUs. The ME can provide additional functionality like a TPM (implemented in firmware), cryptographic acceleration, DRM, as well as other patented and super duper proprietary stuff. There’s a fairly comprehensive feature list available on Wikipedia.

Since Intel doesn’t actually release documents on the ME, it’s hard to come by actual information on the inner workings. It’s also why some libre people are concerned about buying newer laptops: the ME is integrated into the PCH, cannot be disabled, runs an OS with direct memory access to system RAM and has never been audited.

Trammell Hudson is currently experimenting with coreboot on the Lenovo X230, and it seems like there’s a non-zero chance that he’ll succeed in disabling the ME.

Anyway, I was on vacation earlier this year and had lots of time to kill in airports/planes/trains so I read a book about the Intel ME called “Platform Embedded Security Technology Revealed” You can download the ebook for free as a PDF or EPUB from the publisher.

Using knowledge from the above book, we can conclude that the security number of the Series 8 ME firmware must be equal to the security number of Series 7 firmware, or the ME would not allow the platform to power on.

Unfortunately, the updater managed to overwrite something important in flash before the ME cut power, because now I’m stuck with a brick again.

Stay tuned for part 2!

CompuLab MintBox 2 Review

Update 30 July 2017: If you own a MintBox 2 or Intense PC your system is vulnerable to CVE-2017-9457. There is currently no planned fix for this vulnerability.

Update 6 June 2017: If you own a MintBox 2 or Intense PC, please update your system firmware to the latest version (21 May 2017). Your system is vulnerable to CVE-2017-8083.

CompuLab’s MintBox 2 is a small embedded computer designed for home, office or industrial applications that retails for $599 US. The MintBox 2 ships with Linux Mint 15 “Olivia” on it, which was supported until January 2014 (last month).

The specifications of the MintBox 2 are:
Intel Core i5 3337U (Dual-core 1.8GHz, 2.7GHz turbo, 17W)
4GB RAM (2x2GB; DDR3 1333 CL9 SODIMMs)
500GB hard drive (2.5″, 5400RPM, Hitachi HCC547550A9E380)
Dual Gigabit Ethernet (Intel and Realtek 8111F; both integrated)
Realtek 802.11b/g/n 2.4GHz WiFi/Bluetooth 3.0 combo card (RTL8723AE; half-height mini-PCIe)

Also present are two eSATA ports (SATA 300), a full size mini-PCIe which can also double as mSATA, DisplayPort and HDMI (CEC is not supported) video outputs, and 3.5mm audio in/out which also support S/PDIF (coax).

The MintBox 2 comes with a 60 month warranty (5 years), with the hard drive being covered for 24 months (2 years).

The shipping configuration uses legacy booting and partitions instead of EFI booting and LVM.

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x16ad26de

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 968752047 484375000 83 Linux
/dev/sda2 968752048 976773167 4010560 82 Linux swap / Solaris

Encrypting user’s home is supported and offers reasonable speeds, but since user data is stored on the same partition as the OS you may run into trouble if you try to upgrade Linux Mint or install another distribution.

The MintBox 2 supposedly supports up to 16GB of memory, and indeed I had no issues with the 4GB installed, or with an 8GB (2x4GB) kit from Patriot memory. I tried three different 16GB kits (G.SKILL, Patriot, Micron) in the MintBox 2, and all three were incompatible. As such, I highly recommend you consult the list of approved memory modules before purchasing a 16GB kit for the MintBox 2. I am awaiting a 16GB kit that was certified to work with the MintBox 2 and will update this post when it arrives.

People familiar with Linux Mint will know what the standard user interface is like, and the MintBox 2 does not deviate from it apart from a cheeky MintBox 2 wallpaper. Everything works out of the box, with ethernet and wireless configured for DHCP. Suspend to RAM works well and performance is on par with other dual-core computers running Linux Mint.

I installed Arch Linux on my MintBox 2 using EFI boot. This requires reformatting the hard drive completely to use a GPT partitioning scheme. An EFI service partition is required to store the grub boot loader, unless you opt to use the EFI stub in the linux kernel (which I did not). You will also have to boot from live media and use the efibootmgr tool to insert a boot record into EFI nvram to point to your boot loader or you will be sitting sadly in the [seemingly] useless EFI shell wondering why it won’t boot.

As with most other consumer electronics, there is little to no option to tweak in the EFI configuration utility (“BIOS”). There are no voltage monitors, and only the CPU temperature sensor is available over SMBus. Users do not have control over CPU speed, C-states, memory frequency or timings. There is an option for whether the full-height mini-PCIe slot is mSATA or regular mini-PCIe, and users can choose to enable or disable Virtualization (VT-x; VT-d is not supported by the HM76 chipset).

The December 2013 firmware update provides users with the ability to pre-define how much memory to share with the IGP (128MB, 256MB or 512MB) which is reserved and unavailable to the OS. I believe previous firmware versions dynamically allocate VRAM based on the Intel IGP driver requests from the OS.

Depending on the workload the CPU temperature can vary from mid-40s to mid-70s (Celsius), but is almost never hotter. This is average for a mobile CPU and well within safe limits. The stock RAM hits mid-60s in heavy use, but DIMMs with 16 chips (as opposed to 8) run in the mid-70s.

CompuLab support was a little lacklustre at first, but improved tremendously after I discussed my issues with the MintBox product manager. They issued an RMA and replaced the unit to see if the compatibility issue was isolated, but the replacement has the same issues.

Overall the MintBox 2 is a very nice computer. The MintBox 2 is a fanless design, which is very nice from a noise perspective but certainly won’t win it any awards in the design department. The connectivity options are very nice, and exceed what other manufacturers are offering in a small form-factor fanless PC.

I was torn between buying a MintBox 2 and a Mac Mini. I liked the MintBox 2 connectivity options, even though it lacks ThunderBolt, and the fanless design was a bonus. The MintBox 2 also uses a lower TDP CPU than the Mac Mini (17W versus 35W), but is clocked lower.

If you want to buy a computer that works out of the box with Linux and don’t mind paying a premium for it, then the MintBox 2 is an excellent choice. However, the Mac Mini does give you more connectivity options (4xUSB 3.0, FW800 and ThunderBolt) and is compatible with almost all 16GB memory kits available on the market.

+ Low-power
+ Fanless
+ I/O options without purchasing expensive adaptors
+ 5-year warranty

– Limited support for 16GB of RAM
– Limited I/O (no ThunderBolt)
– RMA requires shipping the unit to CompuLab’s US or Israel office which means about 2 weeks without your computer (as opposed to bringing the Mac Mini in to an Apple store and getting it fixed/replaced within a day or two)
Multiple security vulnerabilities present in the system firmware (added July 2017)

Update: I installed the Corsair CT2CP102464BF1339 16GB kit and it seems to be working well in the MintBox. I also measured the power usage of the MintBox. At idle the MintBox draws 11W (110V mains) and under full load it draws around 27W.