이 글의 핵심은 “프로세스를 전부 막는 것”이 아니라, 대상·요청 주체·요청 권한을 구분해 위험한 접근권한만 줄인 정책 변화입니다.
위협 모델
외부 프로세스가
WriteProcessMemory로 Palworld 메모리를 바꾸려면, 먼저 OpenProcess 등으로 충분한 접근권한을 가진 핸들을 얻어야 합니다. 사용자 모드 API만 막으면 다른 호출 경로나 직접 시스템 호출로 우회할 수 있으므로, Windows Object Manager가 핸들을 생성하는 커널 경계를 선택했습니다.콜백 등록
드라이버는
OB_CALLBACK_REGISTRATION과 OB_OPERATION_REGISTRATION을 구성하고, 프로세스 객체에 대한 사전 콜백을 등록했습니다.소스는
OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE를 등록합니다. 그러나 실제 정책 분기는 OB_OPERATION_HANDLE_CREATE일 때만 실행됩니다. 따라서 현재 코드에서 검증된 방어 범위는 신규 핸들 생성 경로이며, 복제 핸들은 등록만 되어 있고 별도 처리 보완이 필요합니다.정책을 개선한 과정
1차: 모든 핸들 접근 차단
처음에는 Palworld에 대한 접근 자체를 막았습니다. 이 방식은 단순했지만 Steam, 오버레이, 백신과 게임 자체의 정상 동작까지 방해할 수 있었습니다. “많이 막는 것”이 곧 좋은 보안 정책은 아니었습니다.
2차: 요청 주체를 분류
요청 프로세스가 다음에 해당하면 허용하도록 바꿨습니다.
- 대상 프로세스 자기 자신
- 프로젝트에서 확인한 게임·Steam 관련 허용 목록
- 실험용 System32 경로 규칙
3차: 위험 권한만 제거
신뢰되지 않은 프로세스의 요청 중 다음 비트가 포함된 경우에만
DesiredAccess를 0으로 변경했습니다.PROCESS_VM_WRITE: 대상 프로세스 가상 메모리 쓰기
PROCESS_VM_OPERATION: 가상 메모리 작업
PROCESS_DUP_HANDLE: 핸들 복제
읽기 또는 조회 목적의 모든 요청까지 일괄 차단하지 않도록 범위를 줄였습니다.
구현에서 중요한 세부사항
보고서 표현과 코드의 차이
당시 최종보고서에는
DesiredAccess를 0으로 만들어 핸들을 막는 흐름을 중심으로 적었습니다. 지금 코드를 다시 보면 모든 요청을 막는 것이 아니라, 비인가 요청이면서 위험 권한 비트를 포함할 때만 0으로 변경합니다. 그래서 이 글에서는 당시의 요약 표현보다 실제 코드가 하는 일을 기준으로 설명했습니다.경로 기반 신뢰의 취약성
System32 아래의 프로세스를 신뢰하는 규칙은 프로토타입에서 정상 시스템 프로세스의 오탐을 줄이기 위한 휴리스틱이었습니다. 경로 문자열은 파일 서명이나 실행 주체의 무결성을 증명하지 않습니다. 또한 기본 경로가 특정 볼륨 번호로 하드코딩되고, 포인터 유효성 검사 일부도 논리적으로 잘못되어 있습니다.
실제 설계라면 경로만 보지 않고 서명, 토큰, 보호 수준, 이미지 객체와 정책 배포 방식을 함께 고려해야 합니다.
통제된 검증
검증 범위를 다시 정리할 때에는 제가 남긴 개인 기록과 최종보고서의 테스트 흐름을 함께 대조했습니다.
- 별도 테스트 프로그램이 Palworld 프로세스 핸들을 요청합니다.
- 드라이버 적용 전에는 대상 값을 변경할 수 있음을 확인합니다.
- 드라이버 적용 후에는 비인가 프로세스의 쓰기 관련 권한 요청이 제거되는지 디버그 로그와 결과로 확인합니다.
- 전체 차단으로 정상 동작 문제가 생긴 뒤, 허용 목록과 권한 단위 정책으로 수정합니다.
이것은 정해진 테스트 프로그램과 환경에서의 기능 검증입니다. 공격 우회율, 오탐률, 성능 저하를 측정한 벤치마크는 아닙니다.
방어 경계의 한계
- 콜백 등록 이전에 이미 열린 핸들은 별도 처리하지 않습니다.
- 커널 권한의 공격자와 취약 드라이버 악용은 범위 밖입니다.
- 복제 핸들 콜백의 정책 분기가 구현되지 않았습니다.
- 파일명 허용 목록은 동일 이름 위장에 취약합니다.
- 대상 PID 탐색과 객체 수명·메모리 해제에 대한 안정성 보완이 필요합니다.
DesiredAccess = 0은 세밀한 비트 제거보다 거친 정책입니다.
결론
가장 큰 변화는 “치트 프로그램을 찾자”에서 “보호 대상에 위험 권한이 부여되는 순간을 통제하자”로 관점을 바꾼 것입니다. 이 과정에서 최소 권한, 정상 프로세스 호환성, 신뢰 근거의 품질이 커널 보안 정책의 핵심이라는 점을 배웠습니다.
당시 원본 기록
아래 하위 문서는 2024년 당시 제가 작성한 개인보고서 원문입니다. 사진·코드·시행착오는 그대로 보존했고, 지금 다시 보며 바로잡은 내용은 위 본문에 따로 적었습니다.