That said, please note that this is partially outdated information (even to the extent of warranting a mod edit even though it's so recent) - the parts that mention how some compressed modules are unreadable are now irrelevant.
The URL for this article is /2017/04/ (April).
More recently (July, three months later), this same group has somehow (??) managed to derive the Huffman compression tables for the previously-inaccessible modules: https://github.com/ptresearch/unME11
I haven't read anything that explicitly states this (on HN; I don't read anywhere else), but I get the impression this is the holy grail, or at least one of the major pieces of the puzzle.
Being able to run unsigned code in ME might allow (depending on how the exploit works) for either a replacement of the ME firmware entirely or just doing a disable that exceeds even the HAP bit (and the rest of magic that me_cleaner does to remove different sections of the firmware). But we'll have to wait for the slides, I'm hoping there's something really useful there for the coreboot community.
I don't know what kind of speculations one could have about that.
To be honest the more transistors components have, the more it is possible to have underlying software that can manage things or even be used as a backdoor.
Am I right to be concerned about this, if only in principle? I don't like having a mysterious embedded chip that can access the network when my computer's off.
The JVM runs as process on the OS. Older MEs used ThreadX on an ARC CPU.
Current ME is the Quark x86 core (~486 class, in-order execution) running MINIX. Probably still running their JVM for applets (the off-CPU McAfee compliance manager is probably built that way).
[+] [-] JepZ|8 years ago|reply
just kidding
[+] [-] ricogallo|8 years ago|reply
[+] [-] exikyut|8 years ago|reply
That said, please note that this is partially outdated information (even to the extent of warranting a mod edit even though it's so recent) - the parts that mention how some compressed modules are unreadable are now irrelevant.
The URL for this article is /2017/04/ (April).
More recently (July, three months later), this same group has somehow (??) managed to derive the Huffman compression tables for the previously-inaccessible modules: https://github.com/ptresearch/unME11
I haven't read anything that explicitly states this (on HN; I don't read anywhere else), but I get the impression this is the holy grail, or at least one of the major pieces of the puzzle.
I found this random comment about actually using unME11: https://news.ycombinator.com/item?id=15447841
This recent HN article suggests that it's also possible to get arbitrary remote code execution, but no details are (yet) forthcoming. https://news.ycombinator.com/item?id=15298833
[+] [-] moppl|8 years ago|reply
Disabling Intel ME 11 via undocumented mode (ptsecurity.com) https://news.ycombinator.com/item?id=15116719
How to hack a turned-off computer, or running unsigned code in Intel ME (blackhat.com) https://news.ycombinator.com/item?id=15298833
Personally I am extremely curious about the upcoming blackhat presentation. If it is really true this might be very big.
[+] [-] j_s|8 years ago|reply
Disabling the Intel Management Engine | https://news.ycombinator.com/item?id=15444607 (Oct 2017, 219 comments)
If nothing else, the BlackHat talk has stirred up interest in the Intel ME which had remained in relative obscurity for quite some time.
[+] [-] cyphar|8 years ago|reply
[+] [-] craftyguy|8 years ago|reply
[+] [-] jokoon|8 years ago|reply
To be honest the more transistors components have, the more it is possible to have underlying software that can manage things or even be used as a backdoor.
[+] [-] theprotocol|8 years ago|reply
[+] [-] adtac|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] youdontknowtho|8 years ago|reply
[+] [-] pgeorgi|8 years ago|reply
[+] [-] jlgaddis|8 years ago|reply
[+] [-] grabcocque|8 years ago|reply
Finally some geek cred for the ME.
[+] [-] unlmtd1|8 years ago|reply
[deleted]