 |
||
 |
 |
 |
 |
 |
| HACK THE X86!!! HACK THE PLANEEEEEEEEEEEEET! by Rafiki 09/10/2017, 12:05am PDT | ||||
 |
 |
|||
| I'm putting this here because I sat through this stupid video so I feel like talking about it.
So I was watching this video from this guy giving a presentation at the Black Hat conference about how he was able to uncover undocumented instructions in the Intel x86 processor instruction set. I don't have any particular interest in x86 assembly or hacking or whatever, but I am a giant dork so I sat through half an hour or so. He seems to have a clever way of uncovering instructions, but if you're not a dork who cares. However, at the 26 minute mark he starts listing some of the hidden instructions he found. In particular, he lists 0F18 through 0F1F as being undocumented in Intel reference manuals until 2016, but being executable on processors all the way back to 2012. He also lists DBE0 and DBE1 as undocumented completely, and being on Intel, AMD, and VIA chipsets. The main thrust of this presentation is that it's scary and unsettling that these undocumented instructions exist because are they back doors? Flaws? Can we trust the hardware we're using? At about 28 minutes he wonders what do they do, and mentions that some of them have no reference anywhere at all online or in reference manuals. I had nothing better to do and I was already sitting at my computer with my browser open, so I did some research. And by "research" I mean literally typed, "intel instruction [code]," into Google. Right of the bat, in less than a minute, I landed here for 0F18, which is a forum on Intel's site where someone was asking about 0F1F being newly documented in 2006. That's two thousand and six, in case you thought that was a typo. In a reply, an Intel rep says they forwarded the question to engineers and a month later responds that it would require an NDA. Sounds scary, but an earlier reply gives a link to a forum on an unofficial site for Intel technical documentation. The forum post doesn't exist anymore, but Archive.org had it. All opcodes in the 0Fh,18h...0Fh,1Fh range attempt to decode a modrm That post was from 2003. It mentioned that the 0F18 was both documented and available on the Pentium 3. And here's the patent mentioned, filed in 1997. Method of modifying an instruction set architecture of a computer processor to maintain backward compatibility Oh. So they're just instructions for backwards compatibility. And they were documented 20 years ago in the patent office. And the "you'll need an NDA" probably was in reference to asking about patented IP, or was just lazy engineers trying to blow off answering a question (probably). Next, I moved on to DBE0 and landed here. Someone's asking about obsolete instructions for 8086 processors. In a response, someone states: Besides POP CS and MOV from/to TR, I'm aware of 0x0F05 and 0x0F07 (LOADALL), and DBE0 (FNENI) and DBE1 (FNDISI), and DBE4 (FNSETPM) andDBE5 (FRSTPM). I looked up FNENI and FNDISI (see: dork), but what they mean is irrelevant. They're nothing nefarious and well-documented, they're just deprecated. And since Intel has tried to maintain backwards compatibility with its processors (see: patent), those instructions are likely just grandfathered in for backwards compatibility and no longer officially documented because they're obsolete and so far out of date that people shouldn't use them. He also mentioned 0FAE and says it wasn't documented until 2014. Here's a post on the Ars Technica forum from 2001 asking about it because it's causing a fault, there's a lot of talk about needing SSE support for what they're doing, and later in the thread it's mentioned that instruction is probably related to SSE. And yep, it 's an SSE instruction for "FXRSTOR." Here is a snapshot of an unofficial site from 2007 documenting the SSE instruction, so it had to have been documented somewhere before 2014 for that site to list it. Probably in the SSE reference manual :( He also mentions F1. Here is a page from the x86/x64 reference manual: The opcodes D6 and F1 are undefined opcodes reserved by the Intel 64 and IA-32 architectures. These opcodes, even though undefined, do not generate an invalid opcode exception. Oh, so that's why his technique uncovered that instruction. Here is a site mentioning the same thing for 8086 processors. I didn't bother looking up other codes. After I got through half of them and found they were all documented, sometimes for decades, I figured you can find out what the rest of these hidden instructions do by reading the fucking manual. I wouldn't care and put all this effort into this post, but fear-mongering combined with me being able to type in a trivial Google search and instantly find documentation about this makes me VERY ANGRY >:( |
||||
 |
 |
|||
|
HACK THE X86!!! HACK THE PLANEEEEEEEEEEEEET! by 09/10/2017, 12:05am PDT  He should document what he is doing with his mouth hole that he needs the by 09/10/2017, 12:41am PDT Caltrops, what is our opinion of the 'french beard'? NT by 09/10/2017, 6:38pm PDT If it's all innocuous, and there's no exploit/malicious angle? by 09/10/2017, 1:00pm PDT |
