Reverse-Engineering the Intel Management Engine | Hacker News Reader

Reverse-Engineering the Intel Management Engine

puri.sm

273 pointslaamalif34 comments

Meanwhile I'm trying to find a way to remove the hard lock on CPU and RAM frequencies (extreme CPUs can't be overclocked, RAM is locked at 1333 MHz) :)

Looks like it can be done through Management Engine, which has access to everything apparently.

Only success so far is unlocking BCLK, but the overclock is small and unstable that way.

Another roadblock was the read only lock, which can fortunately be bypassed on POST on xx67/77 chipsets.

e_context? but good luck anyway.

> extreme CPUs can't be overclocked

You mean non-extreme?

> unlocking BCLK, but the overclock is small and unstable that way

On desktop Skylake, BCLK can get you to anywhere you want (I run an i5-6400 at 4.5GHz daily, over 4.7 for benchmarks). You're talking about laptops, right?

> On desktop Skylake, BCLK can get you to anywhere you want

I thought Intel shut this down with microcode updates.

Microcode can't know anything if all power management is completely disabled :P You need a special firmware build for that: http://overclocking.guide/intel-skylake-non-k-overclocking-b...

BCLK overclocking is heavily motherboard dependent, you need a very good external clock reference and in any case once you go over 3-5mhz you drop your PCIE rates from 3.0 to 2.0.

Intel's HEDT platform supports proper CPU strap overclocking withou adverse effects, but even then it's usually not recommended unless you are doing extreme OC and that's liquid nitro :)

Laptop, and extreme CPU. HP and Dell block TPL/TRL adjustment even for XM processors, and HP took it even further with their 1333 MHz limit on RAM. I have 1600 MHz sticks that can run fine at 1866 and probably more (tried with Thaiphoon Burner), so that's really annoying. I don't want an Alienware to get that.

And BCLK allows for a 5MHz overclock, which is not much, anything more and the system crashes. Which is really strange, may have something to do with PCIE as Dogma said.

I just want to get everything out of my extreme processor and RAM.

Isn't that a bad idea... laptops have significant thermal limitations, things start going wrong quickly when you push beyond those. I've not done any serious overclocking but most seem to stick to desktop and buy more capable cooling systems to make it sustainable.

Aside from heatsink limitations (which can be modded to achieve better cooling), people are pushing their gaming laptops to 80W and beyond, with overclocked GPUs as well.

Some are resorting to dual PSU's to handle the power requirements, so the system boards are capable of handling some insane load.

I myself squeezed another year out of a Core 2 Quad laptop by overclocking everything as much as possible. Temperatures were averaging 90-95 under load, but I didn't care at that point, as I was going to upgrade. It still works :D

Try SetFSB.

This is nice, but it just allows you to replace some of the the Management Engine code. What we need to know in detail is what it's doing. There's probably a backdoor in there that hasn't been discovered yet.

On the other hand, if we get "our" code into the IME, we can really do interesting stuff. For example reading out data that one should not be read out? ;-)

Hopefully we can get a fully libre boot on purism laptops soon.

I feel like there would be legal problems though...

What kind of legal problems would you anticipate?

Perhaps by ways the DMCA, for "p0wning" DRM('d) modules?

Only the people actually subverting the DRM would have legal problems. The people manufacturing the laptop would be fine.

What sections of the law and precedents make you so sure about that?

I tend to take the view that if the law doesn't prevent it, it's ok to do. I don't need legal permission to do something, I just need to avoid things that the law specifically bans.

If someone with a lot of money has a problem with what you're doing, they'll hire lawyers to discover some way that the law prevents you from doing it. If the ensuing lawsuit, which will bankrupt you regardless of its outcome, doesn't serve as a sufficient warning for anyone else who wants to do whatever it was you did, they'll proceed to buy a law that prevents you from doing it.

My guess would be DMCA anti-circumvention issues.

Just develop it anonymously and make information on how to flash it yourself either on an .onion page or on a server in a jurisdiction that does not care (so much) about US American intellectual property.

Did the author notify Intel about the bug they found?

Respectfully, why would they? The goal here is to find exploits in ME and use them to make Intel chips more end-user friendly.

When we were rooting Android devices we sat on a lot of exploits that we believed we could use to give end-users freedom. There were a handful that were bad enough to warrant disclosure [1], but we still offered them as ways for users to control their own devices with a few layers of obfuscation on top.

[1] http://www.unrevoked.com/rootwiki/doku.php/public/unrevoked1...

Publishing a blog post isn't exactly sitting on a vuln. I would understand if they kept it to themselves and I would understand if they reported to Intel, but this?

I'm not entirely sure the same "responsible disclosure" arguments for software apply to hardware.

With software, a patch release is a common enough thing that it's a solid argument that letting companies like Microsoft or Apple or Google or others who've demonstrated they'll actually fix security bugs (so, maybe not Oracle, for example), or any of the hundreds or thousands of widely-used OSS projects - I'm _much_ less convinced that any company like Intel will ever manage to get even a single digit percentage of their users to reflash CPU firmware - if that's even possible - and I've never heard of a hardware company freely replacing all user's CPUs where remote exploits are known.

Where the option of "give them 90 days to get a patch out - possibly give them an extension if they ask and explain why, but otherwise sit on the bug with the vendor until it's fixed or being actively exploited in the wild" à la Google Zero & Tavis seems to work reasonably well enough of the time for software bugs - it seems to me unlikely to be as beneficial for hardware bugs which are much much harder to get fixes to end users - and early disclosure giving the opportunity to mitigate with firewalls or unplugging the device seems more likely to be the better choice.

Isn't the whole purpose of this IME to facilitate remote updates and management of systems? As for patching hardware, Intel does have the ability to apply microcode patches. At the least they are able to disable features that are buggy.

Sure - it's _possible_ to patch the microcode - but can your dentist's receptionist do it? Or your mom? Unless there's a tool that automatically applies security microcode updates as easily and as widespread as automatic Windows updates - it's really only of use to enterprise/corporate networks... I've never bumped into a small or medium sized business that runs remote management for all the machines on their office networks...

Windows update does distribute microcode updates. For example, https://support.microsoft.com/en-us/help/3064209/june-2015-i...

I know the Linux kernel on my Ubuntu system applies microcode patches early on bootup. I also know that Microsoft has microcode patches as updates. For example https://support.microsoft.com/en-us/help/3064209/june-2015-i...

> When we were rooting Android devices we sat on a lot of exploits that we believed we could use to give end-users freedom.

I often think whether one should really help people who decide to buy locked-down Android devices.

I would gladly buy an open source (including firmware) phone instead. Any you'd like to recommend?

First: mmastrac was explicitly talking about rooting Android devices via an exploit. Since as far as I know there are Android devices available that can be rooted on your own, buying one where an exploit is necessary is a conscious decision by people who don't care about such rooting. So your argument is off my point.

This said: To my knowledge for some mobile phones using a TI Calypso chip, one can flash a free firmware (OsmocomBB):

> https://osmocom.org/projects/baseband/wiki/Phones

Even if it was exploitable, it's not like Intel can fix it as they have no mechanism to revoke the old version.

Sure, they could release a new version with the bug fixed, but the attacker doesn't have to use the new version, they can deliberately use the old flawed version in their modified version of the bios.

Hopefully this is true. Though we really don't know what all the components in the Intel ME can do. They might be able to remotely update all chips so long as they have connected to a network that still exists. But I think (hope) this is unlikely and you are right.

Reply on news.ycombinator.com