I'm writing an application that encrypts its data. It can then display it unencrypted using the app's UI after a user enters password. My goal is to minimize exposure of plaintext data while in RAM. For that I want to prevent swapping it to disk as much as possible.
I know that I can adjust my process's working set (by calling SetProcessWorkingSetSize API) and then lock those sensitive pages in RAM (by calling VirtualLock.) That, in theory, should minimize the chances of it being written to disk.
The question I have is, can I do the same with the memory that is used by the common controls in my dialog window, namely in Edit boxes, combo boxes, and most importantly RichEdit control?
PS. I'm assuming that they all use data from the heap for my process. Correct?
EDIT: Seeing all the comments below I need to clarify. By saying "lock", I don't mean, "lock it with a padlock and key so that no one can see it." I meant, lock it as with the VirtualLock
API.
You can use
EM_SETHANDLE
to set a handle for an edit control's initial allocation, then respond toEN_ERRSPACE
when (if) it runs out of space and needs more.From there, it's up to you to also use
VirtualLock
on that block of memory to keep it in RAM as much as possible. If you're going to do this a lot, you probably want to consider superclassing the control(s) to keep from duplicating the code everywhere.For better or worse, I don't believe there's an equivalent for rich text controls though.
There is actually a native windows API to help minimize the exposure of crucial items like passwords to memory scraping.
See CryptProtectMemory as a starting point.