Various network administration tools take advantage of the WMI component to know how their co-workers computers are doing, or what the co-workers are doing with it. This information is passed to those tools trough the WMI Classes. So suppose you don't want to tell them what software you have installed on your computer, then, without stoping WMI service ( leading to the administrator knowing that there was a scan error with your machine ) you can instead delete the WMI CLass Win32_Product and Win32_ProductCheck, lets see:
On the command line:
c:\> wbemtest
( the wbemtest window pops up on Windows)
Click Connect, and where it says root\default replace with root\cimv2 press OK
Now press the button Enum Instances... and you should see:
There enter Win32_Product and accept, you should see a bunch of entries like this:
You can conclude that Win32_Product class is announcing that i have, among lots of other stuff, Microsoft Office installed.
To stop this class from reporting software, the simpler solution i know is to delete the class. Just press where it says Delete Class and enter it's name, but beware: I don't think there is a practicall way to reinstall this class again unless you fully reinstall WMI. So proceed wisely.
Of course, there are other ways to obtain the installed software on your machine remotely. :)
Thanks for reading
This comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteThis is a really intriguing and somewhat mischievous post about deleting WMI classes like Win32_Product to prevent remote inventory of installed software! Thanks for exploring this niche but powerful use of wbemtest.
ReplyDeleteYou've touched on a very real scenario where users might want to control the information exposed about their machine, especially in corporate environments where WMI is widely used for auditing and management. The idea of "going dark" on software inventory without raising red flags by simply stopping the WMI service is clever.
The step-by-step guide using wbemtest to connect to root\cimv2, enumerate instances, and then delete classes is clear and actionable.
However, your crucial warning about the difficulty, or near impossibility, of restoring deleted WMI classes without a full WMI reinstall is extremely important. This highlights the high-risk nature of this particular "trick." Also, acknowledging that there are other ways to obtain installed software (e.g., registry, file system scans) adds a good layer of realism to the post.
This is a very specific technique that demonstrates deep knowledge of Windows internals and WMI. It's a great example of how low-level system components can be manipulated for privacy or "defense in depth" purposes.
For more discussions on WMI manipulation, stealth techniques, or advanced system hardening beyond standard configurations, a hacking forum would be an excellent place to exchange such powerful (and potentially risky) knowledge.