flat assembler
Message board for the users of flat assembler.

Index > Windows > Protected memory curiosities

Author
Thread Post new topic Reply to topic
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
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
Code:
-Commit a range of reserved pages in a process's virtual address space so that physical storage (either in RAM or on disk) is accessible only to the allocating process.
    

listed under the "capabilities" of the virtual memory functions in windows, I'm stillll looking however for exactly how to do it...
Post 23 Feb 2008, 23:48
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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.
Post 24 Feb 2008, 01:03
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
Quote:

which zeroes out memory pages when the system is idle.

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.
Post 24 Feb 2008, 01:41
View user's profile Send private message Visit poster's website Reply with quote
asmhack



Joined: 01 Feb 2008
Posts: 431
asmhack
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..
Post 24 Feb 2008, 02:14
View user's profile Send private message Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
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.
Post 24 Feb 2008, 02:42
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
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.


Last edited by revolution on 24 Feb 2008, 12:58; edited 1 time in total
Post 24 Feb 2008, 02:46
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
Code:
call [GetPhysicalHandle]
mov [hPhycIn],eax
push eax
push HyperSpace
add ebx,[MC^2]
push ebx
call [EnterFourthDimension]
cmp eax,[ChickenStew]
jnz @f
mov [nEwToN'sThIrD],eax
invoke FallingUp!
ret 0xDEADBEEF
    
Post 24 Feb 2008, 03:01
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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.
Post 24 Feb 2008, 12:41
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.