Cheat Engine

CRISISxCupid · Posted: Thu Jul 31, 2008 8:45 am Post subject:

Gotcha

thanks GMZorita and dnsil0.

Another quick question... Are they easy? I have barely any experience with coding.

GMZorita · Posted: Thu Jul 31, 2008 9:49 am Post subject:

CRISISxCupid · Posted: Thu Jul 31, 2008 10:45 am Post subject:

Learn it. I know ASM is a very simple programming language but C++, I haven't got a clue about.

&Vage · Posted: Thu Jul 31, 2008 11:50 am Post subject:

CRISISxCupid · Posted: Thu Jul 31, 2008 12:10 pm Post subject:

So just C++? WHY ARE YOU PEOPLE SO NOT CLEAR!? D:

&Vage · Posted: Thu Jul 31, 2008 12:14 pm Post subject:

CRISISxCupid · Posted: Thu Jul 31, 2008 1:09 pm Post subject:

So just C++?

And a quick question about any programming language

Is it like put in a bunch of words and they'll do a function or is it like something else?

Flyte · Posted: Thu Jul 31, 2008 1:38 pm Post subject:

ASM/C is what you will need to learn. ASM for debugging and C/ASM for the implementation.

GMZorita · Posted: Thu Jul 31, 2008 1:49 pm Post subject:

CRISISxCupid · Posted: Thu Jul 31, 2008 1:59 pm Post subject:

I'll just go with Flyte said. I'll learn how too make CE scripts also so that's a benefit.

rapion124 · Posted: Thu Jul 31, 2008 3:12 pm Post subject:

Easiest way is to find the decryption routine. Most games use a static key (the key is always the same) and their own encryption routine. Or, the key is generated randomly by the server and is contained in the packet. Just debug the game, set a breakpoint on the receive function in WinSocks. Trace to the return and find the decryption routine. Continue tracing until you know how the packet is decrypted.

Also, calling the encryption routine doesn't really work or it's not a feasible way to send your own packet. Most of the time, the encryption routine is not exported and you have to decode the parameters yourself, as most games I know do not have their sources public.

&Vage · Posted: Thu Jul 31, 2008 4:00 pm Post subject:

Ksbunker · Posted: Thu Jul 31, 2008 10:42 pm Post subject: RE:

Reversing packet formats can be a labour intensive with plenty of trial and error and process of elimination.

I wrote a tute not too long ago about reversing a packet in a game I occasionally play;

http://ksbunker.beyondgaming.org/tutorials/roguespear-tutorial.txt

It should go w/o saying but, different games use different formats, timestamps, checksums, etc... so there is no single generic method of reversing packets.

The best way to understanding how a packet works it to attempting to change only one variable at a time within a packet. Much in the same way scientific based experiments attempt constrain all parameters with exception to one to see if the intervention had any effect on x.

So I would recommend working with a text packet and send the same text packet over and over and records the results. If the packets are not the same, you know that there's at least, some form of timestamp. If the packets are the same, you know no timestamp exists, but that does not eliminate a potential checksum.

To determine if a checksum exists, send the same text again HOWEVER change one character of text (same size as before). If only 1 byte has change (ie. the actual letter that was changed), you know there is no checksum. IF the text was checksumed, a single letter edit would grossly alter the configuration and format of a particular aspect of the packet.

In case there is not checksum or timestamp, yourt job is made a lot easier; send and record more text packets of the same length that you originally recorded. If the test was 5 chars, send a 4 character text (different text though), and check to see if there's 5 bytes chains different anywhere. If you find something gj.

If not, try the same text, but use 4 characters (and remove the last character), that way the packet should fundamentally be the same, except for the sizeof string byte (if any existed), but also check to see if the first 4 bytes of the 5 char string were the same in the packet as the first 4 bytes of the 4 char string.

Anyway, i've probably lost you, but it's just some ideas to play with.

As for debugging and tracing back through the code for encryption routines, it can be handy to set a BPM on send. There may be various calls to send from within the code, with WPE you know the data you're looking for so just BP each Send() call and locate the one(s) sending the data you're after.

Once found, using the call stack, just trace back through the calls untill you find something interesting. May also benefit to look in the stack for a pointer to the string that you typed. If you can find the plain text, follow the function, it surely must lead to the encrypt func, and you know you're close.

But yeah, play around.

atom0s · Posted: Thu Jul 31, 2008 10:56 pm Post subject:

Stay on topic, stop the stupid bickering or this will be locked.

crayzbeef · Posted: Wed Aug 06, 2008 4:58 pm Post subject: