OpenKP is the official package-opening utility created and maintained by Knexyce, the author of both OpenKP and KDPH.
OpenKP provides a controlled workflow for decrypting and extracting .kp packages.
It is designed to open packages while deliberately avoiding execution of package build logic.
OpenKP:
- Uses KDPH, also authored and maintained by Knexyce.
- Verifies the KDPH implementation using SHA-256.
- Supports local
.kppackages. - Supports packages hosted through GitHub.
- Reconstructs clustered GitHub packages.
- Decodes Base64-encoded packages.
- Decrypts packages through KDPH.
- Extracts the resulting archive.
- Verifies the extracted
kpcore/kdph.py. - Does not resolve and build package dependencies.
- Does not execute
kpcore/build.py. - Does not execute the
--injectargument.
Knexyce is the original author of:
- OpenKP
- KDPH
OpenKP is an officially endorsed tool from Knexyce for opening compatible KP packages.
The KDPH implementation used by OpenKP is retrieved from the author's canonical repository shown below.
https://raw.githubusercontent.com/Knexyce/kdph/main/kdph.py
OpenKP verifies the downloaded KDPH implementation and uses its SHA-256 digest as the canonical integrity reference for package verification.
- Python 3.9 or newer.
- Internet access when retrieving the canonical KDPH implementation or using the GitHub package workflow.
- A compatible
.kppackage. - The package decryption key/passphrase when required.
OpenKP uses Python's standard library.
python3 openkp.py -p /path/to/package.kpIf --key is not supplied, OpenKP prompts for the decryption passphrase:
Enter the passphrase to decrypt 'package'.
A key can also be supplied directly:
python3 openkp.py -p /path/to/package.kp -k "your-key"python3 openkp.py \
-p /path/to/package.kp \
-l /path/to/outputThe extracted package will be placed under:
/path/to/output/<package-name>/
OpenKP refuses to overwrite an existing extraction directory.
python3 openkp.py \
-a Knexyce \
-p package-nameThe GitHub repository is expected to contain a package directory with the required package metadata and cluster files.
| Option | Description |
|---|---|
-a, --author |
GitHub repository owner. Omit for a local .kp file. |
-p, --package |
GitHub package/repository name or local .kp path. |
-l, --location |
Parent directory for extraction. |
-i, --inject |
Accepted for CLI compatibility. It is ignored and never executed. |
-k, --key |
Package decryption key. |
OpenKP is specifically designed not to execute the package's build system.
In particular, OpenKP does not execute the following. Dependencies are also not resolved.
kpcore/build.py
The --inject/-i argument is retained solely for CLI compatibility. If provided, OpenKP prints a warning and ignores it.
The intended workflow is:
KP package
│
▼
Verify KDPH digest
│
▼
Decrypt with KDPH
│
▼
Extract archive
│
▼
Verify extracted KDPH
│
▼
Return extraction path
No package build process or recursive dependency resolution is invoked as part of this workflow.
OpenKP retrieves the canonical KDPH implementation from the Knexyce repository and calculates its SHA-256 digest.
For local packages, OpenKP expects the final 32 bytes of the package to contain the KDPH SHA-256 digest.
For GitHub packages, OpenKP verifies that the repository's kdph.py matches the canonical KDPH before continuing.
After extraction, OpenKP also verifies the following against the canonical KDPH SHA-256 digest.
kpcore/kdph.py
If verification fails, OpenKP terminates rather than continuing with an unverified package.
A GitHub package can be structured as:
package-repository/
├── kdph.py
└── package/
├── metadata.txt
├── 1.kpc
├── 2.kpc
└── ...
metadata.txt contains:
<package-name>
<number-of-clusters>
For example:
example.kp
3
OpenKP reconstructs the package by combining the numbered cluster files in order.
GitHub packages reconstructed by OpenKP are expected to contain valid Base64-encoded package data before decryption.
OpenKP creates the extraction directory only when it does not already exist.
Existing extraction directories are not overwritten.
Temporary processing files are stored inside Python temporary directories and are automatically removed after processing.
OpenKP does not:
- Execute
kpcore/build.py. - Resolve and build package dependencies.
- Execute the
--injectargument. - Automatically overwrite an existing extraction directory.
- Continue when KDPH integrity verification fails.
- Treat an unverified non-canonical KDPH implementation as trusted.
OpenKP and KDPH are authored by the same developer and therefore OpenKP internally uses KDPH's Library API.
Knexyce
KDPH provides the package decryption and archive functionality used by OpenKP.
OpenKP provides a controlled package-opening workflow around KDPH, including package retrieval, integrity verification, decryption, extraction, and post-extraction verification.
OpenKP should only be used with packages that you are authorized to access and inspect.
Although OpenKP is designed to avoid executing kpcore/build.py, extracted files should still be treated appropriately for your environment and use case.
Apache 2.0
OpenKP Author: Ayan Alam (Knexyce). KDPH Author: (Also Ayan Alam.) (Still Knexyce.)