2017-12-11 07:09 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000406Cheat Enginepublic2015-09-17 00:01
Reportermagusmarisa 
Assigned ToDark Byte 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
Platformx86_64OSWindowsOS Version8.1
Summary0000406: Dereferencing 64-bit pointers in memory viewer and auto assembler fails
DescriptionWhile the former has been happening before I moved from 7, the latter started after the move to 8.1. I can use absolute addresses perfectly, but trying to dereference pointers just results in a "This is not a valid address" on the memory viewer and a "This address specifier is not valid" in the auto assembler.
Steps To ReproduceI'll be using Dark Souls II SotFS as an example because I really haven't done CE work for any other 64-bit game.

Let's say for example, going into the memory viewer and setting the address to "DarkSoulsII.exe"+160B8D0, the pointer to the player heap practically everyone knows by heart. It works fine, so does manually typing the address it holds, but trying to use ["DarkSoulsII.exe"+160B8D0] instead just results in the "This is not a valid address".

In the case of the auto assembler, the issue arises when I register a symbol... let's say for example "passert", in one script then set its value to an address. If in another script I try to use "[passert]:" to inject code there, the assembler shouts "This address specifier is not valid". But using the actual "DarkSoulsII.exe"+whatever address works fine. I know this sounds convoluted, but I have my reasons for it (it's faster to replace one address than dozens of instances of it when an update hits the game).
Additional InformationTable entries that use pointers themselves work perfectly with 64-bit programs.

The auto assembler issue is limited only to labels, dereferencing in instructions like mov is perfectly fine, likely because the size of the pointer is perfectly known in that situation.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000859

mgr_inz_Player (reporter)

Last edited: 2015-09-11 16:27

View 2 revisions

Yes. It is a bug in symbolhandler.pas in TSymhandler.GetAddressFromPointer,
In all CE6.0 - CE6.4 versions.

It was fixed in the SVN:
https://code.google.com/p/cheat-engine/source/detail?r=2845



And here is Lua script I created to fix this issue in CE6.4:
#############################################################
#############################################################
#############################################################
[ENABLE]
{$lua}
fix64bitPointerString = [[

// only for 64bit CE6.4 from 26 VI 2014

define(address1,cheatengine-x86_64.exe+957AC)
define(bytes1,89 45 C0 EB 2B)
define(address2,cheatengine-x86_64.exe+95944)
define(bytes2,8B 45 C0 48 89 45 A8)

alloc(newmem,64,cheatengine-x86_64.exe)
label(part2)
label(return2)

assert(address1,bytes1)
assert(address2,bytes2)


newmem:
  mov [rbp-40],rax
  jmp cheatengine-x86_64.exe+957DC

part2:
  mov rax,[rbp-40]
  mov [rbp-58],rax
  jmp return2

address1:
  jmp newmem

address2:
  jmp part2
  nop
  nop
return2:
]]

autoAssemble(fix64bitPointerString,true)
-- it is safe to execute it many times because of 'assert' instruction
{$asm}


//place your code here

[DISABLE]




#############################################################
#############################################################
#############################################################

~0000860

magusmarisa (reporter)

Oh, that's pretty handy, thank you.
+Notes

-Issue History
Date Modified Username Field Change
2015-09-10 22:41 magusmarisa New Issue
2015-09-11 16:22 mgr_inz_Player Note Added: 0000859
2015-09-11 16:27 mgr_inz_Player Note Edited: 0000859 View Revisions
2015-09-14 12:51 magusmarisa Note Added: 0000860
2015-09-17 00:01 Dark Byte Status new => resolved
2015-09-17 00:01 Dark Byte Resolution open => fixed
2015-09-17 00:01 Dark Byte Assigned To => Dark Byte
2016-06-05 15:18 Jptnuc Issue cloned: 0000483
+Issue History