The Empire Strikes Back Apple – how your Mac firmware security is completely broken

If you are a rootkits fan the latest Chaos Communication Congress (CCC) in 2014 brought us two excellent presentations, Thunderstrike by Trammell Hudson and Attacks on UEFI security, inspired by Darth Venami’s misery and Speed Racer by Rafal Wojtczuk and Corey Kallenberg.

The first one was related to the possibility to attack EFI from a Thunderbolt device, and the second had a very interesting vulnerability regarding the UEFI boot script table. The greatest thing about the second vulnerability is that it allows to unlock flash protections by modifying the boot script executed after a S3 suspend-resume cycle.

Dmytro Oleksiuk aka Cr4sh released proof of concept code regarding this attack against an Intel DQ77KB motherboard. His very interesting blog post is “Exploiting UEFI boot script table vulnerability”. You should definitely read it.

My interest in EFI has been mostly about unlocking a firmware password that I forgot. While Trammell didn’t release the proof of concept code for Thunderstrike he did release an awesome tool, a SPI Flash reader for Teensy 2.x that is extremely fast reading the BIOS contents (takes a few minutes). This was a great improvement versus BusPirate which took hours to just read the BIOS memory. Months before I tried to get into EFI world but the BusPirate was so slow it was impossible to use it for trial and error testing. The new tool got my interest back into EFI. Anyway, enough bla bla.

Trammell on his presentation mentioned the possiblity that Macs could also be vulnerable to the Dark Jedi attack. After Cr4sh blog post I decided to give it a try and explore the same attack.

The attack requires you to reverse the boot script implementation, which is a royal pain in the ass. EFI binaries are a bit annoying to reverse even with the assistance of Snare’s EFI utils. IDA also has some bugs regarding EFI binaries.
While doing some experiments with flashrom I finally noticed something big. I couldn’t believe it the first time so I tried it in other Macs and it was indeed true. Macs have an even bigger hole than Dark Jedi.

Drum roll…

What is that hole after all? Is Dark Jedi hard to achieve on Macs?
No, it’s extremely easy because Apple does all the dirty work for you. What the hell am I talking about?
Well, Apple’s S3 suspend-resume implementation is so f*cked up that they will leave the flash protections unlocked after a suspend-resume cycle. !?#$&#%&!#%&!#

And you ask, what the hell does this mean? It means that you can overwrite the contents of your BIOS from userland and rootkit EFI without any other trick other than a suspend-resume cycle, a kernel extension, flashrom, and root access.

Wait, am I saying Macs EFI can be rootkitted from userland without all the tricks from Thunderbolt that Trammell presented? Yes I am! And that is one hell of a hole :-).

Let me show you how it happens. The following is the flashrom output of a freshly rebooted MacBook Pro Retina 10,1 running the latest EFI firmware available (this is the firmware that was released to “fix” Thunderstrike).

sh-3.2# ./flashrom -r biosdump -V -p internal
flashrom v0.9.7-r1711 on Darwin 14.3.0 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org
 
(...)
Found chipset "Intel HM77" with PCI ID 8086:1e57.
(...)
BIOS_CNTL = 0x01: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
Root Complex Register Block address = 0xfed1c000
GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI)
Top Swap : not enabled
SPIBAR = 0xfed1c000 + 0x3800
0x04: 0xe008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1
Warning: SPI Configuration Lockdown activated.
Reading OPCODES... done
0x06: 0x0004 (HSFC)
HSFC: FGO=0, FCYCLE=2, FDBC=0, SME=0
0x50: 0x0000ffff (FRAP)
BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff
0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write.
0x58: 0x07ff0190 FREG1: BIOS region (0x00190000-0x007fffff) is read-write.
0x5C: 0x018f0001 FREG2: Management Engine region (0x00001000-0x0018ffff) is read-write.
0x74: 0x866f0190 PR0: Warning: 0x00190000-0x0066ffff is read-only.
0x78: 0x9fff0692 PR1: Warning: 0x00692000-0x01ffffff is read-only.
Writes have been disabled for safety reasons. You can enforce write
support with the ich_spi_force programmer option, but you will most likely
harm your hardware! If you force flashrom you will get no support if
something breaks. On a few mainboards it is possible to enable write
access by setting a jumper (see its documentation or the board itself).
0x90: 0xc0 (SSFS)
SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0
0x91: 0xf94000 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=1
0x94: 0x0606     (PREOP)
0x96: 0x3c6c     (OPTYPE)
0x98: 0x0103029f (OPMENU)
0x9C: 0xffd82005 (OPMENU+4)
0xA0: 0x00000000 (BBAR)
0xC4: 0x00800000 (LVSCC)
LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=1
0xC8: 0x00002005 (UVSCC)
UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0
0xD0: 0x00000000 (FPB)
(...)

What we can see here is that the flash lockdown is active (FLOCKDN=1) and that the BIOS region is mostly read-only. The hole that is writable is the NVRAM portion that is necessary for setting boot options, crash logs and so on. The addresses where EFI binaries are located is lock down by the flash protections (PR0/PR1). The Dark Jedi attack would allow to unlock these areas and make them writable.

After I close the MacBook and let it sleep for a few seconds (30 seconds or something is best, sometimes it doesn’t work and needs to sleep some extra time), we get the following flashrom output after waking up the machine:

sh-3.2# ./flashrom -r biosdump2 -V -p internal
flashrom v0.9.7-r1711 on Darwin 14.3.0 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org
(...)
Found chipset "Intel HM77" with PCI ID 8086:1e57.
(...)
BIOS_CNTL = 0x01: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
Root Complex Register Block address = 0xfed1c000
GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI)
Top Swap : not enabled
SPIBAR = 0xfed1c000 + 0x3800
0x04: 0x6008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=0
Programming OPCODES... done
0x06: 0x0004 (HSFC)
HSFC: FGO=0, FCYCLE=2, FDBC=0, SME=0
0x50: 0x0000ffff (FRAP)
BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff
0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write.
0x58: 0x07ff0190 FREG1: BIOS region (0x00190000-0x007fffff) is read-write.
0x5C: 0x018f0001 FREG2: Management Engine region (0x00001000-0x0018ffff) is read-write.
0x90: 0xc0 (SSFS)
SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0
0x91: 0xf94000 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=1
0x94: 0x5006     (PREOP)
0x96: 0x463b     (OPTYPE)
0x98: 0x05d80302 (OPMENU)
0x9C: 0xc79f0190 (OPMENU+4)
0xA0: 0x00000000 (BBAR)
0xC4: 0x00800000 (LVSCC)
LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=1
0xC8: 0x00002005 (UVSCC)
UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0
0xD0: 0x00000000 (FPB)
(...)

This time we have FLOCKDN=0 and the protected range registers (PR0/PR1) without any contents. The flash is unlocked and now you can use flashrom to update its contents from userland, including EFI binaries. It means Thunderstrike like rootkit strictly from userland.

Which Macs are vulnerable to this?

I have tested against a MacBook Pro Retina 10,1, a MacBook Pro 8,2, and a MacBook Air 5,1, all running latest EFI firmware available. And every single one is vulnerable. The Late 2013 Mac Pro (aka Trashcan), MacBook Pro 9,1 are also tested to be vulnerable.
It appears that latest MacBook models are not vulnerable but I’m not 100% sure about this. I couldn’t fully test it on a recent model (the owner was afraid of giving me root access ;-)). The first impression was that the bug was silently fixed by Apple but this requires extensive testing to be sure (or some EFI binary disassembling).
I expect all mid/late 2014 machines and newer to not be vulnerable. Apple either fixed it by accident or they know about it. It’s not something you just fix by accident, just sayin’.

I’m pretty sure Apple is aware of the bug or at least it would be quite irresponsible from them to not test if their BIOS implementation was vulnerable to the Dark Jedi attack. I had no issues doing PoC tests with it but definitely needs other people to test it out (at least to find which other Macs are vulnerable).

How can you protect yourself from this?
Do not let your computer sleep and always shutdown it.
You should also email Apple and demand firmware security fixes for this bug and others to be presented at Defcon 23 – ThunderStrike 2: Sith Strike.
This is not full protection since the full Dark Jedi is most probably still possible to execute. The only real fix is Apple to update the firmware.

Unfortunately I never finished reversing the S3 suspend-resume EFI binaries so I can’t show exactly where the bug is inside the code. It requires some improvements to current EFI reversing tools and other matters got higher priority than this.

There is also something funny. Flashrom requires DirectHW.kext to work. The funny thing is that this kext is on Apple’s exception list so no kext signature is required to load this one on Mavericks/Yosemite ;-).

Oh, is this irresponsible disclosure? Well I’m pretty sure Apple knows about this one but I could be very wrong. I’m confident Corey and Trammell disclosed this one to Apple and they will discuss it on their upcoming Defcon talk. If I’m wrong I just wasted a nice and valuable bug. Ooops!!!!
Either way the goal is to pressure them to fix their firmware. It doesn’t seem they are in a hurry ;-).

Why no fancy logo and name?
Well, because this is a variation of the Dark Jedi attack and I’m old school. I still believe knowledge should be shared for everyone to learn instead of PR whoring. And I already get enough PR from this blog ;-).

Update:

It appears I miscalculated this thing and appears to be an effective 0day. Doesn’t really matter since I always wanted to disclose it and not sell it due to its very powerful nature (and not working in newer machines). Never assume all bugs are shallow.

You might ask if I am into something against Apple judging by the tone of some posts. I am not. I like OS X and I respect Apple security people who I met a few times. My goal is to make OS X better and more secure.
The issue at stake is that I believe Apple has a corporate culture problem regarding security (like Microsoft had many years ago) and they only seem to react when pushed against a corner. If they indeed knew about the bug – because I don’t believe it’s a coincidence not working in latest machines – then they keep their pattern of not patching older versions. This is a bad policy and at least if they want to put it in practice at least be straightforward with customers and warn them about the issues. People can then take informed decisions about their risks. Of course this is wishful thinking and they will not shoot their own foot coming forward with things like this. But that’s a philosophical discussion about management around the world and why it’s so wrong these days.

How can you mitigate/detect a possible EFI compromise?

You can build a SPI dumper and use Trammell’s software to directly dump the BIOS chip. Then you can compare its contents against the firmware files provided by Apple. I asked Apple to start publishing these files and their signatures so we can have a good baseline to compare against. Hopefully they will do this one day. I built some tools for this purpose but they aren’t public.
This solves the EFI problem but others are left. For example there is SMC. Alex Ionescu made a very interesting presentation about it a few years ago at NoSuchCon. SMC has a very interesting potential for compromise so it’s also something that needs more research. And now we have PoC regarding GPU rootkits. Every single chip that has firmware and somehow talks to the operating system is open for compromise. We need to think different and start a trust chain from hardware to software. Everyone is trying to solve problems starting from software when the hardware is built on top of weak foundations.
Apple has a great opportunity here because they control their full supply chain and their own designs. I hope they finally see the light and take over this great opportunity. Google is trying with Chromebook.

Is physical access required to exploit this bug?

No, there’s no physical access required to exploit this. You can trigger sleep with “sudo pmset sleepnow” (thanks Trammell). And then you just wait to come back from sleep and continue exploitation.

How to test for this bug?

Downloading DarwinDumper and load the DirectHW.kext kernel extension. Then you can use flashrom with “flashrom -r biosdump -V -p internal” to dump the bios and show the register contents. Else you can compile yourself DirectHW.kext and also flashrom. DarwinDumper just works out of the box and its kext appears to be legit (it’s on Apple exclusion list so at least Apple trusts it ;-)).

Should you be worried about this bug?

As a general user you shouldn’t, in theory, be much worried with this bug more than you were with Thunderstrike. This is a bug more interesting to attack targeted users than mass exploitation, although a drive-by exploit is definitely feasible.
There are easier and cheaper attacks available against you the general user. As a reminder the latest Mac botnet infected around 17k users just by asking them for administrator privileges. Sophisticated attacks are not required when simple things still work.

Have fun,
fG!

P.S.: The bug can be used with a Safari or other remote vector to install an EFI rootkit without physical access. The only requirement is that a suspended happened in the current session. I haven’t researched but you could probably force the suspend and trigger this, all remotely. That’s pretty epic ownage ;-).

71 thoughts on “The Empire Strikes Back Apple – how your Mac firmware security is completely broken

  1. I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened.

    1. What is frustrating is that this is only tested and documented, and blogged, and noticied and advertised when it works against Apple.

      When it’s a random PC vendor? Nevermind…

      1. Well that is not true.
        Corey and a few ex-Mitre guys just founded a company to continue their firmware work post Mitre.
        They are making a lot of noise regarding BIOS firmware and all its vulnerabilities.

        And a random PC vendor isn’t the world’s biggest public company 😉

  2. When you’ve got an 11-figure bank account and uncountable legions of iZombies, little things like epic security holes don’t amount to much. Maybe if the bug caused Satan to arise and destroy the Earth… but even then I’d have my doubts.

  3. Hi,

    flashrom maintainer here… indeed, the bus pirate is one of the slowest external programmers flashrom supports, but there is a number of others, including AVR-based ones with a similar protocol (named serprog) like what Trammel implemented. It was also implemented on ARM providing a 36MHz SPI clock. Other SPI-capable programmers include the BeagleBone Black, RaspberryPi and all other Linux-based devices with a spidev driver… Apparently our PR is not good enough, since Trammel missed and the author of this article missed all of that. :/

    1. Hi,

      Your PR is definitely bad. I know flashrom’s programmers page. It wasn’t clear at the time and still not at least to me what I can use and how I can use it.
      Trammell stuff is pretty straight to the point and just works. Bus Pirate also had good documentation at the time so that was the reason why I started with it (and a friend having one).

  4. Works on MBP9,1
    Deep sleep is not affected. One may want to setup a short deep sleep delay as a workaround.

    1. Could you please tell me the Intel chipset version? It’s right on the beginning of flashrom output.
      Thanks!

  5. This is all pretty technical. Are my Mac and MacBook Air vulnerable from hackers out side my network? Are my router and firewall protecting my Mac’s from this exploid? Does the hacker have acces to the same network I am using?

    1. It’s easy. If your computer is connected to the internet, you browse websites, run applications downloaded from the internet then yes, you are potentially vulnerable to this and all other attacks there are out there.

      Solution, disconnect the computer from the internet and go read a book.

  6. Hi! Thanks for this awesome research work! I just tested flashrom on a Macbook Pro 5,1 (2008 Unibody with nVidia chipset) and it doesn’t seem affected (or if it is, flashrom can’t give information about it) . Here’s the log dump :

    Found chipset “NVIDIA MCP79” with PCI ID 10de:0aae.
    This chipset is marked as untested. If you are using an up-to-date version
    of flashrom *and* were (not) able to successfully update your firmware with it,
    then please email a report to flashrom@flashrom.org including a verbose (-V) log.
    Thank you!
    Enabling flash write… This chipset is not really supported yet. Guesswork…

    There was no “read-write” string in the rest of the log stream.
    The biggest mistake Apple did here is keeping DirectHW.kext in their whitelist. It really looks like a developer mistake to me. I hope they’ll fix it soon!

    1. Your log dump is incomplete so I can’t understand if it’s vulnerable or not.
      Flashrom warnings are usually not a big problem.

      DirectHW.kext is not a problem. Kernel code signatures are easy to bypass and don’t pose any problem for this attack.
      It’s just a nice thing to have DirectHW.kext whitelisted, not a big deal.

      1. DirectHW.kext got blacklisted in El Capitan. Not sure if there’s a workaround for that, or how to see if your EFI got owned prior to updating to El Cap..

        1. Compile your own, get a kernel certificate.
          And the only way to reliable dump is via hardware, software can be easily hijacked by a rootkit.

    1. Probably. That would also probably blow up the Mac in long term since I doubt its hardware designs will support overclocking.

  7. I’m a little lost here…..the user wouldn’t give you root access? Why would you need root access to test? Most users are admins on their Macs, is it still vulnerable as a normal user without admin privileges?

    1. The vulnerability has nothing to do with user privileges.
      Root is required because the DirectHW.kext requires it to communicate with it.

        1. Root access is required to test and to modify the firmware.
          Root access is not very difficult to exploit in OS X.
          So root access it *not* a barrier against using the bug to install an EFI rootkit in a vulnerable machine.

  8. Hi!

    Does it make a difference if I change the sleep type of my Mac? I could for example change the standard safe sleep to hibernate with sudo pmset -a hibernatemode 1. Does this prevent the exploit? I am really afraid of this bug and I am not sure that Apple is going to fix this…….

    1. No it shouldn’t make any difference.
      Unless you are 007 the chances of someone attacking you with an EFI level rootkit are extremely low.

      1. I checked this with DarwinDumper. After changing to Hibernate instead of Sleep, FLOCKDN stays at 1 after waking up. So ist seems that this maybe a workaround for older machines!

          1. I also configured my Mac with “sudo pmset hibernatemode 25” to always suspend-to-disk. When I perform “pmset sleepnow” and wakeup the Mac FLOCKDN stays at 1. When I use suspend-to-ram, then I can reproduce FLOCKDN is set to 0 after wakeup.

            1. Nope, hibernatemode 25 doesn’t work as workaround.
              Any suspend/resume cycle will trigger the S3 sleep which is where most probably the failure.
              Changing hibernatemode settings should not work disable the vulnerability itself.

              1. I understand that the hibernatemode doesn’t fix the vulnerability itself. But is there a way to trigger suspend-to-ram without changing the hibernatemode? If not, then this workaround could help to make an old Mac a bit more secure. If not, then why don’t we geht FLOCKDN=0 when changing the hibernatemode?

                1. You can’t suspend the computer because that will trigger the bug. Doesn’t seem to matter the type of suspension because at low level it triggers the same things.
                  I have no idea why you are not getting it, I can’t see what you are doing. I tested both modes on my machine and they don’t change anything regarding this.

                  1. That’s interesting. I tested it on a Mac mini (Late 2012). Maybe it only works on desktop Macs. I thought the workaround works because the Mac is turned off after saving the RAM state to disk. So turning the Mac on again is different form just waking up.

          2. I did not hope to solve this with the hibernate mode. But as I am working as a normal user I should be a bit safer with this mode. As I understand you need admin rights to force a Mac to sleep with sleepnow. As a normal User I should get a question for the admin PW, or not? sorry if this is all wrong what I write I am only a normal User without any deeper Knowledge of the system…..

            1. You are as safe as the next unknown exploit that might run code on your computer or the next download you make, pirate or not, and so on.
              Unless you are someone really important it’s a low bug risk against you. There’s also a possibility someone is just waiting to launch chaos against Macs but I doubt it.

    1. Probably you have no idea how easy it is to achieve root access in OS X.
      So yeah, it’s not a big obstacle these days 😉

      1. But one can compromise and break almost any system in many ways by achieving root access, so what’s the big news?

        Of course any security hole found should be fixed, agree 100% on that.

        1. Root access compromise is lower quality than EFI level compromise.
          An EFI rootkit can persist for a long time, and a root compromise shouldn’t be able to compromise EFI firmware contents.

          There’s a considerable difference between them.

  9. Is there any Apple forum or location where we should be bringing this up to Apple, or waiting for a response from them? I work at a college with 250+ Macs in our environment and am worried about this.

    1. Apple support forums at https://discussions.apple.com/welcome is probably a good starting point.
      You should probably email Tim Cook and report your concerns.
      This particular bug is most probably low risk for your environment but there are other bugs and and general Apple attitude towards security that you and others should care about with such considerable Mac environments.

  10. If you have access enough to invoke suspend, install a kext, then run flashrom; this exploit is redundant..

    1. This is getting boring but no it’s not redundant.
      EFI and other firmware level rootkits (hard disk for example) will survive reboots, EFI/BIOS updates, and reinstalls.

  11. Latest DarwinDumper issues a “not verified developer” security error, didn’t you say that the binary is trusted by Apple ?

      1. Latest version is 2015-03-13, well before this post. What is your current setting in “Allow applications downloaded from” ?

        1. Are you talking about the kext or download?
          The kext is whitelisted, the download I don’t know.
          I don’t use Gatekeeper.

          1. I meant the latest DarwinDumper version, so I was more certain that you ran same version.

            And yeap, Gatekeeper blocks it when you don’t config it to allow all apps.

  12. A question from one who’s skills extend no further than using Wireshark to monitor traffic through a soft AP on a Windows 7 box (and of course on the MBP itself). Would this exploit be able to bypass Wireshark’s ability to monitor outbound traffic on this mid-2014 MBP 13.3″ i5 Retina Yosemite 10.10.3 (that’s with the hope that it may have the “we didn’t fix nuttin’ ” fix from Apple)? Tia…

  13. Could you tell me what the best/easiest way to check if this is affecting my Mac please?

    I’ve had problems with my Mac for well over 18 months; looks like it’s been hacked and someone’s been accessing my photos, the camera and the microphone, lots of traffic to & from it when it’s not being used, console logs show weird & random things happening, settings being changed on the firewall/proxy, seemingly altering search results in Google, etc.

    It’s been formatted & reinstalled numerous times but the same problems keep coming back, sometimes even immediately after a fresh install. I thought the BIOS may have been affected previously but until now I wasn’t able to find anything like this online.

    I’ve stopped using it for anything other than browsing the Internet, but I’d really like to have it back to normal!

    Thank you.

    1. There’s no easy way to test it. You need to build a flash dumper, open the Mac and dump it, and verify the firmware integrity against a valid update.

      I doubt you have a EFI rootkit. Your reinstall is probably bogus and you are using some infected software after you reinstall.

  14. Can you post how to do this? >> “You need to build a flash dumper, open the Mac and dump it, and verify the firmware integrity against a valid update.”

  15. Well, this is interesting.
    Step 1: Open BIOS Area
    Step 2: Insert as much of Oh, say… The Art of War, converted to a bitstream… as fits. (With modifications, as needed, to keep the thing from dead choking
    Step 3: Trigger (the last) a reboot.
    Step 4: No BIOS, No Fun.

    Bricked Mac
    varient1 = Brick an office computer from Dell.
    Varient2=Brick ALL THE THINGS.

    Sure, you can go around, booting from a floppy into…oh, wait…..
    Sure, you can go around, replacing the BIOS chips by hand.
    I am SURE that companies like Dell /Apple have racks and racks of such.
    And that ALL of their boards have this chip in a socket(not since about 2005)

  16. So now that Apple have apparently issued an EFI firmware update, I assume I am safe against this rootkit.
    But hypothetically, if I had already been infected, would the security update 2015-006 remove that?

    Thanks for your research!

    1. It depends. A well designed rootkit would survive to that (a proof of concept of this was presented at NoSuchCon 2013).
      If you are a target of such kind of rootkit you probably have bigger problems 😉

      The only reliable way to be sure is to dump it via SPI and analyse/compare its contents.

      Best,
      fG!

  17. Thanks for fucking me and everyone else with your careless disclosure. If you have a few grand lying around to get me some new machines, that’d be great. Fuck you.

    1. Honestly, you are not that important that you are a target of an EFI rootkit.
      Say thank you to Intel and Apple for their fuck ups, not me.

Leave a Reply

Your email address will not be published. Required fields are marked *