Kimiko is an offensive security configuration framework. By its very nature, it generates and processes highly sensitive, adversarial data. Securing your local Kimiko installation is paramount to preventing accidental leaks of exploits, payloads, or reconnaissance data.
This is a configuration repository, not a traditional software package. We support the latest commit on the main branch.
| Version | Supported |
|---|---|
Latest main |
✅ |
| Older commits | ❌ (please update) |
If you discover a security vulnerability in the Kimiko repository — including accidental credential leaks, insecure defaults, or validation bypasses — please report it responsibly.
Do NOT open a public issue for security-sensitive bugs.
Instead, contact the maintainer directly:
- GitHub: @spearchucker667
Please include:
- A clear description of the vulnerability
- Steps to reproduce (if applicable)
- The file(s) and line numbers involved
- Suggested mitigation or patch (if you have one)
We aim to acknowledge reports within 72 hours and provide a fix or assessment within 7 days.
- Never commit credentials. The
.gitignoreexplicitly excludescredentials/,device_id, andkimi.json. - Encrypt your workspace. Since Kimiko is used for pentesting, ensure your
~/.kimi-codeand associated work directories are on an encrypted partition (e.g., FileVault on macOS, LUKS on Linux, BitLocker on Windows). - Run
make verifyafter installation to confirm files landed with correct permissions. - Review scripts before sourcing them into your shell environment.
- Use
chmod 600onconfig.toml,kimi.toml, and mandate YAML files after any manual edits. - Verify with
ls -la ~/.kimi-code. - WSL note: WSL uses the native Linux filesystem, so Unix permissions are fully enforced.
- NTFS uses ACLs instead of Unix permission bits.
- To restrict access to
%USERPROFILE%\.kimi-code:icacls $env:USERPROFILE\.kimi-code /inheritance:r icacls $env:USERPROFILE\.kimi-code /grant:r $env:USERNAME:(OI)(CI)F
- Ensure PowerShell execution policy is set appropriately:
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser.
- Isolate device-under-test. Mobile bypassing, flashing, jailbreaking, and rooting should be performed only on devices you own or are explicitly authorized to test, preferably on a dedicated research device.
- Protect firmware and binary artifacts. Extracted firmware, decrypted binaries, and debug symbols may contain proprietary or sensitive data; store them encrypted and limit access to authorized researchers.
- Secure serial/debug interfaces. UART, JTAG, and SWD probes can leave devices in an unlocked or debug-enabled state; restore default lock states after research.
- Sanitize outputs. Before sharing any Kimi Pentest output, verify it doesn't contain local paths, usernames, device identifiers (IMEI, serial numbers, MAC addresses), or sensitive network identifiers.
- Isolate your pentesting environment. If possible, run Kimiko within a dedicated VM or container to prevent side-channel leaks to your host system.