News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

trying to load a constant address into a pointer

Started by hunt, March 11, 2008, 12:50:59 AM

Previous topic - Next topic

hunt

Dear All,

I am new to start MASM and need a hand.

I am trying to load an address like 12FF00h into a pointer but do not know how and fail to find any helpful info from the web,

My program in C with __asm:
void * p;
__asm  mov p,    [12FF00h]    ; fail p == 12FF00h  => the same as =>  MOV p, 12FF00h, p did not point to the content of 12FF00h as I want


I have also tried with
__asm  mov eax,  [12FF00h]   ; or   __asm  mov eax  12FF00h
__asm  mov p, eax                ; the result is still the same


Thanks in advance for any tips,  :(

Hunt


hutch--

Providing that it is a valid address, load it into a register THEN dereference it to get the value AT that address.


mov eax, 12345678h  ; load the absolute address
mov eax, [eax]          ; get the value AT that address

Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

hunt

Dear All,

I finally wearing out a solution,

void *p;
__asm {
    mov  eax,  12FF00h
    mov  eax,  [eax]
    mov  p,     [eax]
    }


However, anyone can share a different idea or a better solution would still be appreciated,

Hunt

hunt

Oh Hutch,

Thank you very much, I did not see your answer before my own.
Appreciate and regards,

Hunt

MichaelW

12FF00h is an address on the stack, perhaps used in setting up a buffer overflow attack?
eschew obfuscation

zooba

Loading an arbitrary address makes no logical sense, even for creating a buffer overflow attack. The closest thing to your suggestion that will actually work is to get the address of a static/global variable. The address will be constant (ie. not based on any registers at the time of loading the address) but is guaranteed to be valid.

I cannot think of a single application where you would need to do this - including when writing an operating system or low level drivers. (If you want to test access violation exceptions then it could be handy, but that's it.) Maybe you could give a more detailed idea of what you are attempting to do - there is a better way  :green2

Cheers,

Zooba :U

MichaelW

AFAIK altering the stack can provide an indirect method of getting a value into a register.
eschew obfuscation

hunt

Dear Sirs,

MichaelW & zooba thanks for your response.  You guys are really remarkable, I just made an example about where I am pointing then you know it is in the stack.  Actually the address 12FF00h is just an expamle and my target is 12FF5Ch.

Why I need to access this memory it point at is because I am learning asm, so I made a target for myself to discover the rootkit and some of its behavior just for fun.

By the way, do you know how can I get the absolute address of the SS segment like SS:[0h] via program?  
And why we can do this
   mov  ebp,  esp
but we can not do this
   mov  eax, dword ptr SS:[0h]      or     mov  eax, SS:[0h]    ; ?? Access violation reading location 0x...

Thanks anyway,
Hunt

Rockoon

Quote from: zooba on March 11, 2008, 01:12:39 PM
Loading an arbitrary address makes no logical sense

??

Quote from: zooba on March 11, 2008, 01:12:39 PM
I cannot think of a single application where you would need to do this

The performance quality of code generated at runtime could benefit from this sort of technique.

Could be quite usefull in register limitted DSP and software rendering techniques, where each register reserved for a pointer could mean requiring an additional read-modify-write in an inner loop. Some algorithm implementations even go so far as to free up ESP for general computational use.

sigh..

Quote from: zooba on March 11, 2008, 01:12:39 PM
there is a better way  :green2

Within a particular scale of algorithmic consideration there sometimes isnt a better strategy than the one you've narrowed things down to. TANSTATFC only applies when you can be flexible about what scale your algorithm tackles. I do agree that the OP doesn't seem concerned with algorithms that would benefit from the methodology he is considering.... but lets not assume facts that arent in evidence.

When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.

redskull

I was never a huge inline assembly guy, but wouldn't

mov p, [12FF00h]

give an error, because technically the compiler would be trying to do a memory/memory move?  Or does the compiler automatically work around it?

-ac
Strange women, lying in ponds, distributing swords, is no basis for a system of government

Rockoon

Quote from: redskull on March 12, 2008, 01:18:04 AM
I was never a huge inline assembly guy, but wouldn't

mov p, [12FF00h]

give an error, because technically the compiler would be trying to do a memory/memory move?  Or does the compiler automatically work around it?

-ac


thats exactly why

mov eax, [12ff00h] should work

(assuming the process can read that memory location, and that the compiler understands this hex notation)

When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.

zooba

Quote from: Rockoon on March 12, 2008, 01:04:30 AM
Quote from: zooba on March 11, 2008, 01:12:39 PM
Loading an arbitrary address makes no logical sense

??

Arbitrary in the sense that the value is not calculated from another value or retrieved from a source such as a register or the operating system. Hardcoding '12FF00h' is not the same as loading from ESP.

Quote from: Rockoon on March 12, 2008, 01:04:30 AM
The performance quality of code generated at runtime could benefit from this sort of technique.

Could be quite usefull in register limitted DSP and software rendering techniques, where each register reserved for a pointer could mean requiring an additional read-modify-write in an inner loop. Some algorithm implementations even go so far as to free up ESP for general computational use.

Good example. I never thought of something like this. It's not really an arbitrary address though, since presumably you would calculate it while generating the code, so I stand by my assertion that hardcoding a pointer is not useful.

Cheers,

Zooba :U

Rockoon

Quote from: zooba on March 12, 2008, 07:50:13 AM
Good example. I never thought of something like this. It's not really an arbitrary address though, since presumably you would calculate it while generating the code, so I stand by my assertion that hardcoding a pointer is not useful.

His address isn't arbitrary. His address is highly specific.

I think you are a little bit inexperienced here because you aren't realizing the obvious cases where a programmer has full knowledge of pointer values at compile time.

Two simple examples include

(A) a DLL can be loaded at a specific base address (perhaps only containing data and a stub)
(B) accessing your Thread Information Block (TIB), which includes (among others):

    FS:[0]  <-- top of the exception handler stack
    FS:[4]  <-- pointer to the bottom (start) of your stack is here
    FS:[8]  <-- pointer to the top of your stack is here (not the value in ESP, but the real allocation watermark)
    FS:[24] <-- DS:[] relative pointer to this structure
    FS:[32] <-- Your process ID
    FS:[36] <-- Your thread ID

When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.

hutch--

This is the factor that stays with me after discussing the thread with a few otther people.

Quote
Why I need to access this memory it point at is because I am learning asm, so I made a target for myself to discover the rootkit and some of its behavior just for fun.

Stack exploits are well known, the OS vendor has taken steps to prevent them with DEP and to this extent, thee appears to be no useful application for such code except for a stack exploit. On that basis I am closing the thread as a violation of the forum rules.

If the author has a good reason, not just some vacuous notion of "just for fun" then we will hear it and evaluate it but at the moment this thread is finished.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php