I have some (small chunk) of code that uses 240 bytes of memory pretty often, but I realized that if this code is used by other people (I first had the memory address for the 60 dwords given by the user, then I realized that whoever may use it would definitely not like that), it may be insecure because of no protection to outside processes gaining access to memory. I was curious, how would you protect a chunk of memory that could be used readily, but only this process has access to it?

[NOTE] Yes, I've read a lot on msdn trying to find what to use, and I found

listed under the "capabilities" of the virtual memory functions in windows, I'm stillll looking however for exactly how to do it...

If your app terminates, windows will make sure another app can't re-use the memory before it's zeroed out - there's a critical system thread called the zero-page thread that's used for just that purpose, which zeroes out memory pages when the system is idle.

If you want protection while your app is running, make sure every user runs a limited user accounts, so they can't touch eachother's memory with Read/WriteProcessMemory.

Alternatelly, you can use the security APIs to grant/revoke certain rights. World of Warcraft, for instance, does this so you can't attach/open it's process, and thus can't debug or manipulate memory. Of course you can debug it's initialization and stop it from doing this, but if you don't, you don't have access... unless you write a driver.

lol that sounds deviant

Thanks f0dder, what I was looking for is memory protection while the app is running, but I still cannot find anything about this sort of protection. There are the memory protection constants to use with VirtualAlloc and VirtualProtect, but as for making memory process-only I believe (not a good thing to "believe" with this stuff) that Windows will not allow another process to view it.

I was thinking about calling VirtualAlloc in my library's initialization code, (relying that Kernel32 is mapped to memory first), and storing the handle in memory for later (if) use, and VirtualFree when the dll is un-loaded.

One more thing:
If I use section memory in my dll instead of allocating dynamically, can another process still view it?

As for this, I will think about using the dll initializing code to dynam. alloc the 60 dwords, probably lock it also. An entire page devoted to this small amount of data (which probably won't even be used) seems like a silly thing, and so I will most likely settle for a section in the library.

you can bypass the memory access protection using a loader or just changing debug privileges.. if you want so much to protect your data in the memory you should maybe encrypt it there and decrypt when accessing.. or using something like coded values..

lol I realized that no matter how I have the data in memory, my library will always be in the process's memory, and so allocating memory or having it in a section really does not help at all, because it all ends up in the same memory space in the end. So, I will just have it sitting there in a section and zero it out when finished.

You can use VirtualLock to attempt to stop the memory being put in the page file but it is not guaranteed, the OS only uses it as a hint. Also any code running in Ring0 (drivers and some debuggers), a hypervisor, or a VM, will be able to read the memory. In short you cannot be sure to protect your memory and there is no real solution to this. Look at the MS DRM farce, they tried all kinds of tricks to protect the secret keys, but without changing the laws of physics you can't actually make it secure.

Look, VirtualAlloc/VirtualProtect etc. won't help you against having your memory read, in any way.

You need to mess with the debug privileges, which (as asmhack points out) can be subverted with the help of a loader, or manual debugging (it will protect you against trivial attacks though).

But you can never do anything really secure.