Intel Management Engine Interface - What is it?

Some time ago I did a fresh install of Windows 7 Home Premium 32 bit on a
new machine.

In Device Manager there was yellow bang against an unknown PCI
communications device.

I eventually tracked this down to a motherboard chip associated with the
item in the subject line, but could find no 32 bit Win7 driver for it.

Having looked at the Intel documentation and the Wiki entry, I found myself
little wiser as to it's function.

I concluded that as a home user I probably had no need of it.

However, today, Windows Update has offered me a driver for it. Curiously it
is classified as Important (rather than Optional as most driver updates seem
to be).

I would be grateful if someone could explain ( in non-specialist language)
what this device does, and as a home user if I need to have it enabled.

Does it, for instance, provide any function to assist Windows Update.

--
John

"John Aldred" wrote:

Some time ago I did a fresh install of Windows 7 Home Premium 32 bit on a
new machine.

In Device Manager there was yellow bang against an unknown PCI
communications device.
[...]
I would be grateful if someone could explain ( in non-specialist language)
what this device does, and as a home user if I need to have it enabled.

IMEI is one component of Intel's VPRO remote access technology. I'm a bit
surprised that it's unexpectedly showing up in what I presume is a consumer
computer; it's an extra-cost item (last time I talked to our account team we
were told that they paid Intel $25 for each system shipped with the
feature). Unless you plan to put the box in a remote location where it can't
be accessed if (when) it gets hung it's probably not that much use to you.

You don't say what make and model of computer is involved. Look at the BIOS
setup options; assuming that you don't want it you might be able to disable
the feature there (and thus get rid of the yellow bang in Device Manager).

Joe Morris

Joe Morris wrote:

"John Aldred" wrote:

Some time ago I did a fresh install of Windows 7 Home Premium 32 bit on a
new machine.

In Device Manager there was yellow bang against an unknown PCI
communications device.
[...]
I would be grateful if someone could explain ( in non-specialist
language) what this device does, and as a home user if I need to have it
enabled.

IMEI is one component of Intel's VPRO remote access technology. I'm a bit
surprised that it's unexpectedly showing up in what I presume is a
consumer computer; it's an extra-cost item (last time I talked to our
account team we were told that they paid Intel $25 for each system shipped
with the feature). Unless you plan to put the box in a remote location
where it can't be accessed if (when) it gets hung it's probably not that
much use to you.

You don't say what make and model of computer is involved. Look at the
BIOS setup options; assuming that you don't want it you might be able to
disable the feature there (and thus get rid of the yellow bang in Device
Manager).


The computer is a Dell Inspiron Desktop 580.
It has the Intel Core i3 processor 540 and a H57 chipset.
Sold in Europe as a mid-range consumer machine.

There are no BIOS settings relating to IMEI or AMT.

I have disabled the item in Device Manager.

From what I can understand of the technical literature it is to allow remote
access over a LAN for IT admin / repair purposes even when the system is
powered down.

I understand very little about it, but could it be used over the internet to
allow an OEM to fix a customers machine?

--
John

John Aldred wrote:
Joe Morris wrote:

"John Aldred" wrote:

Some time ago I did a fresh install of Windows 7 Home Premium 32 bit on a
new machine.

In Device Manager there was yellow bang against an unknown PCI
communications device.
[...]
I would be grateful if someone could explain ( in non-specialist
language) what this device does, and as a home user if I need to have it
enabled.
IMEI is one component of Intel's VPRO remote access technology. I'm a bit
surprised that it's unexpectedly showing up in what I presume is a
consumer computer; it's an extra-cost item (last time I talked to our
account team we were told that they paid Intel $25 for each system shipped
with the feature). Unless you plan to put the box in a remote location
where it can't be accessed if (when) it gets hung it's probably not that
much use to you.

You don't say what make and model of computer is involved. Look at the
BIOS setup options; assuming that you don't want it you might be able to
disable the feature there (and thus get rid of the yellow bang in Device
Manager).


The computer is a Dell Inspiron Desktop 580.
It has the Intel Core i3 processor 540 and a H57 chipset.
Sold in Europe as a mid-range consumer machine.

There are no BIOS settings relating to IMEI or AMT.

I have disabled the item in Device Manager.

From what I can understand of the technical literature it is to allow remote
access over a LAN for IT admin / repair purposes even when the system is
powered down.

I understand very little about it, but could it be used over the internet to
allow an OEM to fix a customers machine?


According to the chipset datasheet (322169), only the Q57 has AMT 6.0.
The H57, H55, P55 don't.

But yet, the data sheet, doesn't distinguish SKUs when it comes to
the registers and the like. So unlike previous chips with AMT, it's unclear
whether this one, places a firm boundary on having AMT or not.

The 322170 document, shows the VID and PID of the two IME engine blocks.
Again, there is no documentation to state why there are two. Previous
chipsets might have had one (with only the Q series chip having that
one enabled). In a quick comparison of the registers for them, they
look identical. So I can't figure out from the register description,
why there are two.

IMEI #1 8086:3B64
IMEI #2 8086:3B65

It's not even clear to me, why you'd make them visible in the host space,
because they're supposed to have control over the host. In other words,
if your host had a virus, you had AMT, the Management Engine should be
able to reset the machine. You wouldn't want a virus to interact with a
driver pointed at 3B64 and 3B65, if it could prevent AMT from working.
So I don't see the purpose of having a driver. Maybe it's just for
observability or something ?

I only have one slide set, from an IDF presentation, that does a decent
job of describing the capabilities. And that slide set is a few years
old now (and no longer available from the Intel site).

An OEM would not need it to fix a consumer machine. There are other
ways to do that (as long as the OS is running).

So even if the IMEIs was disabled in Device Manager, or no driver was loaded,
that doesn't convince me the hardware isn't still "armed". The solution
is dependent on the firmware (stored in BIOS chip), and if the AMT
firmware block is missing or neutered, that would certainly prevent
a lot of stuff from happening. Perhaps reusing a BIOS intended for
Q57, is why this is happening ? But if that was the case, you'd also
expect to see some kind of BIOS control to disable it. Or a jumper
or something... I checked the strap list in the datasheet, and I don't
see something intended to disable IMEI. I did see a reference to
cryptography, so it may not be possible to attack the computer,
without knowing the key needed to facilitate communications.

When I first read of AMT, I knew there'd be a day like this, where
the user would lose control...

While there are some details here, this info isn't up to date. With
your hardware, there is no evidence that pulling memory DIMMs out
of channel 0, makes any difference at all to the Management Engine.
(I checked the Core i3 datasheet.)

http://software.intel.com/en-us/arti...nt-technology/

Paul

Paul wrote:

[Snip]

According to the chipset datasheet (322169), only the Q57 has AMT 6.0.
The H57, H55, P55 don't.

But yet, the data sheet, doesn't distinguish SKUs when it comes to
the registers and the like. So unlike previous chips with AMT, it's
unclear whether this one, places a firm boundary on having AMT or not.

The 322170 document, shows the VID and PID of the two IME engine blocks.
Again, there is no documentation to state why there are two. Previous
chipsets might have had one (with only the Q series chip having that
one enabled). In a quick comparison of the registers for them, they
look identical. So I can't figure out from the register description,
why there are two.

IMEI #1 8086:3B64
IMEI #2 8086:3B65

It's not even clear to me, why you'd make them visible in the host space,
because they're supposed to have control over the host. In other words,
if your host had a virus, you had AMT, the Management Engine should be
able to reset the machine. You wouldn't want a virus to interact with a
driver pointed at 3B64 and 3B65, if it could prevent AMT from working.
So I don't see the purpose of having a driver. Maybe it's just for
observability or something ?

I only have one slide set, from an IDF presentation, that does a decent
job of describing the capabilities. And that slide set is a few years
old now (and no longer available from the Intel site).

An OEM would not need it to fix a consumer machine. There are other
ways to do that (as long as the OS is running).

So even if the IMEIs was disabled in Device Manager, or no driver was
loaded, that doesn't convince me the hardware isn't still "armed". The
solution is dependent on the firmware (stored in BIOS chip), and if the
AMT firmware block is missing or neutered, that would certainly prevent
a lot of stuff from happening. Perhaps reusing a BIOS intended for
Q57, is why this is happening ? But if that was the case, you'd also
expect to see some kind of BIOS control to disable it. Or a jumper
or something... I checked the strap list in the datasheet, and I don't
see something intended to disable IMEI. I did see a reference to
cryptography, so it may not be possible to attack the computer,
without knowing the key needed to facilitate communications.

From what you say (if I understand your comments correctly), this device
could be more of liability than an asset to home users, in respect of
malicious attack. Unless access to it was blocked by default.


When I first read of AMT, I knew there'd be a day like this, where
the user would lose control...

While there are some details here, this info isn't up to date. With
your hardware, there is no evidence that pulling memory DIMMs out
of channel 0, makes any difference at all to the Management Engine.
(I checked the Core i3 datasheet.)


Someone in another forum pointed me at this:

http://www.intel.com/en_US/Assets/PD...Intel_MEBX.pdf

and suggested that I looked at pages 95 - 105.

I guess It could explain why the device is on a home user desktop.

--
John

John Aldred wrote:


From what you say (if I understand your comments correctly), this device
could be more of liability than an asset to home users, in respect of
malicious attack. Unless access to it was blocked by default.

Someone in another forum pointed me at this:

http://www.intel.com/en_US/Assets/PD...Intel_MEBX.pdf

and suggested that I looked at pages 95 - 105.

I guess It could explain why the device is on a home user desktop.


Yes, I see only liability here. The document you provided mentions
"PKI" or Public Key Infrastructure, so there is some notion of
protecting communications with it. And the thing is, the hardware
assets the microcontroller needs, have to be connected to make
it work, so if some off-brand networking chip was used, perhaps
it wouldn't work.

It would really help, if we could tell exactly what firmware was
loaded for the IMEI. If the only thing loaded, is some fan control
firmware, that might not be so bad. But if the whole standard Intel
package was loaded, I think we deserve to know that.

Even if we knew what IP port it used, we could say "well, if
you're using a firewall, block port X", that would be worth some
small peace of mind. Of course, the firewall would have to be
at your home router, because on the computer itself, the IMEI has
access to the Inteo Pro/1000 network chip directly.

I prefer to see the results of a Black Hat conference on the topic.
To see if that interface has ever been abused. With VT-X from
Intel, it was "Blue Pill".

"The Blue Pill rootkit for x86-based computers was based on this
concept: it presents the illusion of a computer that has not been
tampered with but uses virtualization to monitor and control the
system in a nearly undetectable fashion."

I'm just concerned, that buying a non Qxx series chipset, has now resulted
in a new set of exposures. Intel does try hard, to not open new holes,
but every time you add features like this, it extended the reach of
malware authors. Even SMM, a relatively old feature, offers a
virtually invisible way for malware to control a computer. SMM
is invisible, except if you use a stopwatch and notice chunks of
time disappearing in the OS.

http://en.wikipedia.org/wiki/System_Management_Mode

Stuff like this generally doesn't happen, because of the number
of variables presented to malware authors. It might be of more interest
in a focused attack, where someone knows you have a Dell 580 and they
cook up something specially for it.

Paul

Paul wrote:

John Aldred wrote:


From what you say (if I understand your comments correctly), this device
could be more of liability than an asset to home users, in respect of
malicious attack. Unless access to it was blocked by default.

Someone in another forum pointed me at this:

http://www.intel.com/en_US/Assets/PD...Intel_MEBX.pdf

and suggested that I looked at pages 95 - 105.

I guess It could explain why the device is on a home user desktop.


Yes, I see only liability here. The document you provided mentions
"PKI" or Public Key Infrastructure, so there is some notion of
protecting communications with it. And the thing is, the hardware
assets the microcontroller needs, have to be connected to make
it work, so if some off-brand networking chip was used, perhaps
it wouldn't work.

It would really help, if we could tell exactly what firmware was
loaded for the IMEI. If the only thing loaded, is some fan control
firmware, that might not be so bad. But if the whole standard Intel
package was loaded, I think we deserve to know that.

Even if we knew what IP port it used, we could say "well, if
you're using a firewall, block port X", that would be worth some
small peace of mind. Of course, the firewall would have to be
at your home router, because on the computer itself, the IMEI has
access to the Inteo Pro/1000 network chip directly.

I prefer to see the results of a Black Hat conference on the topic.
To see if that interface has ever been abused. With VT-X from
Intel, it was "Blue Pill".

"The Blue Pill rootkit for x86-based computers was based on this
concept: it presents the illusion of a computer that has not been
tampered with but uses virtualization to monitor and control the
system in a nearly undetectable fashion."

I'm just concerned, that buying a non Qxx series chipset, has now resulted
in a new set of exposures. Intel does try hard, to not open new holes,
but every time you add features like this, it extended the reach of
malware authors. Even SMM, a relatively old feature, offers a
virtually invisible way for malware to control a computer. SMM
is invisible, except if you use a stopwatch and notice chunks of
time disappearing in the OS.

http://en.wikipedia.org/wiki/System_Management_Mode

Stuff like this generally doesn't happen, because of the number
of variables presented to malware authors. It might be of more interest
in a focused attack, where someone knows you have a Dell 580 and they
cook up something specially for it.


Yes, I find this whole concept very disquieting.

--
John