13 replies to this topic

[Ancient Dragon]

It doesn't work because c++ standards say that isn't legal. references are for variables, not addresses. In 32 or 64 bit programs you, the programmer, have no control over where a variable is stored in memory.

[Alexander]

One of the reasons why kernels were designed for in the first place were for memory management. Look at Java's objective, one of the reasons of its liking for programmers is automatic memory management.

It would be a violation for a programming language to do so, more or less:
Memory barrier - Wikipedia, the free encyclopedia

[l@mbd@]

the vmaddr can be hooked, it's one of the common techniques for employing DLL injection, for good or ill purposes.

[julmuri]

Maybe something like:

int main( int argc, char* argv[] )
{
    unsigned int  address = 0x00400100;
    unsigned long protect = 0;

    //
    // make sure we have permission to read && write
    int result = VirtualProtect( reinterpret_cast<void*>( address), sizeof(int), PAGE_EXECUTE_READWRITE, &protect );
    if ( 0 == result )
        return 0;

    //
    // some fugly casting
    int& data = *reinterpret_cast<int*>( address );

    std::cout << data;

    //
    // restore orginal permissions
    result = VirtualProtect( reinterpret_cast<void*>( address), sizeof(int), protect, &protect );
    if ( 0 == result )
        return 0;

    return 0;
}

}

Always some ugly casting but I think it works.
If you are on linux you can use mprotect instead of virtualprotect.

[Ancient Dragon]

If I add an error message then most of the time VirtualProtect() fails most likely because that specific address may or may not be in actual memory. I'm using 64-bit Windows 7 with VC++ 2010 Express

    int result = VirtualProtect( reinterpret_cast<void*>( address), sizeof(int), PAGE_EXECUTE_READWRITE, &protect );

    if ( 0 == result )

    {

        cout << "VirtualProtect() failed\n";

        return 0;

    }

[julmuri]

Ancient Dragon said:

If I add an error message then most of the time VirtualProtect() fails most likely because that specific address may or may not be in actual memory. I'm using 64-bit Windows 7 with VC++ 2010 Express

Hows that relevant ?
I would think that if you wanted to read something from memory, you would know the correct address.
Also what do you mean by 'most likely', getlasterror / formatmessage and stop speculating. (:

[Ancient Dragon]

You are right. The message is "Attempt to access invalid address.", which is what I suspected was the problem.

>>Hows that relevant

Physical addresses can not be hard code in programs, which is the OPs intent.

[julmuri]

Ancient Dragon said:

Physical addresses can not be hard code in programs, which is the OPs intent.

Virtual addresses can be, unless the data is dynamically allocated in random order.
Wich you can also work around.

[WingedPanther]

Most GUI libraries are going to call library functions provided by the environment. wxWidgets, for example, simply provides standard wrappers for the Windows/OS X/GTK/whatever widgets. Eventually, you are making calls to device drivers, based on their standard interfaces. I would not expect to use hard-coded memory addresses outside of a device driver or OS kernel.

[Firebird_38]

Windows loads an exe in memory at some random location that it finds suitable. It then reads from the exe header (the first part of a file is called a header) where the program should start running. It then jumps to the start. The program gets memory using the windows apis, to which it gets access by imports defined in the exe. Windows does a "fixup" of the he exe between loading and starting. The exe thus can call finctions in dlls, such as kernel32.dll, user32.dll, etc. So, it's windows that "tells" the program, at startup, what addresses to direct calls to. These "imports" are mentioned by name or number in the exe file.

Programs can also dynamically load libraries (dlls), and after loading they ask windows what the address of a certain function they need is. They can then call that function. Dynamic loading is mainly employed when at compile-time (when the program is made) it is not known what libraries need to be loaded. Think of plugins. They plugin may not exist when the program is made, but it can later be added and the program can load it, find out how to call it (ask windows) and then call its functions.

What addresses actually get used by a program is dependent on many components:

• Windows loads exes at an address of its choosing, but it always tries a set address (specified in the header) because it saves on loading time and also on memory when multiple copies are loaded. This is complex stuff you don't need to know to make or use programs.
  
• Windows loads dlls where it sees fit
  
• The compiler decides where in the data segment variables get allocated, usually in order of declaration, but it may decide on whatever it "feels" like.
  
• Memory gets allocated by 99.9% of subsystems of programs from "the heap", a system that allows requests for memory, and allows the memory to be returned to the system. (allocated and freed)
  
• Windows allows programs to allocate chunks of memory in chunks called "pages" usually 16k in size I believe with which the program or subsystem can use to do whatver, including implementing a proprietary memory management system (it's own heap system).
  
• The processor stack (a bunch of memory used like a stack of papers, last on = first off) is used extensively to store return addresses of functions calls and local variables of functions.

SInce compilers knows what memory it assigns to what variable, and it knows how to "tell windows" (though the exe header) what its needs are, you simple use a variable name and the compiler resolves this to an address in the data segment (statics), on the stack (locals) or on the heap (with pointers, the new operater, malloc, etc). When using pointers, you are responsible for allocating and freeing this memory, but you have no, or very little, control over where in the PC this gets stored. You do not ever require to know where something's at, unless you want to get really exotic, or you're writing device drivers for legacy hardware. I assume this isn't what you're doing.

In short, when you write a program, you don't need to know what the specific address of a certain item is ahead of time. You normally cannot know. But your program can find out at runtime. Usually it's enough to use variable names, poiners (with malloc, etc) and contructors.

A "reference" can be obtained by asking whatever created the object, item, variable or whatever for a reference. When you created it yourself, you should get a reference returned by whatever you used to create it.

In many cases (especially windows api!) you do not get a memory ref at all, you get a handle instead. That's just a unique number that you use to refer to the object. This could be a file, for instance. When you open a file, you get a handle back. You then pass this handle when you, for instance, want to read from that file, or when you're ready to close it.

So, that's the background, and also, why you don't need the background.

The whole pint of a high level language is to isolate the programmer from such things as obtaining addresses and other obscure things that make it easy to crash your system.

To have some fun, make a simple exe and debug the processor state (step through it). You can see exactly what the processor sees when it's running your program. But you can't make heads or tails of it, because your processor understands this stuff a lot better than you do, and so, btw, does your compiler.

Good luck.