Cheat Engine

Smidge204 · Newbie cheater Reputation: 0 Joined: 01 Jan 2004 Posts: 19

Okay, lesse here... I wrote a faux client to take a peek at what the sever is sending.

98 server, 2K client:

Dark Byte · Posted: Sat Jan 03, 2004 11:33 am Post subject:

When it worked, did the memory view window work too then?
that one uses lots of data, BUT waits for a ack (To check if it depends on the ammount of data, or on the ammount of single packets)

about the 2k server+98 client part: Did the server say it sent the other process items too, or did it give one of those winsock buffer full +errormessage? (and hang) Or did it just hang and do nothing for 30 seconds ?

Also, isn't the TCP protocol suposed to handle the acks for me...
But I'll add some acks.

Oh yes, are you experienced with winsock programming? Whats the best way to find out when you can send data? Right now I use the select function to see if I can write or not.

Dark Byte · Posted: Sat Jan 03, 2004 12:07 pm Post subject:

ok, I made it so that it waits for a ack before sending the next process list item. http://members.chello.nl/~cheatengine/network.zip (The ack command is 18, no param)
But I wouldn't call it a SMALL performance hit...
If I would have to do this with other stuff like the address list, results of scans, this is going to be very slow. (Although I gues I could put the whole process list in one packet, assuming the client doesnt crash because of the ammount of data received)

Smidge204 · Newbie cheater Reputation: 0 Joined: 01 Jan 2004 Posts: 19

The memory view window works, but it crashes or locks up when I try to scroll it. Only on the Win98 machine, though. (Could this be because I'm trying to read a system process? That's all I have left after trying to cut it down to 15 processes!)

The server says it sent all the data, but the client doesn't seen to get it all. No errors reported and no hanging ('cept the client, maybe it never processed a "End of process listing" packet?)

Yes, the TCP protocol does ack packets, but that's on the TCP layer. You need acks on your protocol layer to make sure the client received and properly processed each packet! (TCP only makes sure it gets there, it's your job to make sure it's handled properly)

I'm only experienced with socket programming as it pertains to VisualBasic. Would this be a bad time to mention that I have no official training as a programmer? Smile

Self taught VB with a hearty helping of x86 assembly and a dollop of 87c51 microcontroller. Doesn't mean I can't hold my own, though...

Not knowing how you handle sockets, but in Win32 you can monitor the "State" of the socket. State 7 means you're connected and ready to transmit. Other than that, the only way to tell if there's anything pending transfer is to peek at the buffer - but that tells you nothing about the other side. (Your send buffer may be empty, but the client's receive buffer may not be)

VB is all event driven, so I get a function that runs whenever a packet is received, and I process the data from there. If I'm still processing when another packet arrives, then another instance of the function is created and that runs. When it's done it goes back to the original instance and resumes. (This is a real pain in the ass if the order of the packets is important, but a nice queue system keeps everything in order and the buffer empty!)

If your socket routines are event driven too, maybe it gets tripped up when it gets 16 packets in rapid succession and it corrupts the data?

*tries something*

Okay! I get transmit more than 20 items if I pause between them. So if I send one list item at a time and wait, it doesn't bork. That fits my original theory that ACKing each list item will solve the problem - since it won't send another packet until the client has properly processed the last.
=Smidge=

Dark Byte · Posted: Sat Jan 03, 2004 1:25 pm Post subject:

How did the new client/server combination work ?

Smidge204 · Newbie cheater Reputation: 0 Joined: 01 Jan 2004 Posts: 19

Okay! That last version seems to have fixed the process listing! Listing and changing/freezing addresses works fine, too.

Next, the memory viewer. It likes to crash a lot. (Just the client). The happens even when the server and client are running on the same machine.

Details:

Dark Byte · Posted: Sat Jan 03, 2004 10:03 pm Post subject:

does the normal cheat engine also crash in win98 when using the memory browser?

You can get the same kind of window by deselecting the disassembler in the settings under "assembler stuff"

Dark Byte · Posted: Sat Jan 03, 2004 10:31 pm Post subject:

I gues I need to add acks there too for win98 and earlier to get it to work. The problem is that that makes it slow. It takes several seconds for the process list , while normally it's there in the blink of an eye.

And then the memorybrowser:
The client sends the request for memory and waits
The server sends that memory (max 500 bytes at a time)
Client continues with sending another request or shows it on the screen.
and thats it. Dont know what could go wrong unless it's the size.

wh1t3y · Posted: Sun Jan 04, 2004 12:04 am Post subject:

man with you two working on the network server/client of ce.. its gonna be awesome... but i have no idea what you guys are talking about with this stuff.. who else is with me?

Smidge204 · Newbie cheater Reputation: 0 Joined: 01 Jan 2004 Posts: 19

The normal CE works fine on the 98 machine. The network version (server and client running on same machine) still dies. I get a "Timeout while waiting for data" popup.

I've been thinking about it, and it dawned on me that there really is no benefit to keeping the packet size so small. The TCP protocol is designed to handle packet fragmentation and error correction, and it's quite good at it. You can probably boost performance and reliability by simply compiling data you need to send into larger packets.

For example, compile the process list into a single string and send it all at once. (Either use delimiter bytes or the fact that the data itself tells you how big each entry is to split it up again). There's a little gain in processing overhead to put the list together, but you save much more in bandwidth and the socket libraries won't be doing so much work sending and verifying packets. I think there would be a net increase in performance and reliability.

Also, when sending memory... how are you doing that? Are you sending the ENTIRE memory space each refresh?

What I'd do, is have the client send two config values: Start and Length. The server would then read (Length)*16 bytes of memory from (Start). The start value would be based on the scrollbar's value in the memory viewer (assuming the client knows how big the memory space is!). And ideally (Length) would be just large enough to cover what's visible in the client window plus a little above and below (Since the user is likely to scroll up and down more than jump, this will keep the data that is most likely to be viewed fresh).

I think 2048 bytes of buffer would be sufficient in most cases, so at worst you're sending 2kb of data per refresh. That's 2 refreshes per second on your average crap-tastic dialup connection - not too shabby.

To further enhance, why not toss the data to zlib and compress it? There's a good chance the memory will be mostly 0's, so I'm betting it'll compress really well. (Best part is, zlib is fast, free, and you don't have to code it yourself...)

Just my $0.02 on that.
=Smidge=

Dark Byte · Posted: Sun Jan 04, 2004 12:52 pm Post subject:

try :http://members.chello.nl/~cheatengine/network.zip
The process list is now in one buffer and the memorybrowser uses packet transfers of 2000 bytes instead of 500 bytes

Smidge204 · Newbie cheater Reputation: 0 Joined: 01 Jan 2004 Posts: 19

Hot damn. The process list is almost instant.

The addresses I have listed are not being updated when I hav emore than a few on the list. See attached pic. Note that the first seven items have 0 for their value and the others are blank... if I scroll up, it's always the first seven! Changing these values has no effect on the server.

This only happens once I load more than a few (about 8?) items. Probably a similar problem as before. :/

BTW, Since I've been using this program so much, I'm been keeping a "wish list" of features. It's getting pretty hefty :D

Edit: Helps if I attach the pic...
=Smidge=

Dark Byte · Posted: Tue Jan 06, 2004 8:40 pm Post subject:

Did the memorybrowser still crash in this new version?

I just did a test by sending 20000 small (16 bytes) packets containing a process list item to the client, and all worked fine. I also tried sending one buffer with a size of 1500KB containing a process list to the client and that worked too.

Smidge204 · Newbie cheater Reputation: 0 Joined: 01 Jan 2004 Posts: 19

The 32bit Winsock library on hte 98 machine was actually NEWER than the one on my 2K machine! That's definately not the problem...

The memory browser crashes only if I grab the scrollbar and move it too fast. Probably has something to do with trying to update too often and clogging the socket again?
=Smidge=