Cheat Engine

[ups2000ups]

im making a small memory editor but the scan is slow
well if i just scan with no result no problem it will be fast but when i get alot of result it will take time

i know the problem is that it take long time to write it to the hardware
thats why i wondering how i should save it in the memory and then save it to a file

there will be no difference if i save the result in a listbox than a txt file it will take the same time

[tombana]

When writing the file, you're doing: inttohex(start, and also inttostr(value2).
An int takes up 4 bytes, but when you convert it to readable characters like you do it can take up much more. Just save it into the file as an int. Then you can also read it as an int when you open the file, and convert it to a string if nessecary.

[ups2000ups]

[tombana]

About the speed. You're using ReadProcessMemory on every single byte of memory. ( start := start+$1; )
What you need to do is call RPM once on every section or so, and read that into a buffer. Then compare every byte of that buffer with what you're searching for.
And you could write int's to a text file but then you won't be able to view it with notepad or so.

[Dark Byte]

yes, just read huge chunks of memory and then scan through that block
A ReadProcessMemory call takes time, so do as little of those calls as you can

Thats why you use virtualqueryex to find out which memory blocks are readable


Same for write operations. Instead of immediately writing to disk store the results in memory and only when full call the option to write. E.g have an array of 8196 dwords and when full write that.

I also don't recommend saving it as text but just as binary. This can later on help you make finding stuff faster. (No need to parse each single address back to a value)

Or (i know, it's unacceptable, but still):
look here: http://ce.colddot.nl/browser/Cheat%20Engine/memscan.pas

[tombana]

Yes I think CE's way is the fastest:
First VirtualQueryEx to find out the regions and make a list of those.
Then do ReadProcessMemory on every region.
After every region you should probably search for the desired value. If you first want to do all the RPM's and then search you'll need to allocate a lot of memory I guess.
Then when you've got a list of results write them to the file at once. (as binary)

It's probably even faster to have a dll injected into the process. Then tell the dll to search for a value and then the dll can either write the results to a file or give them back to your application. This is what hyperscan does in CE right?

Tombana

[ups2000ups]

thanks i have learned more in the past 3 days then i did for 2 years i think

Dark Byte there is just one thing i dont get

if i would save it as binary how do i read it then? should i make a function that convert binary to the addresses and values and then put them into my ct? or is there an easier way?

[Dark Byte]

binary is just the way the computer stores values so no need for any conversion at all. (Only need to convert it to text using inttohex when displaying it on the screen, but internally it's just normal datatypes)
Just read the contents of the file into an array or a single dword. (if you care about speed, and your harddisk, go for an array)


let's say you have an array of dwords (e.g addresslist)
then just save addresslist as a block of bytes instead of converting it. And when loading it back you can also just load it back into memory without having to convert the text into bytes (so no need for a strtoint('$'+string))

It will require a slightly different way of filehandling though
e.g instead of usuign a textfile use a TFilestream or a normal "file" and then "Rewrite(WriteFile,1)" and using BlockRead/BlockWrite to read from it.

I recommend using TFileStream though, it makes the code more readable and still fast enough

[nog_lorp]

I'm confused. You say

[ups2000ups]

[Dark Byte]

about the found results,
CE doesn't actually put them all into the listbox.
The listbox just gets set how many lines big it should be so itr creates a valid scrollbox on the right, and then on scrolls it fetches only the items that are visible in the listbox (from first line visible to last line visible) and draws them on it

thats why when you have a huge list and scroll around you can see the harddisk led go up. (ce does cache in blocks of 1000 addresses so only on big scrollmovements it's noticable)
That's also why I use a addressfile in dword format, because the start of the needed address range can be found using (4*firstvisibleitemnr) instead of reading through each line until you've counted the correct number of lines

[tombana]

[Dark Byte]

It's basically just a canvas.textout(x,y,text); (that's calling the windows api ExtTextOut)

In this case i'm only using a customdata listview and the only ownerdraw part is where I set the color of the canvas font to green or black depending if it's inside a module or not.

When using ondata it sends a request for each single item in the list where the data is requested for (e.g drawn) , which limits the processing a lot since it only has to read the memory of the visible items and only has to check if the visible items are inside a module. If it had to do that for a million addresses instead of only 20 then it would take several seconds to update each time

[tombana]

That's so clever
So when you would do this in 'normal' c++, so just win32api, you would create a listview with the 'ownerdraw' option set. Then when you receive a WM_PAINT you check what items are inside the visible region of the listbox and then call ExtTextOut with the correct color and stuff set.
I'm not sure about the ondata part. Is that a window message you receive?
Thanks,
Tombana

[Dark Byte]

ondata is based on a windows message after having been processed heavily by filters and what not (checked in the VCL sourcecode)

messages involved: CDDS_ITEMPREPAINT , CDDS_ITEMPOSTPAINT, CDDS_ITEMPREERASE, CDDS_ITEMPOSTERASE, LVN_GETDISPINFO

I use delphi because I hate gui coding a lot