Breaking the x86 Instruction Set

[@ppp72957]

This guy is impressively good at what he does.

[@Reth_Hard]

Most of us was suspecting processors to have some dirty instructions hidden inside them, but this is certainly not an easy task to search for them. Sincerely, hats off to this guy!

[@marshalcraft]

Not really, well known intel has entire independent risc processor for the purpose of remote monitoring, even when battery is off your intel pc can access microphone and listen to you talk.

[@FlamingPhoenix40]

marshalcraft how? If your battery is off then the microphone won’t work...

[@nfcopier1]

The battery may not be completely off. If the motherboard was designed to provide power to the microphone in the "off" state and provide enough power to the CPU to run the necessary instructions, remote monitoring may be possible. The only way to prevent it would be to remove the battery completely. However, monitoring may not be feasible. I expect the process would have to dump data to a hard drive, which would require a lot of power.

[@bryede]

Well, we occasionally find out that "secure" products have back doors and we know that the gov't frequently approaches tech companies requesting spy features, so we shouldn't be surprised if hidden ring bypass instructions turn up one day. I'm sure Intel was well compensated for them if they exist.

[@Essometer]

Oh man, that page fault analysis is genius.

[@Essometer]

Guy Smith Intresting, it's the first time hearing it for me though. Just thought it such an creative way to test for instructions.

[@joshuakuehn]

​@@Essometerwhy do the two of you have the same pfp

[@tspshilt]

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

[@fss1704]

nop nop

[@rabebonskyjoe5193]

and then AMD's #ud before #pf "bug" to circumvent this

[@wildwest1832]

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

[@lbgstzockt8493]

And this is just "some guy". Think of what a team of people like him with an evil motive could do.

[@vincentschumann937]

@@lbgstzockt8493 especially if given a bottomles budget

[@JDManring]

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!

[@UPsideDOWNworld321]

thats why he is speaking!! dum dum dum dum duummmmmmmmmmmmmmmmmmmmmmmmm

[@zesjerome7189]

no such thing as jealoux or capabx or good or not, cepu, do, say, think any nmw anda ny be perfect

[@tjij-mbai]

He's a Genius.

[@BryanChance]

He makes it easy to understand that I though I was good. :-)

[@niks660097]

cause of hard work and countless hours spent hacking/reverse-engineering...

[@TheOz1999]

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

[@sangamo38]

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

[@wiipronhi]

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.

[@jan_h]

I feel like already running sandsifter to be one of the first that uploads to that site when it inevitably starts existing

[@JoshBeach]

github.com/rigred/sandsifter-tests

[@fss1704]

+Josh Beach damn cool, i'd like to run this shit on the brazilian voting machines using cyrix..

[@baileyharrison1030]

wiipronhi but if they do stumble across a secret instruction there’s a good chance it will mess up the OS operation. And an emulator wouldn’t have the instructions programmed into it anyway.

[@axeman2638]

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.

[@fss1704]

damn i'm in, atleast we got risc v

[@alexwolf4604]

RIP

[@GBGSK]

May his soul find rest and find the peace he deserves.. RIP dear Terry! ☹

[@tsnp423]

And all this in his own universe :)

[@GBGSK]

@@tsnp423 no not Universe.. the correct word would be *Reality*

[@rogerflores9470]

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.

[@ruthlessadmin]

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.

[@jastrckl]

already exists. SPARC.

[@ruthlessadmin]

Thanks..I was aware of SPARC but didn't realize it was open source. I'm also aware of some other open source CPUs. Still, I don't think it quite meets the mark for a genuine competitor to x86. I mean, I can go out and buy a laptop running Linux but I don't think I can go buy a laptop with a SPARC so easily....

[@kunou4527]

Problem here is licensing. It can't be GNU. Would need to be BSD based to entice innovation and protection of intellectual property. Which means the option to not release certain intellectual property for free. Or rather, the freedom to not be compelled to do so at the cost of the innovator.

[@y__h]

Kunou RISC-V is BSD-licensed ISA.

[@bertdowns8186]

RISC V. Linus tech tips made a video on it recently...

[@ehsnils]

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.

[@reversEngiener]

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

[@edmund-osborne]

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

[@Walter_]

You gotta realize these sorts of people are specialized hard into 1 thing.

[@xoloser3]

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.

[@ShadyNetworker]

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

[@morwar_]

They hired him.

[@AbhishekBM]

@@morwar_ To expose themselves?

[@morwar_]

@@AbhishekBM No, my guess is that what he knows is valuable.

[@KishoreG2396]

He works for Intel now

[@tom7]

Neat talk!

[@alexst-laurent5272]

Oh hey! It's Tom! Love your learnfun and playfun videos and programs, it's really fun editing the code and seeing if I can optimize the behavior, and it's also just plain hilarious to run them on hacked roms, especially speedhacked ones. Have you considered doing more work on them?

[@puellanivis]

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.

[@jemakrol]

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.

[@desmond-hawkins]

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.

[@memerichment]

Thanks for following this up! I was extremely curious as well.

[@javaguru7141]

Also hoping to hear more about it eventually. It's been a while.

[@BruceDuncan]

Where are you, Domas? What did you learn?!

[@qualityedits3083]

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.

[@tacokoneko]

32:56 *_This man is claiming that it would be possible to write a malicious program that is completely benign and undetectable on any x86_64 computer that is not using a physical Intel CPU, but when executed on a computer with an Intel CPU it could arbitrarily execute whatever otherwise deliberately avoided lines of ASM the programmer desired, and also vice versa by inverting the principle._* That's the killing blow of this video and, if his demonstration is true, means that nobody should be using x86 CPUs for cryptography of any meaningful level of security.

[@lawrencehook]

His claim applies to all processors. Intel just happens to be the most popular, thus relevant one.

[@tacokoneko]

actually if you click on the timestamp at the beginning of my comment he is literally saying that a difference between intel and amd (+via) is what causes the vulnerability to exist. it could be said that intel is at fault because their noncompliance with their own documentation is what causes the problem. however all cpu manufacturers are at fault for everything he finds with his method, as he goes on to reveal a pentium f00f-like CPU hardlock he purportedly discovered in an AMD CPU.

[@feppfepp]

The behavior of 0x66 with jumps is well-documented since quite some time. This is just tools not being correct visavi the spec, which is pretty common to be honest for a complex spec. The fact that AMD processors behave differently is a compounding of the problem, however. Qemu is not an instruction set reference by a long shot; it is a best-effort project - and there are likely many other similar bugs to be found. When using VT-x to run, you would get the right results.

[@Donaldo]

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

[@justabelief5119]

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

[@MickeyMishra]

I still feel the same way today in 2024 and I never grew up. Toys R Us kid till the end!

[@233kosta]

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.

[@bkiffter]

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

[@TheHuesSciTech]

The graphics card does the blinking. The cursor blinking was literally done by special circuitry back in the days of text-only computers decades ago when the CPU couldn't possible spare CPU cycles to blink a cursor. And since there's been a continuous evolution of compatible machines ever since, the graphics hardware has never been relieved of that responsibility. Of course, modern GPUs can handle that in their sleep. (If the bug was demonstrated in a Graphical UI, then it probably would freeze.)

[@zesjerome7189]

no such thing as stupix qor not

[@matheusrodrigues9653]

@@TheHuesSciTech eu ia morrer sem saber disso

[@AlexSKelly-up7lf]

@Brick It really is, not only because it would have been difficult to come up with, but also because it would be easy to think something else entirely. I thought it would only stop executing instructions in a specific ring or something like that.

[@Lucas_Simoni]

I had some glitch on nvidia drivers on ubuntu that would show up some previous image sprites that were on my windows after I restarted and dual booted into it, it was something related to dual monitor (it didn't work out of the box, I never bothered to fix it), I have no idea how possibly that could have happened, how some sort of buffer could have survived a system restart, but somehow some internal gpu buffer survived, and I never seen anyone talking about that online. It also seems like the cursor is accelerated by the the GPU too, and probably a lot more going on. Check this video out: [PS2 vector unit demonstration Using only 16K of working space; NONE of the ps2 main CPU was used: kzbin.info/www/bejne/p520mX15qqeMqac] Also, in other video game consoles, there is a lot of GPU compute that happens independently of the main CPU, search for architectures for the gameboy advanced, nintendo ds, nes, etc.

[@MrtinVarela]

*"jk i'm malicious af"*

[@zesjerome7189]

wrr

[@JasonMasters]

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.

[@panteltje]

Nice to hear about the Z80, learned asm programming on that long time ago. My coding style comes from this book by professor Miller (bing will find it online); 8080-Z80AssemblyLanguage-TechniquesForImprovedProgramming.pdf Appendix J mentions those instructions.

[@Roxor128]

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.

[@fss1704]

i couldn't agree more with your words, literally.

[@samm3417]

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

[@xDR1TeK]

Remarkable person with a unique mind.

[@olbluelips]

Still my favourite talk

[@djdeluxe76]

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

[@JG-tk3cd]

This guy is a genius

[@Baigle1]

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

[@dirtbikersteve]

THANK YOU!

[@JoshBeach]

Github test results repo github.com/rigred/sandsifter-tests

[@bit2shift]

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

[@bryede]

With simple processors like the 6502, you could enable parts of more than one instruction because the opcodes weren't discretely decoded. On a modern CPU, a working instruction is most likely intentional.

[@bit2shift]

bryede the thing is: we don't know the exact internals of x86 like we do with 6502 because it's closed hardware and it's constantly changing with each new microarchitecture iteration.

[@bryede]

Right, but the x86 is fully microcoded and it can even be updated in the field. This means instructions point to specific internal sequences to be executed. When you find a sequence that works without throwing an exception, it probably means there's something in the table. It doesn't mean it's top secret functionality, but it might be. On the 6502, the undocumented opcodes came from enabling more than one instruction because the sequencing ROM was optimized for size and is built out of fragments that can overlap with illegal bit combinations.

[@bit2shift]

bryede several millions of undocumented instructions would require a fairly big microcode ROM, so we can speculate that there's overlap between some of the documented and some of the undocumented.

[@bryede]

Right. Because of how the instructions are prefixed and expanded in a byte-wise fashion, you don't need a table supporting all bit combinations, but rather you move from one 256-entry table to another. I'm just saying all unused byte entries are supposed to throw an exception. Just modifying instructions with prefix bytes won't.

[@leberkassemmel]

Oh my. That's why I love my RISC CPU. Those x86 CPUs are so complex!

[@dangi12012]

Well have fun writing fast software for RISC. Cisc is the way to go because you need less instructions to get more stuff done. Like sqare root in 1 op.

[@DarklinkXXXX]

HD_Picard Thanks to significant microarchitectural advances in CPU design in the last couple decades, the number of instructions executed is no longer relevant to execution speed.

[@firefly618]

I have good news for you: x86 has been a RISC CPU for decades. The bad news: it's running a proprietary real-time OS known as "microcode" that emulates the CISC ISA and does all manner of shenanigans behind your back.

[@IljaSara]

Waiting and waiting and waiting for some company to push out some RISC-V ISA based CPU for consumers.

[@IljaSara]

If you completely disable the microcode, could you run code on "bare metal"?

[@analkarldervierte1759]

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

Has the hardware bug been disclosed yet?

[@MagicBoterham]

Not to me, at least.

[@hjembrentkent6181]

Bump.

[@y__h]

Dunno yet, but today some people hinted at a whole new family of Spectre-class vulnerability.

[@devlogged7633]

@@y__h This aged quite well haha

[@snooks5607]

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

[@unvergebeneid]

Save the best for last as they say.

[@fss1704]

damn yeah what kind of person doesn't get excited over ring -1 stuff....

[@omgjingles]

I understood nothing, but enjoyed it.

[@joemama-js6hv]

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

[@hoshinova9791]

Oh boy. And now it's been revealed that Intel chips created in the past decade have a kernel memory leak "bug"/backdoor. Well, at least the Intel CEO sold as many shares as he could during Q4...

[@EdPin_]

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

[@georgetroulis]

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

[@cataria3903]

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

[@dorukayhanwastaken]

😂

[@slookify]

so much respect for those smart people

[@tkothadev]

22:26 ok this part genuinely looks like what you would see in hollywood movies

[@dtm303909]

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..

[@kbabioch]

Great talk, nice ideas!

[@SarahC2]

Hidden instructions BETWEEN chip manufacturers = NSA. 26:00

[@ujiltromm7358]

... Or simply one manufacturer licensing the instruction set to the other, and implementing them all for inter-compatibility reasons.

[@sent4dc]

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

[@caliniaru1673]

Extremely captivating!

[@mohammadkaif3868]

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

[@ongunkanat]

Does anybody have a link for full disclosure?

[@ropersonline]

So did he ever post an update to the undisclosed bug he talks about at 38:43?

[@FamilienSoelberg]

You are my favorit! Love your stuff.

[@347573]

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

[@luisponce3580]

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.

[@AbdulelahAlJeffery]

you know he's really good at what he's doing when he speaks at 200 k/h

[@tjij-mbai]

It takes one to know one.

[@Ultrajamz]

Intel ME, AMD PSP...

[@foobargorch]

Ultrajamz technically not part of it the ISA, a whole other layer of shit... Joanna Rutowska has a very long review of the problems with the arch, x86 considered harmful. there's also a great paper on doping attacks in the fabrication process that can reduce the rng entropy, so even if the spec is good the chip itself might not be... It's all so rotten to its core, we really need open hardware and auditable fabrication

[@RogerBarraud]

Johanna *

[@RogerBarraud]

Rutkowska*

[@torpcoms6428]

That happens with older ME versions as well, anything past Penryn has a 30 minute reset timer. mail.coreboot.org/pipermail/coreboot/2016-September/082021.html

[@torpcoms6428]

Yes; also nothing except ME11 is even using x86. AMD's ASP/PSP is an ARM core, and ME versions 10 and below were ARC cores.

[@memadmax69]

I like this. But my approach would be more like: Ok, put the candidate processor to be scanned on it's own, isolated mainboard/breadboard/experimental board, and feed the candidate processor instructions from another machine. That way everything is nice n isolated during crashes and could make scanning the ENTIRE instruction set faster and more reliable.

[@fss1704]

i saw some shit like that already... don't remember where.

[@devrim-oguz]

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.

[@maksymiliank5135]

probably not. Why would they create something like that, invest their time and money and never use it again? Idk

[@majorfallacy5926]

@@maksymiliank5135 espionage backdoors. There's a reason china wants its own silicon so badly

[@A-Milkdromeda-Laniakea-Hominid]

I am reminded of Joe and Gordon running current through every pin of an early 80s IBM, resulting in that 2 inch thick blue binder, which Cameron was subsequently legally barred from reading it while she coded the BIOS for "The Giant."

[@fss1704]

can you send a link...?

[@gblargg]

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.

[@MrocznyTechnik]

"You can fool all the people some of the time, and some of the people all the time, but you cannot fool all the people all the time." (Abraham Lincoln)

[@nzz2]

2:31 - secret functionality, list of hardware bugs .. 20:30 Capstone disassembler ..

[@douro20]

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.

[@alfin3644]

He did fuzzing bytes up to 15, seeing how the instruction pointer register incremented. Results start at 25:00

[@_zproxy]

good stuff

[@davivify]

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.

[@benjaminbrady2385]

This has been fascinating!

[@lohphat]

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.

[@DougCube]

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?

[@SupLuiKir]

It seems like exploiting a f00f-like bug (where it stops the processor) could be a more efficient DDOS-like attack provided you can manage to run unsigned code. Just get a company's servers to execute the processor stop instruction and they'll have to reboot all their computers. If you set it to run on startup, then they'll be locked out of their OS, forcing them to solve the issue from the BIOS.

[@meithecatte8492]

it's DoS, not DDoS! I don't understand why your comment is here, since all of this was said in the talk. Also, your nickname... is this the stop instruction? Did you not hear about responsible disclosure ;)

[@johnnycochicken]

They carefully wrote "DDoS-like" and were talking about a specific scenario

[@damionyates1]

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.

[@qbasicmichael]

First of all, inc and dec do not affect the carry flag. An overflow will set the zero flag, but not the carry flag. As for the rest, i think it depends on whether you're executing in 16 or 32 bit mode. If you're in 16 bit mode, then 40 is inc ax, and 66 40 is inc eax, as you describe. If you're in 32 bit mode, then 40 is inc eax, and 66 40 is inc ax, as he describes.

[@panjak323]

This is really well explained.

[@stalinvlad]

Fantastic thinking, using PF to find the instruction length, reminds me of when I learnt how traceroute works, ping with TTL 1, ping with TTL 2 etc. And then learning the DNS of assembly is BSing you! And cross platform (Intel.AMD, VIA) GOD BLESS AMERICA

[@doctorweile]

The man is a genius!

[@edwardkostreski6733]

did that brick the processor or only until power cycled?

[@-argih]

technically unless it have some non volatile status memory

[@nahCmeR]

He said he tried it on multiple os and it always locked the cpu. So sounds like it's just locked until power cycles.

[@gnagyusa]

Awesome. Pretty clever tricks!

[@etmax1]

Great well explained video, thanks

[@tjij-mbai]

I have not watched something this impressive in a very long time. Somehow I had such a core-vulnerability suspicion in my mind.

[@disk0__]

How is Chris Domas so fuckign based holy shit

[@XalphYT]

disco__ This presentation left my jaw on the floor.

[@JorgetePanete]

disco__ fucking*

[@bakedbillybacon]

Couldn't you create a "layer" in the linux kernel to block all instructions that are not documented?

[@torpcoms6428]

Not a layer, but you could make the loader refuse to load programs that have an undocumented instruction, or that generate code that they later execute. Among other things, you could not use the JIT compilers in Java or ECMAscript runtimes.

[@bakedbillybacon]

Torpcoms Thanks for the answer. I was hoping for something in a lower level and not language restricted, blocking anything in the kernel level and above to use such instructions.

[@KoflerDavid]

You could execute suspicious software on a fully virtualizing VM patched for this purpose. The VM would have to scan all code scheduled for execution for "undocumented" instructions. Problem is, you will lose a lot of performance. And there would still be the slight issue of hypervisor and disassembler bugs creating false positives/negatives. Watch the video for what can go wrong with such approaches.

[@fss1704]

+David Kofler vm's can't prevent magic numbers...

[@sebastianramadan8393]

@@bakedbillybacon The detail about JIT compilers in Java and ECMAscript runtimes kind of is low-level in ways. Some processors have instructions that allow a subset of JVM bytecode instructions to be used kind of natively... as in in the assembly for the processor. It's not a documented feature in the ARM specification, but I think the name nowadays is Thumb2EE or something like that... the technology known by about as many previous names as a cheap hooker has teeth... so this proposal would indeed strip these devices (like your mobile phone) of their ability to quickly execute various JVM bytecode operations... the JIT compiler would have to simulate using software instead, which would be much slower... Similarly, I think you would lose a lot of multiscalar instructions that Intel has developed which aren't x86-standard...

[@unfa00]

33:26 "Intel is 95% of the market share". That aged poorly :D

[@w04h]

42:20 Mine didn't literally halt and catch fire but maybe yours will, _that would be awsome_

[@thewhitefalcon8539]

Did he release info on his f00f bug discovery?

[@athf226]

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.

[@stonent]

What concerns me is let's say he executes one of these unknown instructions and it alters the way the processor executes a currently benign instruction. Perhaps changing a jump and read to a jump and execute. I'm not saying it's changing the hardware, I'm saying maybe this instruction is inside the processor for a reason that we're not supposed to know about. Such as this instruction flips a bit that diverts an execution pipeline to a part of the processor that has been idle for years that now is operating under an altered instruction set. So I suppose that when this scanning tool is run, you should probably run it numerous times to see if you find some different results during the second pass, indicating a new instruction or instruction set has been enabled. (I'm talking like NSA level stuff)

[@stonent]

Another thing that needs to be addressed is capturing what microcode level is being used in the processor. When you flash your bios on your computer, the motherboard vendor will frequently add microcode revisions to the bios that patch bugs in the CPU, but they could also activate or disable these things you weren't supposed to know about. The same thing with silicon revisions and steppings. Those are hardware alterations to the CPU internally.

[@kcw8886]

Interesting! Generally speaking, should the problem of undocumented instructions also be relevant for RISC as well? Even with an open architecture, implementation can be (and likely will be) done secretly. Manufacturers are risking their brand name to have these hidden instructions that they may lose track of. Agree with the concept of developing more universal tools to audit our hardware. We shouldn't only audit software.

[@notgate2624]

Incredible talk

[@iMPRE7ed]

This is actually something amazing

[@EnsignRho]

Awesome. Excellent presentation. Am unable in late October, 2017 to yet find disclosure on the new HCF bug.

[@panteltje]

Nice presentation, i just sucked it in being an avid asm programmer.... It is a well known problem.The only way around it for REALLY high security applications is code your own processor in FPGA, and not an FPGA with already an ARM core in hardware of course. Anyways, there is more danger lurking in the normal processors and interface chips, and often many interfaces are integrated, for example when when ethernet and some input device handling is also integrated then is quite possible it takes just a single request from some specific IP to send all you keystrokes to NSA or whatever have you elsewhere. There is no real security, I come from a hardware background and would implement that as firmware if I worked for any of those entities in any of those countries. But anyways, they know I want to take over the world by now..... ;-)

[@fss1704]

;-)

[@slemsvamp]

I feel a bit worried running anything this guy has created, he could rip my CPU to pieces with his mind. :D Jokes aside, this is awesome!

[@MarioManTV]

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.

[@JwopDk]

I don't know heaps about x86 but it seems like it could REALLY do with a "lite" version, with the same speed and set of _useful_ instructions; nothing undocumented, useless or too obscure. I bet people have thought of this before, so why doesn't it something like this exist, or if it does, why haven't I heard of it?

[@fss1704]

a qemu processor is what you want, i know i want one too man, a shame they don't exist.

[@7Shol]

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.

[@JOHNSMITH-ve3rq]

absolutely incredible stuff.