This guy is impressively good at what he does.

The use of No Execute on memory to find instruction length made me go "oh man" out loud. Genius.

Oh man, that page fault analysis is genius.

its kind of scary how good some of these guys are at figuring these things out

I am jealous. Not only is this guy much more capable of mentally processing this complex information than I am, he's also incredibly good at presenting it!

With Intel's ZombieLoad, PlunderVolt, Meltdown and more severe vulnerabilities these days, this video is more relevant than ever

they should crowdsource the undocumented instructions the same way that pass mark gets benchmarks. Everyone uploads the results and a website shows a nice breakdown of what instruction run on what.

I just keep thinking how poor Terry Davis has wasted all his time. He needs to make his own silicon as well as his own compiler and OS.

Goddamn, did Intel send assassins after this guy or what?

My god that page fault technique is so awesome. So clever

Neat talk!

It's good to see Black Hat uploading videos unlike the other popular tech conference.

Really good. Having done some Z80 programming once upon a time I know that some undocumented instructions are merely side effects of the microcode and not necessarily intentional. But the point is to figure out the instructions that really are intentional and undocumented. Unintentional undocumented instructions could of course be fun too if you want to do some "smart" programming, but don't expect them to work in the next generation of processors.

It looks like the "halt and catch fire" instruction he describes starting at 38:46 was never described publicly, at least that I could find. As he explains in this talk there was no time for vendors to address the issue under responsible disclosure so he couldn't give all the details at Black Hat 2017, but I couldn't find any reference to publications in the following months as he said would happen. There's a question about it on the Reverse Engineering StackOverflow site, but no one seems to know. I'm not particularly looking for a way to execute this instruction, but I'm curious to know if any mitigation was possible for CPUs that had already shipped. If anyone knows and has a reference this would be much appreciated.

Maybe a stupid question, but how does the cursor keep blinking if the CPU is locked up?

This talk takes a while to get interesting but it's worth it

This is why open source is so important. I would love to see a viable open CPU alternative emerge, on the scale of Linux in the software world. It's not impossible, but it would be a much different and more challenging problem to solve.

Thanks for the talk! You used such fascinating methodology to carry out this project. Definitely learned a lot, not just about hidden instructions but also software searching techniques.

Incredible job done presenting this critical topic. Keep up the good work :)

A brilliant talk showing persistence and out of the box thinking. As pointed out, the time is well past for trusting the docs of closed hardware designs! I need to go now and think about working the ideas into my disasm and emulator.

This is so well done in every aspect. There are smart people and there are people like this, that goes beyond that. Well performed presentation. As of 2021 I find surprisingly little follow up info on that Halt and Catch Fire instruction - dunno if that's me sucking in searching or that the disclosure still apply.

what a talk! phenomenally creative, important, and useful. i understood almost all of it despite knowing next to nothing about x86, barely anything about process/OS security schemes and how their traps/exceptions are passed around, what the rings mean, and just generally being very new to OS and hardware stuff.

Wow. This just shows me I need to brush up on my awful, awful assembly skills. Hats off to Christopher Domas.

*"jk i'm malicious af"*

Link to GitHub repositories! github.com/xoreaxeaxeax/sandsifter

This has been fascinating!

Information dense talk in a manner of John Carmack. Now i need time to digest. Awesome.

Mind blowing!! Neat and complete... bravo!! :)

Outstanding work

Fascinating.

This is really well explained.

Remarkable person with a unique mind.

Finally! Someone speaking at a tech event who isn't a stuttering incompetent mess onstage!

You are my favorit! Love your stuff.

This guy is a genius

Great talk, nice ideas!

Incredible talk

absolutely incredible stuff.

I should imagine a lot of these undocumented instructions would be work in progress, perhaps left there for eventual future use, perhaps used to reduce the cost of prototyping, but the coordination between x86 manufacturers does raise some serious concerns. These could be anything from hyperoptimised inverse square root calculations to deliberate holes in x86 security, put in place for "the right people"... See "idiocy of back doors"... It could also be as simple as Micro$oft (or Apple?) paying them a handsome sum of money to implement a custom instruction set just for them without telling anyone.

When I was a kid guys like this were the rockstars and astronauts to me.

Amazing talk.

TL;DR: This tool is awesome, thanks for writing it, good thinking all the props. So, some thoughts, sometimes undocumented instructions can be implemented across multiple architectures because it is simply a logical extension of the architecture that isn’t actually documented, but putting in the logic to block those undocumented instructions is more work than it is worth. (i.e. undocumented, or “behaviour undefined” register combinations) similarly, a short-cut in implementation (pinning a behaviour-changing mux to a specific bit of the opcode, rather than actually decoding it) A good example here is the SL1 instruction on the Z80 processor. The three instructions SRA, SLL, SRL are combined in a quad-structure with a section of missing shift-left instructions. Actually executing these instructions results in a shift-left then set bottom-bit. Likely as a result of opcode bits being pinned to muxes. Additionally, there is still a worth in specifications. Specifications detail what is _expected_ behaviour, and what one can rely upon. As such, there’s a giant chasm of instructions that may work at the time, but are not guaranteed to work in the future, or even potentially after a microcode update. So, we get this horrible area, where like the 66 e9 instruction, good software should never include this instruction, because it is non-standard and “a valid implementation of undefined behaviour is to make monkeys fly out of the user’s butt”, but meanwhile, the processor still accepts these instructions, and can potentially then be malicious. At the same time, you can’t _really_ trust that only malicious code uses these instructions… so… poop.

Awesome. Pretty clever tricks!

This is actually something amazing

Bravo! Just brilliant.

Great well explained video, thanks

The man is a genius!

great stuff! hopefully resulting in some good microcode updates and more secure cpus in the future.

Still my favourite talk

good stuff

ok woah.. this guy has some impressive talks here. a bright mind for sure.

This is awesome! This guy's very resourceful to come up with these tools. Questions tho... Why wouldn't a processor's Instruction Cache prefetch generate the page-fault much earlier than when the straddling instruction was hit?

This is incredible

nice work

I watched this video 𝟓 𝐓𝐈𝐌𝐄𝐒!... not because I didn't understand it but because it's just wonderful and so INTERESTING. Amazing Black Hat

8086/8088 processors had an instruction prefix interrupt bug which wasn't fixed until the 80c88 was introduced. There was also a rather critical bug in early 8086/8088 processors which would cause an interrupt immediately after a MOV SS or POP SS to push data off the stack into an incorrect memory location, causing data corruption.

Wow, that is amazing! Just curious though, any updates on that Ring3 DoS instruction that locked up his CPU?

superb.

10:25 when you make the processor roll over for you, you know you're next level

so much respect for those smart people

I totally understood all of this:) :) :)

thank yu very much yu have rightly guided me to pursue a career in reverse engineering software yu are actually a genius and open sourcing those software tools makes yu true master in your field yu can turn those software tools into million dollar startup

holyfuck. I might be high, but tell me if that wasn't the best blackhat talk yet?

If you were going to make a backdoor, How would you do it? Possible with 2 or more differant instructions in tandem, creating a false page fault or it might effect something completely hidden or not monitored. There is a backdoor here somewhere but its going to be very well hidden.

Oh snap! This is great.

Most of those undefined opcodes could be what LAX was on 6502: opcodes without explicit microcode.

Epic.

love you !

Undocumented instructions have been around at least since the Z80 and perhaps before then. This is an 8-bit CPU which uses a separate 16-bit address bus. The Z80 has two 16-bit index registers, IX and IY, intended solely for indirectly accessing memory, but people noticed that the binary code for accessing these registers was just one byte to say "Use IX" or "Use IY" followed by exactly the same instructions used to access the HL register pair, which are two 8-bit registers which can be used together as a 16-bit address. Since the H and L registers can be used as separate 8-bit registers, people decided to try adding the "Use IX" or "Use IY" byte in front of the 8-bit H or L register instructions and discovered that they could access IXH, IXL, IYH and IYL as 8-bit registers. Many programmers then wrote an include file which defined these undocumented instructions as macros so they could use them directly in their programs.

I understood nothing, but enjoyed it.

respect!

I'm kind of curious what sort of similar tools the processor developers have. When I've made processors in uni we would generally brute force/cherrypick things we thought may break stuff.

GooooooooooD Job

niiice nice work

Just tried the call with 66 prefix in IDA 7 on an i7-6700K and both IDA *and* the CPU interpret it as a call with a 16 bit offset. What CPUs were you testing on?

Couldn't help but notice the venue for your seminar. Kind of puts a different slant on things, doesn't it? What a difference a couple of months can make.

Nice nice carry on

26:53 **Puts on tin foil hat** No seriously, that shit's scary

About 6m40s in it says #40 is a single byte instruction `inc eax`. I assumed an #40 would cause a situation where if `ax` reached #ffff it would go back to #0000 and set the carry flag, but #66 #40 should increment eax to #00010000. There are several other minor factually confusing statements throughout the video. On the whole this is a great talk and seems to be presented by an absolute expert so now I'm doubting myself.

Ok thanks for this talk. Just confirmed an old acquaintance must work for an intelligence agency. He told me this in 98 but was drunk and denied saying it after.. Lol..

This guy sifts.

The real question is whether these instructions yield some result because of the inherent physical logic-fabric and the way the op-codes are implemented or if it is a designed instruction.

Wow, this guy!

Is this separate from the custom instruction sets added for individual large customers but disabled for everyone else?

Not super familiar with these architectures, but isn't it feasible to have certain combinations of instructions be used to cause specific, hidden behaviors? Seems like something that this tool would miss.

His search scheme seems to exclude some possibilities. From what he described, if say 00 xx is a two-byte instruction, he checks 00-FF for xx. Then he goes back and checks the length of 01. If it's also two bytes as before, he then doesn't search 01 xx, assuming that the last byte won't do anything special. But what if 01 00 is a three-byte instruction, or 01 23 is a three-byte instruction? Essentially, he seems to assume that there won't be two different types of instructions of the same length, next to each other in his search order. That is, if say 00 is a two-byte instruction, 01 is a one-byte instruction, and then 02 is a two-byte instruction, he will properly search both two byte instructions' second bytes, but if instead 00 and 01 are the two-byte instructions, he won't search the second one. Later he says he has the instruction at the end of a page to use a page fault to detect instruction length. I'd be wary of trusting that mechanism, especially for hidden instructions. I'm sure I've read errata for processors where instructions near or crossing a page boundary have issues.

15:40 how that is truth? I thought we don't relay on what's said in documentation and it's sounds like a good idea to hide backdoor/hiden instructions by continuously throwing exceptions.

18:30 Why fuzzing only 1 random bite will not corrupt memory state? I would have assume that it would be a specific bite that we should not change.

Has the hardware bug been disclosed yet?

i wonder if AI could be used to make correlations and or do testing or variations of things/data?

I think this was 80% nifty and 20% scary. Nifty for coming up with that approach for finding undocumented opcodes. Scary for the fact that so many were found.

My guess is many undocumented opcodes just do nothing. My guess the number of really secret opcodes are few, they just treat the potential execution paths as NOPs. Complex CISC CPUs use microcode to decode instructions so just routing them to NOP is more economical. However I still am concerned that the OEMs have included opcodes which may only be used for debugging but are vectors for abuse. What’s worse, some of the vulnerabilities may require several undocumented opcodes to do something so just poking single opcodes isn’t enough to scope the problem set.

Is there anything to be learned any more through physical disassembly of the chip? I know the Soviets used to grind the chip, miniscule layer by miniscule layer, but eventually the chips became too tightly packed for this to be viable, but I wonder if technological advances have been made in the last 25 years that could re-enable the technique, even if exotic technology like electron microscopes are needed to observe the chip...

Does anybody have a link for full disclosure?

This guy is pro

Did he release info on his f00f bug discovery?

The only true way to know is to reverse engineer the die. There might be some secret knock codes that is outside the instruction space that could enable special functionality.

I knew of LoadAll when I was around 10-14. I don't know why he says it's undocumented or unacknowledged, but I can guarantee that that wasn't the case in the early 90s. Very weird. The appropriate opposite is SaveAll. Doesn't work in ring3, iirc. Works in DOS, of course. Preferred it over pushA for some reason, but I don't remember.

This is truly disturbing. This guy was able to do this single handed (of course we can assume that a lot of people helped him, im too lazy to watch the video again to see if he said that he was not alone in this project), imagine what a group of malicious people, that literally do this all day, can actually do? I imagined these "malicious people" have literally all the backdoors in every single [Intel, Amd] hardware (processors) . If they were to find and fix a vulnerability, the "malicious people" still have the rest. But what do i know :) im just a student, and I am sorry for my english, I hope you still be able to get my concerning point.

Well this video is certainly a great deal more relevant. Fuck.