Cheat Engine

[Samsei]

- The debugger, regardless of the settings, leads to an immediate crash of the application. (Whether on task or thread level)

- However, the debugger works with the tutorial without any issues.
- Switching to the GDB debugger is unfortunately not an option due to Apple "M".

- The problem occurs with all games, for example, the macOS version of Dave: The Diver.
- With other programs, for example, BitSlicer, it works without any further issues.

[Dark Byte]

When you target a rosetta process ce should ask you to attach the debugger. Did you click yes on that? (if you click no you can't edit memory)
Is the rosetta gdb debugserver path configured correctly? (does it exist?)
is xcode installed?

have you tried other games like kindergarten on steam ?
or terraria ?

[Samsei]

1. Yes, the prompt does appear. How would I get the debugger to run if it's not a Rosetta process? Is GDB-Server the only way then?

2. The path is correct and configured accordingly. The Rosetta debug server can also be started via terminal, but it only works if the application is explicitly started as a Rosetta application beforehand.

3. Xcode is installed, but only with the essentials (default).

4. The last program I tried was Death Stranding, which was released today as a native application for macOS. This also did not work.


So, my takeaway is that the debugger only functions with Rosetta processes, correct? When it comes to native applications that don't need Rosetta, the application seems to crash.

[Dark Byte]

if it's not running under rosetta it'll do the normal m1 debug method

perhaps the games you've tried have protection?

[Samsei]

I'll try representing this as an image, maybe that will bring some clarity to the situation. Essentially, this happens with every application I've tried. With other programs, like Bit Slicer, it works without any issues.

h*ttps://postimg.cc/5j1YWjK4

I like Cheat Engine and have been using it for ages, though previously on Windows. I truly consider it the best program for such purposes, but I'm somewhat despairing over the situation.

----

I was able to reproduce the error just now with the tutorial as well. As soon as I try to open the (AARch64) with the debugger, I receive the same error message. Therefore, the problem likely doesn't lie with the programs I've tested Cheat Engine with.

[Dark Byte]

ok, I see. So for some reason something force terminates Cheat Engine when it starts the debugger.
Looks like some kind of security system as it's not caught by the internal exception handler.

But what issue do you have with the gdb/lldb debugger interface ? What kind of errors do you experience there ? Did you fill in the path to the lldb server ?

[Samsei]

Path: /Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Versions/A/Resources/debugserver 0.0.0.0:33453

h*ttps://postimg.cc/tZZznyH9


----

When I enable SIP or set it to reduced security, the tutorial works without crashing. However, now I get the message that I can't open the file because: "Failed opening process. Likely due to lack of admin rights."
Unfortunately, "sudo ./CheatEngine752.app/Contents/MacOS/cheatengine-x86_64 hasrights" also doesn't work.

[Dark Byte]

even the tutorial? Try selfsigning both CE and the tutorial and see if that makes a difference

[Samsei]

Sorry for the confusion earlier; the tutorial file works without any restrictions or problems.

The problem now is that I can't access any files other than the tutorial file. I followed the instructions on Patreon and didn't encounter any errors, but I just can't grant Cheat Engine the necessary permissions.

[Samsei]

I managed to fix the crashing issue, and the error is even reproducible. Executing the new signing command (sudo codesign --force --deep --sign - CheatEngine752.app) leads to the aforementioned problem; without it, the debugger works... to an extent.

The debugger starts running but crashes shortly after: (see code)

[Dark Byte]

That it crashes differently is likely because it couldn't hook the exception port on the target process, and thus not trigger to guarded resource shutdown. But since the exception isn't hooked it can't handle the debug trap bp

It might be a new security option in the latest macos version or this game has anti debug enabled.

[Samsei]

Since the modification works with other programs, I'm currently assuming the issue lies with Cheat Engine / MacOS Sonoma, and there's not much more I can do than wait for a new update, right?
Otherwise, I'm open to suggestions.

[Dark Byte]

I currently don't know. Perhaps it's the mac version. It works for me on a Apple M1 on Ventura 13.5 and it's possible that new security stuff got added to later versions. See if there's a way to disable "guarded resources"

[Samsei]

Okay, I think this concludes my attempt to get things working. I believe I'll have to wait for an update to resolve the issue. I assume I can't fix the problem myself, as rolling back an update on macOS isn't straightforward, and identifying the root cause seems nearly impossible.


Thank you for the support, even though it unfortunately didn't have the desired effect. Perhaps the problem will resolve itself in the foreseeable future (with the Cheat Engine update).

[Samsei]

I couldn't resist and went back to troubleshooting:

1. The issue seems to be related to macOS Sonoma, evident with other programs and the Rosetta debugger as well.
2. Consequently, I uninstalled Xcode (partially manually).
3. Furthermore, I manually deleted Rosetta and reinstalled it.

The debugger now runs without crashing for some programs, but with others, I'm not sure if a protective mechanism is causing issues.
In conclusion: Reinstalling Rosetta 2 solved some problems, and it might help others as well.