Copying "unknown" reparse points

[PlasmaHH]

Hi, this might be an odd request, but it seems that a lot of windows internal knowledge is in these libraries. Since at least 2018 windows has a special kind of reparse point ( 0x8000001b ) that acts similar to a symlink but contains some extra data ( that seemingly gets passed on to checking for executable permissions etc. when executing files through it... things are rather bad documented here.. )

Would it be possible that the junction tool ( or maybe it fits better into any other?? ) can copy reparse points verbatim? Or even create the attached data from a file or similar?

It happens sometimes that one of these special reparse points gets deleted, and sometimes the only solution is to reinstall windows, but all that was really needed is to (re)create that reparse point...

[JFLarvoire]

Hi Jeffrey, This is absolutely not an odd request, but this is definitely a more difficult one than it looks. The reparse point type 0x8000001B is for UWP "App Exec Links". All I know about them comes from this blog post, and from my own experiments thereafter. For that I created a dedicated script called AppExecLink.bat (not (yet?) published in SysToolsLib), dumping their contents. I published a summary of what I found in this message. But I still don't understand enough about UWP applications startup to generate modified App Exec Links for use in a copy.

Actually what's your use case for doing such a copy? As far as I can tell, these links are only used in the "C:\Program Files\WindowsApps\" directory for pointing at installed UWP applications. Copying them to another place, or worse still to another PC, does not seem very useful. Do you know of other cases where they're used?

[PlasmaHH]

Does it contain more than the data fsutil dumps?

From what I understand the actual .exe being started in the WindowsApps Folder contains a special condition for being executed (look in the explorer right click properties dialogue, there will be a new column checking for some string, which matches the first string contained in the data of that reparse point ).

I think the case of wsl this is kinda being used as setuid mechanism, where it is checked that was run through the "symlink" contained in the users appdata folder, and then the wsl can with elevated credentials startup its vm...

Anyways, my usecase might be a bit special, but the whole ordeal is. Due to some misunderstandings, the local users AppData folder was being deleted, along with all the necessary app exec links for wsl. Now all uninstalling and reinstalling of wsl did not work, and as such starting it as a user won't work ( as the .exe files in the WindowsApps folder cannot be started as a normal user, unless started through that special link).

All attempts to re-create them from scratch for me failed so far, so I was thinking about, that if they do only consist of all the information that fsutil can also display, that feeding that data block to some tool and then re-creating the link might do the deal.

M$ support answer is simple as always: just reinstall windoze.

Another usecase to be able to create them with arbitrary data might be to play around and see how they work. Decompiling windows code to figure out whats going on is really tedious and leads to too much dead ends ;)

[JFLarvoire]

Does it contain more than the data fsutil dumps?

No, as far as I can tell, everything is in fsutil output.

I could easily create a new dedicated tool for managing AppExecLinks. (Displaying the content of existing ones, or creating new ones.) The problem with recreating new AppExecLinks from scratch is that it'd be difficult for the user of that tool to figure-out what strings to put in these new links. For example for Microsoft Edge, the strings are:

C:\JFL\Temp>AppExecLink.bat "C:\Users\Larvoire\AppData\Local\Microsoft\WindowsApps\MicrosoftEdge.exe"
Microsoft.MicrosoftEdge_8wekyb3d8bbwe
Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge
C:\WINDOWS\system32\SystemUWPLauncher.exe
1
C:\JFL\Temp>

The third string is the target executable. But as shown above, it's not always directly related to the target application. The fourth string seems to be a number encoded as a string. I've seen cases where it's "0"; Others where it's "1". No idea what it means, nor how it's used.

Note that the AppExecLink.bat script I used above is just a simple wrapper around fsutil.exe. It only converts the hexadecimal dump to readable strings. And it only works with ASCII strings. The final tool should support any Unicode character.

[PlasmaHH]

My hope here would be that while it would initially be difficult, having a tool to play with will one day lead to more knowledge about what works and what doesn't....