MantisBT - Cheat Engine
View Issue Details
0000344Cheat Enginepublic2014-10-11 21:492014-10-21 14:36
Assigned ToDark Byte 
StatusresolvedResolutionno change required 
PlatformOSOS Version
Summary0000344: CE 6.4 Pointer scan yields incorrect pointers
DescriptionPlease see attached screenshot while reading this.

I ran a scan, the results are on the screenshot.
According to that, all pointers in the result list point to 0x3EFA5C80.

I included the dissected structure shot and the Change address dialog as proofs that these are not valid pointers.
If you check the last offset (0x780) of the the highlighted pointer scan result, you'll see that the address 0x3EFA5C80 points to 0x02A01F00.

I got the address 0x3EFA5C80 all right, but not as a pointer.
Additional InformationThe second Change address dialog shows another address, so you can see it's not specific to one pointer.

I used compressed pointer scan file.

As a side note, CE created 5*100GB scan files before the disk filled up - I had to stop the scan. Creating that amount took about 3 hours. Rescanning the pointer was at 0000011:0000015-20% after 4 hours of rescan - all four CPU core performance maxed out. Something is slowing down the rescan. I had to close CE to abort the re-scan as it would take 2 days...
TagsNo tags attached.
Attached Filespng CE_PointerScan.png (64,179) 2014-10-11 21:49

Dark Byte   
2014-10-12 01:10   
(Last edited: 2014-10-12 01:15)
You're making the mistake that the last line is a pointer+offset.
But look closely and you'll see it's missing the [ ] around it. That means it's just a calculation

The final address in the structure isn't a pointer, but it's the actual address you're interested in
3efac5c80 : xxxxxxxx

from that point on it's up to you to interpret it as the type you wish. you 'could' interpret it as a pointer itself as you did in the screenshot, but showing it as an integer, or 2 byte, ot whatever type it actually is would be better

As for rescans taking long that it because the results are read from disk. Rescans will take at least the amount of time it took the scan to write them to disk in the first place

Anyhow, next version you can do a rescan before the results are written to disk, greatly reducing diskspace (e.g instead of 100 billion results you only get 1 or 2 million)
Will eat up yet another 2 to 4 GB of RAM depending on the game

2014-10-12 11:28   
(Last edited: 2014-10-12 12:00)
Yes, I can see that they are not pointers, that's why I filed the report.
I have hundreds of gigabytes of these 'calculations'.

From my perspecive, it's a bug because the pointer scan collects a lot of irrelevant data - these calcualtions are not pointers after all.

If possible, I'd like to have these thrown away during the first scan already; I'd think it would reduce number of paths to scan and the number of false results.

Thought I am not sure how CE works internally. If these calculations are really needed, I'd like all these calculations stored separately from the actual results (maybe save them to a different file?), so the results are really pointer results.

Could the cause of the slow rescan be that the pointer files are highly fragmented?
They are on a HDD rather than an SSD and CE wrong 5 of them in parallel (during the scan), so I'm sure they are very fragmented.
There's no way to force writing results to a single file, or, to write different files on different disks, is there?

Dark Byte   
2014-10-12 16:59   
(Last edited: 2014-10-12 17:08)
all results in the pointerfiles are valid pointers. (valid at that time)
A valid pointer is a path that goes from any base address to the address you're looking for.
It doesn't contain any irrelevant data (if any field is missing it's impossible to find the address)
e.g it's stored as:
moduleid+offsetintomodule, offsetcount, offset1, offset2, offset3, offset4
moduleid+offsetintomodule, offsetcount, offset1, offset2, offset3, offset4
moduleid+offsetintomodule, offsetcount, offset1, offset2, offset3, offset4
moduleid+offsetintomodule, offsetcount, offset1, offset2, offset3, offset4

on a 4 offset entry:
baseaddress+offset1 points to a pointer
that pointer+offset2 points to another pointer
that pointer+offset3 points to another pointer
that pointer+offset4 points to the final address

that last offset is required else you wouldn't know where the final address is

As for fragmentation that could be an issue yes. Although the files are written in decent sized chunks at a time (16MB at once) there can still be some overlap at the same time.
Have you tried manually defragmenting the disk before doing a rescan ? (Or just copy the files to another disk)

Anyhow, as I mentioned earlier, if you use next ce's pointerscan properly you will be able to really cut down on the disk access
It involves finding the address, taking a snapshot of the game, restart the game, find the address again and then do a pointerscan with for the new address combined with the snapshot you made earlier

2014-10-12 18:32   
Is that how it was earlier? (the results)
I have not used it for ages so I can't recall.
Dark Byte   
2014-10-12 23:21   
not sure what you mean with that question. Anyhow, it has always been like that yes.
Even compressed pointers files store it like that. It's just that in that case there's less space between offsets. Instead of 32 bits for each offset it now only stores the max amount of bits needed(sz 2047 means 11 bits) and stuffs them together. 4*11=44 bits( =6 bytes rounded) as opposed to 4*32=128 bits (=16 bytes) for every pointer found
2014-10-13 14:29   
(Last edited: 2014-10-13 14:31)
I meant individial results.
Hmmm. I remember differently, buy okay; I'll just accept that my memory has faded over the years.
With that, this report should be closed.

On the second part:
So that's why it does not look compressed... I'll send a PM about this shortly to avoid having to keep this report open.

Issue History
2014-10-11 21:49CsimbiNew Issue
2014-10-11 21:49CsimbiFile Added: CE_PointerScan.png
2014-10-12 01:10Dark ByteNote Added: 0000697
2014-10-12 01:10Dark ByteStatusnew => acknowledged
2014-10-12 01:15Dark ByteNote Edited: 0000697
2014-10-12 11:28CsimbiNote Added: 0000699
2014-10-12 11:59CsimbiNote Edited: 0000699
2014-10-12 11:59CsimbiNote Edited: 0000699
2014-10-12 12:00CsimbiNote Edited: 0000699
2014-10-12 16:59Dark ByteNote Added: 0000701
2014-10-12 17:08Dark ByteNote Edited: 0000701
2014-10-12 18:32CsimbiNote Added: 0000702
2014-10-12 23:21Dark ByteNote Added: 0000703
2014-10-13 14:29CsimbiNote Added: 0000704
2014-10-13 14:31CsimbiNote Edited: 0000704
2014-10-21 14:36Dark ByteStatusacknowledged => resolved
2014-10-21 14:36Dark ByteResolutionopen => no change required
2014-10-21 14:36Dark ByteAssigned To => Dark Byte