 |
Cheat Engine
The Official Site of Cheat Engine
|
| View previous topic :: View next topic |
| Author |
Message |
Alphasoldier
Advanced Cheater
![]() Reputation: 1
Joined: 07 Apr 2009
Posts: 95
|
 Posted: Sat Nov 30, 2013 9:32 am Post subject: Automatic Pointer Scan Options |
 |
|
Now I've used Cheat Engine for quite some time, and I know my way around it, more or less. The sad thing is, you don't learn more about CE and general memory hacking over time, you have to really study up on memory, follow tutorials and figure out the workings of how different sorts of code affects different kinds of memory.
At a certain point; a long time ago, I started getting into pointers, and half of the time I was able to find them on my own. Then I bumped into some more complicated games and I couldn't find the pointer manually anymore because of having hundreds of addresses after the first 'what writes to' scan. And even then hitting a dead end somehow.
So I jumped to the automatic pointer scanning, which was back then a new feature. With this I could find pointers almost all the time, even though it took some time with scanning, and a lot of disk space as well. When I still couldn't find what I was looking for I went levels deeper and sometimes even changing offset value, which worked wonders in Borderlands 2. While these options helped me, a later update of CE gave me even more things that I didn't understand.
Now my question, the reason I made this topic is: What are all the pointer scanner scan options for?
I more than often have a list where steamapi.dll pops up in the pointer list, among others. This is never a stable pointer, because it's obviously not the right executable, but does it have any use whatsoever? Or is there some kind of options to stop the pointer scanner from scanning these at all and just go for the game executable?
At the same time I once had a pointer that had a base address of something with STACK in it, which I presume is because of the "Allow stack addresses...". This pointer seemed stable throughout all the future plays of this game, and I don't even know what it is, how it got there or how it works.
Now why I ended up making this thread now, is because I've been playing a game whose values are usually saved as double, and I couldn't find anything with the pointer scanner until I turned off "Addresses must be 32-bit aligned.". Now this still didn't give me a stable pointer, but with it on I got no results whatsoever.
While I have this thread created anyway, I was wondering if there was any kind soul out there that would want contact outside of the forum to help me achieve some of the more complicated things with Cheat Engine. I ain't thickheaded and I learn quickly. Heck, I was one of the first to come up with most of the pointers and hacks for Borderlands 2. And while I admit that the game isn't too hard to hack, I was quite humbled by the complexity of all the hacks that came out shortly after my first few discoveries and I would love to get on that same level.
|
|
| Back to top |
|
 |
Dark Byte
Site Admin
 Reputation: 470
Joined: 09 May 2003
Posts: 25803
Location: The netherlands
|
| Posted: Sat Nov 30, 2013 11:05 am Post subject: |
 |
|
a pointer doesn't have to be in the game's executable to be a valid pointer.
steamapi.dll can be used as a valid pointer base, but you must then make sure that the version doesn't change, and when you give it to someone else, they must have the same version
The stack is a thread specific memory storage. It's main use is for storing local variables.
It's useful as a pointer base as a lot of games tend to store some important data in a local variable before calling other functions
e.g:
| Code: |
int main(...)
{
CMyGame game;
game->Run();
}
|
the pointer to "game" would then be stored in the stack, and no static address anywhere else. With stack pointers you can find and use it
as for the other options:
Addresses must be 32-bit aligned:
When enabled, only pointers that are stored in an address dividable by 4 are looked at
When disabled, it won't bother.
pro: Fast scans
Con: On some horrible designed games that you shouldn't even play it won't find the paths
That the type is a double has nothing to do with it(But might indicate that it's a waste of space, meaning you shouldn't be surprised to see a level 15 used here)
Only find paths with a static address:
When checked the pointerscan will only store a path when it starts with a static address. (or easily looked up address)
When it's disabled, it finds every single pointer path
pro: Fast
con: It may miss pointers that are accessed by special paths like thread local storage. (but even then they'd be useless for ce)
Don't include pointers with read only nodes:
When checked the pointerscan will throw away memory that is readonly. So when it looks for paths, it won't encounter paths that pass through read only memory blocks.
When it's unchecked, it does include readonly memory
pro: faster, less useless results
con: If the game decides to mark a pointer as readonly ce won't find it
Stop traversing a path when a static has been found
When the pointerscanner goes through the list of pointervalues with a specific value, this will stop exploring other paths as soon as it encounters a static pointer to that value
pro: Fast
con: You may miss some valid results
Improve pointerscan with gathered heap data
When this is checked the heap is used to figure out the offset sizes, instead of blindly guessing them.
pro: Greatly improve speed and a lot less useless results
con: if the game allocates gigantic chunks of heap memory, and then divides it up itself, this will give wrong results.
In other cases this will give perfect pointers
Only allow static and heap addresses in the path
When checked, the pointerscan will refuse to guess the offset if it's not a heap address and just marks the whole path as invalid
pro: Even faster and less guessing
con: See normal heap scan+if the game uses a mix of self allocated and heap memory ranges. It won't find anything then
First element of pointerstruct must point to vtable
Object oriented programming languages tend to implement classobjects by having a pointer in the first element to something that describes the class
With this option enabled, ce will check if it's a classobject by checking that rule. If not, it won't see it as a pointer.
pro:Tremendous speed increase and almost perfect pointers
con:Doesn't work with runtime generated classes (java, .net)
(I may add a feature for that)
No looping pointers:
This will filter out pointerpaths that ended up in a loop
e.g:
base->p1->p2->p3->p1->p4
you could just as well do base->p1->p4 then, so throw this one away (base->p1->p4 will be found another way)
pro: Less results so less diskspace used
con: slightly slows down the scan as it needs to check for loops every single iteration
max different offsets per node
When the pointerscan looks through the list of pointers with a specific value, it goes through every single pointer that has that value. Every time increasing the offset slightly.
With this feature enabled the pointerscan will only check the first few pointers with that value.
pro: Extremely fast, and the results have the lowest pointer paths possible.
con: You'll miss a lot of pointers that might be valid too
allow stack addresses
This allows the stack of threads to be seen as static addresses by the pointerscan.
The main thread is always a sure bet that it's the first one in the list. And often the second thread created is pretty stable as well.
With more there's a bigger change they get created and destroyed randomly
When a program enters a function and exits it, the stack pointer decreases and increases, and the data there gets written to.
The farther the game is inside function calls, the more static the older data will be.
With max stack offset: you can set the max size that can be deemed as static enough.
pro: It finds paths otherwise never found
con: More results, more diskspace
If combined with "stackaddresses as ONLY base" then
pro: You'll only get paths to the stack and no random dll's or the .exe
con: You'll only get paths to the stack and no random dll's or the .exe
Use pointermap from previous pointerscan
If you just did a pointerscan and found the scan didn't take too long, you can do a higher level scan, and skip the initial stage (progeressbar part)
Just make sure that address hasn't been changed
Pointers must end with specific offsets
If due to debugging or guessing you know a pointer ends with offset 3c018 then you can fill that in to speed up the scan(, and without the need to change the structsize to at least 245784)
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
justa_dude
Grandmaster Cheater
 Reputation: 23
Joined: 29 Jun 2010
Posts: 892
|
| Posted: Sun Dec 01, 2013 6:25 am Post subject: |
|
|
| This is really good information! Thanks for sharing. Is there any chance this could be added to the CE help file?
|
|
| Back to top |
|
|
Zaladine
Expert Cheater
 Reputation: 3
Joined: 14 Oct 2012
Posts: 129
Location: Djokdja, Indonesia
|
| Posted: Sun Dec 01, 2013 10:24 am Post subject: |
|
|
Highly informative... Excellent info...
_________________
... to boldly go where no eagle has gone before ... |
|
| Back to top |
|
|
Alphasoldier
Advanced Cheater
![]() Reputation: 1
Joined: 07 Apr 2009
Posts: 95
|
| Posted: Sun Dec 01, 2013 1:42 pm Post subject: |
|
|
| Holy information on a stick, Batman, that's more elaborate than I could've hoped. Thanks a lot Dark Byte! This'll definitely help me in my future endeavors.
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
