I had a need of a quick unique ID in one of my classes to differenciate one process from another. I decided to use the address of the instance to do so. I ended up with something like this (quintptr is a Qt defined type of integer to store addresses with the correct size, according to the platform):
Foo::Foo()
: _id(reinterpret_cast<quintptr>(this))
{
...
}
The idea is to compare the output of two different processes of the same exe. On Vista (my dev machine) there's no problem. But on XP, the value of _id is the same (!) in the two processes.
Can anyone explain why is that? and if it's a good idea to use pointers like that (I thought so, I'm not so sure anymore)?
Thanks.
Every process gets its own address space. On XP, they're all the same. Therefore it's very common to see what you saw: two objects that have the same address, but in two different address spaces.
It turns out that this contributes to security risks. Attackers were able to guess where vulnerable objects would be in memory, and exploit those. Vista randomizes address spaces (ASLR) which means that two processes are far more likely to put the same object at different addresses.
For your case, using pointers like that is not a smart idea. Just use the process ID
The reason is each process has its own address space and if two processes do the same they just use the same virtual addresses - maybe even heap allocations will be done at same virtual addresses.
You could call GetCurrentProcessId() once and store the result somewhere so that further retrieval is very fast. The process id persists and is unique for the lifetime of the process.
Each process gets its own address space. Unless something like ASLR kicks in, the memory layouts of two processes stemming from the same executable are likely to be very similar, if not identical.
So your idea is not a good one. Using the process ID sounds like a saner approach here, but keep in mind that those can be recycled too.
Related
I'm trying to make a program that can read some information from another process. I use Cheat Engine to find the memory address of whatever I'm looking for and ReadProcessMemory in c++ to get the value.
So far so good. Here is my problem: The process I'm trying to get the information from can have multiples windows open at the same time. I will take notepad++ as an example. With notepad++, I can open as many .txt files as I want. Each of these files' content will have their own memory address. So what I think I need is a memory address with every pointer to every files content as value
Example:
Address A = Value 1
Address B = Value 2
Address C = Value 3
etc... for all files opened
I would need to find a static address with the value: (address A, address B, address C, etc...).
I don't even know how to look for that... Can a memory address hold an array of values...?
EDIT: Really guys, you think the ONLY purpose of cheat engine is cheating? I'm not trying to cheat or hack anything. I didn't know trying to learn about memory address was wrong... For your info, I'm trying to make my own interface for a program I like. AN INTERFACE, that's not cheating.
In a program where windows are dynamically allocated, variables related to those windows will generally be dynamically allocated as well. That means the addresses may be different each time the program runs (depending on what else is in the program's heap at the time). In order to reliably get those locations, you'd need to start at the top-level static pointer (e.g. the address of the list of windows) and then dynamically follow the chain of dynamically-allocated pointers down to the addresses you are looking for. Whether CheatEngine can do this, or if it can even be done safely at all, I don't know.
Memory only holds numbers. It may be helpful to think of process memory as a huge list of numbers, each taking a value in the range (0-255). How those numbers are interpreted as is entirely up to the process (i.e., notepad in your example). This includes whether or not they are some "value" or perhaps a pointer to some value, etc.
I'm writing a simple program that accesses the memory of another process. I have been using a memory editor to find the addresses of the variables I want my program to retrieve and use with the ReadProcessMemory function. So far, there have been no problems, but I am unsure whether the addresses of the values may change depending on the environment the other program is being run on.
Aside from alterations to the program itself, should I be concerned about this? I have noticed that my memory editor saves the addresses relative to the location of the .exe (such as program.exe+198F6C), and I would love to implement my program like this, but I could not find any method for retrieving the current address of program.exe in C++.
Yes, they change.
The OS loads the process into different offsets each time it launches, and anything allocated with new or malloc is very likely to get different addresses each time the code is run.
There are two issues here: location of variables inside a process's memory space, and the location of a process in physical memory. The first should concern you, the second should not.
Local variables (as well as global/static variables) will have the same address relative to the program location in memory. Dynamically allocated variables (new/malloc) will have different addresses each time.
When I say "memory", I mean the virtual memory space of a specific process: the address 0x100 in one process doesn't equal 0x100 in another process, and in general is different than cell number 0x100 in your RAM.
The actual address isn't usually interesting, because both ReadProcessMemory and your memory editor only work with those relative addresses. You don't need the location of program.exe.
If you're interested in local variables, you can count on ReadProcessMemory returning a meaningful result each time. If you need memory which has been dynamically allocated, you need to find a local pointer, get the address of the allocated memory from it, and call ReadProcessMemory again.
Yes, they will change. Write a program that outputs the memory address of a few variables and run it a few times. Your output should differ each time, especially on other machines.
You are also going to run into concurrency problems with multiple accesses of the same memory area.
Correct order - W1a, W1b,R1a,R1b,W2a,W2b,R2a,R2b
Incorrect order - W1a,W1b,R1a,W2a,W2b,R1b,R2a,R2b
To solve this problem you need to look at IPC, Inter Processor Communication:
http://en.wikipedia.org/wiki/Inter-process_communication
What is serial copy? Is it different from deep-copy and shallow-copy?
According to the wiki entry under Duff's device, it is traditionally implemented as:
do { //count > 0 assumed
*to = *from++; //Note that the 'to' pointer is NOT incremented
} while(--count > 0);
And then it makes a note, saying
Note that to is not incremented because Duff was copying to a single memory-mapped output register.
I didn't really understand this note.
If to pointer is not incremented, then what is the point of the loop? Why then it is implemented as:
*to = from[count-1]; //does it not do the same thing?
I suspect that it has something to do with the definition of serial copy.
How can we allocate memory for to so that the loop would make some difference?
The point of such a copy is that it is not made to normal memory, but to a serial register.
So, each time a write is made to the address of the register (to), the hardware associated with the register will do something like send the bits over a serial link, or push them onto a queue for some other hardware to deal with.
Typically you cannot even read from register addresses like this, so they are very unlike normal memory, and best thought of as an interface to a particular piece of hardware that just happens to be located at a memory address.
http://en.wikipedia.org/wiki/Memory-mapped_I/O#Example
Some platforms have special addresses that when you read from / write to it, the system will perform some I/O. For example, the to could be an address that controls the speaker when written. In that case, the loop would, e.g. be able to play a sound, while the *to = from[count-1]; will not give any useful output.
The to pointer here is "special". On certain hardware you can access IO ports by writing to special memory regions. If you wanted to send a bit pattern over an IO port, where the pattern was already in memory this is the sort of thing you'd do.
Every write to to causes the output from the IO port to be changed typically. This is for iterating over the pattern and writing it to the "special" memory.
How you get access to such "special" memory is very platform and implementation specific. Sometimes it's just a question of always writing to a fixed address - normally some platform header provides a #define or similar then to make that information available to you at compile time. Sometimes there's a system call you need to make that tells you the address a particular device you're interested in is mapped at.
Or are those things are reserved for the operation system and things like that?
Thanks.
While it's unlikely that 0x00000001, etc. will be valid pointers (especially if you use odd numbers on many processors) using a pointer to store an integer value will be highly system dependent.
Are you really that strapped for space?
Edit:
You could make it portable like this:
char *base = malloc(NUM_MAGIC_VALUES);
#define MAGIC_VALUE_1 (base + 0)
#define MAGIC_VALUE_2 (base + 1)
...
Well the OS is going to give each program it's own virtual memory space, so when the application references memory spaces 0x0000001 or 0x0000002, it's actually referencing some other physical memory address. I would take a look at paging and virtual memory. So a program will never have access to memory the operating system is using. However I would stay away from manually assigning a memory address for a pointer rather than using malloc() because those memory addresses might be text or reserved space.
This depends on operating system layout. For User space applications running in general purpose operating systems, these are inaccessible addresses.
This problem is related to a architecture's virtual address space. Have a loot at this http://web.cs.wpi.edu/~cs3013/c07/lectures/Section09.1-Intel.pdf
Of course, you can do this:
int* myPointer1 = 0x000001;
int* myPointer2 = 0x000032;
But do not try to dereference addresses, cause it will end in an Access Violation.
The OS gives you the memory, by the way these addresses are just virtual
the OS hides the details and shows it like a big, continous stripe.
Maybe the 0x000000-0x211501 part is on a webserver and you read/write it through net,
and remaining is on your hard disk. Physical memory is just an illusion from your current viewpoint.
You tagged your question C++. I believe that in C++ the address at 0 is reserved and is normally referred to as NULL. Other than that you cannot assume anything. If you want to ask about a particular implementation on a particular OS then that would be a different question.
It depends on the compiler/platform, but many older compilers actually have something like the string "(null)" at address 0x00000000. This is a debug feature because that string will show up if a NULL pointer is ever used by accident. On newer systems like Windows, a pointer to this area will most likely cause a processor exception.
I can pretty much guarantee that address 1 and 2 will either be in use or will raise a processor exception if they're ever used. You can store any value you like in a pointer. But if you try and dereference a pointer with a random value, you're definitely asking for problems.
How about a nice integer instead?
Although the standard requires that NULL is 0, a pointer that is NULL does not have to consist of all zero bits, although it will do in many implementations. That is also something you have to beware of if you memset a POD struct that contains some pointers, and then rely on the pointers holding "NULL" as their value.
If you want to use the same space as a pointer you could use a union, but I guess what you really want is something that doubles up as a pointer and something else, and you know it is not a pointer to a real address if it contains low-numbered values. (With a union you still need to know which type you have).
I'd be interested to know what the magic other value is really being used for. Is this some lazy-evaluation issue where the pointer gives an indication of how to load the data when it is not yet loaded and a genuine pointer when it is?
Yes, on some platforms address 0x00000001 and 0x00000002 are valid addresses. On other platforms they are not.
In the embedded systems world, the validity depends on what resides at those locations. Some platforms may put interrupt or reset vectors at those addresses. Other embedded platforms may place Position Independent executable code there.
There is no standard specification for the layout of addresses. One cannot assume anything. If you want your code to be portable then forget about accessing specific addresses and leave that to the OS.
Also, the structure of a pointer is platform dependent. So is the conversion of the value in a pointer to a physical address. Some systems may only decode a portion of the pointer, others use the entire pointer value. Some may use indirection (a.k.a. virtual addressing) to access real objects. Still no standardization here either.
I am currently in process of making our application Large Address Aware. As experience has shown, there are some unexpected gotchas when doing so. I create this post to make a complete list of steps which need to be taken.
The development considerations listed in the AMD Large Address Aware guide provide a good starting point, but are by no means complete:
The following considerations will help to make sure that the code can handle addresses larger than 2GB:
Avoid the use of signed pointer arithmetic (I.e. compares and adds)
Pointers use all 32-bits. Don’t use Bit31 for something else.
Some dll’s will be loaded just under the 2GB boundary. In this case, no consecutive memory can be allocated with VirtualAlloc().
Whenever possible, use GlobalMemoryStatusEx() (preferred) or GlobalMemoryStatus() to retrieve memory sizes.
Therefore, the question is: What is the complete list of things which need to be done when making C++ Win32 native application Large Address Aware?
(obvious) select Support Address Larger than 2 Gigabytes (/LARGEADDRESSAWARE) in the project properties: Linker / System / Enable Large Address
check all pointer subtractions and verify the result is stored in a type which can contain the possible difference, or replace them with comparisons or other constructs - see Detect pointer arithmetics because of LARGEADDRESSAWARE). Note: pointer comparison should be fine, contrary to AMD advice, there is no reason why it should cause 4 GB issues
make sure you are not assuming pointers have Bit31 zero, do not attempt to use Bit31 for something else.
replace all GetCursorPos calls with GetCursorInfo - see GetCursorPos fails with large addresses
for all assignments into PVOID64 use PtrToPtr64, needed e.g. when using ReadFileScatter, see ReadFileScatter remark section