DPAPIのCryptProtectMemoryAPIを使用すると、CRYPTPROTECTMEMORY_SAME_PROCESSフラグを渡すことができます。これにより、他のプロセスがメモリを復号化できなくなります。これを回避する1つの方法は、、、を使用OpenProcessしてWriteProcessMemory、CreateRemoteThreadターゲットプロセスにコードを挿入し、それを呼び出すことCryptUnprotectMemoryです。これにより、メモリが復号化され、他のプロセスにリークされます。
両方のプロセスがWindowsVista以降で同じ制限付き特権ユーザー（つまり、管理者ではない）のコンテキストで実行されていると仮定すると、これはまだ可能ですか？プロセスACLに関係なく、限られたユーザーに対してプロセスメモリの書き込み操作が拒否されたという印象を受けましたが、間違っている可能性があります。
コードインジェクションを使用する必要がある正確なシナリオについては説明していません。管理者権限なしで実行されているopeプロセスが、CreateProcessに関して別のプロセスを作成する場合、たとえば、（PROCESS_INFORMATIONのPROCESS_ALL_ACCESS）すべての権限を持つ新しいプロセスのハンドルを取得します。あなたはここで例えば次を読むことができますhProcess
CreateProcess関数 によって返されるハンドルには、プロセスオブジェクトへのPROCESS_ALL_ACCESSアクセスがあります。
CreateProcessしたがって、子プロセスへの完全なアクセス権が必要になるまで、から返されたハンドラーを保持し、閉じないでください。このようにして、 CreateRemoteThreadとWriteProcessMemoryを呼び出すために必要なPROCESS_CREATE_THREAD、PROCESS_QUERY_INFORMATION、PROCESS_VM_OPERATION、PROCESS_VM_WRITE、およびPROCESS_VM_READアクセス権があります。
したがって、あなたの質問に対する答えは、「はい、いくつかの追加の条件下で可能です」となります。
WindowsはプロセスACLを尊重します。デフォルトでは、これにより、プロセスが実行されているユーザー、およびローカルシステムアカウントとユーザーのログオンセッションSIDにアクセスできます。管理者は、SeDebugPrivilegeを使用してこのACLをバイパスできます。
それ以外の場合は、独自のコードをデバッグするために管理者である必要があります。
プロセスACLは変更できますが、通常（IIRC）は現在のユーザーがプロセス所有者であるため、現在のユーザーコンテキスト内の別のプロセスが元に戻すのを防ぐことができるかどうかはわかりません。また、プロセスが同じデスクトップで実行されている可能性が高いため、とにかくシャッター攻撃を受ける可能性があります。