Cheat Engine

[desertricker]

Hi everyone, I've been developing a reverse engineering tool called PINCE. It's a gdb front end mashed with scanmem to provide CE utilities

https://github.com/korcankaraokcu/PINCE

Just wanted to tell that you won't miss CE in linux when this project (hopefully) finishes properly. I'll post the important updates here

[desertricker]

PROGRESS TIME!

Bugfixes and addition of a few new nice features including Variable Inspection&Modification, GDB Console and code generalization(required for the libPINCE to be reusable)

[Stylo]

Looks pretty impressive I gotta say..
One problem though, I attached it to ubuntu's calculator and for every action I'm getting inferior is running.. what do I do with it?

[desertricker]

[kantoboy69]

Tried that before but never actually started a prototype project

On my research I found this backdoor SSHEATER can be use to modify memory just like cheat engine so it can be helpful on building a prototype similar to cheatengine without actually using GDB

I forgot the name of the project for the android counterpart which I think could also work on linux.

[Dark Byte]

Look at ceserver
It's easy to compile for linux.

You just need a gui. (E.g ce running in wine connected to localhost)

(Or compile the cecore project and use java to control it)

[desertricker]

[Dark Byte]

No, ceserver is specifically to target native linux processes.(android linux, but should be easy enough to make it work for most linux builds) But you need to control it through sockets

[desertricker]

[Dark Byte]

i've written a wrapper/emulator for openprocess, writeprocessmemory, readprocessmemory and some basic debugging (same windows API call, but uses ptrace internally, and of course also reads /proc/$pid/mem when available )

https://github.com/cheat-engine/cheat-engine/blob/master/Cheat%20Engine/ceserver/api.c#L2481 has the rpm implementation

as for compiling, I use eclipse with the cdt package. you may have to adjust some parameters (it may default to android, but there is a linux build as well)

[desertricker]

Tbh, this made me feel useless about my project. I didn't even know all these things existed. But I should continue to this project I guess... What do you think? Is this project a waste of effort or needed? It's native, uses gdb(adds features such as python scripting and reverse-debugging which doesn't exist in CE). But on the other hand CE has a lot of tools that gdb doesn't have(such as speedhack, unrandomizer etc.). I'm asking this question because I fear that these projects may overshadow each other. See scanmem&GameConqueror for instance, even when cheat engine works with ce-server, people prefer GameConqueror over CE because it's very easy to find&install compared to ce-server. So, PINCE may also overshadow ce-server. What would ce-server lack compared to a native implementation? And are you planning to port CE to linux?

Also I'm new to ce-server. What to do after compiling? Could you please write step by step?

Thank you in advance

[Dark Byte]

you can of course improve ceserver for non android situations. e. g android can only read mem after a ptrace, but depending on how your kernel is compiled that doesn't have to be the case. in that case read can work a lot faster (no need to wait for attach) and threaded

but you do need to change some more code. (every thread will need it's own proc mem handle else threading problems will arise)

but it's up to you.
adding new features to ce that use gdb is possible too, just add new commands to the server layer and program in the cegui how to use it (but may be complicated if the ptrace read and gdb conflict) and you need to work with pascal

-
i may someday port ce to linux, but not sure when
it is possible using the wrapper and skip the server part, and after enough editing ce will compile for linux (i did the same for the mac port where i wrote a wrapper for rpm/rpm but then to mach_* functions)

-

after ceserver is compiled, run it as root and it will open some ports. Then you can connect and give it commands (binary commands, not text) like openProcess, readProcessMemory, debugProcess, waitForDebugEvent, getThreadContext, etc...

[desertricker]

Correct, gdb and ptrace() conflicts. The only way to use ptrace() within gdb is to wrap it with python then call it by using "source" command of gdb. This means that you have to convert entire CE backend to python, which is not very easy to do.

Even ce-server and PINCE look like they are trying to accomplish the same thing, they have different approaches, which results in different features&behaviours.So, I guess I should continue developing PINCE. Diversity is a good thing to have

Oh, btw. Since you have mentioned using /proc/$pid/mem, I wondered that if it's possible to reuse CE's code for memory searching in linux. If it's possible, where is the code that's responsible of searching in github page of CE?

[theidiot]

[helenedwards]

Looks pretty impressive I gotta say..