64 bit memory range?

[rock5]

Hi, I was trying to write a small program for Minesweeper. I found some addresses using CE but MM couldn't read them. That's when I noticed the addresses for Minesweeper are over 0x100000000. That's 9 characters. Is that because the OS is a 64bit OS and Minesweeper is a 64bit version? Is MM able to read a 9 character long address?

[lisa]

This won't answer any of your questions but I can tell you
32bit
version 6.1 build 7600
starts at 0x50000

--=== still no help ===--
Still not answering your questions but I did notice something.
I have "gaps" in memory for it this time.
stuff in range
50000 - 50fff
then gap (?? ?? ?? ??....)
51000 - 5ffff

stuff in range
60000 - 60fff
then gap (?? ?? ?? ??....)
61000 - 6ffff

stuff in range
70000 - 70fff
then gap (?? ?? ?? ??....)
71000 - 7ffff

I thought it was weird.

--=== And still no help lol ===--

You know how in RoM we always have to add 0x400000 to the addresses found in CE, so "client.exe"+050868B4, the client.exe is always 0x400000 well for minesweeper this isn't the case.
Open up CE and add pointer "minesweeper.exe"+000868B4 with 0x10 0x10 as the offsets (number of flags used). As a pointer it works fine (my version) but the actual "minesweeper.exe" value changes, still not sure how to handle that. One time it was 0xb00000, then next it was 0x220000, next 0x8b0000

[lisa]

Ok this may not help you, still lmao
but I found a static address that has the value of what needs to be added, so the value of "minesweeper.exe"

My version this works.

Code: Select all

local windowList = findWindowList("*", "Minesweeper");
function getWin(character)
	if( __WIN == nil ) then
  		__WIN = windowList[1]
	end

	return __WIN;
end
function getProc()
	if( __PROC == nil or not windowValid(__WIN) ) then
		if( __PROC ) then closeProcess(__PROC) end;
		__PROC = openProcess( findProcessByWindow(getWin()) );
	end

	return __PROC;
end
exevalue = memoryReadUInt(getProc(),0x7706ac10)
flags = memoryReadIntPtr(getProc(), exevalue + 0x868b4 ,{0x10,0x10})
print(flags)

[rock5]

Hm... This is what happens if I use your code.

Code: Select all

WARNING: Failure reading memory from 0x28FA94 at 0x7706ac10 in memoryReadUInt().
 Error code 299 (Only part of a ReadProcessMemory or WriteProcessMemory request
was completed.)
11:50pm - scripts\ms.lua:18: attempt to perform arithmetic on global 'exevalue'
(a nil value)

[lisa]

yeah like anything you would need to use the same game version for it to work.
If you click on "help" drop down menu and then "about minesweeper" it will bring up it's details.

I could probably look at doing an updater and see if it works on your version, would be tricky to test though, guess I could test it on one of my 64bit win 7 machines.

[rock5]

If the problem is because it's 64bit then you probably would have to test on a 64bit machine to get the same results.

About says Version 6.1 (Build 7600) which is the Windows version. There is no separate Minesweeper version.

BTW this is what I was trying when I first realised the problem. As far as I can tell it should work except for the 64 bit memory problem

Code: Select all

local __PROC, __WIN
local mines, tiles, cleared
function getProc()
	if __PROC == nil then
		__PROC = openProcess( findProcessByWindow(__WIN) );
	end

	return __PROC;
end

function main()
	repeat
		__WIN = findWindow("Minesweeper");
		if __WIN > 0 then
			attach(__WIN)
			while windowValid(__WIN) do
				mines = memoryReadIntPtr(getProc(), 0x10006AA38, {0x18,0x8})
				cleared = memoryReadIntPtr(getProc(), 0x10006AA38, {0x18,0x18})
				tiles = memoryReadIntPtr(getProc(), 0x10006AC18, 0x10)
				printf("\r%d  tiles left to click\t\t",tiles-cleared-mines)
				yrest(1000)
			end
			closeProcess(__PROC)
			__WIN = 0
			__PROC = nil
		end
		yrest(5000)
	until false
end
startMacro(main,true);

[lisa]

It might sound silly but try it without the 1

Code: Select all

mines = memoryReadIntPtr(getProc(), 0x06AA38, {0x18,0x8})

It seemed to me from looking at CE that it loops back to the start after FFFFFFFF

BTW I just get

Code: Select all

1:17am - scripts\ms/main.lua:43: attempt to perform arithmetic on upvalue 'tiles' (a nil value)

because of the failed reads. Those pointers are all ?? ?? for me.

These work for me on 32bit

Code: Select all

exevalue = memoryReadUInt(getProc(),0x7706ac10)
flags = memoryReadIntPtr(getProc(),exevalue + 0x868b4,{0x10,0x10})
cleared = memoryReadIntPtr(getProc(),exevalue + 0x868b4,{0x10,0x14})
mines = memoryReadIntPtr(getProc(),exevalue + 0x868b4,{0x10,0x4})
optionmines = memoryReadIntPtr(getProc(),exevalue + 0x868b4,0xD4)
optionheight = memoryReadIntPtr(getProc(),exevalue + 0x868b4,0xD8)
optionwidth = memoryReadIntPtr(getProc(),exevalue + 0x868b4,0xDC)
tiles = memoryReadIntPtr(getProc(),exevalue + 0x87454,0x8)

"optionmines" is the value set to custom for mines, only has any affect on game if it is set to use the custom settings.
Changing the value for any of the "options" in CE changes value in the game, well next game started anyway, again just for custom.
actual window width and height, kind of useless lol

Code: Select all

winwidth = memoryReadIntPtr(getProc(),exevalue + 0x87460,{0x30,0x4})
winheight = memoryReadIntPtr(getProc(),exevalue + 0x87460,{0x30,0x8})

[rock5]

Removing the '1' didn't work. And yes I suspected there would be no problem getting working pointers on a 32bit system. My 64bit CE has no problems showing those 3 pointers so I can use CE to give me the values I want but it's too bulky. I really think it's just MM is not able to read 64bit addresses or it's some sort of protection or file security issue.

[Administrator]

Well, there would be no problem supporting 64-bit addresses with MicroMacro. Lua itself doesn't really support 64-bit integers which would cause a lot of issues.

Now, the high precision timer functions work off of a table of high/low parts that represent a 64-bit int. So, I guess it would be possible to use that on the Lua side to make things work. The problem with that is how do you want to put that in your scripts? You wouldn't just be able to use var = 0x<insert 64 bit hex here> as that hex value couldn't be handled by Lua.


Edit:
Actually, even if we worked out the problems with Lua, since MicroMacro is still a 32-bit application, it wouldn't be able to read from a 64-bit program. This explains why.

[rock5]

Actually, even if we worked out the problems with Lua, since MicroMacro is still a 32-bit application, it wouldn't be able to read from a 64-bit program

I suspected as much when I tried to attach the 32 bit CEs debugger to the program and it wouldn't work.

I may have to look for another solution. Maybe I'll download a 32 bit version of a Minesweeper variant.

[lisa]

This explains why.

Interesting reading, it explains a few things I have noticed when working on a 64bit when next to a 32bit machine =)

[lisa]

Ok at work and having a play with a 64bit system.

static address ox76F1478 has value of FFDB0000, which is the value needed for the "minesweeper.exe" but yeah it seems MM has an issue with using it.
It prints the value fine with

Code: Select all

printf("0x%x",exevalue) 
0xffdb0000

but fails with the reading memory straight away at 0x80000000.
So 32bit only goes to 0x7FFFFFFF (that is what is on CE as max search) which is why MM has issues with using 0xFFDB0000

So yeah all I can do is confirm MM won't handle minesweeper on 64bit.

[rock5]

Tried a few versions of minesweeper. I even found a Windows 7 version which I expected to be a 32 bit version but behaved exactly the same so maybe it was also the 64bit version.

What put me off mos of the versions is they weren't able to be maximised so the boxes were often too small. Finally found one I'm happy with that is totally resizable and I can also get the info I want from memory.
http://download.cnet.com/Ivanche-Minesw ... 37682.html