Local variables not on the stack

[dedndave]

good to know, Dave
fortunately, i try to keep branch labels unique so i can search and/or replace without mishaps

[bf2]

My point is that there is no protection for "variables" per say.  The protection level of a segment has nothing to do with the scope of symbols in the source, which is the what the OP seems keen on.  If you can read/write it from one place, you can read/write it from any other place (or vice-versa).

You are absolutely correct. I have tested my code after sorting out the little niggle of the missing hex radix ( :red), and now each procedure, while being in separate modules, can access and modify the other's 'private' variable.

Main program:

Code Select Expand

MyProc PROTO

.DATA
num DD 10

.CODE
start:

ADD DWORD PTR DS:[403010h], 10 ; num2 is private to the procedure and is loaded at 403010h

CALL MyProc

INVOKE ExitProcess, NULL
END start

Procedure:

Code Select Expand


.DATA
num2 DD 32

.CODE
MyProc PROC

ADD DWORD PTR DS:[403000h], 11 ; num is private to the main program and is loaded at 403000h

RET

MyProc ENDP
END



I have checked in the debugger that each can now modify the other's variable. So the 'privacy' is entirely artificial and enforced only at the assembler/compiler level.

[bf2]

My next objective is to see if I can make this scheme portable. This works on XP but will not work on Vista or 7 - because of ASLR.

I'll see if there is a way to access a memory location n bytes from the beginning of the data segment.

[redskull]

My next objective is to see if I can make this scheme portable.

If only there were some magical tool that could manage the locations of data in memory, and automatically replace references of names with their addressess as they become available...  :wink

[bf2]

My next objective is to see if I can make this scheme portable.

If only there were some magical tool that could manage the locations of data in memory, and automatically replace references of names with their addressess as they become available...  :wink

No, it is possible. This way:

Main program:

Code Select Expand


INCLUDE \masm32\include\masm32rt.inc

MyProc PROTO

.DATA
num1 DD 10

.CODE
start:

MOV EAX, OFFSET num1
ADD EAX, 10h ; Go forward 10h bytes from num1 and you get num2
ADD DWORD PTR [EAX], 10

CALL MyProc

INVOKE ExitProcess, NULL
END start


Procedure:

Code Select Expand


INCLUDE \masm32\include\masm32rt.inc

.DATA
num2 DD 32

.CODE
MyProc PROC

MOV EBX, OFFSET num2
SUB EBX, 10h ; Go backwards 10h bytes from num2 and you get num1
ADD DWORD PTR [EBX], 11

RET

MyProc ENDP
END



[qWord]

ASLR does not have much effects to you application - it only randomize the base address of the modules, the heap and the stack, thus there are no 'static addresses' that could be used for manipulation or execution.
You can suppress or activate randomization of your modules base address while linking (/fixed:no)

[clive]

If only there were some magical tool that could manage the locations of data in memory, and automatically replace references of names with their addressess as they become available...  :wink

It was so much easier punching chads out of cards, or toggling switches. Who needs assemblers, linkers and loaders. You heretic, lets put you in the duck pond and see if you float, or at least weigh the same!!

[dedndave]

never cared much for punch-cards
back then, the "address" of a line of code was "which shoe-box is it in"

Monty was fun, though   :bg