Jump to content

Memory Reading with 64bit OS


Recommended Posts

hello folks,

I have been working on a WoW Bot lately and after almost everything was done I hit a little problem:

It seems that all MemoryReading Functions posted on this forum(e.g. by w0uter or Nomad) only work for 32bit Windows Versions.

MicroSoft said:

Differences between 32-bit and 64-bit Windows

The major differentiator between 32-bit and 64-bit Windows is in memory support. Currently, 32-bit Windows is capable of supporting up to 4 GB of system memory, with up to 2 GB of dedicated memory per process. Windows XP 64-Bit Edition will currently support up to 16 GB of RAM, with the potential to support up to 16 TB of virtual memory as hardware capabilities and memory sizes grow.

Customers will find some feature differences, but overall, 64-bit Windows includes a majority of the features that are included in 32-bit Windows.

Well those little feature differences are exactly the ones that hurt me...

Back to my problem: I believe that the problem lies within the DllCall() However i just cant find any infos on the web about kernel32.dll and its functions.

The following Code is taken from Nomad's Memory UDF. The Red Line is the one that I think needs to be changed:

Func _MemoryRead($iv_Address, $ah_Handle, $sv_Type = 'dword')
    
    If Not IsArray($ah_Handle) Then
        SetError(1)
        Return 0
    EndIf
    
    Local $v_Buffer = DllStructCreate($sv_Type)
    
    If @Error Then
        SetError(@Error + 1)
        Return 0
    EndIf

    DllCall($ah_Handle[0], 'int', 'ReadProcessMemory', 'int', $ah_Handle[1], 'int', $iv_Address, 'ptr', DllStructGetPtr($v_Buffer), 'int', DllStructGetSize($v_Buffer), 'int', '')
    
    If Not @Error Then
        Local $v_Value = DllStructGetData($v_Buffer, 1)
        Return $v_Value
    Else
        SetError(6)
        Return 0
    EndIf
    
EndFuncoÝ÷ Ú)ߢƢëfÊÇ­ºZ)Ý£?®Ñ®f§ëhÙZµë-mëZâm4îËZnWyÍ´Ó¢¦Þr&­{*.®¥¦÷«Êk©*ÿØ­ ©ç¢Û¬yÊ%¢¸§jëhÛZËazX§z)j{b±«­¢+Ù±±
±° ÀÌØí¡}!¹±lÁt°Ìäí¥¹ÐÌäì°ÌäíIAɽÍÍ5µ½ÉäÌäì°Ìäí¥¹ÐÌäì°ÀÌØí¡}!¹±lÅt°Ìäí¥¹ÐÌäì°ÀÌØí¥Ù}ÉÍÌ°ÌäíÁÑÈÌäì°±±MÑÉÕÑÑAÑÈ ÀÌØíÙ} ÕȤ°Ìäí¥¹ÐÌäì°±±MÑÉÕÑÑM¥é ÀÌØíÙ}    ÕȤ°Ìäí¥¹ÐÌäì°ÌäìÌäì¤

/Edit2:

If anyone could provide a list of the functions of kernel32.dll I would be very thankful

Edited by Zephir
Link to comment
Share on other sites

mhh okay that is what i figured,

MicroSoft said that users had to work their way around it, however did not say how.

I am sure CheatEngine works with kernel32.dll as well (for MemoryReading and Writing) and since CheatEngine can access all apps on my pc w/o problems, there should be a way to perform a dllcall so that autoit could read memory as well. Or am i thinking wrong?

P.S.

I checked NomadMemory.au3 again and did some debugging on it. I found out that (within the _MemoryRead func) the DLLStructCreate() statement always returns 0. Thus the next operator cannot work properly since the buffer is not created correctly...

Link to comment
Share on other sites

mhh okay that is what i figured,

MicroSoft said that users had to work their way around it, however did not say how.

I am sure CheatEngine works with kernel32.dll as well (for MemoryReading and Writing) and since CheatEngine can access all apps on my pc w/o problems, there should be a way to perform a dllcall so that autoit could read memory as well. Or am i thinking wrong?

P.S.

I checked NomadMemory.au3 again and did some debugging on it. I found out that (within the _MemoryRead func) the DLLStructCreate() statement always returns 0. Thus the next operator cannot work properly since the buffer is not created correctly...

CheatEngine run in Kernel mode and Autoit run in user mode. See the difference?
Link to comment
Share on other sites

32bit apps can't access the memory of 64bit apps.

Well i don't believe that World of Warcraft is a 64Bit app. The memory scan worked fine with other users of this forum. I use the same Script as they did and mine does not return what it is supposed to.

I made many of my friends test the script as well and it did not work. We live in Germany. The "other" users on this forum who used the script were all from USA/England. is it possible that its a matter of language? maybe the kernel32.dll api is different on german os than on english ones? that would be stupid though...

what do you think?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...