$ man 2 ptrace
/proc/sys/kernel/yama/ptrace_scope On systems with the Yama Linux Security Module (LSM) installed (i.e., the kernel was configured with CONFIG_SECU‐ RITY_YAMA), the /proc/sys/kernel/yama/ptrace_scope file (available since Linux 3.4) can be used to restrict the ability to trace a process with ptrace() (and thus also the ability to use tools such as strace(1) and gdb(1)). The goal of such restrictions is to prevent attack escalation whereby a compromised process can ptrace-attach to other sensitive processes (e.g., a GPG agent or an SSH session) owned by the user in order to gain additional credentials that may ex‐ ist in memory and thus expand the scope of the attack. More precisely, the Yama LSM limits two types of operations: • Any operation that performs a ptrace access mode PTRACE_MODE_ATTACH check—for example, ptrace() PTRACE_ATTACH. (See the "Ptrace access mode checking" discussion above.) • ptrace() PTRACE_TRACEME. A process that has the CAP_SYS_PTRACE capability can update the /proc/sys/kernel/yama/ptrace_scope file with one of the following values: 0 ("classic ptrace permissions") No additional restrictions on operations that perform PTRACE_MODE_ATTACH checks (beyond those imposed by the commoncap and other LSMs). The use of PTRACE_TRACEME is unchanged. 1 ("restricted ptrace") [default value] When performing an operation that requires a PTRACE_MODE_ATTACH check, the calling process must either have the CAP_SYS_PTRACE capability in the user namespace of the target process or it must have a predefined relationship with the target process. By default, the predefined relationship is that the target process must be a descen‐ dant of the caller. A target process can employ the prctl(2) PR_SET_PTRACER operation to declare an additional PID that is allowed to perform PTRACE_MODE_ATTACH operations on the target. See the kernel source file Documentation/ad‐ min-guide/LSM/Yama.rst (or Documentation/security/Yama.txt before Linux 4.13) for further details. The use of PTRACE_TRACEME is unchanged. 2 ("admin-only attach") Only processes with the CAP_SYS_PTRACE capability in the user namespace of the target process may perform PTRACE_MODE_ATTACH operations or trace children that employ PTRACE_TRACEME. 3 ("no attach") No process may perform PTRACE_MODE_ATTACH operations or trace children that employ PTRACE_TRACEME. Once this value has been written to the file, it cannot be changed.
$ cat /proc/sys/kernel/yama/ptrace_scope
0
$
If you don't have 0 there, you might try, as root, echo 0 > /proc/sys/kernel/yama/ptrace_scope and see if everything starts magically working.
If it does, to make said setting persist, you might want to add "kernel.yama.ptrace_scope=0" to /etc/sysctl.conf to apply that setting at boot.
Also, probably won't address your issue alone, but I use scanmem, a Linux CLI program, for memory-modifying cheating. If there's some failure in trying to do its ptrace thing, it might display an error message in the console. If you want, rather than changing the systemwide ability to use ptrace, you could also just run scanmem as root (you could also do the same with GUI programs, but more hassle, and honestly, I've never gone to look up how to make that work under Wayland, just Xorg, where # xauth merge ~/.Xauthority will do it).
EDIT: It looks like the Fedora guys were thinking about changing their default away from 0, and if the Nobara people just did so, that might be what's triggering that.
EDIT2: I thought that Debian did it too, since I remember smacking into that at one point, but I don't see anything in my sysctl.conf, and I can still happily scanmem; it's 0 on my system. Sounds like what happened was that they changed it to 1, decided that that was a bad idea, and then put it back to 0, so I probably tried using it during that window.
EDIT3: Just to clarify, ptrace() is the system call that most processes use to access another process's memory, and is probably what your memory-cheat program is using to try to look at (and modify) the memory of that other process.