Category Archives: Embedded

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!

s-l1600

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.

f_0020914

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:

mini_pcie-usb30-1_zps098e038b

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:
ida_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!

Allwinner H2+/H3 Ethernet with Linux 4.9-rc8

The Orange Pi PC is not a new single board computer. It’s been released for over a year now, but has mostly been stuck on a heavily patched 3.4 release kernel.

There have been ongoing efforts since the release to have support for the Allwinner H3 in the mainline kernel. In the past weeks there have been new patches released which enable support for the Ethernet MAC on the H3 (and H2+).

Unfortunately this support is not in mainline yet, and won’t make it in the upcoming 4.9 release. However, that doesn’t stop you from taking the patches and applying them against 4.9 yourself.

I wrote a script to compile the kernel from source, applying the necessary patches to the kernel and using a minimal .config file which compiles the sun8i_emac support as a module. You can download the build script from GitHub.

It does try to be somewhat smart: verifying the integrity of the downloaded files, and will bail out if there are errors in patching the source code. But, it doesn’t do toolchain dependency checking because that’s just too complicated. Since the emac support will end up in mainline soon, I doubt it’s worth the time to improve the build script. However if anyone is interested in improving it, the script is released as GPLv2.

The result? If you are patient enough to wait for the kernel to compile, you get a uImage and modules for Linux 4.9-rc8 with Ethernet support:

Allwinner H3 emac performance:

orangepi@OrangePI:~$ iperf -n 1024M -c 192.168.1.150
————————————————————
Client connecting to 192.168.1.150, TCP port 5001
TCP window size: 43.8 KByte (default)
————————————————————
[ 3] local 192.168.1.206 port 42572 connected with 192.168.1.150 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-100.6 sec 1.00 GBytes 85.4 Mbits/sec

Orange Pi Zero (Allwinner H2+):

I’ve also just received my Orange Pi Zero and confirmed that the same kernel works on the Orange Pi Zero, so you can run Linux 4.9 on the Orange Pi PC (Allwinner H3) or Orange Pi Zero (Allwinner H2+) with Ethernet support.

Allwinner H2+ emac performance:

orangepi@OrangePI:~$ iperf -n 1024M -c 192.168.1.150
————————————————————
Client connecting to 192.168.1.150, TCP port 5001
TCP window size: 43.8 KByte (default)
————————————————————
[ 3] local 172.16.4.206 port 54762 connected with 192.168.1.150 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-95.9 sec 1.00 GBytes 89.5 Mbits/sec

Download:
If you want to skip compiling the kernel yourself, I’m providing the kernel uImage and modules here.

I am using u-boot v2016.11 from denx.

Note: HDMI isn’t working on my Orange Pi PC, and since I run it headless I’m not interested in investigating why. If you’re using your Orange Pi PC with HDMI output, you may need to modify the kernel .config file to fix HDMI.

Intel DK200 IoT Gateway

Earlier this year I was at a conference and heard from other attendees that the Intel booth was giving away IoT gateways. Never one to turn down free conference swag, I hurried over to the Intel booth and was told to pick up a gateway out of a pallet of boxes just delivered (and rapidly disappearing).

The Intel IoT gateway series is codenamed Moon Island, but the design targeting the transportation market is codenamed Clanton Hill. Clanton Hill known to us mortals as the “Intel DK200 Series Gateway Solution for the Internet of Things (IoT)” quite the mouthful.

Let’s get down to it.

Availability
Unless you happen to be at a conference where Intel reps are handing these out like candy, I don’t think it’s practical to try and buy one yourself:

dk200_mouser

Some interesting details to note about this product:

  1. Although released in 2014, the DK200 still costs more than the new MacBook (3,712.50 EUR versus 3,199 EUR)
  2. It’s End Of Life

When a low volume product goes EOL and you still have stock, I guess giving it away at conferences is the next logical step.

Hardware Specifications
The DK200 (datasheet) is targeted toward the transportation industry, and it really shows in the appearance of the device:

Only available in 'Cosmic Black'

Only available in ‘Cosmic Black’

I don’t work in the transportation industry, and have never seen connectors that look like this before. They’re very well made, and I suspect probably do a good job of keeping dust, dirt, and debris out of the ports. Since I don’t wish to make a mess by throwing dirt and debris at it, I’m going to have to trust the engineers who designed it.

The build quality is quite good, as one might expect from a device selling for 3,700 EUR. Nearly every screw is secured with loctite to prevent vibration from loosening them:

DK200 screw with loctite

No pentalobe nonsense here

However, I was surprised to find that despite all the physical hardening applied to the enclosure, I couldn’t find any information on an IP rating. In fact the top and bottom of the case don’t appear to offer any additional dust or water seal. There’s clearly been a lot of thought put into the design of this enclosure to withstand vibration and dirt, so it’s strange that there doesn’t seem to be water protection of any kind.

Processor
The Intel Quark series SoC was introduced in late 2013. The X1020D in the DK200 is a single core SoC based around a 80486 core running at 400MHz, with modern I/O and memory.

dk200_x1020d

In 2014 a leaked product roadmap suggested a successor to the X1000 series named “Dublin Bay” to be released in 2015. Then news emerged that “Dublin Bay” had been cancelled, to be replaced by “Liffy Island” and “Seal Beach” which would be released in 2015. As of late 2016 Intel has not released a direct successor to the X1000 series, and there is no new news of “Liffy Island” or “Seal Beach” being cancelled (or released). So it’s anyone’s guess whether Intel is still even interested in the IoT gateway market.

Storage
The DK200 doesn’t include any of the typical storage buses like SATA, NVMe, or NAND (EMMC). This is not overly surprising given the embedded nature of the hardware (requiring lower power) and the simplicity of the Quark processor.

The only storage option is a micro SDHC card, and the DK200 includes an 8GB class 4 micro SD card:
dk200_sdhc

Given that it’s a class 4 card, the performance is quite poor. Use of an SD card for storage isn’t a bad decision per se, but the DK200 uses ext3 for the root partition. Ext3 is not a flash aware filesystem. SD cards have only basic wear leveling, and ext3 has no wear leveling. So it hardly seems like the appropriate combination of storage and filesystem for a headless embedded device with an expected lifetime of 5-10 years.

Input and output

  • Dual 100Mbit Ethernet controllers
  • 3 x USB 2.0 host and 1x device
  • Audio in/out
  • CAN bus
  • RS-232
  • GPIO
  • 1x half-height mini PCI-e slot (populated with Intel 7260)
  • 1x full-height mini PCI-e slot (unpopulated; for 3G modem/GPS)

The Intel documentation also mentions ZigBee, however this is an external device, presumably attached via the USB bus.

Power consumption
Development platforms aren’t known for being highly optimised devices. They often include extra I/O which would not necesssarily be included in the final product, and as such do not have the same energy efficiency as a finished product.

This being said, I was quite surprised that a device intended for 24/7 operation in an embedded environment, and especially serving the “Internet of Things” market, could be so energy inefficient. Issuing a poweroff command in Linux results in the platform going into an S5 (shutdown) state. I was surprised to discover that the energy consumption in the S5 state is 2W. This seems quite high for a device which includes an ignition input for automatic power-on and shutdown.

When booting, the device peaks at 7.9W consumption, while the idle power consumption is 7.5W. This is almost certainly due to the added peripherals as the TDP of the Quark processor is only 2W.

It’s difficult to see how Intel expects the Quark platform to compete with ARM. My PandaBoard ES, an ARM-based development board from 2011, peaks at 4W, idles at 2W, and draws nothing when off. Now some might argue that comparing an ARM board from 2011 with an Intel IoT gateway from 2014 isn’t valid, but they do have a lot of similar features. Now, I will grant that the PandaBoard is not in a rugged enclosure with fancy connectors, but since it cost 95% less than the DK200 does, there’s some room in the budget for an enclosure and funky connectors. And, since Texas Instruments has stopped making OMAP chips, the PandaBoard gets about the same amount of vendor support as the DK200!

Software

I will be exploring the software of the DK200 in a follow up post. Stay tuned!