The Package Support Framework (PSF) was originally a Microsoft open-source project to help Win32/DotNet applications run when inside an MSIX Container. TMurgent has taken up the support for the PSF in our own fork here on GitHub.
A new update to the PSF has been released. From the release notes:
-
Updated RegLegacyFixup to more certain intercepts from Kernel32.dll to the lower layer KernelBase.dll, and added a new intercept in KernelBase.dll.
The PSF was built with the understanding that application code would call Microsoft APIs that are generally in the kernel32.dll library, and intercepts are traditionally placed there.
There are some other Microsoft libraries called directly by application code which sometimes bypass these Kernel32.dll functions and instead directly call functions in lower level dlls, such as KernelBase or even NtDll. When this happens, the PSF does not get a chance to intercept those calls.
One such Microsoft library is the Winsock2 library, used when a traditional application wants to open a socket. Inside of ws2.dll is a registry call that tries to open a registry key by directly calling a function in KernelBase, and is requesting “Full Access” permissions when opening the key. While permitted in apps outside the container this is not allowed inside the container. The RegLegacyFixup is generally used to transform the requested permissions on the call to those that will succeed in the container. But as those intercepts are bypassed, the apps may fail.
This change moves the intercept of all functions that exist at both levels to now intercept at the lower level of Kernelbase, and adds one new intercept that only exists in KernelBase.
-
Altered MfrFixup by adding a number of new intercepts in Ntdll.dll and Windows.Storage.dll.
A number of Microsoft libraries bypass the Kernel32.dll and go directly to Ntdll.dll for file-based access.
Examples of this include any application that is WinForms or .Net Framework based and has a “file picker” dialog based out of the Microsoft User32 library. The result is that MfrFixup/FileRedirectionFixup intercepts are bypassed, which may be needed when file paths are native paths other than those layered by the underlying system (i.e., those other than windows and the program files folders). So while the application may have visibility for files in the package generally due to the fixup, the File Picker dialog does not.
These new intercepts are not yet functional but will produce logging (even in release builds) to the console port (DebugView) if triggered by a call that was not handled at a higher-level API. This will help us to identify which calls are being made and which ones we need to handle in the future.
-
In both MfrFixup and FileRedirectionFixup, changes were made to recognize a new category of file paths and to not affect this new category.
In file-based intercepts, incoming file paths are first categorized to determine whether changes may be required, eliminating those that are, for example, device references for which PSF changes would not apply.
We discovered a new category of file paths that should not be affected but were not being recognized, causing an issue.
These filepaths use the “Windows Storage Namespace”, and may be detected as a path starting with “\\?\STORAGE#Volume”.
Both of these fixups now recognize this new category as pass through the calls without impact to the caller.
This version of the PSF would be included in future releases of TMurgent Tools:
- PsfTooling: Version 6.6.0.0 or later
- TMEditX: Version 4.1.0.0 or later
