| 73Q Music Videos | Vote On Clips | Submit | Login   |

Reddit Digg Stumble Facebook
Desc:Guy creates tools to audit x86 CPUs, finds them full of hidden/undocumented stuff.
Category:Science & Technology, Educational
Tags:hacking, intel, real hacking
Submitted:jfcaron_ca
Date:09/10/17
Views:442
Rating:
View Ratings
Register to vote for this video

People Who Liked This Video Also Liked:
Trailer Park Boys - Best of J-Roc
The Charleston mixed with Daft Punk
Jacques Pépin does amazing things with eggs
Termite Queen
Nick Cage in: USS INDIANAPOLIS: MEN OF COURAGE
Globe and Mail footage captures shooting in Ottawa Parliament building
World's first BMX triple-backflip
U.N. Owen Was Yee?
DeForest Kelley's favorite fan letter
Guy tells cop 'God bless you,' cop loses it
Comment count is 6
Ugh
good and all but scarey
Rafiki
http://lmgtfy.com/?q=intel+opcode+0f18

https://software.intel.com/en-us/forums/watercooler-catchall/t opic/307174

https://web.archive.org/web/20041106070621/http://www.sandpile .org/post/msgs/20004129.htm

http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HIT OFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSr ch=yes&Query=PN/5701442



DBE0 and DBE1 are old 8086 opcodes, which x86 is derived from. f1 is literally in the reference manual, and was also part of 8086:

https://xem.github.io/minix86/manual/intel-x86-and-64-manual-v ol3/o_fe12b1e2a880e0ce-212.html

Other codes have been around for years and years as well. This was a half hour of Googling. Dude didn't look too hard.
jfcaron_ca
Is there any reason to believe those opcodes do anything close to what they did on 8086? In any case, albeit relevant, I think your comment is beside his main point.

I think his point is more that we have little ways to verify the trust we put in the CPUs. Complete reference manuals are great and all, but they rarely are complete. At the very least this kind of tool will put some pressure on the manufacturers to not leave out any details (as innocuous as they may be).

Rafiki
Given that x86 is built from 8086 architecture and inherited its instruction set, I think it's more reasonable to ask if there's any reason to believe those codes DON'T do what they did on the 8086. Furthermore, it would be easy enough to verify. Run both instructions on each processor and check the results.


If his presentation was purely that he created a clever way to verify processor instruction sets, and that he found some instructions he wasn't sure what they were and offered them up as a way to crowdsource their meaning, that would be fine. The idea of independently auditing that hardware does what it's advertised to do is great. However, some of his conclusions are flawed, some of his claims are false and trivially provably so, and his presentation of his findings to the public is irresponsible. He's CLEARLY trying to strike a fearful tone, but I'm not convinced it's deserved.

Mostly it chaps my ass if someone publishes claims I can debunk in 2 seconds of googling in my underwear.

jfcaron_ca
Fair enough.

CrimsonHyperSloth
I can't watch the video right now but the idea is not without merit. It's well known Intel/AMD and the rest tend to have extra registers and other functions in cases there is problems, as well as microcode.

https://en.wikipedia.org/wiki/Microcode

Which is used to reprogram a chip if there is issues.

Things are less hardcoded after their original fuck up with the FP look up table.

My bigger concern is side-channel attacks. It would be very difficult to verify if a certain chip leaked info via other means then hidden instructions in there.

Register or login To Post a Comment







Video content copyright the respective clip/station owners please see hosting site for more information.
Privacy Statement