The WinX Menu and its hashing algorithm revisited

This post first appeared on Within Windows on June 1, 2012.

In an April post, I covered the new "Win-X" menu, named after the keyboard shortcut used to access it, and how it features a hashing algorithm to determine if a shortcut was approved for display. I also offered a tool that would sign shortcuts, upgrading them the to coveted approved status.

This won't be a regurgitation of all that again. Instead, I will simply cover some changes made to the menu in Windows 8 Release Preview. (And more importantly, offer an updated version of hashlnk!)

First of the notable changes to the WinX menu in Windows 8 Release Preview is the unfortunate removal of the Network Connections shortcut. This shortcut provided a sneaky backdoor to the legacy Network Connections area, offering immediate access to network interfaces -- you know, the very items we stumble around looking for in that abhorrent Network and Sharing Center. But on the flip side, Network Connections is becoming less and less useful, thanks to better software (e.g. Windows, network drivers/stack) and the cluttering up of pseudo-interfaces like Virtual Wifi NICs, VMware and Hyper-V virtual switches and complex VPN thingamajigs. No worries.

The more important change, however, was to its hashing algorithm that sussed out whether a shortcut was approved for display in the menu. I created a tool for folks to upgrade their own shortcut files (.lnk) however it broke with the new Windows release. Let's dig a little deeper into why.

In previous versions of Windows 8, WinX would grab a shortcut, pull out the target path and arguments, hash it, and compare with an embedded value in the shortcut. This worked great, until shortcuts with environment variables were used. (I noted this as a bug in my previous post.)

For example, let's consider a shortcut pointing to %SystemRoot%\Explorer.exe. In the process of examining the shortcut, the WinX menu would expand this path -- that is replace any variables present with values fed from the OS. On a 64-bit system, the path would likely expand to C:\Windows. In some rare cases, however, this could expand to possibly C:\Winnt or even C:\Winderz for the haters out there. (The drive letter in previous versions of the algorithm was ignored.) This means the hash could be viewed as invalid and not render in the WinX menu; that kind of runtime inconsistency just won't fly in Windows.

So it was fixed.

But how?

Nothing magic really. WinX now takes the path and runs it through a quick search and replace function. It looks for matches using OS backed "folder IDs", specifically FOLDERID_ProgramFiles, FOLDERID_System, and FOLDERID_Windows. On a typical 64-bit system, these IDs would point to the values "C:\Program Files", "C:\Windows\System32", and "C:\Windows". If a match is found, WinX strips this part of the path out and replaces it with the folder ID's GUID.

To continue our example above, %SystemRoot%\Explorer.exe would expand to C:\Windows\Explorer. Having FOLDERID_System in the path, it would then ultimately transmogrify to {F38BF404-1D43-42F2-9305-67DE0B28FC23}\Explorer.exe.

That's it.

If you want to re-sign your shortcuts to now work on Windows 8 Release Preview, I updated the hashlnk tool bringing it to 0.2.0.0. Both the binaries and code at on GitHub.

Feedback is very welcome.