PrivSec-dev/privsec.dev
1
0
Fork 0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2024-11-08 07:51:33 -05:00
Code

Minor fixes

Browse Source 
Signed-off-by: Tommy <contact@tommytran.io>
This commit is contained in:
Tommy 2024-06-10 07:39:03 -07:00
parent 6bb69fe16b
commit 5eddf1992a
Signed by: Tomster
GPG Key ID: 555C902A34EC968F
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/posts/knowledge/Laptop Hardware Security.md
View File

@ -90,9 +90,9 @@ Here are some facts about it:
- You can disable it firmware settings.
- Certain firmware allows you to permanently disable it by blowing an eFuse.
- It is detectable. An easy way is to just go visit port 16992/tcp on your device.
- To be extra sure, you can also run nmap to scan the port from a different device.
- To be extra sure, you can also run `nmap` to scan the port from a different device.
This is not a hidden thing at all, people have accidentally [run into it on social media]().
This is not something hidden, people have accidentally [run into it on social media](https://mastodon.lilysthings.org/@i_lost_my_bagel/112228352384742242).
For attack surface reduction, you should absolutely disable it. With that said, don't let the scary claims about "remote management" by the Free Software Foundation spook you - if some sort of hypothetical backdoor actually implemented this way, it is not hard to detect. There are better ways to implement a backdoor as discussed above, and if you don't trust the CPU vendor you should avoid them as a whole, not just the vPro model.