Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse-Engineering the Intel Management Engine

puri.sm

Post reply on HN
Print view View original

11–20 of 36 posts

Re: Reverse-Engineering the Intel Management Engine

#11

Post by floatboth »

prodmerc wrote: post #9

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…

> 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?

Re: Reverse-Engineering the Intel Management Engine

#12

Post by Buge »

cryptarch wrote: post #6
d33 wrote: post #3

Earlier quoted context omitted.

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.

Re: Reverse-Engineering the Intel Management Engine

#13

Post by lightedman »

prodmerc wrote: post #9

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…

Try SetFSB.

Re: Reverse-Engineering the Intel Management Engine

#14

Post by wolfgke »

ReverseCold wrote: post #2

Hopefully we can get a fully libre boot on purism laptops soon. I feel like there would be legal problems though...

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.

Re: Reverse-Engineering the Intel Management Engine

#15

Post by bigiain »

qb45 wrote: post #8
mmastrac wrote: post #5

Earlier quoted context omitted.

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 obfuscat…

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.

Re: Reverse-Engineering the Intel Management Engine

#16

Post by pkaye »

bigiain wrote: post #15
qb45 wrote: post #8

Earlier quoted context omitted.

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_ les…

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.

Re: Reverse-Engineering the Intel Management Engine

#17

Post by bigiain »

pkaye wrote: post #16
bigiain wrote: post #15

Earlier quoted context omitted.

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_ les…

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...

Re: Reverse-Engineering the Intel Management Engine

#18

Post by Namidairo »

floatboth wrote: post #11
prodmerc wrote: post #9

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…

> 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.

Re: Reverse-Engineering the Intel Management Engine

#19

Post by tsomctl »

bigiain wrote: post #17
pkaye wrote: post #16

Earlier quoted context omitted.

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…

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

Re: Reverse-Engineering the Intel Management Engine

#20

Post by pkaye »

bigiain wrote: post #17
pkaye wrote: post #16

Earlier quoted context omitted.

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…

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...
Post reply on HN