HN Theater @HNTheaterMonth

What are the implications of such hardware on user security?

Threat persistence, i.e. persistent rootkits, persistent remote monitoring if one has privs to tickle the CPU instructions that give access. It is just a matter of time before there are public tools for script kiddies to manage the OS within the CPU. Here [1] is an example of someone slowly making progress decoding all the undocumented instructions and here is a talk with a brief overview of the tools. [2] This is not specific to Intel's ME but it is the way people will eventually tame/exploit that beast in my opinion. There are more recent talks that get deeper into security rings in the CPU. This video [3] more related to your question but not specific to ME however can be used to access ME and much more. If this appears to difficult and time consuming just know that some folks out there have the documentation for the undocumented instructions.

You may find some tools on github and other public repos for disabling ME. Use with care. Test on an identical model of system that is at the same firmware/BIOS and same model of CPU as those tools can brick your CPU. As @rocket_surgeron stated, one can buy CPU's with ME disabled but that will not disable the "God Mode" referenced in [3].

[1] - https://github.com/xoreaxeaxeax

[2] - https://www.youtube.com/watch?v=KrksBdWcZgQ

[3] - https://www.youtube.com/watch?v=jmTwlEh8L7g

⬐ intelVISA

Got hired by Intel to shut up not long after that vid, Sandsifter hasn't been updated by Domas since 2017 iirc.

⬐ LinuxBender

That suggests to me that he was turning over rocks that were not expected to be turned over. I leave it to the open source community to fork his code and continue the work. If nothing else it shows me that there are a myriad of undocumented tools in the CPU that could be used by anyone that has the patience to enumerate them.

⬐ Paul_S

Did anyone, on the back of this presentation and tools, find any hardware backdoors in more common CPUs?

If the downvotes are due to poor quality discussion, that's fair enough. If they're due to skepticism, here's his talk from the next year:

[0]: https://www.youtube.com/watch?v=jmTwlEh8L7g "DEF CON 26 - Christopher Domas - GOD MODE UNLOCKED Hardware Backdoors in redacted x86"

⬐ icedchai

I'm not skeptical they exist, I'm skeptical that they're "for the NSA."

Is that links supposed to be https://www.youtube.com/watch?v=jmTwlEh8L7g, the one you used didn't work for me

⬐ SSLy

reload or reopen in a new tab

⬐ sprayk

neither of those worked.

This guy now works for intel: DEF CON 26 - Christopher Domas - GOD MODE UNLOCKED Hardware Backdoors in redacted x86

https://www.youtube.com/watch?v=jmTwlEh8L7g This is one of many amazing videos this guy did before they hired him.

haha maybe Christopher Domas knows :D https://www.youtube.com/watch?v=jmTwlEh8L7g [x86 god mode]

but there is a difference between knowing vaguely how internal combustion engine works versus treating your car as a magic box from the future. (which of course now most cars are, you can not even disable the tire pressure alert after you pump your tires without going to the service shop)

I fear that nobody will even teach the fetch-execute cycle to our kids.

⬐ goto11

https://nandgame.com is a great introduction to such stuff. But that is just a single layer. The problem with computing is not that the individual layers are difficult to understand, is it the sheer amount of layers.

I follow the rule of thumb that you should understand the layer you are working at, and one layer below. Understanding all they layers is great, but will take you a lifetime.

⬐ kalium-xyz

Nandgame is awesome. really like the new levels. Adding the relay level made it more grounded in reality and the maze is fun.

These links don't work for me, but the videos are on YT:

- https://www.youtube.com/watch?v=jmTwlEh8L7g

- https://www.youtube.com/watch?v=XH0F9r0siTI

And yes, they are spectacular.

Related: a defcon talk about it (DEF CON 26 - Christopher Domas - GOD MODE UNLOCKED Hardware Backdoors in redacted x86) https://www.youtube.com/watch?v=jmTwlEh8L7g

Website collecting info on thin clients, which many are VIA, if anyone gets interested in exploring it from a recycled unit: https://www.parkytowers.me.uk/

EDIT: also https://news.ycombinator.com/item?id=17727140 - Christopher Domas: Hardware Backdoors in X86 CPUs

⬐ blueflow

Now seeing the whole context, i feel incredibly betrayed - This was not a backdoor, but behavior documented in the datasheet. I didn't realize this 3 years ago! If this was academics, Domas' work would be plagiarism, with the 2004 datasheet being unquoted prior work: http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia... (Page A-10 in the appendices)

⬐ mhh__

Wasn't his thing about accessing it not finding it, though? We all know Intel CPUs have management engines, running doom on one would be a feat.

You are taking these ideas into crazy places!

Fun to think about.

Given this context, I have a few thoughts:

Contemporary processors may be interesting when simplified some. Your projects make me think about the Zachtronics games.

http://www.zachtronics.com/tis-100/

That is an assembly language game with surprising depth. People, who play it seriously will learn quite a lot.

Using older hardware in tandem with current is a lot of fun. The terminal, for example, still does exactly what it was designed to do and is still useful today. A C64 has a user port for this kind of thing. Apple 2 computers saw all manner of expansion cards capable of data capture, control, computation... making ones own card with a PIA was a standard type project, just as connecting a circuit to the user port was. BASIC was often enough for many basic controls, say regulating temperature, or turning things off and on based on time, or other data states, assembly language brought more of the speed possible, and with more speed, we get more posibilities.

Take one bit wired to a speaker. That is what the Apple and IBM PC shipped with to make sound. The PC had a spiffy timer to bang out notes, and the Apple had nothing but a toggle. Speaker on, or off.

Here is where the fun part was back in the day:

At first, it seems useless. Access an address and the speaker pops out. Do it again, and the speaker pops in. One can type this right into the computer with a BASIC POKE statement, or the monitor by address and watch the speaker change states.

A loop gets one some clicks rapidly, or maybe a buzz, depending. But in assembly language a lot more is on the table! Suddenly one realizes it is possible to turn the speaker on or off long before it has reached the other state. There are lots of other realizations, such as what a read modify, write instruction does compared to one that does a single read or write.

There are any number of simple, seemingly shallow examples out there, racing the beam, making sounds, cramming more onto a floppy, and so on.

But what happens when the hardware is simple, driven by software gets right at the heart of assembly language, in my view. Hardware may be designed to do something, and if designed reasonably, will do that thing.

But, where it may be simple, or over engineered, has bugs, whatever, all suggest more, and as time passed we saw people get far more out of a lot of hardware than intended. Demoscene comes to mind here.

Maybe four thoughts! You should definitely take a look at this guy:

https://m.youtube.com/watch?v=jmTwlEh8L7g

Here is the assembly programmer mindset modeled well. People generally approach it wanting to get more out of their hardware, or understand what is really happening better, or to help them with subtle program errors.

Some do it for fun too.

This work suggests the ideas evolved during early computing, hacking on hardware, exploiting bugs, design choices, and more continue to play out on modern processors and systems just fine.

Keys to the kingdom for those willing to play.

You can't explore undocumented CPU instructions, like this guy is doing: https://youtu.be/jmTwlEh8L7g

While somewhat interesting, I'm not sure there's much to discuss unless the presentation or details are already available.

Interestingly, this reminds me of two Defcon talks I watched in the last day or two, which also cover vulnerability through additional processors onboard.[1][2]

1: https://www.youtube.com/watch?v=jmTwlEh8L7g

2: https://www.youtube.com/watch?v=XH0F9r0siTI