Device Query: Dead of 64-bits

Last Updated on April 10, 2024 by rudyooms

This blog will show you why the new Device Query Intune Suite feature could give you the wrong information when you are using the WindowsRegistry entity to retrieve some registry keys from your device!

Please Note. After posting this blog a lot happened and Microsoft has fixed the 32 bits issue! Please read part 5!

I will divide this blog into multiple parts

  1. Introduction
  2. What’s happening?
  3. The flow
  4. It’s Fixed!

1. Introduction

This week, a new feature, Device Query, was officially released. With Device Query, we can query the device to get real-time insights into it.

I decided to investigate how the Device KQL Query is sent to your device and how the Intune management extension executes it for you.

Intune Device Query | Real-Time insights | Pivot | KQL (call4cloud.nl)

While spending time on that blog, I also encountered some issues in which the device query was not running. I decided also to take a closer look at how we could solve it and how people could troubleshoot Device Query when they run into some issues.

Device Query | An Error occurred. Try Running the query again (call4cloud.nl)

So, two blogs about Device Query—job done, right? Nope. With the official release of Device Query, my tenant was also flighted for DataProtection (end-to-end encryption). With this IME feature, I could now query the Windows registry in a protected way.

From there on I decided to look to see if we could use device query to query some specific registry keys from our device.

For example, this is the DCLAPS registry key we previously used to temporarily store the LAPS admin password so we could retrieve it with our RMM tool.

Afbeelding met schermopname, tekst, software, lijn

Automatisch gegenereerde beschrijving

After selecting the proper device and opening the device query tab, I entered the command to fetch that registry key and pressed “Run”

Afbeelding met tekst, schermopname, lijn

Automatisch gegenereerde beschrijving

As shown above, no results.?? That’s weird because I know for sure that there is a registry key in it. To be sure I wasn’t going mad, I also decided to look at a different registry key to find out if it was only impacting the Microsoft registry key or others.

As shown above, the Devicie registry key in the root of the software registry key has the same outcome: no results!

2. What’s happening?

What’s happening? Why am I not getting the proper results back???? No error? Just no results to show? That’s weird! Luckily, Procmon was also running. Guess what it showed me!

Afbeelding met tekst, schermopname, software, lijn

Automatisch gegenereerde beschrijving
Afbeelding met tekst, schermopname, Lettertype, scherm

Automatisch gegenereerde beschrijving

As shown above, the 32-bit IntuneWindowsAgent was trying to find the registry key in the corresponding 32-bit registry key on my 64-bit device. This wow6432node registry node doesn’t hold that DCLAPS key!

Let’s add the same DCLAPS registry key inside the wow6432node as shown below.

This time, when running the same device query, we will get some results! As shown below, we now get the wow6432node DCLAP registry key results!

Let me briefly explain what is going on: when a 32-bit program runs on WOW64, it naturally looks at the 32-bit part of the registry. Similarly, a 64-bit program checks the 64-bit section of the registry. However, specific settings allow a 32-bit program to peek into the 64-bit part and vice versa for a 64-bit program. These settings don’t influence shared registry entries.

Registry Keys Affected by WOW64 – Win32 apps | Microsoft Learn

Of course, this is not new, as I have been discussing this issue in one of my older blogs. In that blog, I am using the sysnative path to make sure I am looking at the proper registry key

From there on, I started wondering if maybe adding the KEY_WOW64_64KEY to the access request could solve it… something like this.

#include <Windows.h>
int main() {
HKEY hKey;
LONG result = RegOpenKeyEx(HKEY_LOCAL_MACHINE, "SOFTWARE\\Microsoft\\DCLAPS", 0, KEY_READ | KEY_WOW64_64KEY, &hKey);
if (result == ERROR_SUCCESS) {
// Successfully opened the key in the 64-bit registry view
// Do your operations here
RegCloseKey(hKey);
} else {
// Handle error
}
return 0;
}

However, Microsoft needs to examine how to fix the fact that Device Query looks for 32-bit registry keys.

If you want to know how Microsoft fixed it, keep reading!

3. The Flow

As shown below, here is the corresponding WindowsRegistry Flow.

Please Note: I manually added that warning in the known limitations device query faq

4. 64 vs 32 bits is now Fixed

Somehow, Microsoft seems to have fixed the issue without me spotting any change in the Intune Management Extension Code. On 21-03-2024, the IME was updated. With this update, the IntunePivotPlugin.dll was also updated

When I noticed the update, I immediately opened the IntunePivotPlugin.dll and started searching for wow6432node. Well, it seems that Microsoft is working on the “Programs” entity to ensure that it lists all the installed programs on the device and does not only focus on 32-bit programs.

But I can tell from the code that they are not there yet. I am explaining this in the blog below.

I was hoping that the registry 64-bit issue I discussed in this blog would also be fixed. However, it seems that some things have changed in the meantime. So, thanks, Jose, for pinging me.

This is how it looks when executing a device query and targeting the regular “Software” registry key on a 64-bit device

As shown above, it will query the key we want!!!!

If we do the same but enter the wow6432node as a registry entity location in the device query this time, we will get some different results!

As shown above, entering the wow6432node registry path in the device query path will show us the 32-bit path!

After noticing that this issue was fixed, I decided to switch to dotpeek… and that tool showed me a lot more than IDA… I opened the intunepivot.dll and started looking into the WindowsRegistry entity.

When looking at the WindowsRegistry entity, this is the fix Microsoft implemented..

The Evaluate method in the WindowsRegistry class now checks if the operating system is 64-bit or 32-bit and opens the specified registry key accordingly using the RegistryView enum (RegistryView.Registry64 for 64-bit or RegistryView.Registry32 for 32-bit). This ensures that the correct registry view is accessed based on the system architecture, allowing for accurate retrieval of registry information.

Conclusion

I love Device Query and the power it could give us to retrieve some actual information from the device. It’s good that Microsoft fixed the issue, and we can finally query the 64-bit registry keys on our 64-bit device!

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  84  =  89