Cheat Engine

Zanzer

I was attempting to build a custom type and the 64-bit code suggested RCX holds the address containing the value.
However, this address is not the game's address containing the value.

Is the actual game address accessible from within the conversion routines?

For example, if I defined ConvertRoutine as below, I would expect address 7FEFDA21000 to display the value 7FEFDA21000 using this type.

mgr.inz.Player · Posted: Fri May 01, 2015 3:43 am Post subject:

Nope. Because memoryscanner unit is designed to work on copies, and copies of copies (compare to first scan results/compare to last scan results).

Also MemoryRecord unit works on copies (buf variable):

Dark Byte · Posted: Fri May 01, 2015 4:19 am Post subject:

the TCheckroutine in memscan would then also need to be changed, and for every check, wheter it's a valid found result or not, the address needs to be calculated, which will slow down the scan.
so not sure if an address based custom type is worth it to slow down the normal scans, or fragment the scanner's design even more (there is already seperate handling of multiaob's and the all type)

Zanzer · Posted: Fri May 01, 2015 11:26 am Post subject:

Sorry, I haven't glanced at the source code, but it wouldn't be as simple as sending the address by value as an additional argument?

All of the functions could simply ignore it and continue using their local copies of the value.

But then if the address is ever needed, we could get it from the stack.

pseudo code:
local value = readInteger(address)
compareResult(value, address)

The only reason this has come up is because of GTA5's encryption logic.
They XOR every address' value with the address itself.
So if I could add a custom type which does the same, I could more easily find the values.

mgr.inz.Player · Posted: Fri May 01, 2015 6:39 pm Post subject:

I changed CustomTypeHandler and MemoryRecordUnit units.
(and it is still backward compatible for older custom AA scripts)

Results:

I'm still editing memscan unit.... can take a while.

EDIT:

Patch:
https://github.com/mgrinzPlayer/cheat-engine/commit/ee33e74cfb93e96b615fcf51592d57663fab55a0
CustomTypeHandler, MemoryRecordUnit, byteinterpreter, memscan

Info:
Real address value passed to convert routines.

in ConvertRoutine routine, I appended realAddress just after "structure/chunk/RAWDataCopy"
depends on currently used ByteSize.

in ConvertBackRoutine routine, realAddress is inside [EBP+10] or R8

Dark Byte · Posted: Fri May 01, 2015 7:14 pm Post subject:

why not use r8=realaddress for convertroutine ?

(you forgot the all type loop)

And try not to put any extra IF statements inside "while (ptruint(p)<=lastmem) do" loops. See the first scan example for vtByteArrays and vtAll scan, instead of putting the if statement inside it, put it outside of it

mgr.inz.Player · Posted: Fri May 01, 2015 7:26 pm Post subject:

I wanted to save original "real address" for some checkroutines (compare to previous or saved).

I forgot to add a note:

Dark Byte · Posted: Fri May 01, 2015 7:30 pm Post subject:

mgr.inz.Player · Posted: Fri May 01, 2015 8:01 pm Post subject:

I agree.

For now, the changes I made are just for "proof of concept".

I know that scans for customtype with UsesRealAddress will take about 105% more of time (another copyMemory).
And scans for non-customtype will be slightly slower because of those extra IFs...

Zanzer · Posted: Fri May 01, 2015 9:06 pm Post subject:

Throwing out some random ideas. No experience with Pascal or CE's source, so forgive me. Smile

1. Would it be a monumental change or cause a performance hit to pass the input by reference instead?
procedure TCustomType.ConvertToData(input: pointer; output: pointer); or
procedure TCustomType.ConvertToData(input: ptruint; output: pointer);
Or if useRealAddress is enabled, then to use this third, new conversion routine instead?
So as to not affect standard custom searches.
This way you are interacting directly with game memory.

2. In your current approach, to not affect other custom searches, you could:

Dark Byte · Posted: Fri May 01, 2015 9:26 pm Post subject:

1: cheat engine has no direct access to the game's memory. Only copies it inspects locally. So when ConvertToData(input, output) input and output are CE's addresses, not the game's
And sure, I could let the custom type do the ReadProcessMemory call,for every single address, but that would just be too slow

2: I did, but it just looks so cluttery

3: p holds the address of the current copy
CE allocates a block of up to 512KB (depending on the settings) copies a chunk of the game's memory into there
sets P to the start of the copy, and lastmem to the end of the copy
and then goes through the loop which will check every bytes or 4 bytes (fastscan) if the value matches what was being looked for
To calculate the actual address ce needs to get the base address of the copy, the original address and p, then add the difference of p and the copy to the actual address
Doing that for every address, including the ones that don't have a matching value, is a small amount of wasted cpu cycles, but for a 2GB game that would be :(2147483648-found results) * number of wasted cpu cycles

anyhow, I just implemented something of my own.
I added a new calling convention you can activate with

Zanzer · Posted: Fri May 01, 2015 11:51 pm Post subject:

1. checkroutine doesn't need to be sent currentAddress?
2. Should you be adding base again to AddressFound?

Dark Byte · Posted: Sat May 02, 2015 3:59 am Post subject:

1: no, the TCheckRoitine methodcall does not need an address, else it would have to be applied to other types as well.
In this case the tscanner. currentaddress var is a type specific addition for vtCustom which the CheckRoutine implementation for custom scan uses to figure out the address

2: that is a bug yes (not a big one as it only takes effect in lua scripts that use the vtCustom type specifically in a custom memory scan, and use the only one result option, which is most of the time useless for integer types)

mgr.inz.Player · Posted: Sat May 02, 2015 5:35 pm Post subject:

OK. I deleted my realAddressForCustomType branch... There's no point in keeping it.

"ret" instead of "ret 4" in 32bit ConvertRoutine
ConvertBackRoutine also different: RDX==>R8, [ebp+c]==>[ebp+10], "ret 8"==>"ret"

Recent changes, CE is no longer backward compatible with my collection of CustomType scripts.

Also typo here:

Dark Byte · Posted: Sat May 02, 2015 6:17 pm Post subject:

if you set CALLMETHOD to 0 (or don't define it at all) it should be fully compatible with the old custom types (and old custom types don't have that defined)
but yes, new scripts developed for 6.5 won't work for 6.4(unless made for 6.4 specifically), which isn't anything that new (same goes for lua, new lua functions won't work on 6.4)