최근 MS에서 HOTPatching 한 녀석들의 API를 보면 아래와 같은 모습이다.
5x 90 5x nop
FnStart:
8B FF mov edi, edi
55 push ebp
8B EC mov ebp, esp
56 push esi
57 push edi
8B 35 g_Data mov esi, g_Data
함수의 시작 이전에 5개의 NOP이 존재하고 함수의 시작 부분에 의미 없는
mov edi,edi 인스트럭션이 포함되어 있다. 왜 MS에서는 API에 이련 뻘짓(?)을
해놓았을까? 버그트럭의 포럼에서 mat님이 퀴즈를 내어서 좀 살펴보게 되었다.
흔히 Detour가 사용하는 Function Hooking 기법을 보면 함수의 Preemble를 덮어
씌운 후에, Detour로 점프를 하고 Trampline에서 원래 API의 바이트를 저장하였다가
실제 후킹구현된 함수에서 온갖 짓거리를 하고 나서 detour에서 오리지날 코드에서
지워진 부분을 다시 복원하여 실행한 뒤, 원래 API의 다음 인스트럭션으로 복귀한다.
그런데 실제로 확인해 본 결과, 커널 레벨에 있는 API도 이와 같은 모습을 지녔다.
그래서 커널 레벨에서 inline hooking을 할 경우 MS에서 사용하는 Hot Patching 기법을
그대로 시뮬레이션 할 수 있다.
그럼 MS Patching 기법을 살펴보자. 위의 원형에서 다음과 같은 변화를 주어 HotPatching
을 한다.
E9 Rel32 jmp FnContinue ; 요녀석 먼저 채우고 나서
FnStart:
EB F9 jmp $-5 ; 그다음 이녀석 채운다.
55 push ebp
8B EC mov ebp, esp
56 push esi
57 push edi
8B 35 g_Data mov esi, g_Data
위 comment와 같이 함수의 앞부분 NOP을 먼저 채우고 나서 그 다음에 함수의 시작
부분을 변경한다. 왜 그럴까? 이것은 동기화와 Race Condition문제이다.
만약에 순서를 바꾼다면 어떻게 될까?
Intel x86은 한번에 4바이트씩 처리한다. 그러므로 함수의 첫 부분 (2바이트)를 먼저
변경 한 후, 함수시작 앞부분에 있는 NOP 5바이트를 덮어 쓴다고 가정한다치자.
5바이트를 덮어 쓰기 위해서는 2번의 실행사이클을 거쳐 실행해야 한다.
그러므로 하나의 사이클을 돌은 후에 누군가 이 함수를 CALL한다면 나머지 한바이트는
채워지지 못한채로 이상한 주소로 jmp하게 될 것이고 아주 비극적인 결과가 벌어질 수
있다.
RootKit의 BugCheck가 Single Byte Hook이라는 Article을 통해서 이 HotPatching에 대해
설명하였으며, IDT를 통해서 One Byte (0xcd) 덮어 써서 훅을 구현 할 수도 있다.
8b ff mov edi, edi => cd ff int ff
물론 미리 IDT의 FF를 미리 수정해놓았다는 가정하에서 가능하다.
관련 링크
http://www.openrce.org/articles/full_view/22