Definitionen gängiger Begriffe bei Cheat Engine, im Forum und im Wiki.
Eine Stelle im virtuellen Speicher eines Prozesses, meist hexadezimal angezeigt (z. B. 0x00401234). Wenn Sie mit dem Scanner einen Wert finden, erhalten Sie eine oder mehrere Adressen. An dieser Adresse liegt der aktuelle Wert (z. B. Leben). Adressen können sich beim Neustart des Spiels ändern – deshalb werden Pointer-Scans für stabile Referenzen genutzt.
Ein im Speicher gespeicherter Wert, der selbst eine Adresse ist. Ein Pointer „zeigt auf“ eine andere Stelle. Spiele speichern oft die Adresse des Spieler-Objekts in einer globalen Variable oder in einer Pointer-Kette. Pointer-Scan findet diese Ketten, damit Ihr Cheat nach Neustart noch funktioniert.
Erster Scan: Speicher nach Werten durchsuchen, die zu Typ und Bedingung passen (exakter Wert, unbekannt, erhöht usw.). Nächster Scan: Von den vorherigen Ergebnissen nur die Adressen behalten, die jetzt der neuen Bedingung entsprechen. „Wert im Spiel ändern → Nächster Scan“ wiederholen, bis die richtige Adresse gefunden ist.
Eine Folge von Byte-Werten (oft in Hex, z. B. 8B 0D ?? ?? ?? ??), die eine Stelle im Spielcode eindeutig kennzeichnet. „??“ bedeutet „beliebiges Byte“. AOBs werden in Auto-Assembler-Skripten genutzt, damit das Skript die richtige Stelle auch nach einem Spiel-Update findet, solange das Code-Muster noch existiert.
Wenn Sie eine Adresse in der Adressliste „einfrieren“, schreibt Cheat Engine den aktuellen Wert fortlaufend zurück an diese Adresse. Wenn das Spiel versucht, Ihr Leben zu verringern, wird der Wert sofort wiederhergestellt. Wird für unendlich Leben, Munition usw. genutzt.
Eine Datei, die Adressen, Skripte und Optionen speichert. Cheat-Tabellen sind XML und können in einem Texteditor geöffnet werden. Sie werden im Forum geteilt. Nur Tabellen aus vertrauenswürdigen Quellen nutzen; sie können Lua oder Assembler ausführen.
Ein eigenständiges Programm (oft eine .exe), das aus einer Cheat-Tabelle erstellt wird. Nutzer können Cheats per Kontrollkästchen oder Tastenkürzel aktivieren, ohne Cheat Engine zu öffnen. Wird mit dem Trainer-Maker in CE erstellt.
Ein Skript-System in CE, in dem Sie x86/x64-Assembler plus Direktiven (alloc, aobscan, inject usw.) schreiben, um Spielcode zu patchen. Wird für Code-Injection, Ersetzen von Anweisungen und robuste Cheats genutzt, die mit AOBs auch Neustarts überstehen.
Eine CE-Funktion, die die Laufgeschwindigkeit des Spiels ändert (z. B. 0,5x für Zeitlupe, 2x für schneller). Sie hakt zeitbezogene APIs ein, sodass der Prozess „glaubt“, die Zeit vergehe langsamer oder schneller. Nur für Einzelspieler.
Debugger Virtual Machine. Ein Hypervisor unter dem Betriebssystem, der CE erweiterte Fähigkeiten gibt (z. B. Ultimap, erweiterte Breakpoints). Optional; benötigt kompatible Hardware und Laden per UEFI o. Ä.
Einen Prozess in Cheat Engine öffnen, um seinen Speicher zu scannen und zu ändern. Sie wählen den Prozess aus der Prozessliste (Datei → Prozess öffnen oder Computer-Symbol). Einige Prozesse erfordern, CE als Administrator auszuführen.
Die Art der gescannten Daten: 1/2/4/8-Byte-Ganzzahl, Float, Double, String usw. Der falsche Typ (z. B. 4 Bytes, wenn das Spiel 8 nutzt) liefert keine oder falsche Ergebnisse.
Ein Punkt, an dem der Debugger die Ausführung anhält. Sie können Breakpoints auf eine Anweisung setzen (Stopp, wenn die CPU sie ausführt) oder auf Speicher (Stopp, wenn etwas diese Adresse liest oder schreibt). Wird genutzt, um zu finden, welcher Code auf einen Wert zugreift.
Managed-Code-Laufzeiten. Viele Spiele (z. B. Unity) nutzen Mono oder .NET. CE kann Klassen und Felder in diesen Laufzeiten auflisten, sodass Sie z. B. „Player.Health“ nach Namen finden können statt über rohe Adressen.
In CE eingebettete Skriptsprache. Wird für Automatisierung, eigene Oberfläche und Erweiterungen genutzt. Lua-Skripte können über die im Wiki dokumentierte CE-Lua-API auf Speicher, Adressliste und Debugger zugreifen.
Eigenen Assembler-Code in den Zielprozess schreiben (oft in reservierten Speicher) und die Spielausführung umleiten, damit Ihr Code läuft. Wird für unendlich Munition, keinen Rückstoß usw. genutzt. Über Auto-Assembler-Skripte.
Eine laufende Instanz eines Programms. Sie „binden“ CE an einen Prozess (z. B. ein Spiel), um seinen Speicher zu lesen und zu schreiben. Jeder Prozess hat seinen eigenen virtuellen Adressraum.
Die Liste unten im CE-Fenster, in die Sie gefundene Adressen eintragen. Sie können Werte bearbeiten, einfrieren, Beschreibungen hinzufügen und Skripte zuweisen. Wird als Teil einer .CT-Datei gespeichert.
Eine Tastenkombination, die Sie einer Adresse oder einem Skript zuweisen (z. B. Strg+H zum Umschalten von unendlich Leben). Über Rechtsklick auf die Adresse oder in den Skript-Optionen einstellbar.
Assembler „No Operation“. Eine Anweisung durch NOPs zu ersetzen entfernt sie effektiv. Wird genutzt, um Prüfungen zu deaktivieren (z. B. eine Prüfung, die Munition verringert).
Findet Ketten von Pointern (Adressen, die auf andere Adressen zeigen), die zu Ihrem Wert führen. Nach einem Neustart ändert sich die direkte Adresse oft, der Pointer-Pfad (z. B. Basis + Offset → nächster + Offset → Ihr Wert) bleibt meist gültig.
Eine CE-Funktion (wenn DBVM geladen ist), die die Ausführung verfolgt und anzeigt, welcher Code läuft. Für fortgeschrittene Analyse. Siehe Wiki für Ultimap-Dokumentation.
Eine Server-Komponente, die unter Linux, Android oder anderen Plattformen läuft, damit ein Windows-CE-Client sich über das Netzwerk an den Prozess anbinden kann. Für fortgeschrittene Nutzer. Siehe Downloads.
Die Startadresse eines Moduls (z. B. der Spiel-.exe oder einer DLL). Adressen innerhalb des Moduls werden oft als Basis + Offset angegeben. Basisadressen können bei jedem Start wegen ASLR wechseln; Pointer und AOBs finden Code/Daten zuverlässig.
Eine feste Zahl, die zu einer Basis oder einem Pointer addiert wird, um ein Feld zu erreichen. Z. B. „Spieler + 0x10“ könnte Leben sein. Offsets bleiben über Läufe gleich; Basis oder Pointer können sich ändern. Pointer-Scan-Ergebnisse zeigen eine Kette von Offsets.
Eine ausführbare Datei oder Bibliothek, die in den Prozess geladen ist (z. B. die Haupt-Spiel-.exe oder eine .dll). CE kann Module auflisten und Scans auf ein bestimmtes Modul beschränken. Das „Hauptmodul“ ist meist die primäre .exe.
Die Ausführung vom ursprünglichen Code zu Ihrem Code umleiten (z. B. den Anfang einer Funktion durch einen Sprung zu Ihrer Routine ersetzen). CE macht das beim Speedhack (Hooking von Zeit-APIs) und bei der Code-Injection. Ihr Code kann das Original aufrufen und das Verhalten anpassen.
CE-Funktion, um Speicher als Struktur darzustellen (z. B. eine C-Struct): Sie definieren Offsets und Typen, CE zeigt die Felder an. Hilft beim Reverse Engineering, wie das Spiel Spielerdaten, Objekte oder Arrays speichert.
Die Bedingung für einen Scan: Exakter Wert, Unbekannter Ausgangswert, Größer als, Kleiner als, Erhöhter Wert, Verringerter Wert, Geänderter Wert, Unveränderter Wert usw. Erster Scan nutzt die Ausgangsbedingung; Nächster Scan grenzt mit der neuen Bedingung ein.
Address Space Layout Randomization. Das Betriebssystem lädt Module bei jedem Start an zufällige Adressen, daher ändern sich direkte Adressen. Deshalb nutzt man Pointer-Scans und AOBs statt fester Adressen in Skripten.
Zeigt Maschinencode als lesbaren Assembler (x86/x64). In CE nutzen Sie ihn, um den Spielcode anzuzeigen, Anweisungen zu finden, die auf Ihre Adresse zugreifen, und Patches vorzubereiten. Der Assembler erlaubt das Bearbeiten oder Hinzufügen von Anweisungen.
Im Auto Assembler reserviert alloc einen Speicherblock im Zielprozess für Ihren Code oder Ihre Daten. Ihr Skript injiziert dort Code und leitet das Spiel dorthin um. Die allokierte Adresse ist für die Sitzung stabil, aber nicht über Neustarts hinweg ohne Pointer oder AOB.