Inline Hooking

 보통 유저 어플에서만 Inline API Hooking을 사용해 봤는데 이번엔 커널에서 사용해 보면서 정리해봤습니다.

유저 어플에서와 큰 차이점이 없습니다. 아니... 아에 없다고 보셔도 됩니다.

글을 간단히 작성하기 위해 2가지 차이점만 비교해보겠습니다.

일반적인 SSDT 후킹과 NT함수 내부 5Byte를 수정해 Inline Hooking 하는 경우입니다.

1. 일반적인 SSDT 후킹

위 그림은 일반적인 SSDT 후킹입니다. KiServiceTable에 있는 값을 제가 만든 Func Address로 바꿔버리는 것입니다.

위 그림대로 SSDT 후킹을 한 후 Kernel Detective Tool로 봐보겠습니다. ( Windows XP )

SSDT.sys라는 놈이 후킹을 했군요.

2. Inline Hooking

이번 후킹은 NtOpenFile 함수 내부로 들어가 처음 5Byte를 jmp MyFunc로 바꿔버리는 것입니다.

간단히 그림으로 보시겠습니다.

Normal 루틴의 처음 5Byte를 수정해 제가 만든 Func로 점프되게 하는 것입니다.

이건 KiServiceTable을 건들이는 후킹이 아니므로 SSDT를 봐도 아무런 이상이 없습니다.

Inline Hooking 후 툴로 다시 봐보겠습니다.

전혀 이상이 없군요.

하지만 내부 어셈코드를 봐보겠습니다.

처음 5Byte를 보니 어디론가 점프를 하는 코드가 있습니다. Inline Hooking이 된거군요.

또는 Kernel Modifications 기능을 사용해 Inline Hooking을 확인할 수도 있습니다.

C:\Inline.sys라는 놈이 NtOpenFile을 처음 5Byte를 수정해 Inline Hooking을 했군요.

이처럼 대부분 바이러스나 보안 툴을 보면 직접적으로 SSDT후킹을 하는 경우는 드물고 Inline Hooking을 많이 사용합니다.

그리고 루트킷 책을 봐보니 런타임 패치.. 점프 템플릿.. 이렇게도 불리는거 같습니다.

대응 방안으로는 System Thread를 사용해 CRC체크하는 방법을 사용하면 어느정도는 효율적으로 막을 수 있을 것 같습니다.