Looks like it does roughly the same thing as this [1]. I guess it's a tossup between a proprietary program from Intel or a free program on github from the person who found the bug.<p>[1] <a href="https://news.ycombinator.com/item?id=14335159" rel="nofollow">https://news.ycombinator.com/item?id=14335159</a>
Something security-related to keep in mind (TL;DR at end):<p>Directory state after initial unpack (becomes important in a minute):<p><pre><code> -rwxr-xr-x 1 i336 users 19K May 13 10:43 INTEL-SA-00075-Discovery-Tool
-rw-r--r-- 1 i336 users 27K May 13 10:57 INTEL-SA-00075-Discovery-Tool.c
-rwxr-xr-x 1 i336 users 15K May 13 10:44 INTEL-SA-00075-Unprovisioning-Tool
-rw-r--r-- 1 i336 users 16K May 13 10:42 INTEL-SA-00075-Unprovisioning-Tool.c
-rw-r--r-- 1 i336 users 187 May 13 10:42 Makefile
</code></pre>
Build:<p><pre><code> $ cd INTEL-SA-00075-Discovery-Unprovisioning-Tool-Engineering-Release
$ make
gcc -I../../usr/include INTEL-SA-00075-Discovery-Tool.c -o INTEL-SA-00075-Discovery-Tool
strip INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool
$
</code></pre>
OK; wipe and do it again:<p><pre><code> $ rm INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool
$ make
gcc -I../../usr/include INTEL-SA-00075-Discovery-Tool.c -o INTEL-SA-00075-Discovery-Tool
gcc -I../../usr/include INTEL-SA-00075-Unprovisioning-Tool.c -o INTEL-SA-00075-Unprovisioning-Tool
strip INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool
$
</code></pre>
Wait - why did the unprovisioning tool only get compiled on the second build?<p>Because the binary for the unprovisioning tool is <i>two minutes NEWER</i> than the source code, as shown in the directory listing.<p>The binary for the discovery tool is older than the source (as normal).<p>Objectively it's 50/50 as to whether this is meaningless noise or something hidden. Of course everything points toward the former, but I thought I'd leave this here just in case.<p>It's worth noting that an independent security company rapidly found (and announced) the vulnerability after the initial undisclosed CVE. So if it was that easy, this vulnerability has clearly been known about in various circles for a while.<p>It's also worth noting that the build process strips the binary, which is arguably unnecessary, but is a nice way to explain why there are no debug symbols in the provided binaries.<p>Again, I trust Intel and can easily talk this away as the inanites of bureaucracy and management and deadlines, but my "hmmm" sense is tingling nonetheless.
Thankfully it comes from an https connection on downloadmirror.intel.com. But there's no md5 sha1sum or sha256sum posted anywhere else. For whatever it's worth this is what I got:<p>INTEL-SA-00075-Linux-Detection-and-Mitigation-Tools-v1.1.zip<p>md5: a4645f80a0d573a8345545954d8da8ed<p>sha1: 600ca16f9530dd9069b42e9696b0ea772eb059f0<p>sha256: 808620dd939bd3011c689eb8f4f56d92195159fd5cab570dd86598c68dd7ec63
This is weird: this tool says my laptop is vulnerable, although AMT is disabled. I also tried mjg59's mei-amt-check and it indicated that because my system is unprovisioned it was not vulnerable.