In 2012, an industry-wide coalition of hardware and software makers adopted #Secure #Boot to protect against a long-looming security threat.

The threat was the specter of malware that could infect the BIOS, the firmware that loaded the operating system each time a computer booted up.

From there, it could remain immune to detection and removal and could load even before the OS and security apps did.

The threat of such BIOS-dwelling malware was largely theoretical and fueled in large part by the creation of ICLord Bioskit by a Chinese researcher in 2007.

ICLord was a #rootkit, a class of malware that gains and maintains stealthy root access by subverting key protections built into the operating system.

The proof of concept demonstrated that such BIOS rootkits weren't only feasible;
they were also powerful.

In 2011, the threat became a reality with the discovery of #Mebromi, the first-known BIOS rootkit to be used in the wild.

Keenly aware of Mebromi and its potential for a devastating new class of attack,
the Secure Boot architects hashed out a complex new way to shore up security in the pre-boot environment.
Built into #UEFI
—the Unified Extensible Firmware Interface that would become the successor to BIOS
—Secure Boot used public-key cryptography to block the loading of any code that wasn’t signed with a pre-approved digital signature.

To this day, key players in security
—among them Microsoft and the US National Security Agency
—regard Secure Boot as an important, if not essential, foundation of trust in securing devices in some of the most critical environments, including in industrial control and enterprise networks.
An unlimited Secure Boot bypass
On Thursday, researchers from security firm Binarly revealed that Secure Boot is completely compromised on more than 200 device models sold by Acer, Dell, Gigabyte, Intel, and Supermicro.

The cause:
a cryptographic key underpinning Secure Boot on those models that was compromised in 2022.
In a public GitHub repository committed in December of that year, someone working for multiple US-based device manufacturers published what’s known as a #platform #key,
the cryptographic key that forms the root-of-trust anchor between the hardware device and the firmware that runs on it.

The repository was located at github.com/raywu-aaeon/Ryzen2000_4000.git,
and it's not clear when it was taken down.
The repository included the private portion of the platform key in encrypted form.
The encrypted file, however, was protected by a four-character password, a decision that made it trivial for Binarly, and anyone else with even a passing curiosity, to crack the passcode and retrieve the corresponding plain text.

The disclosure of the key went largely unnoticed until January 2023,
when Binarly researchers found it while investigating a supply-chain incident.
Now that the leak has come to light, security experts say
it effectively torpedoes the security assurances offered by Secure Boot.

https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/

Hello! I am back with a project again!
#infosec #reverseeng #backdoor #backdoors #backdooring #hddfwbootkit #bootkit #rootkit

#birthday
It's my birthday today, I turn 24 xD.. Not that that is interesting but, I thought of making a progress post about the HDD Bootkit I was planning to make.

To recap!

Awhile ago I wrote about a hdd bootkit I was gonna make. and I Will copy and paste it BUT!
FIRST I will actually post real progress, I have now got to Project "1", which is to unscrew hard disks cover, identify the cpu n stuff, get schematics, wire stuff, debug, and load hello world on it. simply put that's "project 1".

Project 2, is to "take project 1's hello world" and turn it into a 'hdd firmwre bootkit'.

I will copy the links here.

Link 1: https://www.linkedin.com/posts/william-martens-16872717b_hard-disk-hacking-intro-activity-7184950421034070016-3SLA?utm_source=share&utm_medium=member_desktop

I will copy paste the text I wrote below.
==============================

Hello!
I wrote a post some weeks ago, about this project - me making a bootkit for a firmware of a HDD, and/or a SSD's controller cards.

Many of you most likely wonder what's taking so long to even make a update on it?

And the truth is, I just had to get a special set of 'screwdrivers' (I think, many will laugh now but this is actually the first step, to open up any disk's 'case' to be able to see what CPU and all that is) you have to, (I had to at least) use a "TorxScrewDriver" or something along those paths.

So, Now I got it and I will begin the first step, namely the
"Pre-Research part". What's that? I call it that cuz, now I have to open them up, see what CPU and stuff they are using, note all of this down.

Then it's part 2, namely the "Research" Part. What is done here? For me, it's googling about resources, writing a report on what it's uses, and what schematic(s) (if any) is available.

Then, part 3 is the "Debugging" part. Here, as the name suggests, is to try to debug it using the report from Part 2.

Part 4 is the final step in the POC(Proof Of Concept) project. This is to take step 3 and make a software, and load it and run it. This will simply be a hello world project to begin with. To just, using the hardware of the Disk itself, write out, in debug print outs, "Hello World".

And this is the "project number one", Project 2.. Will the post I wrote about

Part 2 (probably already posted but)
===================
https://www.linkedin.com/posts/william-martens-16872717b_hard-disk-hacking-intro-activity-7177941239516782592-zXrG?utm_source=share&utm_medium=member_desktop

I will begin reversing some HDD/SSD's, to see if I can replicate spritesmods hdd hack ( https://spritesmods.com/?art=hddhack )
(and, part 2, 3 , etc)

And, reading up on it this is another great article

( https://malwaretech.com/2015/04/hard-disk-firmware-hacking-part-1.html )
(and, part 2, 3 , etc)

When I say "I will post the progress" or something along those lines, I will post it on my GitHub.

I will, of course, NOT post the reversed firmware or stuff like that, cuz.. that would'nt be any good for obvious reasons. Instead I will just show what I can achieve, like at least one but probably more than the below:
- backdoor the firmware (persistence)
- make hidden sectors (possibly using encryption and or obfuscation with some steganography)
- kleptography(detect CRYPTO operations to gather the priv keys and store it either a) in the chip(like the firmware), b)in the hidden sector or c) in another way, possibly transmitting it to elsewhere)
- Run Linux on it. Yes. The Linux Kernel if possible.

I will try some stuff I believe will be the first things one tries before, breaking the HDD/SSD open and try for JTAG, cuz, what about if there's no jtag? Or, "better" (worse) if there may be jtag but it's obfuscated? I mean there's no real good thing for companies to label "here we got jtag! so you can hook it up to a machine if you want to debug it!" no no, quietness is what it is. Heh. (By the way that's the same with datasheets, it's not something just 'given out') <- At least.. Not with my experience.

- JTAG (of course)
- Serial (even if some of these might not achieve anything we want, we should just begin small)
- See some pinouts
- other known "ports"
- datasheets
- schematics

This will not only be "a project" on its own, it's a major part (the first part, actually) for something much bigger.

Alright! have a great day people! Wishes from Sweden!