Behind Hacking-Team’s vector-edk
This post is written almost 10 years after Hacking-Team’s data leak.
The original source code can be retrieved on GitHub.
The first question I was asked was why now? The answer is quite simple, over the years other “products” have been released onto the market, so this project is no longer a chimera.
This is not a technical article, but just a narrative of how individual events that happened over the years influenced me and convinced me to work on it.
vector-edk was the name of repository name where we initially used to store a full copy of TIANO CORE EDK, the Open Source project of an EFI firmware implementation, compatible with QEMU and the first edition of MinnowBoard.
The name is composed by vector and edk:
- vector: In GitHub you’ll find different vector projects, so it’s easy to deduce what it was supposed to be used for.
- EDK: Efi Development Kit, a full copy of the TIANO CORE plus the files we introduced in the project.
The main purpose was to ensure persistence in the event that machine was formatted or the hard disk replaced.
Although the topic may be considered ambiguous by many, my aim is to tell the behind the scenes of this project, on which I began to think about, write and test with the support of a single person in the company.
In many ways, the story of this project does not begin in Hacking-Team where, from what I remember I believe in the spring of 2014.
At that time, I was looking for a new career path, somehow bored with the daily routine, when they proposed that I follow this project.
Before HackingTeam, the project had already taken shape in my mind, in a sort of unattainable dream a long, long time ago.
This might sound like I’m an old retired man, but the truth is that somehow this idea was born from my interest in computer viruses.
A little personal history
My brother received his first computer way back in 1993, a gift from our grandparents to help him with his studies.
Keep in mind that I come from a little peasant town, where certain things at the time were not taken for granted at all.
Having a computer, without modem (I didn’t known what the internet was back then), forced people to get software through other means — and by other means, of course, I mean software piracy.
I remember very well the afternoon my brother brought a floppy disk with a copy of Frogger and the popup triggered by the Norton Anti-Virus with which the computer was supplied to us.
I think that was the exact moment when I started to get interested in viruses, in programming, in all the topics that would have been influencing my life for the next 32 years (and I hope at least for the next 30/40 years).
Unfortunately, the actions my brother took immediately after that popup don’t allow me to remember exactly which virus infected our computer.
What I do remember thought, is that was almost certainly able to infect .COM and .EXE files, and was able to remain resident in memory (maybe we’ll talk about this in future articles).
At the time, the only useful tools that could help solve such things, were a boot-able floppy disk of another copy of Microsoft DOS, in other words:
you were forced to reinstall everything!
As my interest in computers and programming grew, thanks to some relatives and friends, I was initially directed to study C++ (Basic wasn’t enough to me, nor was Turbo Pascal) and assembly language right after.
In the meantime, while attending high school I met the second computer-virus of my life, “Invisible Man”, which certainly broadened my horizons on the capabilities of these software.
At that time, widespread viruses had some or all these common features:
- Infect executable files (COM, EXE, SYS)
- Infect BOOT SECTOR and MASTER BOOT RECORD
- Polymorphism
- Memory residents and etc…
But even the most sophisticated ones never went beyond certain barriers, like surviving an OS re-installation or hard disk replacement.
One of the constants back then was simply that the BIOS was on a Read Only Memory (ROM), responsible for initializing the computer at startup, checking memory and peripherals and to load the Operating System, with a specific boot-order, Floppy Disk First, then Hard Disk.
In practice, an infected floppy disk marked as bootable was enough for a Virus to transfer from computer to computer (almost nobody had Internet connections).
During the 90s the was an Italian magazine dedicated to the world of computer viruses, PC Antivirus. I remember, in one of the articles they wrote about an old computer virus (almost certainly from the 80s) which had the ability to damage the processor by abusing some operations. Considering that I’ve never read anything about it except for the aforementioned article, the statement might just be speculation.
The CPU processors registers must be considered like memory, but stored inside the CPU itself. This buffer obviously was obviously made up of components (integrated circuit), so abusing of operations focusing on specific area could lead to overheating resulting in damage, but I said, this is only my opinion and I never found other sources.
What is BIOS?
BIOS (Basic Input/Output System) is a type of firmware used to provide runtime services for operating system and programs (predominantly before Windows era) through an API full of secrets for me, despite being documented in several books (and the only source of information at the time was the school library where they had a copy of Intel 8080 manual!)
Not having access to internet (at the time BBS too) the only little information I had access to were articles from specialized magazines, some technical books and a copy of the Intel 80386 Programming Reference Manual (which I still keep as a relic).
Just to give a little context, when an intel CPU is nitialized, it starts running code from a linear, fixed, address: 0xFFFF0 (16 bytes below the first megabyte), which corresponds to an address reserved and mapped to the the BIOS.
The BIOS code, and all additional extensions of hardware components are located at top of first megabyte (256Kb), and since these are potentially addresses mapped to a ROM component, any attempt at writing was a failure (no exceptions of course, on the read operation you would simply find the original content, not your data, unless a specific range was available because not mapped to any ROM extension).
Obviously, without any memory management unit, running all your code with the same privileges of the firmware, it was a simple enough to get a copy of your ROM also using the debug tool provided by Microsoft with MS-DOS.. At least that’s what I thought!
As the size of BIOS grew, the memory layout for it never changed, to maintain compatibility, so any extension the ROM would always be mapped the address reserved for them.
After initialization, the BIOS transferred the control to the boot sector loaded, and through INTERRUPTS it was possible to request the APIs.
A complete and exhaustive copy of these functions is available in the Ralf Brown’s Interrupt List, and I got a copy through the insert attached to DEV, a spin-off of the Italian magazine of Computer Programming published by Infomedia.
CIH computer virus
As technology evolved, ROM chips were replaced by Flash ROM, so that it was possible to update the mother board firmware, for bug-fixing or updates.
Before that, to write an E-PROM required a Flash-ROM writer, but nowadays this procedure is possible thanks to manufacturers who have made this functionality accessible through the motherboard chip-set. But each has a specific set of commands, and since there was no standard for updating the firmware, each manufacturer had its own tool.
One of them, the Intel 430TX became in the late 90s the target of CIH, the first computer virus who had crossed the barrier, able to overwrite the flash memory preventing the computer from restarting properly, resulting in economic damage.
Without an external flash-programmer, the only alternative was to boot a system with same motherboard (and same hardware components), remove the Flash ROM (not soldered onto the motherboard), put the corrupted one in and to run the the software to update the BIOS.
Things are starting to get more and more interesting.
BIOS Disassembly Ninjutsu Uncovered
Moving forward in time, reaching what I certainly consider as very important stepping stone, in 2006: Darmawan Mappatutu Salihun published his fabulous book BIOS Disassembly Ninjutsu Uncovered.
I read avidly during the holidays, only for personal growth, as I was just working as software consultant in another company working mainly on Navision (part of Microsoft Dynamics 365 Business Central today).
Around the same time I also started to use BOCHS IA-32 emulator and the source code of the BIOS used in the project, which boosted my confidence in experimenting allowing me to try things out without doing any damage.
When the game got interesting
But one day , everything changed.
So far I mentioned my brother, but the truth is I also have a sister, never interested in computer science — a normal person: when she has a problem with the computer, she calls one of her brothers (and quite recently also with the smartphone).
At the time she was studying and I gave her a laptop which she used to write her thesis, when one day she called me to tell me the computer wouldn’t turn on anymore.
I had contacted the assistance center and they had provided me a floppy disk image and some pretty simple instructions (they knew me so instead of taking the laptop for repairing it they gave me the tool)
Get cod’s stories in your inbox
Join Medium for free to get updates from this writer.
The solution was:
- Format a USB device and make it boot-able
- Transfer the content of the floppy disk image to the device
- Remove the laptop battery and keep only the power charger
- Plug the device into a specific USB port
- Use a specific boot sequence (Press simultaneously 3 or 4 different keys..).
A laptop that wouldn’t turn on (no beep or LEDs to give you an idea of what was wrong) miraculously came back to life after a few minutes.
What the hell happened here?
They will simply explain it to me that it was a known problem (a BIOS update failure), so there was a BIOS backup which provided minimal support to reinstall the firmware, stored on a device with a specific file name. I mean, were they telling me I could put whatever I wanted in the BIOS chip??
All of this costed me another laptop, because since she had to write her thesis, I had to buy a new computer, remove the old hard disk with her documents, put it in the new computer and bring the damaged one to repair and I never got the new computer back from her: I have never seen a cent.
Computrace/LoJack for Laptops
Another software that has influenced the development of vector-edk has been Computrace. I found a copy in one of our laptop (I think it was a DELL), so I wasted some time reverse engineering it. The main reason was that at the time the BIOS were still the legacy ones: the limitations still existed in my mind.
The first POC
When the project started, the target was any laptop, so ideally, the idea was to create a Computrace-like extension for the BIOS, to patch the BIOS and reinstall.
That would take time obviously (I’m not talking of the development itself, but the time required to get the firmware, patch it and put back), and there are plenty of vendors out there (Phoenix BIOS, AMI Bios, HP Bios, Insyde, American Megatrends, Flash-ROM with different sizes, no idea of how much space will be available in the Flash-ROM, etc.)
Another non trivial issue was the target would be a Windows Machine, and after Windows XP NTFS had become the filesystem used by the OS, it’s not a simple FAT file system (is easy to to implement a FAT driver also in assembly language).
Except the source code of `NTFS-3G`, some forensic analysis articles and some slides, I didn’t find anything else.
I had to dust off all my tools of the time, the Borland C++ compiler (where else could I find a compiler that could generate x86 code for real mode in 2014?), the Ralf’s Brown Interrupt List, the BIOS Disassembly book, BOCHS, MSDOS distro, UniFlash etc.
Initially I was focused on writing a NTFS driver, trying to keep it simple and light, due the obvious technical limitations (Flash-ROM size, ROM extension reserved memory, etc.).
NTFS and FAT are not exactly the same things.
Writing a file to a FAT volume is very easy:
- Open the FAT volume
- Read the FAT table to find free clusters that you will use to store your content, reserve them, do same stuff in the copy
- Open the directory (so search the directory in the directory tree, access to data through the FAT volume)
- Add an entry if there is space available in the DIRENTRY list, or do an extra allocation in the FAT to grow the directory.
NTFS is different:
- Open the NTFS Volume
- Find the MFT directory, parse it, find an entry record
- Open the Bitmap file, find a contiguous number of free clusters (LCN), mark them as used in the bitmap, create the entry in the MFT
- Open the directory, find the content, add the reference to MFT
- Open the directory index, load everything, insert your record there, resort the tree, rewrite on the disk
- Update everything in the Journal.
All this from an extension that theoritically should have been a maximum of 32kb, a limit of 640Kb of memory shared between stack and heap, and in 16 bit mode (LCN are 64bit records, Borland C++ was a 16-bit compiler which provided a support for 32bit integer).
Simply, at every step I had to work my way around more problems.
In a second moment, I decided to abandon the 16-bit compiler (not at all) and use the Unreal Mode, to switch in 32-bit mode, where I was able to use a 32-bit compiler, perform many steps, but every I/O access it was a switch to 16-bit mode to interact with the legacy BIOS reading and writing a LCN per time.
It was the sum of everything I had learned with our first computer.. protected mode, memory management, dos extenders, literally everything.
I wasn’t seeing the light of the project.
# The second POC
One day, an ACER laptop arrived on my desk, a cheap computer, but it was different.
This computer came with a modern firmware, a UEFI BIOS made by Insyde equipped with a legacy subsystem to run legacy operating system.
The EFI specifications (the TIANO CORE documentation) changed everything.
Finally, I didn’t have to fight with all the legacy limitations and I was able to use a modern 32/64bit compiler, the ROM was organized as volume, like a file system, plus everything well documented.
It was very easy to deal with this technology. EFI/UEFI are a standard, and with the exception of the PEI subsystem responsible for initializing the hardware, you are in front of a system which provides you a rich system of standard APIs, exposed as if they were COM objects.
A memory management already there, all APIs to deal with hard disk and volumes, You are able to use all resources of the machine running directly in 32 or 64bit mode.
No more unreal mode, no more context switch between 16-bit and 32-bit to invoke the interrupt 13h and the most fabulous thing of all.. full supported by QEMU and Minnow-Board for development & debugging.
So, the custom NTFS driver implementation was abandoned in favor of a NTFS-3G porting (taken from Linux kernel), plus something else taken from a Playstation porting of the same driver. Meanwhile the pressure of the approaching deadline was starting to be felt.
Honestly, I didn’t do a really clean job. I had to keep track of all patches to update the NTFS-3G driver one day, but I did not.
A few years later, when I tried to port a new version I realized that I have no idea what I’ve done, I’m almost certain it’s memory alignment problem, I should investigate.
As luck would have it, the BIOS of that machine wasn’t protected in SMM mode, so the first attempt consisted in replaced the ACER logo with the Hacking-Team one and by result money rained down on the project. (a pouring rain, believe me!).
They gave us a maximum budget of 516,46 Euro per laptop (The Italian Bureaucracy fources you to stay under certain costs so as not to have to amortize the cost over several years), a welding machine, a SPI programmer, some other minor other programmers bought from E-bay (with a “no invoice, no refund” policy), and a suitcase with wheels to work from home.
Right in between de-soldered SPIs and grilled meat at home-hosted BBQs, the project was taking shape.
Of course, even in this case, there was a difference between different vendors on how update the flash (image hashing, digital sign validation) but with a bit of luck and some NOP instructions in some UEFI DXE we were able to patch the machines used for tests.
Well, that is true for all but a couple of HPs ended up making a little smoke after our “surgery” due to hand tremors and age-related vision problems.
In the meantime, my colleague also tried CHIPSEC project, a security assessment framework, written in Python.
When he tried CHIPSEC, the execution times were biblical, kind of reading operations from the SPI 1 byte at the time, with a lot of logs.
Retrieving a BIOS of 2Mb it could take several hours, and as usual, the monkey makes you experience different things like disabling log, patching python engine to support memcpy/memset primitives operation on buffer, etc. until we re-eventually rewrote in C the the routines to get the BIOS, unpack it, open volumes, patch it and rewrite the flash memory.
Conclusion
I think this was one of the funniest moments in my Hacking-Team career.
We were working on other features, trying (successfully) to patch BIOSes where SPI protection was enabled, some experiments on Apple Mac-Book, and devising ways to bypass disk encryption.
Sadly, as everyone known, the events of July 2015 changed corporate priorities, putting all research aside and focusing on the new reality.
Overall, I think we have destroyed almost 10 laptop, burned motherboards, others cannibalized, some with de-soldered SPI replaced by sockets to be able to restore at any time… I’m grateful that the administration office never came to ask for the bill!
In the future I hope to find the time to go deeper into this story, publishing other, more technical, articles to illustrate what was just briefly told here.
As a final reassurance, as far as I know, no vulnerability has ever been leaked, because we were storing code but not the BIOSes, the unpacked volumes, the IDB files, or everything else that wasn’t distributed..
Thanks to the members of Memento Mori for taking the time of reviewing this article.
Rereading what I wrote, I was just wondering if without their proposal the project would ever have seen the light of day? I honestly don’t known how to answer, perhaps it would probably have continued at a totally different pace, always favoring the software development due to budget problems.. writing software it’s free, buying hardware is expensive!
