Refactor WinDbg install

[naacbin]

I rework WinDbg install to improve it (versioned + icon support #997)

Closes https://github.com/mandiant/VM-Packages/issues/997

[emtuls]

So I'm looking into this and it looks like the same issue I ran into when I was trying to do the windows-terminal package for wt.exe (https://github.com/mandiant/VM-Packages/issues/934#issuecomment-1977815578) where it installed to the correct location for Windows Server 2022, but not for Windows Server 2019. Unfortunately, I never found a solution to do it properly for Windows Apps, and instead I went the route of using a Github package which doesn't seem to exist for WindbgX.

It seems that the Windows Server 2019 either installs the Windows Apps to a different location than the standard one (or installs it differently in general), or it's failing to install for some reason. But the fact that $iconLocation = Join-Path $installDir "DbgX.Shell.exe" -Resolve actually resolves leads me to believe that it is installing, just not how we expect.

Now the issue with not being able use DbgX.Shell.exe as the executable location is because it's in a highly protected folder, so @Ana06 is likely correct in that the shortcut to that as the executablePath in the catch statement is very unlikely to actually be working and I'm not sure if that's the route we want to take. There seems to be ways that we can possibly change the ownership of the directory and be able to potentially make it run, as noted here, but I don't think that's the best route.

I'm thinking that the better route might be what @Ana06 suggested with https://github.com/mandiant/VM-Packages/pull/1058#discussion_r1644253183 where we use a Console App, or an alternative that I think may be more suitable would be to just remove the Console App part:

VM-Install-Shortcut -toolName $toolName -category $category -executablePath "$toolName.exe" -iconLocation $iconLocation -RunAsAdmin

In either case, the issue still remains that WinDbgX.exe may not actually be resolving, so it's possible that it does not -actually- work, but this is no different than what we currently have, just maybe slightly better to not run it as a console app, imo.

I will try to do a little more testing to see if I can find an alternative, but that's my current take at the moment. :)

[emtuls]

Judging from these posts, it sounds like the WinDbgX.exe and similar executables in Microsoft\WindowsApps are considered an "Execution Alias", which is not supported in Windows Server 2019 as noted here: https://stackoverflow.com/questions/67495731/how-do-i-make-an-execution-alias-work-on-windows-server-2019 https://github.com/microsoftfeedback/WinDbg-Feedback/issues/19#issuecomment-1537741148 This is why it's not created when we do Add-AppxPackage for the windows-2019 github runner.

A suggested alternative that may work for us would be to create a command similar to Explorer.Exe Shell:AppsFolder:<ApplicationID>!<AppID> which looks like it can potentially be done programmatically: https://www.andreasnick.com/106-starting-msix-and-appx-packages-with-powershell-from-the-command-line.html

Or a powershell command Invoke-CommandInDesktopPackage: https://learn.microsoft.com/en-us/powershell/module/appx/invoke-commandindesktoppackage?view=windowsserver2019-ps

I'm not sure what the best solution really is, but for it to truly work on Windows Server 2019 we'd likely need one of these options, as VM-Install-Shortcut -toolName $toolName -category $category -executablePath "$toolName.exe" -iconLocation $iconLocation -RunAsAdmin is merely making a shortcut to something that may not actually be working. Unfortunately I do not have this sort of setup at the moment to test this.

I'd be willing to accept VM-Install-Shortcut -toolName $toolName -category $category -executablePath "$toolName.exe" -iconLocation $iconLocation -RunAsAdmin, as it seems that there have not been any complaints as of yet for it.

@Ana06 thoughts?

[naacbin]

Now the issue with not being able use DbgX.Shell.exe as the executable location is because it's in a highly protected folder, so @Ana06 is likely correct in that the shortcut to that as the executablePath in the catch statement is very unlikely to actually be working and I'm not sure if that's the route we want to take. There seems to be ways that we can possibly change the ownership of the directory and be able to potentially make it run, as noted here, but I don't think that's the best route.

I don't think changing permission of the directory will solve anything, because on my side it's working with DbgX.Shell.exe without modifying the permission of the protected folder. However, I agree that it's unlikely to work on Windows Server 2019.

[naacbin]

I'd be willing to accept VM-Install-Shortcut -toolName $toolName -category $category -executablePath "$toolName.exe" -iconLocation $iconLocation -RunAsAdmin, as it seems that there have not been any complaints as of yet for it.

So we merge this PR with the line provided and create an issue to find a better way with Explorer.Exe Shell:AppsFolder:<ApplicationID>!<AppID> or Invoke-CommandInDesktopPackage ?

[Ana06]

@naacbin sorry that it took that long to review the PR, I am not sure which the best solution is. @d35ha thanks for sharing your feedback, hopefully we can soon find a good solution. :wink:

[d35ha]

@naacbin sorry that it took that long to review the PR, I am not sure which the best solution is. @d35ha thanks for sharing your feedback, hopefully we can soon find a good solution. 😉

@Ana06 A simple solution is to create a shortcut that points to the application directly under shell:AppsFolder, in that case the shortcut target type is set to PackageFamilyName!PackageName effectively running the windows application directly without any middlewares (ex. cmd.exe).

[naacbin]

Smart solution @d35ha! :bowtie: thanks for taking this over so that we can finally merge it.

@naacbin sorry, you put a lot of effort into implementing this enhancement and we were not very fast responding/reviewing your changes. I was busy working on other priority tasks and I didn't have the time to investigate an issue for which I didn't have a good solution. @naacbin can you please let us know if you are ok with @d35ha proposal? 🙏

I also wasn't available much over the past few months, but I'm glad to see that a solution has been found. I'm happy with the outcome of it. Thanks for your work @Ana06 @d35ha