A recent publication by Kaspersky Lab (mirror) describes the first publicly-confirmed instance of a Microsoft Windows 'trojan' capable of infecting hard disk drive firmware. For every word that's been written on the subject so far, ten thousand words of disinformation, FUD, and general-purpose obscurantist rubbish are floating about – eagerly passed around by spambots disguised as 'independent bloggers' and fleshy meat-puppets alike. Expect no shortage of 'product' from the well-funded – but, interestingly, not especially competent – FUD agency charged with spreading confusion and misplaced skepticism after this and every other Snowden-related tidbit.

Especially galling to any serious student of the 'dark arts' is the orgy of public genuflection – by the usual set of revolting Quislings of the English-speaking press – before the United States Government and its supposedly 'omnipotent' bureaucrats:

'How omnipotent hackers tied to NSA hid for 14 years and were found at last' – Ars Technica
'US can permanently spy on, sabotage foreign computers, Kaspersky Lab report says' – Toronto Star
… etc.

Presumably the reader is not especially interested in the thinly-disguised spew of the American propaganda ministries (those who are will find a warm welcome at, e.g., Schneier's site) and is concerned with demonstrable facts. And so, without further delay:

Every hard disk drive sold in the past twenty-odd years contains a small computer, which translates logical commands from the host (e.g., a PC-compatible asking to load or store a sector of N – typically 512 to 4096 – bytes) to physical motions of read-write heads (in mechanical drives) or read/write-with-wear-leveling operations (solid state drives.) Readers interested in the fine points of hard disk design and operation are invited to consult the literature (e.g., Wang & Taratorin's 'Magnetic information storage technology.') For our purposes, it suffices to say that a microcontroller is featured in all such drives as are presently sold.

Your current hard disk drive 'is not your grandfather's Winchester', yes, disks have been getting cheaper, faster, solid-state units appeared on the consumer market, etc. But something else has also changed: some time ago (roughly during George W. Bush's second term) these devices began to ship with firmware stored in EEPROMS ('flash' memory) Not simply rewritable – but rewritable specifically using 'in-band' commands – that is, commands that can be issued by software running on the machine the drive is connected to (e.g., PC-compatible) rather than a factory test stand or a field repair kit. Unraveling the reasons for this quietly-introduced 'enhancement' is an exercise for the alert reader.

Above: photo of a typical SATA hard disk controller. The eight-legged chip highlighted in red is the firmware EEPROM. In some drives, the nonvolatile storage for the firmware is embedded in the CPU (large IC in the middle-left) itself. It also bears repeating that one does not necessarily have to become a U.S. civil servant to experiment with modifications to HDD firmware…

For some peculiar reason, Kaspersky did not mention the U.S. Government in their publication. The likely explanation is possibly some misguided notion of 'diplomatic tact,' as the 'smoking guns' here are rather obvious – and smoking acridly and abundantly still:

A Snowden release on Jan. 17, 2015 titled 'S3285/InternProjects' (mirror, plaintext mirror) features a detailed discussion of a series of actively-developed intelligence 'products' under code name 'IRATEMONK.' Most of the projects outlined in this leaked memo were variations on the overall theme of slipping malicious code into HDD firmware:

—
(TS//SI//REL) Integrate SSD research into IRATEMONK products. This will
involve 4 different parts:
* (TS//SI//REL) Leveraging research to create ARM-based SSD implant. This works involves reverse engineering SSD firmware and creating C and ARM assembly code to place inside of a firmware image to implement the IRATEMONK algorithm.
* (TS//SI//REL) Create version of the IMBIOS code that supports the SSD implant. This code runs on the x86 host and involves writing both C and x86 assembly. This work will involve interacting with the firmware implant as well as the code that IMBIQS bootstraps (SIERRAMIST).
* (TS//SI//REL) Add support for the SSD to WICKEDVICAR. WICKEDVICAR is the remote tool used to perform remote survey and installation. This code is C + + and will involve interacting with the firmware implant from a Windows OS.
* (TS//SI//REL) Add the SSD vendor support to the IRATEMONK firmware and implant database tool. This code is mostly python code that interacts with a drive via a Linux driver.
—

—
(TS//SI//REL) Covert Storage Product

(TS//SI//REL) Create a covert storage product that is enabled from a hard drive firmware modification. The idea would be to modify the firmware of a particular hard drive so that it normally only recognizes say half of its available space. It would report this size back to the operating system and not provide any way to access the additional space. The firmware would have a special hook inside of it that on receipt of some custom ATA command, it would "unlock" the rest of the drive on the next boot of the drive. When covert storage is locked, only 1 partition would be present on the drive. When unlocked, the firmware would fix up the partition table to account for the second hidden partition whose space is now available on the drive. When finished with covert storage, a special command can be sent back to the drive that will lock the drive again. On the next boot, the firmware will hide the extra space and fix up the partition table so only 1 partition exists.
—

—
(U//FOUO) SADDLEBACK

(TS//SI//REL) Utilizing a hard drive's serial port, create a firmware implant that has the ability to pass to and from an implant running in the operating system. In practice, the serial port will be connected to a short hop radio that can communicate with another radio in a system. Doing a firmware modification eliminates the need to tap the SATA bus as was done on other versions of SADDLEBACK. Performing firmware modification will allow for a smaller SADDLEBACK in the form of a laptop drive as opposed to the current version which only comes in a a 3.5 inch version.
—

—
(U//FOUO) ALTEREDCARBON Support

(TS//SI//REL) Develop IRATEMONK implants for the newest Seagate drives including their hybrid drive products. This work will primarily be a reverse engineering effort, but if successful will require updates to both IMBIOS (x86 code, C and assembly), WICKEDVICAR (x86, C + +), and SPITEFULANGEL (python).
—

—
(U//FOUO) FAKEDOUBT Support

(TS//SI//REL) Create an IRATEMONK implementation for ARM-based Hitachi drives. This includes a firmware implant, IMBIOS code, and WICKEDVICAR and SPITEFULANGEL support.
—

—
(U//FOUO) PLUCKHAGEN Support

(TS//SI//REL) Create an IRATEMONK implementation for ARM-based Fujitsu drives. This includes a firmware implant, IMBIOS code, and WICKEDVICAR and SPITEFULANGEL support.
—

Further examples are to be found in the document, which the reader is well-advised to study in its entirety. Very little is left to the imagination; here we find a direct statement of purpose for these civil servants' years of hard work:

'While a lot of work in the Persistence Division involves modifying firmware, there is still a large need for OS kernel and user-mode expertise. The firmware modification done at the lowest levels of hardware needs a way to obtain execution inside of a running OS so that a DNT payload can be either given execution or installed.'

The basic idea of infecting hard disk firmware is not a new one, nor is the overall design of the payload a serious riddle. The disk is subverted in such a way that particular blocks (typically, the Master Boot Record, but in a 'classier' attack will include those portions of the operating system which load immediately at the boot process, e.g., 'NTLDR') will be replaced with maliciously-patched copies precisely once per power-up. The idea being, if the victim were to examine his disk some time after bootup, he would turn up nothing untoward. Additionally, a clean install of the operating system by the victim (or the vendor he bought the machine from) will still result in a compromised machine.

Persistent kernel subversion is thus one obvious goal of crafting malicious patches for HDD firmware, but there are others – some of them carefully explained in the memo, presumably for the edification of chromosomally-challenged golf-playing U.S. military brass. E.g., temporary concealment of data such as recorded keystrokes that is to be ferried out of a compromised machine intermittently – rather than continuously – to avoid waking up a paranoid sysadmin, etc.

Let's examine why a hard disk drive that knows to return a modified version of a particular sector if ever asked for said sector is ever a useful attack vector at all, focusing specifically on the 'pre-boot persistence' (to use their term) scenario:

1. Enemy knows that victim will run a particular operating system;
2. … that said OS stores a particular string of initialization code in a particularly numbered sector (e.g., 0)
3. … or, failing (2), that a particular bitstring of block length (512 to 4096 bytes) can, if encountered, be safely assumed to be part of said initialization code and hence worth infecting

By destroying the enemy's ability to rely on all of the above, this particular attack vector (that of your drives being pre-infected at the factory or at the post office, that is; if you disks are infected in situ, you – necessarily – have already been 'pwned,' and your goose is cooked) is rendered wholly uninteresting.

Rather than fixating on diddled HDDs, it is worth pointing out that all other 'hardware-flavoured' low-level exploits (e.g., 'FLUXBABBITT') – both discovered and undiscovered – rely on precisely the kind of foreknowledge described above. The one and only correct pill against such shenanigans is: to deprive the enemy of the detailed understanding of 'which bits to flip' that he is accustomed to.¹ Working out all of the implications of this formula is left to the alert reader, but let's include the obvious:

If you make use of Microsoft products of whatever kind, for whatever purpose – American bureaucrats really are 'omnipotent gods' as far as the fate of your sorry skin is concerned; simply because you have already surrendered to them.²

1. Mircea Popescu describes the virtues of a maximally-custom (and thus unfamiliar to the low-level attacker) computing stack thusly:

   'The cost to you in old hardware is to the tune of 500 dollars a pop, the cost to the attacker isn't to the tune of another 500 man hours a pop, his workload increases exponentially.'

    ↩

2. If you make use of 'Unix-likes' that may as well be Microsoft products – e.g., Redhat, Ubuntu – while entertaining delusions of 'security' – you are not only a fool, but a self-deluding 'learned fool' – perhaps the most pitiful kind.

   And if you are interested in surrender, pick your favourite '.gov' to surrender to and get it over with. Quit bothering the rest of us. ↩