These are the smart way to look at software (firmware) and hardware. The adversary will undermine software and hardware wherever they can in any way they can.
Those looking to protect runtime environments and information from adversaries must strive to increase the difficulty to undermine or intrude for the diverse spectrum of adversaries (and their specific circumstances and capabilities).
How can someone really verify this? If you can run commands on the Minix based OS, how do you run them? If you do have a way to run them, what commands do you run? If instead you run a binary that talks over the HECI/PECI, have you considered that taking what the Minix based system responds with over the HECI/PECI is rather naive?
Have you ever had a binary you compiled yourself successfully execute and run on the processor the Minix based OS runs on? Have you successfully interacted with this binary? If so, what insight was the binary able to provide for the Minix based kernel it was subject to?
You can flip the HAP bit on an Intel ME firmware image and the Intel ME firmware image may successfully run with no detected ill effects (which seems to be the case you experienced), but how can you verify that the HAP bit was not benign?
Igor Skochinskyâs talk that not only brought attention to the Intel ME but provided useful revelations was presented in 2014, more than a half decade after the Intel ME had been deployed to users to be positioned to victimize them.
Other actionable Blackhat talks came nine years later (about a decade). Intel security advisary 00086 was disclosed in the same year.
Mate Kukri introduced Deguard in 2024.
Take a moment to step back from this pattern of calling others liars. Please take a moment to seriously consider this larger picture, the much larger picture. At sixteen years after the Intel ME had been positioned to victimize high-value targets, were machine owners able to meaningfully reign in control of their own property they lawfully own, on a processor reasonably not too ancient, and only on machines that were closer to one decade old (seven years) than they were one half of a decade.
If you have yourself successfully executed code at all on the processor the Minix based Intel ME system runs on (not the same CPU as the Intel Core i5/i7 CPU) on a 12th gen Intel chipset (one that does not have a publicly available exploit like Deguard) in your possession, let alone code that runs in the equivalent context to root or kernel space, then perhaps you can tell this broader community something new with some confidence that does have some substance behind it. But if you do not do this, then weâll have to take what you have posted as what your situation looks like at face value: your asshole is thoroughly exposed.
Might be a bit off topic here, but I created this script which disables the IME on the software level⌠Posting because it may help some people⌠Iâll just copy and paste the readme and script from my GitHub page.
Let me know if you find this useful.
This is a simple script which disables and neutralizes the IME (Intel Management Engine) on the software level. Created for Qubes OS, but will probably work on most other linux distros tooâŚ
------- INSTRUCTIONS -------
Download script from here in any AppVM.
Copy script to dom0:
qvm-run --pass-io VM_NAME âcat /home/user/ime_neutralize.shâ > /home/USERNAME/ime_neutralize.sh
Make script executable:
sudo chmod +x ime_neutralize.sh
Run script with sudo:
sudo ./ime_neutralize.sh
Reboot system:
sudo reboot
Once back in system, run:
lsmod | grep mei
Zero output means the neutralization was successful.
Annnd the script:
#!/bin/bash
set -e
echo "------- Intel ME Neutralization Script -------"
echo "[*] Writing configuration to '/etc/modprobe.d/50-blacklist-mei.conf'..."
cat << 'EOF' | sudo tee /etc/modprobe.d/50-blacklist-mei.conf > /dev/null
blacklist mei
blacklist mei_me
blacklist mei_hdcp
blacklist mei_gsc
blacklist mei_gsc_proxy
blacklist mei_pxp
install mei /bin/true
install mei_me /bin/true
install mei_hdcp /bin/true
install mei_gsc /bin/true
install mei_gsc_proxy /bin/true
install mei_pxp /bin/true
EOF
echo "[+] Configuration saved."
echo "[*] Regenerating initramfs (boot image)..."
echo " This usually takes 10-30 seconds. Please wait..."
sudo dracut --force
echo "[+] Initramfs updated successfully."
echo "-----------------------------------------------------------"
echo "[!] DONE. You must REBOOT your computer now."
echo "[!] After reboot, run 'lsmod | grep mei' to verify it is empty."
echo " Zero output means success."
This actually improves general system performance too, because the cpu has freed up resources it would otherwise be using for the MEâŚ
It is also good to use a dedicated PCIE LAN adapter for your Ethernet connection as the IME cannot recognize it to send out outgoing data and basically air-gaps the ME network connection.
https://github.com/Eddie-Burbank/IME-Neutralizer-for-Qubes-OS
Cheers
I think there is a very big difference between worrying about the possibility that there could be a backdoor in Intel ME / AMD PSP, and on the other hand on a security focused forum outright making unsupported claims that there in fact is a backdoor, which is what @de_dust2 was doing. The former may very well be sensible, depending on oneâs threat model, latter is spreading FUD and what I am opposing.
Intel ME (and I assume AMD PSP alike) implements many security features that are available for the regular user to use, including parts of Intel BootGuard, firmware TPMs and that secure execution mode I forgot the name for that can recover the system from a compromised state and attest that. Intel ME also implements support for remote management, which is also available for end users to use, but only for certain models intended for enterprise cooperations.
In my threat model, I worry about Intel ME getting persistently compromised by a remote attacker, as this is the kind of things that is actually documented to happen, and actually worrying for me. For me, running âlspciâ and concluding the Intel ME interface is not there, is good enough, as that means even if my computer is fully compromised at kernel level, Intel ME cannot get compromised too. I obviously also monitor my network with Wireshark, neither UEFI nor Intel ME generate any traffic at all, so can not get compromised that way either.
Theoretically, Intel ME may still run, just without exposed an interface accessible to the regular user levels. However, as NovaCustom and Dasharo has concluded that it is not possible to update the Intel ME firmware without first HAP disabling it, due to race conditions, that suggests HAP disabling it actually does disable the system at a deeper level than soft disabling. They have also concluded that Intel BootGuard wonât work if Intel ME is HAP disabled, but works fine if it is soft disabled, again suggesting the system is actually likely not operating at all, even during early boot when HAP disabled. I trust the NovaCustom and Dasharo developers understand how Intel ME works far better than me, since they actually work with Intel ME to ensure system works when it is HAP disabled. Crucially, they too do not make any statements anywhere about presence of any backdoor, they too have not noticed any, nor any odd or unexpected behavior.
More FUD. At no point have I seen anything that claims Intel have implemented Intel ME with malicious intentions, nor that they have used it as such or been coerced to. Intel ME is one of the subsystems responsible for enhancing hardware security.
Very serious security vulnerabilities in Intel ME has been found many times, yes.
Unlikely, Intel ME does not run on the regular CPU.
This does not disable the Intel ME, and in fact does not even make the interface unavailable to an attacker that has compromised dom0, as they can simply unblacklist it again. HAP disabling is the only method I know for certain disabled Intel ME. I have a question up about soft disabling with people who actually know these things, but hasnât got any definite answer yet whether Intel ME is fully disabled and cannot be re-enabled in that state again.
can you explain this please.
The way I see it, your calling this âFUDâ is an attempt to silence legitimate concerns based on unsupported claims that there isnât a backdoor 
unless maybe youâre willing to share with the class why youâre so sure about this.
I donât know about enterprise folks, all I know is my computer has hidden features that others (god knows who but I can guess) have the password to but I donât, and they can access it at any time without me knowing about it. If you like security so much how does this not bother you? 
You do realize that IME/PSP donât need your OS to know about its operations, right? Itâs not something that lspci or any other software is capable of assessing for certain. This is hardware level crapware that runs outside of user space AND kernel space.
The Intel ME has full read+write access to the memory used by the Core i5/i7 series processor. The reverse is not true.
The Intel ME does not need to be âcompromisedâ, the purpose of the Intel MEâs architecture is to ensure you can always be reliably compromised by the presence of static data loaded into memory.
If this sounds like a âclaimâ to you that is outlandish, it is because you wrote âeven if my computer is fully compromised at kernel level, Intel ME cannot get compromised tooâ, which is the kind of oblivious that is the complete and total opposite of what what I was referred to in what I wrote earlier: âThis is obvious to anyone who knows some basics on how computers work.â
This âeven if my computer is fully compromised at kernel level, Intel ME cannot get compromised tooâ confirms you did not possess the comprehension of basics on how computers work necessary to even enter a discussion about the serious risks of Intel ME.
You were utterly oblivious to: the Intel ME has full read+write access to the memory used by the Core i5/i7 series processor. The reverse is not true.
Given the lucidity of what you have posted I do not doubt that you can comprehend these things but you did not connect the dots. The blind spot is not so much technical but blind spots in human behaviors that you are fortunate enough to have personally remained oblivious to. Maybe some day you will experience something that was not ever expected to happen, although I do not wish this on you.
The Intel ME runs no matter what. The Intel ME does not give a shit what Linux or some other software running on the subordinate CPU does. You can not turn the Intel ME off.
If you comprehended full read+write access to the memory above then you can comprehend why there is NOTHING that Linux/Xen/BSD/illumos/Retardows can do or neglect to do to prevent ANYTHING loaded into memory, any random document or any random web page contents, from talking to the Intel ME.
The Intel ME is the backdoor. From a computer engineerâs perspective it is more like a frontdoor. Itâs the same tactic Microshit did embedding a web browser in the file explorer. The Asahi Linux people commented that Appleâs boards looked more like a Talos II board from RaptorCS and that they do not have a critical single point of compromise reaching into every single peripheral on the board like Intel ME does.
The Intel ME is a frontdoor by design.
The big question to be asked is: security, but on terms defined by who?
Bootguard does not protect the interests of the machine owner. Bootguard protects the interests of someone else.
If Bootguard was for the machine owner then the machine owner would have an accessible means to apply a cryptographic key as the machine owner sees fit. But Bootguard never had this, we had to wait for Deguard to âbreakâ the Intel ME for the machine owner to have some control.
This is not a âpoliticalâ stance this is basic ethical standard.
Every vulnerability disclosed was a backdoor/frontdoor to ring -3, not ring 3, not ring 0, ring -3. Just because you choose to call it something else doesnât make it magically something else after all the whole time it was a 0day.
Here is what the source code for a piece of the Intel ME software stack looked like before the HAP bit was publicly disclosed:
case $HAP in
0))
scan_for_fuck_up_dumb_cattle_lol ;;
1))
things_are_okay_NSA ;;
esac
now here is what the source code for a piece of the Intel ME software stack released to dumb_cattle (NSA/GHCQ gets a separate release, coordinated by ODM) after the HAP bit was publicly disclosed:
// lol dumb fucks
The world doesnât revolve around you and the limits of the perceptions you just happen to experience individually on your own.
These vulnerabilities were essential to flipping the Intel ME to work for the machine owner rather than against the machine owner.
I see you @ryrona ignored the questions I presented in this post which tells us that the answers of whether you have run software of your own volition on the higher privileged processor is no which means you have no idea what happens on that other operating system other than blindly trusting word you get from others. You have never been able to get insight to have any idea what the fuck the thing is doing by your own hands.
Many red team actors have run their code on the Intel ME. Fortunately, some blue team actors have too.
You are not the one who gets to choose if the adversary chooses to intrude on you or not.
The Intel ME is not a subsystem. From the perspective of Intel and the ODMs, the Intel ME is the system.
All of the plausible deniability is baked in by the design. There is no need for coercion, they already know the game, they are 100% on board (no pun intended) with the potential to instantaneously compromise any target to be always there.
HAP bit method is available on all Intel machines?
Which year HAP bit method is starting?
Intel ME is a microcontroller running an RTOS with ring-0 access?
Man, I could not have articulated it better. Bravo @de_dust2. Iâm saving your post to link next time I run into an x86 toxicity denier 
It is available from Intel (CS)ME version 11 and up. Before version 11, it is called AltMeDisable:
Skylake, which is 2015.
Yes, it uses MINIX as the RTOS, although Intel (CS)ME is usually described in security circles as ring -3, with System Management Mode as ring -2 and the hypervisor as ring -1.
ring-0 is most privileged CPU access mode?
There are any forensic studies of the AltMeDisable bit, or the HAP bit
in terms of its effectiveness? What does this BIOS configuration option actually
do? This disables specific IntelME modules present on the SPI flash chips?
The me_clearner method removes these specific firmware modules completely.
The HAP/AltMeDisable switch just prevents these modules from being loaded
into the microcontroller?
I do not intend to silence legitimate concern, and I am absolutely in no way sure there are no backdoors. I am sorry if my messages came across like that. I have not and did not intend to claim there are no backdoors, just that we donât know about any. I am just really fed up with the fact that hard claims about presense of such backdoors are allowed to flourish, as opposited to legitimate concern. There are unfortunately many bad actors who try to scare people away of actually secure systems to less secure systems, and one theme in that direction has been trying to get people to believe new PCs have âNSA backdoorsâ and old PCs donât, so that people buy these old PCs that have many known and easily exploitable microcode vulnerabilities and that are trivial to break into. Me attacking the claims about a presence of backdoor is because I legitimately worry people will fall for this and buy into insecure systems instead, including fellow activists.
How do you know this? What indications have you seen for this.
True statement. Actually, it has more access than this, which is why Intel ME is such an awful design and should be HAP-disabled.
The question here is, what does âdisabling HAPâ actually do? Does it
prevent the IntelME firmware modules from loading? Have not seen any
security paper on this subject.
The firmware is loaded from SPI flash chip into CPU microcontroller along
with CPU microcode.
Microcode is updated to mitigate Spectre vulns, but this class of vulns is
the result of x86 and x86_64 âspeculative executionâ IPCore VDHL/Verilog
It is a CPU architecture design flaw.
RISC-V can mitigate this by changing the instruction set.
ARM is very opaque instruction set and security architecture, not sure
if there is an IntelME equivalent.
FSF Foundation saying Rockchip ARM is most transparent because fewer
firmware binary blobs, firmware modules.
But ARM could have IntelME equivalent easily, just as AMDPSP.
Best option is Intel with me_cleaner, or RISC-V (IMHO).
ARM security is still a mystery to me.
HAP bit and AltMeDisable is still not transparent to me.
From what I have heard, Intel ME still loads, but is halted after initializing the main CPU and other early hardware initialization. So Intel ME is already halted by the time the bootloader is loaded, and wonât start running again other than through a reboot (power cycle).
No, speculative execution has nothing with instruction set to do.
ARM also contain highly privileged running states similar to what Intel ME is running in, but it is up to each device vendor to decide what they want to run there, if anything at all, and typically, if I have understood it correctly, you run some kind of âsecure monitorâ that isolates access similar to a virtual machine, so even code running in those highly privileged running states can be enforced by that vendor provided âsecure monitorâ to not have read or write access to arbitrary RAM or devices. Generally better architecture, depending on what the device vendor do, but similar. Take all of this with a grain of salt, as I only talked to someone who knows these things about all of this, I donât know ARM myself.
IntelME is loaded into the microcontroller, then it retrieves the bootloader from disk, then it checks the HAP bit setting and if disabled (to turn IntelME off)
it stops execution and therefore privileged memory access.
Speculative execution; maybe this is a verilog/vhdl coded IPCore within
Intel CPUs. Sounds like a marketing term.
ARM; âsecure monitorâ who manages this âmonitorâ the user? Some remote
administrator?