Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Solved HWiNFO64 (v5.60) and Intel Management Engine
#1
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 Smile
Reply
#2
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
Reply
#3
(11-23-2017, 07:08 PM)Martin Wrote: 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 Confused )

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
Reply
#4
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...
Reply
#5
(11-23-2017, 08:00 PM)Martin Wrote: 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.

(11-23-2017, 08:00 PM)Martin Wrote: 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
Reply
#6
(11-23-2017, 08:14 PM)Gobbo Wrote: 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.

(11-23-2017, 08:14 PM)Gobbo Wrote: 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.
Reply
#7
(11-23-2017, 08:38 PM)Martin Wrote: 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!

(11-23-2017, 08:38 PM)Martin Wrote: OK, so this change seems to be feasible. Will be available since the next (Beta) build.
Nice to know, thanks for your effort Martin.
Reply
#8
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 ?
Reply
#9
(11-29-2017, 02:02 PM)Martin Wrote: 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.
Reply
#10
(11-29-2017, 02:07 PM)Gobbo Wrote:
(11-29-2017, 02:02 PM)Martin Wrote: 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


Attached Files Thumbnail(s)
   
Reply
#11
Thanks for the test and feedback Smile
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)