Cheat Engine

[Dark Byte]

There's now an initial version of cheat engine for linux available for download on cheatengine.org

it uses qt5 but if requested i can make a gtk version as well

please report bugs you encounter

the windows version will come soon

[ParkourPenguin]

Running on Arch w/ KDE desktop environment (Wayland). I got most of the way through the tutorial and didn't test most of the features.

v The binary `cheatengine-x86_64` links with `libQt5Pas.so.1`. This dependency should be mentioned somewhere, e.g. in the readme. On Arch, the package "qt5pas" provides this library; I've heard Debian, Ubuntu, and Fedora also have relevant packages.
Long term, an appimage would be convenient.


v vI noticed the scandata files are saved in the `/tmp` directory. This is often mounted as a `tmpfs` filesystem that's backed by RAM. If the game is already taking up the majority of the system's RAM, scanning could cause bad things to start happening.
`/var/tmp` might be a better default for people who don't know what they're doing: by convention, it's expected files in this directory will persist across a system restart, so it must be backed by something other than RAM.
Dynamically switching between them would be best, but also complicated.

If the main window isn't in focus, right clicking a record in the address list doesn't work properly. If it's some window CE created ("Advanced Options" or "Table Extras" buttons), the popup window spawns out of place relative to the window that was in focus; if some other window is focused (e.g. the tutorial, a web browser, etc.), an entirely new window is created that's also out of place.

CE gets stuck in an infinite loop trying to allocate memory in the target process. Tested with both AA `alloc` and Lua `allocateMemory`.

[Dark Byte]

thanks. i'll get on it (did you try to allocate while the target was frozen ? as that's not an option at this time)

[ParkourPenguin]

The target wasn't frozen.

The Lua function `allocateMemory` doesn't enter an infinite loop, but it doesn't appear to work either. Running the code `return allocateMemory(4096)` in the Lua engine shows the function didn't return any values.
The Auto Assembler entering an infinite loop on allocation failure could be a separate issue from the allocation failure itself.

Steps to reproduce:

1. Execute `sudo bash -c 'echo 0 >/proc/sys/kernel/yama/ptrace_scope'`
   
2. Run the executable cheatengine-x86_64 as an unprivileged user
   
3. Open the tutorial from the "Help" menu
   
4. Attach to the tutorial
   
5. Open an AA script window
   
6. Execute the code `alloc(foo,4096)`

The lag when typing also happens in the AA script window. These messages are output to the terminal when the lag spike happens:

[Dark Byte]

for 4: when you say "attach to the tutorial" do you mean you click on "attach to process" or just doubleclick the tutorial, or click the tutorial and click ok ?

if you do "attach to process" which debugger interface method did you have selected in settings ?

[ParkourPenguin]

I click on the glowing computer icon in the top left of the main window to open the "Process List" window. The CE tutorial process is highlighted by default, so I don't change that. Then I click the "Open" button.

AFAIK the debugger is never attached to the process, but in Edit -> Settings -> Debugger Options -> Debugger method, "Use Linux(PTrace) debugger" is selected.
Executed in the Lua engine:

[Dark Byte]

weird. try running ce with sudo. Perhaps your security blocks the readout of maps for same user accounts

or you're way to dockered up (do not run ce in a docker) ce can usually deal with the target being inside a docker, but if it is inside one it may mess up

[ParkourPenguin]

Running CE as root didn't change anything. Memory allocation still failed. The tutorial was run as an unprivileged user, and no containers are in use.

Here's the full output of running CE as root, opening the unprivileged tutorial process, executing `return allocateMemory(4096)` in the Lua engine, and closing CE after that failed: