The CryptProtectMemory API in the DPAPI allows you to pass the CRYPTPROTECTMEMORY_SAME_PROCESS flag, which prevents other processes from decrypting the memory. One way around this would be to use OpenProcess, WriteProcessMemory, and CreateRemoteThread to inject code into the target process and have it call CryptUnprotectMemory, thus decrypting the memory and leaking it to the other process.
Assuming both processes are running under the context of the same limited privilege user (i.e. not an administrator) on Windows Vista or later, is this still possible? I was under the impression that process memory write operations were denied to limited users, regardless of the process ACL, but I may be wrong.
Windows respects the process ACL, and by default, this allows access to the user the process is running as as well as to the local system account and the user’s logon session SID. Administrators can bypass this ACL using SeDebugPrivilege.
Otherwise, you would need to be an administrator in order to debug your own code.
You can change the process ACL, but since normally (IIRC) the current user is the process owner I’m not certain whether or not you can prevent another process in the current user context from changing it back. Also, since it is likely that the processes are running on the same desktop, you would be subject to shatter attacks anyway.