For the last 4 years, on and off, I have been trying to build a tool to do just that. And for just as long I have been really close to having such a tool, but not close enough to release one. I could list files and folders and expand the virtual registry, but I always either missed some things from the file or picked up extraneous garbage. Why? Because it is hands-down the worst file format ever devised. By comparison, the Sft format is a piece of cake. And it's not just me, Kalle Saunamäki (the creator of Application Virtualization Explorer ) worked on this long and hard without success for a long time too. This month Kalle released an update to the paid-for version of his tool with capabilities to read the pkg.
Meanwhile I had been working, with some encouragement from Microsoft, to complete a workable release. Once I finished it last winter, I had to wait Microsoft gave me permission to release (a bureaucratic thing that took way too long). Well, today I finally have that permission!
This tool is free. Consider it more of a debugging tool and Kalle's a professional tool. With this tool you can view modified files and registry settings, and dump out files from the pkg in either text or hex format.
Why?
Why do we need such a tool? Because things don't always work perfectly.
Sometimes files get marked as "application" when what we really need is for it to be marked "user", so the changes made don't roam with the user. Sure, if we know what file it is we can check the sft, but when the app just breaks, we don't always know which file it is to modify the settings to.
And then there is all of the .net stuff. Side by side components sometimes cause issues in packages. Before having such a tool, we were forced to just reset the entire user pkg because we couldn't tell what has changed. While you can't edit the pkg with this tool, you can find what changed and use the "/EXE %COMSPEC%" trick to get a cmd prompt inside the user pkg to fix the issue.
And we need such a tool to figure out DSC issues, such as which package is getting the changes.
How does it work?
Install the software and run PkgView.
You select the Pkg file you are interested in and click on the Analyze button. The display on the left shows an information tab with GUIDs and versions and dates and sizes of things. To this we add the counts of the number of file/folder and registry changes contained in the pkg file.
The preference is to supply both the Sft and Pkg file for viewing. When you provide both, the files and registry tabs provide an overlay view of the pkg contents on top of the sft. If you don't also reference the Sft file, you will need to use the "PkgFiles", "PkgFolders", and "PkgDeletes" tabs to view the lists of files and folders that have changed. You will need to view the "Pkg Settings.cp" tab to view the registry changes. Without the Sft, the Pkg tends to have stub folder references that cannot be placed on any kind of tree structure, as the folder references a parent folder that is not in the Pkg.
So I recommend that you also identify the Sft file associated with it. By identifying the sft, the tool can display an overlay of the Pkg on-top of the Sft.
This display shows how the changes are overlaid and integrated onto the sft. With both the Sft and Pkg provided, you can click on the Files tab to see what files have changed, been added, or been deleted in a full tree view. This is much easier to understand.
The folders and files are color coded to indicate which have modifications in the Pkg. For example, modified folders are colored blue. Modified files are also bard blue. New files have an "asterisk" on them.
There is a "Find Next Changed File" button to skip from one to the next.
For files that are new or modified in the Pkg, you can obtain a dump-view of the file using the "Dump Changed File" button. Select the new or modified file on this screen and click on the button. After clicking on that button a new tab will appear with the dump. If it is a text file, it will be displayed as text, otherwise it is shown using a hex-dump.
You can also view an overlay of the Pkg Registry changes.
Clicking on the Registry tab (when both sft and pkg are provided), we see a tree like layout of the virtual registry. Again here, the items are coded with colored icons to aid in identification of changed items. Values of virtual registry items are shown both as they are in the sft and in the pkg.
Version 1.6 Enhancements
- Replaced compression library. Now works on compressed SFTs on x64 systems!
- Added ability to auto-locate the SFT file from it's original source, if available. This feature requires that the sft was loaded using a FILE: override, such as with the stand-alone client or SCCM. Otherwise you should manually specify the sft filename.
- Various small glitches are fixed, especially related to packages with ACLs stored (enforce security descriptors).
- A New Installer is used.
Version 1.5 Enhancements
- Ability to dump pkg files to screen in text/Hexdump format.
- Several fixes where original version might crash
Things not in the tool
The tool covers the basics of what you need, but not everything that could be done.
- While it handles uncompressed sfts and sfts compressed with the standard zlib format, it does not handle sfts that used the old bzip compression algorithm.
- The tool silently ignores "links" in both Sft and Pkg.
- It does not display fonts captured in the Sft or Pkg.
- It does not display additional file/folder mappings recorded in the Sft or Pkg.
- You also cannot "export" file contents, only view.
- The tool might or might not work on a "corrupted" file.
- It ignores any security descriptors.
- As it doesn't work with OSDs, it knows nothing about DSC.
- And finally, it displays contents of files only up to 4MB in size.