HWiNFO64 (v5.60) and Intel Management Engine

Gobbo

Member
Hello,
I'm not sure this is a bug, but this seems the appropriate section to post in.
It might be useful to other users and to Martin himself.

My setup-related info:
- Windows 10 EDU 1709 Build 16299.19
- Asus ROG Maximus IX Formula
- Intel 7700k
- HWiNFO64 v5.60

Some days ago Intel answered (INTEL-SA-00086) to the recently discovered vulnerability in Intel Management Engine. 

They released a Detection Tool, useful to check if your system is affected.
And they released updated firmware too, in collaboration with various mobo manufacturers (Asus, Gigabyte, Acer, ...).

So what I did was:
  • launched the Detection Tool and found that ME version was well below the minimum / recommended one 
  • then updated ME Driver && ME itself, using .exes provided in the Asus Website
  • pls note that when performing such updates, I closed all extra-process for good measure (Logitech GS, Asus Ai Suite, HWiNFO, ...)
  • the update went through, all good
After reboot I launched again the Detection Tool and with much surprise, my system was still detected as "Vulnerable", despite the ME version was increased correctly.

I did some digging and discovered that running the Detection Tool with HWiNFO opened, will always result in the system being detected as a "Vulnerable" one.
The steps I followed to reproduced the error may be boring, so I won't post them here.
However you can find the details here on ROG Forum...

Long story short: running the Detection Tool without HWiNFO opened, will result in a "normal behavior" by the Detection Tool; aka correctly loading MEI device driver and then checking the FW version.

I don't know if this is supposed to happen or if this is an already known behavior.
What I know for sure is that the Intel detection tool is giving some very misleading message when it can not load MEI dd correctly.

This happen to lots of people, probably having some conflicting SW/process running on their machines.
Since in my case HWiNFO was THE process, I've thought to share.

I hope my post can help somehow :)
 

Martin

HWiNFO Author
Staff member
HWiNFO communicates with the Intel Management Engine (IME) too and opens a handle to it.
I believe the Intel detection tool does the same too, but in a slightly different way - it doesn't accept anyone else to have an open handle to the IME. So it fails to access it, logs the error, but reports that the system is vulnerable (which is not quite true). HWiNFO on the other hand doesn't enforce exclusive access to IME, it allows other applications to access it (object access sharing).
So I believe there's a problem in the Intel detection tool:
1. It doesn't accept shared access to IME
2. A failed access to IME is reported as a vulnerable system instead of reporting the true problem
 

Gobbo

Member
Martin said:
Intel detection tool (...) fails to access it, logs the error, but reports that the system is vulnerable (which is not quite true).
(...)
2. A failed access to IME is reported as a vulnerable system instead of reporting the true problem
Exactly this, thanks for your confirmation!

There actually is a warning when you use the FWUpdate tool, about "closing any other programs"... And being an update it's understandable.
But there isn't anything similar when launching the Detection Tool.
So lots of users using software for temperature-monitoring which communicate with IME (like HWiNFO) are getting confused about the "vulnerable system" report.

A much better choice would be to handle the exception / suggest the user to close any monitoring program, instead of report the system as vulnerable (and expose a different SVN too :s )

That being said, maybe this thread is in the wrong section and needs to be moved since we are not talking about an HWiNFO bug / issue  :cool:
 

Martin

HWiNFO Author
Staff member
I don't think there are many tools utilizing the IME.
But I think I could modify HWiNFO so that it doesn't hold a handle to ME when not needed. It might hold it only during the initial scan and release it afterwards. This would significantly reduce the likelihood of the conflict in case Intel doesn't fix their tool. Let me have a look at that...
 

Gobbo

Member
Martin said:
I don't think there are many tools utilizing the IME.
Mmh ok, maybe other people are getting false vulnerable reports for other reasons. But that's a good amount of users tho...
I'm wondering why, in first place, a Detection tool need to have an exclusive access to communicate with IME and work properly.

Martin said:
But I think I could modify HWiNFO so that it doesn't hold a handle to ME when not needed.
Ah, this would be nice of course! Improving software is always a good thing  :sleepy:
 

Martin

HWiNFO Author
Staff member
Gobbo said:
I'm wondering why, in first place, a Detection tool need to have an exclusive access to communicate with IME and work properly.
Because IME is their technology, not expected to be widely used this way by other applications.

Gobbo said:
MartinBut I think I could modify HWiNFO so that it doesn't hold a handle to ME when not needed.
Ah, this would be nice of course! Improving software is always a good thing  :sleepy:
OK, so this change seems to be feasible. Will be available since the next (Beta) build.
 

Gobbo

Member
Martin said:
Because IME is their technology, not expected to be widely used this way by other applications.
Ah ok, I see. Fortunately you are using it in HWiNFO and it's working good!

Martin said:
OK, so this change seems to be feasible. Will be available since the next (Beta) build.
Nice to know, thanks for your effort Martin.
 

Martin

HWiNFO Author
Staff member
I have just released v5.61-3293 Beta that should fix this problem (more precisely significantly reduce or almost eliminate the probability of the conflict).
Can you please try if it's OK now ?
 

Gobbo

Member
Martin said:
I have just released v5.61-3293 Beta that should fix this problem (more precisely significantly reduce or almost eliminate the probability of the conflict).
Can you please try if it's OK now ?
Hello, cool! 

I will report in a few hours, not at home atm.
 

Gobbo

Member
Gobbo said:
Martin said:
I have just released v5.61-3293 Beta that should fix this problem (more precisely significantly reduce or almost eliminate the probability of the conflict).
Can you please try if it's OK now ?
Hello, cool! 

I will report in a few hours, not at home atm.
I can confirm that v5.61-3293 Beta has no issue on my system.
Unzipped the file and ran the executable after overwriting the INI file with my usual settings.

See result in attached file.
Thanks Martin once again  :shy:
 

Attachments

Top