Windows에서 실행되는 프로그램은 RAM을 직접 처리 할 수 없습니다. 그들은 가상 주소에 액세스합니다. RAM에 액세스하려면 목적에 맞게 작성된 커널 모드 드라이버의 도움이 필요합니다. (이것은 Mark Russinovich의 "sysinternals 도구"중 일부를 수행하는 방법입니다. .exe 내에 리소스로 패키지 된 드라이버를 설치합니다.)
한 프로그램이 다른 프로그램에 액세스하는 한 Windows의 모든 프로세스에는 이미 자체 가상 주소 공간이 있으며 다른 모든 주소와 분리되어 있습니다. 즉, 한 프로그램의 0x10000은 다른 프로그램의 0x10000과 완전히 다릅니다. 어떤 주소를 보려고하더라도 항상 자신의 프로세스의 해당 주소 인스턴스를보고 있습니다.
그러나 ReadProcessMemory 및 WriteProcessMemory API를 사용하면 프로그램이 가상 주소 측면에서 교차 프로세스 액세스를 수행 할 수 있습니다. 이들을 사용하려면 "액세스"하는 프로세스가 PROCESS_VM_READ 또는 PROCESS_VM_WRITE 권한을 가진 다른 프로세스를 열어야합니다. 사용자 세션 내에서 실행되는 프로세스는 일반적으로 서로를 수행 할 수 있습니다 (즉, 대부분의 프로세스의 보안 설명자는 프로세스 작성자에게 이것을 허용합니다 ... 당신입니다).
그러나, 한 프로그램은 다른 프로세스에서 관심있는 것이 어디에 있는지 알 수있는 방법이 없습니다. 흥미로운 것을 찾기 위해 길고 피곤한 검색이 될 것입니다. 대부분의 시도는 64 비트 시스템, 특히 Windows 8.1 이상에서 "주소 정의되지 않음"영역을 초래합니다. 가상 메모리의 정의 된 영역 내에서도 프로그램이 "뱅크 계좌 번호는 여기에 있습니다 :"와 같은 컨텍스트 정보로 일상적으로 메모리 영역에 태그를 지정하는 것처럼 보이지 않습니다.
모든 프로세스가 다른 프로세스의 "메모리"(느슨하게 해석 됨)에 액세스 할 수있는 것은 다소 무심하다고 생각할 수 있습니다. 그러나 하나의 로그인 ID 및 권한 부여하에 수행하는 모든 작업은 단일 사용자가 수행 한 것으로 간주됩니다. 즉 그것은 어쨌든 모든 데이터입니다.
솔직히 디스크의 데이터에 대해 더 걱정할 것입니다. 데이터가 포함 된 모든 파일은 보안 ID로 귀하가 작성 했으므로 보안 ID로 실행되는 모든 프로그램이 해당 파일에 모두 액세스 할 수 있습니다. 더 나쁜 것은 Windows 기본 설정은 "사용자"그룹에 읽기 권한이 부여 된 모든 파일을 만드는 것입니다. 따라서 다른 보안 ID로 실행되는 프로그램도 읽을 수 있습니다. 그리고 파일 이름이 잘 정돈되고 이름이 잘 정돈되고 체계화 된 디렉토리에 저장되기 때문에 accounts.txt와 같은 "흥미로운"파일을 찾는 것은 그리 어렵지 않습니다. NTFS 파일 암호화는 자신의 계정으로 실행되는 스 누퍼 프로그램에 도움이되지 않습니다. 프로세스 간 메모리 액세스보다 노출이 훨씬 큽니다.