Gov Spyware

Abstract. This paper is a short summary of a real world AES key extraction performed on a military grade FPGA marketed as 'virtually unbreakable' and 'highly secure'. We demonstrated that it is possible to extract the AES key from the Actel/Microsemi ProASIC3 chip in a time of 0.01 seconds using a new side-channel analysis technique called Pipeline Emission Analysis (PEA). This new technique does not introduce a new form of side-channel attacks (SCA), it introduces a substantially improved method of waveform analysis over conventional attack technology. It could be used to improve upon the speed at which all SCA can be performed, on any device and especially against devices previously thought to be unfeasible to break because of the time and equipment cost. Possessing the AES key for the ProASIC3 would allow an attacker to decrypt the bitstream or authenticate himself as a legitimate user and extract the bitstream from the device where no read back facility exists. This means the device is wide open to intellectual property theft, fraud and reverse engineering of the design to allow the introduction of a backdoor or Trojan. We show that with a very low cost hardware setup made with parts obtained from a local electronics distributor you can improve upon existing SCA up to a factor of x1,000,000 in time and at a fraction of the cost of existing SCA equipment.

cl.cam.ac.uk/~sps32/AES_in_the_blink_draft.pdf

This is one of the scariest papers I read in a while…

Search Google for 9C5A203A if you want to enter the rabbit hole……

At first I thought that somewhere I was mistaken, I did not understand something, I forgot something. I checked everything up to the last bit in my code, I did not find any mistakes and began to sin not on myself, but on my colleagues because of the hillock.

First of all replaced the processors, but it did not help. On motherboards at that time, the virtualization hardware was only in the BIOS, where it was initialized when the server was turned on, so I started comparing the BIOSes on motherboards (the same type of motherboard with samples) - everything was the same as the byte and the BIOS number itself. I fell into a stupor and, no longer knowing what to do, applied the last resort - the "method of poking." What I did not do, no longer thinking, but simply combining, and in the end stupidly downloaded the bios from the official site of Intel and rewrote them again in the motherboard, after which it all worked …

To my surprise there was no limit: the BIOS number was the same, the images of the BIOS coincided byte by byte, but for some reason the serial motherboards earned only when I filled them with the same bios taken by the Intel site. So, the reason is still in the motherboards? But the only difference was in the marking: samples were written Assembled Canada, and on serial cards - Assembled China. It became clear that the fees from China contain additional software modules, stitched in the BIOS, and the standard analysis programs did not see these modules. They, apparently, also worked with virtualization equipment and, accordingly, had the opportunity to hide the true contents of the BIOS. I became aware of the reason for my hyperdrive hangs on these Chinese boards: two software systems simultaneously worked with the same virtualization equipment, which did not allow me to share my resources. I wanted to deal with this malicious bios, and without any backward thought about "bookmarks", "backdoors", "undocumented opportunities," was just academic interest, and nothing more.
…….
The totality of the facts alarmed and led to paranoid thoughts in the style of spy detectives. These facts unequivocally spoke about the following:

In the new Intel-based serial server boards based on the chipset 5000, there are programs stitched in the flash memory of the IUD unit and executed on the central processor, and these programs work with virtualization hardware from the central processor.
Images of flash memory from the official site of Intel do not contain such software modules, therefore, the software modules interfering with me were illegally stitched into motherboards at the production stage.
The flash memory of the IUD block contains encrypted program modules that can not be collected and poured into flash memory without knowledge of the encryption keys, therefore, the one who inserted these illegal program modules knew the encryption keys, that is, it had virtually access to classified information.

Inside every modern CPU since the Intel Pentium fdiv bug, assembly instructions aren’t a one-to-one mapping to what the CPU actually does. Inside the CPU, there is a decoder that turns assembly into even more primitive instructions that are fed into the CPU’s internal scheduler and pipeline. The code that drives the decoder is the CPU’s microcode, and it lives in ROM that’s normally inaccessible. But microcode patches have been deployed in the past to fix up CPU hardware bugs, so it’s certainly writeable. That’s practically an invitation, right? At least a group from the Ruhr University Bochum took it as such, and started hacking on the microcode in the AMD K8 and K10 processors.

The hurdles to playing around in the microcode are daunting. It turns assembly language into something, but the instruction set that the inner CPU, ALU, et al use was completely unknown. [Philip] walked us through their first line of attack, which was essentially guessing in the dark. First they mapped out where each x86 assembly codes went in microcode ROM. Using this information, and the ability to update the microcode, they could load and execute arbitrary microcode. They still didn’t know anything about the microcode, but they knew how to run it.

So they started uploading random microcode to see what it did. This random microcode crashed almost every time. The rest of the time, there was no difference between the input and output states. But then, after a week of running, a breakthrough: the microcode XOR’ed. From this, they found out the syntax of the command and began to discover more commands through trial and error. Quite late in the game, they went on to take the chip apart and read out the ROM contents with a microscope and OCR software, at least well enough to verify that some of the microcode operations were burned in ROM.

cont. (1/2)

The result was 29 microcode operations including logic, arithmetic, load, and store commands — enough to start writing microcode code. The first microcode programs written helped with further discovery, naturally. But before long, they wrote microcode backdoors that triggered when a given calculation was performed, and stealthy trojans that exfiltrate data encrypted or “undetectably” through introducing faults programmatically into calculations. This means nearly undetectable malware that’s resident inside the CPU. (And you think the Intel Management Engine hacks made you paranoid!)

[Benjamin] then bravely stepped us through the browser-based attack live, first in a debugger where we could verify that their custom microcode was being triggered, and then outside of the debugger where suddenly xcalc popped up. What launched the program? Calculating a particular number on a website from inside an unmodified browser.

He also demonstrated the introduction of a simple mathematical error into the microcode that made an encryption routine fail when another particular multiplication was done. While this may not sound like much, if you paid attention in the talk on revealing keys based on a single infrequent bit error, you’d see that this is essentially a few million times more powerful because the error occurs every time.

The team isn’t done with their microcode explorations, and there’s still a lot more of the command set left to discover. So take this as a proof of concept that nearly completely undetectable trojans could exist in the microcode that runs between the compiled code and the CPU on your machine. But, more playfully, it’s also an invitation to start exploring yourself. It’s not every day that an entirely new frontier in computer hacking is bust open.

github.com/RUB-SysSec/Microcode
media.ccc.de/v/34c3-9058-everything_you_want_to_know_about_x86_microcode_but_might_have_been_afraid_to_ask

So what you are saying is that, Zig Forums-user is considered a serious threat?
Now thats a start.

>Kali
That's the most unsafe Linux distro, user. A lot of security features have been disabled, so that its tools would work better.