IAT Hook에 관한 고찰




그옛날 후킹이라는 주제를 처음 배울 때 인터넷이든 해외 사이트든 가장 먼저 설명하던
후킹의 종류는 IAT Hook 이었다고 생각합니다. IAT Hook을 먼저 안내하는 이유는 일단
PE를 공부하면서 Import Address Table 이라는 것에 대해 알아볼 때 부수적 효과로
덩달아 학습되기에 가장 적당한 주제이기도 하고, 또 후킹 구현이라는 데에 있어
inline hook 따위에 비하여 훨씬 쉽기도 하기 때문입니다.

그래서 보통 후킹에 대한 입문 하면 IAT Hook 부터 접하게 되는 것이 일반적이었다고
생각합니다. 따라서 저는 후킹이라는 주제를 하나의 큰 학문이라고 가정하고 그것을 수학에
비유한다면 IAT Hook 은 인수분해 쯤 되는 순서라고 봅니다. 또 그만큼 기초적이기도
하니까요.

하지만 쉬웠던 만큼 IAT Hook은 실전에선 그렇게 많이 써먹히지가 않았죠. 그 이유는
무엇일까요. 바로 IAT Hook 에는 "범용성" 이 없었습니다. 써먹을 타겟에 한계가 있던 것이죠.
IAT Hook 을 널리 전파하기에는 프로텍터와 패커라는 너무도 높은 관문이 있었습니다.
패킹한 바이너리의 IAT 를 찾는것은 패커의 종류마다 버전마다 너무도 많은 차이가 있고
또 그 각각의 IAT를 구하기도 쉽지 않습니다. 따라서 후킹하기에 앞서 모든 호환성이나
플랫폼을 감안하여야 하는 보안 솔루션 입장에선 IAT 는 건드리기 힘든 혹은 건드려서는
안되는 불모지 쯤으로 전락하게 됩니다.

그리고 역시 inline hooking 이 가장 범용적이면서 또 기능도 강력하기 때문에 사람들의
관심은 이쪽에 맞추어진 채로 지금까지 오게 됩니다. 그래서 inline hook 을 더 효율적으로
하는 여러가지 연구가 이루어집니다. 예를 들면 중간번지를 후킹한다거나 push address
retn, 트램벌린 코드 같은 시도가 그것들이죠. 처음 볼때마다 신기한 넘들이 등장하고
또 그것을 막거나 우회하기 위한 논의가 지속됩니다. IAT Hook은 버려져 있다고 생각하기
쉬운 이 시점에 overwrite hook은 계속 발전하고 있습니다.

하지만 최근에 실제 현업에서는 분위기는 또하나의 물결이 보이는 것 같습니다. 해커들에게
요즘의 대세는 IAT Hook 입니다. 보안업계 사람들이 버려둔채 이목이 집중이 되지 못하고
있는 영역인 것을 그들이 눈치라도 챈 듯, IAT 쪽을 최근 집중적으로 건드리고 있습니다.
특히 보안 모듈이나 보안 코드가 온전히 가동되고 있는 상황에 더욱 그렇습니다.

이들이 IAT 쪽을 공격하는 제가 나름대로 생각하는 이유를 적어보겠습니다.

1. 공격대상은 거의다 패킹된 바이너리이며 보안 코드 작성시 그 상태에서는 IAT 를
   쉽게 구할 수 없다. 따라서 검사하지 않을 것이다. 
2. 하지만 해킹툴을 만드는 입장에선 까짓거 노가다로 찾아서 하드코딩 해버리면 된다.
   (대부분이 이런 넘들임. 클라이언트가 패치하여 번지가 바뀌면 후킹하지 못함)
3. 보안 솔루션이 IAT 를 구하더라도 패커가 내부적으로 리다이렉트 시키는건지
   해킹툴이 훅을 하는건지 패커의 내부구조를 상당수 파악하기 전까진 분간하기 힘들다.
4. 훅을 해도 system dll 들의 메모리 CRC가 변경되지 않는다.


대략 이정도 같군요. 늘어놓고 보니 IAT Hook 이 공격하기에 꽤 매력적이라는 생각이
듭니다. 즉 이정도 이유만 되어도 IAT Hook 으로 공격할 당위성은 충분하다고 보입니다.

저는 르네상스 라는 단어를 좋아합니다. 르네상스는 문화의 부활 이라는 의미로 많이
사용되죠. 그래서 저는 IAT Hook 도 일종의 르네상스라고 보고 있습니다. 이전에
디버그랩에서 발표를 할 때에도 IAT Hook 의 르네상스라는 표현을 사용한 적이
있고 작년 마소에서 IRP Hook을 다룰 때에도 역시 마찬가지 비유를 들었던 기억이
있네요. 르네상스보다 사실 더 좋은 우리 선조들의 말씀도 있죠 "구관이 명관이다!"
예~ 역시 옛 것을 다시 살펴보는 것은 정말 중요한 것 같습니다.

마무리 짓자면 리버스 엔지니어링을 할 때 무언가 답은 나오지 않고 답답하다 싶으면
한번 IAT 쪽도 살펴보세요. 큰 힌트를 발견하게 될 수도 있습니다 :)

최근 들어 IAT 를 고도의 기술로 건드리며 우리를 당황하게 하는 중국애들을
보며 느낀 내용들입니다.


window31. 2009년 1월


Posted by window31


트랙백 보낼 주소 : http://window31.com/trackback/232 관련글 쓰기

댓글을 달아주세요

  1. 2009/01/12 09:01
    댓글 주소 수정/삭제 댓글
    좋은 글 잘봤습니다. 역시 내공이 대단하셔요. 그나저나 중국해커들은 참 대단하다는 생각을 많이 합니다. 사람이 많아서 그런건지 정말 똑똑한건지.. 노가다를 좋아하는건지.. ^^;; 오늘도 화이팅하세요.
    • 2009/01/12 21:50
      댓글 주소 수정/삭제
      일단은 사람이 많아서 라고 추측하고 있다는 ㅎㅎ
      뭐 잔대가리도 대단하죠 ^^
  2. rodream
    2009/01/12 10:13
    댓글 주소 수정/삭제 댓글
    IAT Hooking 구조적으로 호환성이 안좋습니다.

    XP 32bit 에서만 실행된다고 하면 모르겠지만,

    Vista 에서 GetProcAddress 로 가져가서 저장하고 쓰는 경우와

    64bit 에 대한 지원 불가능으로 인해서 다소 압박입니다 =_=;;
    • 2009/01/12 21:50
      댓글 주소 수정/삭제
      그렇죠 ㅎㅎ 그래서 구현/검사/원복화 는
      다들 꺼려하죠 ^^
  3. 2009/01/13 11:11
    댓글 주소 수정/삭제 댓글
    ㅎㅎ 이게 지난번에 말씀하셨던 "IAT Hook의 르네상스"라는 것이었군요.
    이 바닥에서 일하려면 정말 잔머리가 잘 돌아야겠다는 생각을 해보게 되는군요.
    • 2009/01/13 18:52
      댓글 주소 수정/삭제
      네 맞습니다.
      정파 기술 + 잔대가리가 필요하죠 : )
  4. 2009/03/21 22:27
    댓글 주소 수정/삭제 댓글
    오랜만에 다시 보는 글입니다... :D

    제 블로그에서도 보셨겠지만... VirtualQueryEx() 를 이용해서 PE header가 차지하는 page size를 얻어낸뒤 그것을 더해버리면 대부분의 파일의 경우 IAT가 나와버려서... (물론 난점이라면 어떤게 후킹해야할 API인지 모른다는 것이 있겠지요...;;)
    • 2009/03/23 09:50
      댓글 주소 수정/삭제
      네~ 그렇군요 ㅎㅎ!
  5. Dual
    2010/07/16 21:28
    댓글 주소 수정/삭제 댓글
    1년 이나 지난 글에 대한 리플이고 하지만, 생각해보면 그 외의 장점이 생각나서 적어봅니다,
    분명 아래 단을 후킹할수록(Lower, Wider) 한게 사실입니다.
    그게 장점이지만, 그만큼 훅 체인에 대한 경쟁도 치열하고, unhook될 가능성도 높죠, 또 Game Hack의 입장에서는 어떻게든 Native API의 꼭 호출해야만 하는 (Pesudo code 짜기가 좀 까다로운, system에 많이 dependent한)
    놈만 어떻게든 호출하면 되니까요, ObObjectByPointer와 KeAttachProcess(더 아래단의 stack이 더 많이 쓰이겠지만서도) 같은 놈들 말이죠,

    업계 리더 그 제품도 SSDT 에서 -> 인라인 훅으로 바뀌었더군요(커널단에서)

    SSDT Restore가 워낙 빈번하기 떄문이겠죠, 또한 원본 함수 주소를 구하는 것도 쉬우니까요,
    그다음 inline hook일떄도 후킹 대상 프로세스 또는 dll의 원본 파일을
    읽어서 , 제계산을 통한
    HookingStub(;;;)
    {
    execute rap code
    jmp originalfunc + rapcodesize
    }

    식으로 처리가 가능하죠, 이미 저도 몇년전에 써봤던 테크닉이고,
    그랬더니 그 후엔 훅이 중간으로 이동되더군요.

    이에 대한 Game Hack 의 대응은 바로 Code Relocation 이겠죠,
    이제 더 이상 그 함수를 쓸 필요도 없는, Pure한 코드는 제계산을 통해서
    얻을 수 있을테고, Relocation 해서 새로운 메모리 영역의 새로운 함수를
    쓴다면 더 이상 영향도 안받겠죠,
    이제 가장 중요한건, 보안 솔루션의 훅들 보다 가장 먼저 닿는 포인트가 어디인가 하는겁니다. 예전에는 가장 깊숙히 하는게 중요했다면, 더 로우레벨의 함수를 호출해서 우회했다면, 이젠 가장 상위에 함수를 후킹해서, 슈도코드를 짜서, 아랫단의 함수 호출 없이 처리 해버리는 , 점점 말하자면 가상화 방식으로 가는거죠, IAT 훅도 보안솔루션이 선점하면, 어짜피 요즘 Detour나
    Madchook 같은 라이브러리의 Disassemble 코드도 잘되있으니,
    API Call 부분을 찾아서, 고쳐주는, inline hook 이지만, 가장 상위의 inline hook 을 시도할겁니다 저라면, 그외엔 그냥 후킹도 하지 말고 자기가 만든 함수 DeviceIoControl 로 불러주면 될꺼 같습니다 ㅋㅋ 물론,
    IoControlCode도 보고 감지 하니, 가변적으로요 하하 ㅋㅋㅋ
    (xor 이 생각나네요)

    ㅠㅠ 그냥 이 글에 안적혀 있길래 썻지만, 이 블로그에 있는 글들에 충분히 담겨 있는 내용이라고 생각합니다 ㅋㅋ 클라이언트 단의 훅 체인, 후킹 방지 방법도 뭐 사실상 의미 없는 논쟁이고, 사실 상 불가능하죠 ㅋㅋㅋ 그럼에도 불구하고, 정보가 필요한 분들에게 혹시나마 도움이 될까 하고, 남겨봤습니다 ㅋㅋ (아마 없을듯)

    생각해보면 게임해킹은 다시하면 별로 재미없을거 같은게, 이제 더이상은 window31님이 안게시니까요 ㅠㅠㅋ
    츤츤ㅋㅋ!

BLOG main image
by window31

카테고리

분류 전체보기 (281)
Reverse Engineering (21)
C, C++ (20)
Kernel (8)
Guitar (19)
잡담 (77)
etc (8)
who am i (8)
보안 이야기 (88)
Tools (3)
월간 마이크로소프트웨어/그.. (28)

글 보관함