Jump to content
Sign in to follow this  
cooleko

Workaround for Nomadmemory in Windows 7 x64

Recommended Posts

cooleko

A few months ago I tried compiling scripts on Windows 7 x64 using NomadMemory. Everywhere I looked no one could figure out why _memoryRead() would only return 0s. The best advice that would be given is set debug privileges.

At the time I just continued compiling my scripts on Vista x64 and accepted there wasn't a solution. However, a few months back I shared my code to a few people whom were using Windows 7 x64 and had to figure out why the scripts were not working.

Here is what I found.

Anything typecast as variable1 would immediately convert to 64 bit representation, however, if typecast instead as variable2 would not.

variable1 = "0xVALUE" ;Bad, auto-converts to x64 representation
variable2 = hex("VALUE") ;Good, stays as needed for x32

So i converted every instance of Variable = "0xVALUE" accordingly.

The scripts still were not reading memory, but I was able to isolate the new problem, NomadMemory would return 64 bit representation for every int value. Floats, Bytes, character arrays, etc were working fine (inherently are the same length), but int, uint, etc were not.

The workaround for this was replacing every _MemoryRead() with a function

Func _NewMemRead($Addr1, $Proc1, $type1)
   If $type1 = "int" Then ;I only used int, if you use uint or any other integer representation, add them in here
      Return (Dec(Hex(StringRegExpReplace(_MemoryRead($Addr1, $Proc1, $type1), "00000000", "", 1))))
   Else
      Return _MemoryRead($Addr1, $Proc1, $type1)
   EndIf
EndFunc   ;==>_NewMemRead

Essentially the function would strip the extra 0s because of the conversion to x64, allowing the script to read memory.

I am writing this up many months after the fact, At this time I cannot remember why I had to type cast the result to Hex and then Dec to get it to return the proper integer value. But it is probably the first problem mentioned above about the value being typecast to the wrong format.

I hope this helps anyone out there who is looking for a solution to this problem.

Share this post


Link to post
Share on other sites
Newb

Excellent. Really. I would like to ask you a couple of things.

1)Could you post here fullcode of nomadmemory (or .au3 file) with the updated code for everyone use?

2) Is the "new" nomadmemory code working both for 32bit and 64 or i should use old nomad memory for 32bit and this new one you fixed for 64?

Thanks for the brilliant work ;)


I'm a compulsive poster. When I post something, come to read it at least 5 minutes later after the posting, because I will edit it. I edited even this signature a few minutes later after I wrote it.

Share this post


Link to post
Share on other sites
cooleko

With these changes, the script can be compiled on both x32 and x64 systems with no adverse effects.

I hesitate to release a modified Nomad Memory as there may be unintended side effects for specialized users that want to do more than read memory using specifically Int, float, char[], byte. There are numerous other parameters accepted by nomad memory which I have not looked into, and since I will not be using them I have not considered how this function would be modified (if it even does need to be) to be compatible with all supported parameters. If I had created a function that was complete I would have no problem posting an updated version of Nomad Memory with the adjustment.

By posting this, I only hope to assist other users in understanding that there exists a previously non-disclosed problem with Nomad Memory in Win7 x64 which can be corrected by making a a very simple dummy function which provides the equivalent output that users expected if scripts were compiled in any other setting (Win7 x32, Vista x64 x32).

Share this post


Link to post
Share on other sites
JLogan3o13

@Szmycu you obviously didn't bother to read the forum rules that I pointed you to already. Take the next 24 hours being unable to post on the forum to give you plenty of time to read them. Post this kind of question again and you'll be shown the door.


√-1 2^3 ∑ π, and it was delicious!

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

  • Similar Content

    • msd1994
      By msd1994
      I have a script that just adds some keyboard shortcuts for things like displaying the current song and artist, moving the window to the side so it won't pop up in my way, and play/pause, next song, previous song (these are the only 3 to still work since they don't need the window handle.)
      In some update recently, Spotify's window class swapped from "[CLASS:SpotifyMainWindow]" to "[CLASS:Chrome_WidgetWin_0]". Using the new class in my controls doesn't seem to work, I've tried getting the window handle from the process handle (_GetHwndFromPID($PID)) but that seems to fail as well.
      Does anybody have some idea of a way I could get this script working again?
       
      edit: seems like discord has the same window class name, so could be some issue with this? Still not sure of a way to solve the issue though, I added a function to get the handle of the active window and can just use that now, but it was able to find it on its own before on spotify startup or script startup which would be preferred.
       
      Thanks!
    • RTFC
      By RTFC
      Please answer me these questions three, ere the other side you see:
      Are you running a 64-bit machine with a 64-bit Windows operating system? Can your AutoIt scripts cope with having directive #AutoIt3Wrapper_UseX64=Y, and thus @AutoItX64=True? Are you sick and tired of seeing this error message?
      If you (like me) answered "YES" to all three questions, then the _HighMem library may ease your pain (the name commemorates a useful utility from the days when CPUs were still steam-powered). Forget about pathetic boot switches /3GB and /userva; in a full-fledged 64-bit environment, _HighMem can pre-allocate all available physical/virtual RAM you've got (or any smaller size you need), and manage individual allocations therein with four simple functions:
      _HighMem_StartUp( $nSize, $sUnit="GB" ) ; parse size of total region to pre-allocate, e.g. (10,"GB") _HighMem_Allocate( $nSize, $sUnit="B" ) ; returns $pOffset (new allocation's base address) _HighMem_Release( $pOffset ) ; existing allocations are identified by their offset (base address) _HighMem_CleanUp() ; close handles, release all pre-allocated memory Of course, existing AutoIt limitations remain in force (e.g., DllstructCreate() is still limited to 2 GB per call), but the maximum of 2-4 GB of virtual memory per Windows process can (under the right circumstances, in the proper environment) be circumvented. However, this is the first beta release, so glitches are likely, and performance may vary. In fact, it may not work at all for you (if you're running 32-bit, for example). And since this involves your own hardware, it's unlikely I would be able to reproduce your issues in my own work environment. Nevertheless, if you find obvious bugs or mistakes in the code, please do post. And if it works for you, that's also good to hear. My own motivation for developing it was to supercharge my matrix computing environment (Eigen4AutoIt), so it can handle matrices of any size that fit in machine RAM.
      The attached zip contains the library itself (HighMem.au3) and two test examples. HighMem_Test1 performs a dry run stress test of the allocation management system; it does not actually do any memory I/O. By contrast, HighMem_Test2 pre-allocates a 6 GB space, stores 3 x 2GB structs there, performs some basic I/O, and releases the allocations one by one. Obviously, for this to work you'll need at least that much free RAM to begin with (check with Task Manager -> Performance -> Memory if you're unsure). My own test environment has 16 GB of physical RAM, and runs W10Pro/64.
      EDIT: minor edits added to improve user experience (many more status messages if $_HighMem_Verbose=True)
      HighMem.v0.85.7z
      EDIT: from beta version 0.9, HighMem supports shared memory, including mutex negotiation.
       
      HighMem.v0.91.7z
    • TrashBoat
      By TrashBoat
       
      This got closed and im trying to figure out why isint this one closed too:
      I didint want to "hack" or "automate" a game all i wanted to do is learn memory reading and i needed help so i ask again
       
    • steveeye
      By steveeye
      hey, can anybody enlighten on lesser known Windows hacks or uses ?
    • iXX
      By iXX
      Hi!
      Looking for working code to  get full path of process  - both 32 & 64 bit.
      I tryed this bellow, but it works only for 32-bit processes, even if compiled for x64...
      Thanx for suggestions!
       
      Func _ProcessGetPath($vProcess) ;get the program path done by MrCreatoR Local $iPID = ProcessExists($vProcess) If NOT $iPID Then Return SetError(1, 0, -1) Local $aProc = DllCall('kernel32.dll', 'hwnd', 'OpenProcess', 'int', BitOR(0x0400, 0x0010), 'int', 0, 'int', $iPID) If NOT IsArray($aProc) OR NOT $aProc[0] Then Return SetError(2, 0, -1) Local $vStruct = DllStructCreate('int[1024]') Local $hPsapi_Dll = DllOpen('Psapi.dll') If $hPsapi_Dll = -1 Then $hPsapi_Dll = DllOpen(@SystemDir & '\Psapi.dll') If $hPsapi_Dll = -1 Then $hPsapi_Dll = DllOpen(@WindowsDir & '\Psapi.dll') If $hPsapi_Dll = -1 Then Return SetError(3, 0, '') DllCall($hPsapi_Dll, 'int', 'EnumProcessModules', _ 'hwnd', $aProc[0], _ 'ptr', DllStructGetPtr($vStruct), _ 'int', DllStructGetSize($vStruct), _ 'int_ptr', 0) Local $aRet = DllCall($hPsapi_Dll, 'int', 'GetModuleFileNameEx', _ 'hwnd', $aProc[0], _ 'int', DllStructGetData($vStruct, 1), _ 'str', '', _ 'int', 2048) DllClose($hPsapi_Dll) If NOT IsArray($aRet) OR StringLen($aRet[3]) = 0 Then Return SetError(4, 0, '') Return $aRet[3] EndFunc  
×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.