If I want a secure computer should I go with an older one with no intel ME or a newer one with secure boot and TPM?

  • 🔧 Actively working on site again.
Rusty Crab said:
all this stuff about bootloaders can be circumvented with rubber hose cryptography.
Click to expand...
i hate to be a buzzkill but boot attacks are most useful for when you dont want the victim to know they've been compromised
encryption and obfuscation is defeated by rubber hose
 
Likely said:
Yes, and kernel driver signing cannot be trusted without full boot chain of trust.

If someone compromises the bootloader, they have compromised the kernel.
If they have compromised the kernel, they have compromised driver verification.
Click to expand...
And I've talked about the whole chain in the post above yours.

It's still wrong to say that Secure Boot stopped drivers being a common target to infect.
Driver signing is much older (since Vista) and more widespread than Secure Boot (since Windows 8 ). This plus putting more drivers into user space is the actual reason drivers were less targeted.

The actual motivation for Secure Boot was to avoid someone defeating full-disk-encryption by hooking into the boot loader and injecting a fake password prompt. In a so-called Evil Maid Attack. Not to avoid kernel drivers getting infected.
Persistence after a simple reboot once the whole system is already compromised was never a hard problem for an attacker.
 
Last edited:
  • Dumb
  • Thunk-Provoking
Reactions: Likely and lemmiwinks
byuu said:
I've talked about the whole chain
Click to expand...
dude

wtf

fuck

there is something so fucking innately sexy about this i just can't

from now on @byuu you fucking own my soul bb. IT's yours. Better or worse. Richer or kek even moar richer dw bb i'm fucking loaded.

And whatever else comes our way, bb
We'll face it, head on
well
ass onn
given the physics of things etc

dm me bb
 
  • Deviant
  • TMI
Reactions: Bongocat and lemmiwinks
byuu said:
Persistence after a simple reboot once the whole system is already compromised was never a hard problem for an attacker
Click to expand...
I disagree with this. Today, even when you have physical access to a device, persistence is often hard to achieve. That's why, with a lot of console hacks/iOS JB's, you have to reapply it on boot each time. Achieving persistence is always a goal. Sometimes it takes years to get there, or it just never happens at all, and you wind up with a tethered jailbreak or whatever.
 
lemmiwinks said:
I disagree with this. Today, even when you have physical access to a device, persistence is often hard to achieve. That's why, with a lot of console hacks/iOS JB's, you have to reapply it on boot each time. Achieving persistence is always a goal. Sometimes it takes years to get there, or it just never happens at all, and you wind up with a tethered jailbreak or whatever.
Click to expand...
what in the liveing fucking shit are you fucking talking about ou fucking cunt

do you understtand what's at stake here????!?!?????!??!

FUCKING SHIT, WAKE THE FUCK UP!!!!
 
  • Semper Fidelis
Reactions: lemmiwinks
lemmiwinks said:
I disagree with this. Today, even when you have physical access to a device, persistence is often hard to achieve. That's why, with a lot of console hacks/iOS JB's, you have to reapply it on boot each time. Achieving persistence is always a goal. Sometimes it takes years to get there, or it just never happens at all, and you wind up with a tethered jailbreak or whatever.
Click to expand...
Yes, that is true for a totally locked system like an Apple iPhone or a console where even the owner needs Apple's permission to run any bit of code. And I do believe that this is Microsoft's end goal but even Windows 11 is not at that level yet.

Personally I despise this model but it seems to work for some people.
 
  • Agree
Reactions: lemmiwinks
Scamhook said:
what in the liveing fucking shit are you fucking talking about ou fucking cunt

do you understtand what's at stake here????!?!?????!??!

FUCKING SHIT, WAKE THE FUCK UP!!!!
Click to expand...
Semper-Fi noble re.tard, I salute your dedication to the cause.
 
  • Like
Reactions: Scumhook
lemmiwinks said:
Semper-Fi noble exceptional individual, I salute your dedication to the cause.
Click to expand...
mate that is a fucking awesomep post

SEMPER-FI MY FUCKING BROTHER

FUCKING RIDE OR DIE, YOU AND ME BB





* this opingon may change tomrorow when i sover up lol icant read this stupid tiny text
 
byuu said:
It's still wrong to say that Secure Boot stopped drivers being a common target to infect.
Click to expand...
Without a full chain of trust, you can't protect against this threat

byuu said:
Not to avoid kernel drivers getting infected.
Click to expand...
Again, wrong. The point of secure boot is to help establish a chain of trust. Part of that chain is an uncompromised boot process. Microsoft's own documentation counters what you've said. But also now it's kinda clear you have a poor understanding of computer security and defense in depth.
 
Likely said:
Without a full chain of trust, you can't protect against this threat
Click to expand...
Without completely airgapping your computer in a safe deep in the ocean you can't protect against this threat.
How about doing more to protect your computer getting compromised in the first place?

Likely said:
Again, wrong. The point of secure boot is to help establish a chain of trust. Part of that chain is an uncompromised boot process. Microsoft's own documentation counters what you've said. But also now it's kinda clear you have a poor understanding of computer security and defense in depth.
Click to expand...
Saying "Secure Boot defends against kernel driver infection" is like saying a locked window protects against someone breaking in through your door because when the window isn't locked you can enter through it and then open the door from the inside.
It's just stupid.

And additionally you tried to paint Secure Boot as a proven deterrent for kernel driver infection even though that is not true at all.
Far fewer people use the whole chain of trust with TPM and Secure Boot and everything than people using just kernel driver signing which almost every Windows user has used since Vista.

Oh and Microsoft's own documentation says TPM isn't required for Secure Boot. There goes your chain of trust.
 
If you're looking for something secure for more short term use you can use the tails operating system on a USB stick. But that's not really meant to be a replacement for casual use, its more so for short term stuff when you need more security for what ever it is you're doing.

But if you're looking for a every day use computer your options are pretty much don't use computers at all or come to terms with the fact that almost *everything* is going to mass farm your data
 
byuu said:
Without completely airgapping your computer in a safe deep in the ocean you can't protect against this threat.
Click to expand...
Useless whataboutism. Nothing is perfect. More controls and depth raises the difficult for attackers and the effectiveness of the security model. But the baseline protection of this threat is ensuring that no untrusted code is run in kernelspace under normal operation. Any broken link from start to userspace execution violates this.

byuu said:
Saying "Secure Boot defends against kernel driver infection" is like saying a locked window protects against someone breaking in through your door because when the window isn't locked you can enter through it and then open the door from the inside.
It's just stupid.
Click to expand...
Lmao wrong

You're applying a completely different analogy to a process that is NAMED after an analogy: a chain (of trust) is only as strong as its weakest link.

byuu said:
And additionally you tried to paint Secure Boot as a proven deterrent for kernel driver infection even though that is not true at all.
Click to expand...
Lmao wrong

I don't know why you have such a difficult time with understanding the concept of a "chain of trust".

If you're really interested in not looking like a dumbass, take a look at these docs that explain implementations of modern chains of trust in boot processes. The apple stuff is actually quite good docs
https://koansoftware.com/secure-boot-and-chain-of-trust/
https://css.csail.mit.edu/6.858/2014/readings/ios-security-may12.pdf pg 4
https://support.apple.com/guide/sec...r-ios-and-ipados-devices-secb3000f149/1/web/1
https://support.apple.com/guide/security/boot-process-secac71d5623/1/web/1
https://www.apple.com/ca/business/mac/pdf/aaw-platform-security.pdf pg 26

(Actually, Apple is using their TPM-style equivalent to do boot process verification, although still in a relatively limited capacity. But that's also for other reasons than just "trusted boot".)

byuu said:
Far fewer people use the whole chain of trust with TPM and Secure Boot and everything than people using just kernel driver signing which almost every Windows user has used since Vista.
Click to expand...
this betrays a fundamental misunderstanding of the place the TPM has in the Windows/eUFI security model. Also saying that "far fewer" people use Secure boot than they do kernel driver signing is unambiguously wrong.

Correct that the TPM is not required for secure boot/trusted boot, sad that you think saying it is some sort of revelation . The TPM's actually not really REQUIRED for anything that most users will do - almost every feature that "requires" it can be configured to use less user friendly or inferior options. You don't seem to have a good grasp on the role of the TPM/SE in a secured computing environment.

Also, literally every mainstream OEM windows PC and most self-built ones as well has shipped with "secure boot and everything", not to mention the vast majority of OEM built made since 2016 or so ship with a TPM.

It's a pretty safe bet to say MOST people use the whole chain of trust with TPM and Secure Boot and everything.

byuu said:
Oh and Microsoft's own documentation says TPM isn't required for Secure Boot. There goes your chain of trust.
Click to expand...
fundamental misunderstanding of the place the TPM has in the Windows/eUFI security model. It's not really used for cryptographic operations except when those operations are using protected key material. Such as: BitLocker keys or protected applications such as DRM (applying a KEK to yield a DEK (in the tpm) and then send that DEK to kernelspace for further decryption).

In fact, considering the speed of the TPM and the capabilities (mailbox style api over spi), doing secure boot or trusted boot operations with it would probably add minutes, if not hours to a boot process.
 
Last edited:
  • Informative
Reactions: lemmiwinks
I am NOT jumping into this pool of spergery, but I got curious and started doing some research on ME today.

There's lots of resources available, and hacker conferences about messing with it.
The long story short is that if it were malicious, you would not expect it to be designed the way it is. It's a modular system and different parts can be turned off (and by that I mean completely wiped out) independently without interfering with the boot process. It's not tamperproof in the way that you would expect an espionage system to be. On newer generations it can be turned off easily(ish) if you have the right equipment.

Despite all the claims I've heard, it's not encrypted, just encoded to save space. People have gotten around this without too much headache.

I am NOT making the claim that it's not a backdoor. I am saying that it's a very oddly designed backdoor if it is one.
 
  • Like
Reactions: Knight of the Rope
You must log in or register to reply here.
Back