# PINCE: a GDB front end that borrows Cheat Engine's vocabulary

> A Python and Qt front end for the GNU Project Debugger aimed at game processes, with memory scanning, a speedhack, Mono and IL2CPP dissection, and .pct session files. The repository is candid about its limits and unusually specific about how it is installed.

**korcankaraokcu/PINCE** — Reverse engineering tool for Linux

- Repository: https://github.com/korcankaraokcu/PINCE
- Website: https://korcankaraokcu.github.io/PINCE/
- Stars: 3,118 · Forks: 193
- Language: Python
- License: NOASSERTION
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/korcankaraokcu-pince

## The name is a negation and the disclaimers come first

The expansion is in the first paragraph: PINCE is not Cheat Engine. Two disclaimers follow it before any feature is mentioned, and both are the sort usually left to a wiki. The first says not to trust any source other than this GitHub repository that claims to have the source code or package for PINCE, and to report such sources immediately, which tells you impersonation is a known problem rather than a hypothetical. The second says you are responsible for your actions and that PINCE takes no responsibility for damage caused by users. The project then points at three places to read: the features section for what is done, the roadmap inside CONTRIBUTING.md for what is planned, and the wiki for how it works. That division is the honest shape of the project, a shipped feature set next to a separate plan.

## isort is configured to skip every file

The project file contains formatting settings and nothing else.

```toml
[tool.black]
line-length = 150
[tool.isort]
skip_glob = ["*"]
```

Two things follow. There is no project table, so this is not a packaged distribution: installation goes through the root install.sh script and the pinned requirements file, not through a package index. And the isort configuration skips everything, which is the way to leave an import sorter configured but inactive. The black line length of 150 is unusually wide, which matches a codebase where long GUI-related lines are left alone. A comment in the README completes the picture, stating a TODO to include build status once test coverage improves and a GitHub Actions test workflow is added, next to a badge reference to an AppImage release workflow. So releases are automated and tests are not.

## Nine exact pins, including both directions of assembly

The requirements file pins every dependency to an exact version, which is unusual for a desktop application and tells you the supported surface.

```
PyQt6==6.11.0
PyQt6-Qt6==6.11.1
pexpect==4.9.0
capstone==5.0.9
keystone-engine==0.9.2
pygdbmi==0.11.0.0
keyboard==0.13.5
msgpack==1.2.1
```

The pairs explain the feature list. capstone is the disassembler behind the disassembly views, and keystone-engine is the assembler behind the on-the-fly assembler and the restore-instructions command, so both directions of code generation ship together. pygdbmi is the machine interface used to talk to GDB, with pexpect handling the process itself. PyQt6 and its Qt runtime are pinned as two separate entries, keyboard covers the hotkeys the memory view relies on, and msgpack carries structured data. Nothing here is a web framework: this is a local desktop tool.

## Speedhack without LD_PRELOAD, native and Proton alike

The speedhack is the feature with the clearest engineering claim: it is built in for both Linux native and WINE or Proton targets, and it needs no LD_PRELOAD and no other libraries. That matters because the usual approach on Linux is to preload a library into the target process, which changes how the process starts and interacts badly with how Wine and Proton launch games. Memory scanning is handled by libmemscan, which the repository consumes as a git submodule rather than a wheel, so the scanner is patched alongside the tool. Underneath is a scripting engine called Libpince for advanced work such as code injection, and the whole session runs commands in the background by default, so you can issue GDB commands while the target process keeps running instead of stopping at every step.

## Chained breakpoints and address tracking, ported from CE

The variable and debugging features are described by comparison to Cheat Engine more often than by explanation, which is efficient if you know that tool. Value types follow it, including extended strings in utf-8, utf-16, and utf-32 encodings, and bit fields can be read and edited as 1 to 64 bit values at any bit offset, as signed, unsigned, or hexadecimal, without disturbing the surrounding bits. Variables can be frozen, which constantly rewrites a memory cell, and smart casting lets you modify several differently typed values in one input as long as the text parses, with parse and memory errors sent to the terminal instead of a dialog. On the debugging side, chained breakpoints set several connected breakpoints at once so an event on one affects the others, watchpoint tracking answers what accesses or writes to an address, and breakpoint tracking resolves addresses from register expressions at a given instruction, with several expressions allowed at once.

## A dissected class can be exported into a structure

Managed runtimes get their own section, and it is the part that reaches beyond raw memory. Mono and IL2CPP targets can be dissected to browse classes with their fields and methods, read static and instance values, and drill into nested types, from Tools, Dissect Mono/IL2CPP in the memory view, and it works for Linux native as well as WINE and Proton processes. Once a class is open, live instances can be located, methods can be invoked on a chosen instance with the return value inspected, and the whole class can be exported into a PINCE structure. Structures are the connective tissue: named typed members that you can build by hand or generate from a dissected class, then overlay on any address to read memory through them. The memory view also carries a call-function command that invokes a function inside the target by GDB expression and shows what it returned.

## Sessions are .pct files, and the archive is a separate organisation

Work is saved as a session file with the extension .pct, and one file holds the address table, bookmarks, free-form session notes, and structures. Those tables can be browsed and shared through the community archive, which lives at a site under the PINCE-org organisation rather than in this repository. The repository layout explains the rest of the build. libmemscan is the submodule, libpince/ and GUI/ hold the engine and the interface, PINCE.py and PINCE.sh are the entry points, mono_collector/ is a component of its own, and i18n/ with tr/, compile_ts.sh, and fix_ts.py is a Qt translation pipeline rather than an afterthought. ci/ and install.sh cover automation and installation, AUTHORS and THANKS credit contributors, and the root carries both a COPYING file and a COPYING.CC-BY file, which is why the licence metadata records no single identifier. Release tags came at v0.10 on 2026-07-27, v0.10.1 on 2026-08-08, and v0.10.2 on 2026-09-18, the same day as the most recent push to master.

## Conclusion

PINCE suits someone who already knows GDB but wants a Cheat Engine style workflow against a running Linux game, including Wine and Proton targets. Before you rely on it, read the two disclaimers at the top of the README rather than the feature list, since the project explicitly disclaims responsibility and warns about fake distribution sources. If you plan to package or extend it, note that the project file configures isort to skip every file and declares no distribution metadata, so the install path is the root script plus the pinned requirements.

## FAQ

### How do I use PINCE on Linux?

PINCE is a front end for the GNU Project Debugger, focused on games. It scans memory through libmemscan, ships a built-in speedhack for Linux native and WINE or Proton targets with no LD_PRELOAD needed, and dissects Mono and IL2CPP managed runtimes for both kinds of process.

### How do I install PINCE on Linux?

The repository ships an install.sh script at its root, and the Python dependencies are pinned exactly in requirements.txt: PyQt6 6.11.0, capstone 5.0.9 for disassembly, keystone-engine 0.9.2 for the assembler, and pygdbmi 0.11.0.0 for communicating with GDB.

### Is PINCE related to Cheat Engine?

The name expands to PINCE is not Cheat Engine. The feature set deliberately mirrors that tool in places, including value types, bit fields, freezing variables, chained breakpoints, and what-accesses tracking, and community cheat tables are shared as .pct session files through the PCT-archive.

### What licence covers PINCE?

The repository root carries both a COPYING file and a COPYING.CC-BY file, and the licence metadata records no single identifier for the project. Contributors and acknowledgements are listed separately in the AUTHORS and THANKS files.

## Sources

- [Issues](https://github.com/korcankaraokcu/PINCE/issues)
- [korcankaraokcu/PINCE on GitHub](https://github.com/korcankaraokcu/PINCE)
- [Project website](https://korcankaraokcu.github.io/PINCE/)
- [README](https://github.com/korcankaraokcu/PINCE/blob/master/README.md)
- [Releases](https://github.com/korcankaraokcu/PINCE/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/korcankaraokcu-pince