MantisBT - Cheat Engine
View Issue Details
0000406Cheat Enginepublic2015-09-10 22:412015-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

Notes
(0000859)
mgr_inz_Player   
2015-09-11 16:22   
(Last edited: 2015-09-11 16:27)
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   
2015-09-14 12:51   
Oh, that's pretty handy, thank you.

Issue History
2015-09-10 22:41magusmarisaNew Issue
2015-09-11 16:22mgr_inz_PlayerNote Added: 0000859
2015-09-11 16:27mgr_inz_PlayerNote Edited: 0000859bug_revision_view_page.php?bugnote_id=859#r108
2015-09-14 12:51magusmarisaNote Added: 0000860
2015-09-17 00:01Dark ByteStatusnew => resolved
2015-09-17 00:01Dark ByteResolutionopen => fixed
2015-09-17 00:01Dark ByteAssigned To => Dark Byte
2016-06-05 15:18JptnucIssue cloned: 0000483