PkgToolBox gives one GUI to PSP through PS5 package files

The scope is package inspection and editing, not decryption

PkgToolBox is a desktop application for working with PlayStation PKG files, providing a unified graphical interface for inspecting package metadata, browsing internal files, extracting and modifying content, working with trophies, analyzing package structures and performing other PKG-related operations. It supports the package formats used across PSP, PS3, PS4 and PS5, although some platform-specific features may still be experimental or under development. The requirements section is unusually specific about the limit: protected PS4 PFS payload decryption is reported as unsupported until the internal key pipeline is fully validated, and clear-text PKG metadata remains browsable and extractable. The application also does not require shadPKG, OpenOrbis command-line tools or bundled platform-specific executables. That is the honest scope. You can open, read, browse and edit what is not protected, and you can modify the metadata of protected packages without touching the encrypted payload.

Running it is a clone, a pip install and one command

The installation path is three steps, and the development requirements are Python 3.13 or newer, PySide6 and PyInstaller, with the dependencies listed in requirements.txt. The dependencies themselves are short, four lines covering the GUI toolkit, image handling, HTTP and the crypto primitives:

pip install -r requirements.txt

The clone and the run are equally short:

git clone https://github.com/seregonwar/PkgToolBox.git
cd PkgToolBox

python main.py

One instruction in the requirements section deserves attention if you intend to redistribute the tool: use PyInstaller when packaging the application, because alternative packaging tools such as cx_Freeze may not preserve all of the behavior required by PkgToolBox. That is a specific warning about a specific alternative, and it suggests the Qt bindings and the way the application loads its resources are sensitive to how the binary is assembled. The project can run on Windows, Linux and macOS.

The GP4 and GP5 workspace is the part built for publishing

One feature stands apart from the rest and is worth explaining on its own. The GP4 and GP5 Project Workspace opens PS4 .gp4 and PS5 .gp5 publishing projects, validates mapped paths, inspects param.sfo and param.json, previews source assets and exports the resolved project files, with GP5 supporting both flat and recursive layouts. This is the workflow where a developer assembles the content of a package before it is built, and the behaviour described in the usage notes is careful. PkgToolBox resolves mapped paths, shows missing files without hiding them, and keeps the project read-only while allowing available content to be browsed, previewed and exported. The fact that missing files are surfaced rather than silently skipped is the kind of detail that matters when a build fails three hours later, and the read-only stance means you cannot accidentally write back into a project definition that other tools share.

Everything is browsed in place, without unpacking the whole package

The file explorer navigates the internal structure of a PKG without extracting the entire package, and the standalone file inspection mode does the same for any local file, so you can drop or open a file to preview it and use the integrated text and hex inspection flow without first loading a package. A hex reader and editor inspects and modifies files directly in hexadecimal, and a text reader and editor views and edits supported text based files. There is also standalone file management, which means managing and deleting files contained inside supported packages, and a full package dump when you do want everything out. The package information view inspects package metadata and gives detailed information about the file. The efficiency here is the point: a multi-gigabyte package does not have to be extracted to answer a question about one file inside it.

Trophies, wallpapers and PFS analysis live in the same window

Beyond the package handling, there are three domain features that are more than utilities. Trophy management loads, unpacks, inspects and manages PlayStation trophy files, and the roadmap lists PS4 .trp support and PS5 .ucp support as completed. There is also a trophy creator that creates custom trophy sets with configurable icons, descriptions and achievements, which is the sort of thing a homebrew author needs. Wallpaper management inspects, extracts and modifies wallpapers and background assets included in packages. PFS analysis inspects PS4 PFS and PFSC container geometry with the built-in dependency-free engine, and the roadmap lists ShadPKG integration, PS4 PFS extraction and a PFS information viewer as completed. Separately, PARAM.SFO and image metadata are handled directly in the application, with all SFO keys parsed and PNG and DDS dimensions inspected.

The roadmap is the honest measure of what is not finished yet

The roadmap is split into completed and in progress or planned, and reading it is the fastest way to know where the tool stands. Completed: advanced internal PKG file explorer, detailed package information parsing, improved hexadecimal value analysis, PS3 retail and debug PKG support, PSP PKG support, initial PS5 PKG support, PS5 GP5 project loading in flat and rootdir layouts, PS4 GP4 project loading and standalone file workspaces, the two trophy formats, the three PFS items, Windows, Linux and macOS support, and a batch of stability work covering error handling, application stability and general bug fixes. Unchecked: extended PS5 PKG support, advanced PKG splitting, improved FPKG update handling, a native PkgToolBox implementation for PS4 and PS5, extract modify and rebuild of supported PKG files, recomputing required digests and package metadata, and .ESFM file decryption. The rebuild entry is the important boundary, since it means a package you modify in the tool may not be able to be written back out as a valid package from the tool alone.

The repository layout keeps the UI, the core and the tools apart

The top level tells you how the project is organised. There is a GUI/ directory for the interface, a pkgtoolbox/ directory for the application package code, Utilities/ for shared helpers, packages/ for the console format implementations, tools/ for command line utilities, scripts/ for automation, tests/ for the test suite, docs/ for documentation, and assets/, icons/, logos/ and installer_assets/ for the visual assets. main.py is the entry point you run, and settings.json holds the configuration, which is worth noting because it means the app has a persistent settings file rather than reading everything from flags. There is a CHANGELOG.md at the root, and the releases are tagged v1.5.0 on 2026-08-24, v1.4.0 on 2025-09-03 and v1.3.0 on 2024-10-30. The repository is not archived and the last push was on 2026-10-03, and the licence field in the repository metadata is recorded as unknown, so the terms are something to establish directly rather than assume.

Where PkgToolBox is the wrong choice

Three cases argue against it. The first is a scripted workflow. Everything here is a desktop application, and while the repository has a tools/ directory and a scripts/ directory, the documented entry point is a window you open and drop files onto. A pipeline that processes thousands of packages unattended wants a command line tool per platform with a defined output, and the README even notes that the application does not require the OpenOrbis command line tools, which cuts the other way. The second is a task that needs the protected payload. If your work requires reading encrypted PFS content or decrypting .ESFM files, the tool is not there yet, since payload decryption is reported as unsupported pending validation of the key pipeline and the decryption item is unchecked on the roadmap. The third is a platform whose package format is not covered. The support matrix is broad but it is not uniform, with PS5 PKG support described as initial rather than extended, and the roadmap still lists native PS4 and PS5 implementations as pending. The realistic alternative for scripted or bulk work is to use the per-platform command line tools directly, shadPKG and OpenOrbis among them, and to keep PkgToolBox for the interactive inspection, editing and project workspace tasks where a GUI is genuinely the faster path.

Editorial conclusion

Adopt PkgToolBox when you need a single cross-platform window for inspecting and editing PlayStation package content across PSP, PS3, PS4 and PS5, and pick a command line tool per platform if your work is scripted. Verify first that the platform and feature you need is in the completed list rather than the roadmap, because extended PS5 support, package rebuild, file decryption and the native PS4 and PS5 implementation are all still unchecked, and note that the repository records its licence as unknown.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. seregonwar/PkgToolBox on GitHub