API Code Patch 를 통한 API Hooking 방법에 대해서 공부합니다.

또한 모든 프로세스를 후킹 하는 global hooking 방법에 대해서 살펴봅니다.

위 기법을 사용하여 특정 프로세스를 감추는 은폐(stealth) 기법에 대해 실습해 보겠습니다.



<photo : Rob Shenk on flickr>


* 은폐(Stealth) 프로세스를 리버싱 전문 용어로 루트킷(Rootkit) 이라고 합니다.
보통 루트킷이라고 하면 커널 모드 후킹을 통한 프로세스, 파일, 레지스트리 등의 은폐 기술을 지칭합니다. 루트킷은 본 포스트의 설명 범위를 벗어나기 때문에 편의상 스텔스 프로세스라고 하겠습니다. (루트킷에 대한 내용은 커널에 대한 방대한 기반 지식을 요구합니다. 향후 제 블로그에서 하나씩 살펴볼 계획입니다.)

* 본문 내용을 편하게 읽기 위해서는 아래의 배경지식이 필요합니다.
☞ DLL Injection (DLL Injection – 다른 프로세스에 침투하기
)
☞ API Hooking (API Hooking – 계산기, 한글을 배우다
)
☞ API Hooking (API Hooking - 리버싱의 '꽃')



Tech Map



<Fig. 1>

API Code Patch
기법을 위 TechMap 에서 빨간색으로 표시하였습니다.

이 기법은 API Hooking 에서 가장 널리 사용됩니다.


그 이유는 대부분의 user mode API 를 자유롭게 후킹 할 수 있기 때문입니다.

* IAT Hooking 기법은 후킹하려는 API 가 프로세스의 IAT 에 존재하지 않을 경우 후킹이 불가능한 반면에 "API Code Patch" 기법은 그러한 제약 조건이 없습니다.

덧붙여 대상 프로세스의 메모리를 자유롭게 사용하기 위해 DLL Injection 기법을 사용하였습니다. (다음 번 주제에서 DLL 파일이 아닌 Code 자체를 Injection 하는 고급 기법에 대해서 살펴볼 예정입니다.)



API Code Patch 동작 원리


API Code Patch 를 통한 API Hooking 기법의 동작 원리에 대해서 알아보겠습니다.

* IAT Hooking 방식과 비교해 살펴보시면 더 쉽게 이해 될 것입니다.
☞ API Hooking (API Hooking – 계산기, 한글을 배우다)


IAT Hooking 방식이 프로세스의 특정 IAT 값을 조작해서 후킹을 하는 방식이라면, Code Patch 방식은 실제 API 코드 시작 5 byte 값을 JMP XXXX 명령어로 변경하는 방식입니다.

후킹된 API 가 호출되면 (패치된) JMP XXXX 명령어가 실행되어 후킹 함수로 제어가 넘어옵니다.

아래 그림은 Process Explorer(procexp.exe) 프로세스에 stealth.dll 파일을 인젝션 시킨 후 ntdll!ZwQuerySystemInformation() API 를 후킹하는 방법을 설명하는 그림입니다.

먼저 후킹 되기 전의 정상적인 프로세스 메모리의 모습입니다.

<Fig. 2> 

(1) procexp.exe 의 00422CF7 주소의 CALL DWORD PTR DS:[48C69C] 명령어는 ntdll.ZwQuerySystemInformation() API 를 호출하고 있습니다. (48C69C 주소는 프로세스의 IAT 영역으로써 7C93D92E 값을 가지며, 이는 ntdll.ZwQuerySystemInformation() API 의 시작 주소입니다.)

(2) 해당 API 는 실행이 완료되면 호출 코드 다음 명령어 주소로 되돌아 갑니다.

이것은 매우 정상적인 상황의 API 호출 흐름입니다.

그럼 이제 API 가 후킹된 프로세스의 그림을 보시겠습니다.
stealth.dll 을 인젝션 하여 ntdll!ZwQuerySystemInformation() API 를 Code Patch 하였습니다.

<Fig. 3>

위 그림이 상당히 복잡하게 보입니다. 하나씩 차근차근 살펴보도록 하겠습니다.

먼저 stealth.dll 이 인젝션 되면서 ntdll!ZwQuerySystemInformation() API 를 후킹 하였습니다.

ntdll!ZwQuerySystemInformation() API 시작 주소(7C93D92E)의 5 byte 코드를 JMP 10001120 으로 덮어 써버린 것이죠. (5 byte 패치) 10001120 주소는 stealth!MyZwQuerySystemInformation() 함수 주소입니다.

이때 procexp.exe 코드에서 ntdll!ZwQuerySystemInformation() API 를 호출하면 코드 흐름은 아래 순서와 같습니다.

(1) 422CF7 주소에서 ntdll!ZwQuerySystemInformation() API 를 호출(7C93D92E)합니다.

(2) 7C93D92E 주소에 있는 패치된 코드 JMP 10001120 에 의해서 10001120 주소(후킹 함수)로 점프합니다. 1000116A 주소의 CALL unhook() 명령어에 의해서 ntdll!ZwQuerySystemInformation() API 시작 5 byte 는 원래대로 복원됩니다.

(3) 1000119B 주소의 CALL EAX(7C93D92E) 명령어에 의해서 원본 함수(ntdll!ZwQuerySystemInformation) 가 호출됩니다. (unhook 상태이기 때문에 정상적으로 실행됩니다.)

(4) ntdll!ZwQuerySystemInformation() 의 실행이 완료되면 7C93D93A 주소의 RETN 10 명령에 의해 stealth.dll 코드 영역(자신을 호출한 위치)으로 리턴됩니다. 그리고 10001212 주소의 CALL hook() 명령어에 의해서 ntdll!ZwQuerySystemInformation() API 를 다시 후킹합니다. (시작 5 byte 를 JMP 10001120 명령어로 패치함)

(5) stealth!MyZwQuerySystemInformation() 의 실행이 완료되면 10001233 주소의 RETN 10 명령에 의해서 procexp.exe 프로세스 코드 위치로 리턴됩니다.

처음에는 좀 어려운 듯 보여도 몇 번만 읽어보시면 금방 이해하실 수 있으실 겁니다.

Code Patch 방법의 장점은 프로세스에서 사용되는 어떤 API 라도 후킹할 수 있다는 것입니다. IAT Hooking 의 경우에는 후킹 가능한 API 가 제한 된다는 사실과 비교해 보세요. (비록 코드는 조금 더 복잡하지만 말이죠.)

Code Patch 방법에 있어서 제한 사항은 후킹하려는 API 코드의 길이가 최소 5 byte 보다 커야 한다는 것입니다만, 모든 API 의 코드 크기는 5 byte 보다 크기 때문에 사실상 제한이 없다고 보시면 됩니다.

* 주의!
코드 패치 방법은 말그대로 프로세스 메모리 공간에 매핑된 DLL 의 코드를 직접 수정하는 것입니다. 만약 프로세스의 다른 스레드에서 어떤 함수를 read 하고 있을때 코드 패치를 시도하면 어떻게 될까요? Access Violation 에러가 발생합니다. 따라서 이점을 유의 하셔야 합니다.

다음에는 스텔스 기법에 대한 원리와 실습 예제 파일을 가지고 직접 실습을 해보도록 하겠습니다.


API Hooking - '스텔스' 프로세스 (2)


ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

  1. RED_BIT 2009.12.13 04:18 신고 댓글주소 | 수정 | 삭제 | 댓글

    아.. 전체적으로 작업관리자, procxp와 같은 녀석들에게 dll을 삽입해서...
    작업하는건가요..?! 제가 이해하고있는게 맞을까요..!? ㅎㅎ
    오늘도 좋은글 감사합니다~ ^^*

    • ReverseCore 2009.12.14 21:12 신고 댓글주소 | 수정 | 삭제

      RED_BIT님, 안녕하세요.

      네, 실행중인 모든 프로세스에 stealth.dll 을 인젝션 시킬겁니다.

      말씀하신대로 작업관리자, procexp 만 인젝션 시켜도 일반 사용자에게는 "스텔스" 처럼 보이겠지요. ^^

      감사합니다.

  2. 세의 2009.12.13 14:10 신고 댓글주소 | 수정 | 삭제 | 댓글

    잘 읽었습니다. +_+

  3. Sun2Day 2009.12.14 09:37 신고 댓글주소 | 수정 | 삭제 | 댓글

    항상 좋은 내용 잘보고 갑니다 '-'//

  4. BABOHA 2009.12.14 23:17 신고 댓글주소 | 수정 | 삭제 | 댓글

    감사합니다~
    Reversecore 님은 참 부지런 하십니다. ㅎㅎ
    다음 것도 기대할게요~

  5. Externalist 2009.12.15 20:58 신고 댓글주소 | 수정 | 삭제 | 댓글

    작성하느라 수고 많으셨습니다... 나중에 하나로 묶어서 책으로 출간해도 전혀 손색이 없을 정도로 훌륭한 퀄리티네요...^^

  6. Vice 2009.12.17 18:22 신고 댓글주소 | 수정 | 삭제 | 댓글

    앗.. 불과 며칠전에 공부했던 내용이군요!
    다시 복습하는 의미로 읽었더니 머리에 쏙쏙 들어오네요. 감사합니다!!

  7. 쭈욱 2010.02.18 14:28 신고 댓글주소 | 수정 | 삭제 | 댓글

    감사합니다. 블로그 통해서 많이 배우고 있습니다.
    바쁘시겠지만 한가지만 여쭤볼께요.
    API 중 MapViewOfFile API를 코드패치 방식으로 후킹하려고 했는데...
    5바이트에 JMP XXXX 쓰는 부분에서 항상 죽네요.
    vs8.0 디버거로 돌려서 직접 디버깅해보면 정상작동하구요
    직접 디버깅시 잘 되는걸로 봐서 사용자 권한 문제같은데요.
    방법이 없을까요??

    • reversecore 2010.02.19 23:46 신고 댓글주소 | 수정 | 삭제

      쭈욱님, 안녕하세요.

      제 글을 읽어보니 매우 중요한 "주의사항" 이 빠졌네요.

      바로 쭈욱님이 질문하신 내용인데요...

      코드 패치 방법은 말그대로 프로세스 메모리 공간에 매핑된 DLL 의 코드를 직접 수정하는 것입니다.

      만약 프로세스의 다른 스레드에서 어떤 함수를 read/write 하고 있을때 코드 패치를 시도하면 어떻게 될까요? 바로 에러 납니다.

      이 문제가 아니라면 해당 파일을 저에게 보내주시면 제가 살펴보겠습니다.

      확장자를 exex 또는 압축하셔서 zipx 등으로 변경해서 첨부해 주세요~

      감사합니다.

  8. 쭈욱 2010.02.22 16:11 신고 댓글주소 | 수정 | 삭제 | 댓글

    답변 감사드립니다. 말씀해주신 내용 잘 봤습니다.
    그래서 MapViewOfFile API는 IAT 후킹하는 방식으로 바꾸니까 잘 됩니다.
    다시 한번 감사드립니다.

    • reversecore 2010.02.23 01:52 신고 댓글주소 | 수정 | 삭제

      쭈욱님, 안녕하세요.

      다행히 IAT 후킹 방식을 잘 해결 하셨군요.

      나중에라도 코드 패치 방법을 연습삼아 시험해 보시기 바랍니다.

      감사합니다. ^^

  9. 울터치 2010.04.08 03:37 신고 댓글주소 | 수정 | 삭제 | 댓글

    아....제가 질문란에 올렸던 질문이 여기서 해결되는군요.......

    사실 여기있는 모든 글들을 저장해서 두세번 보았는데 볼때마다 새롭네요 ㅡ.ㅜ

    제가 후킹하려던 함수가 dll이 동적 로딩해서 IAT에 보이지 않았다는 사실을 뒤늦게 깨달았습니다..

    이제 코드패치로 도전해보려고 하는데요 아 정말 주옥같은글 너무 감사합니다

    도전 ㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱㄱ^^

    • reversecore 2010.04.08 23:01 신고 댓글주소 | 수정 | 삭제

      울터치님, 안녕하세요.

      아, 벌써 문제의 원인을 파악하셨군요.

      궁금하신 점 있으시면 질문 올려주세요~

      감사합니다.

  10. 알려주세요 2012.06.27 21:40 신고 댓글주소 | 수정 | 삭제 | 댓글

    강의 잘보고 있습니다! 그런데 한가지 궁금점이 있습니다.

    CALL hook()을 호출하면 ZwQuerySystemInformation의 첫 5byte가 다시 JMP문으로 바뀔텐데

    이걸 하는 이유가 나중에 또 호출할 일이 있을때를 대비하여 미리 만들어 놓는 건가요?

    그럼 뒤에 나오는 수동으로 JMP XXXX의 XXXX를 구하는 방법은 처음 1번만 해주면 그 외에는

    hook()함수로 자동으로 JMP XXXX로 설정되는건가여?

  11. 게시물이 안보여요 2012.09.27 10:45 신고 댓글주소 | 수정 | 삭제 | 댓글

    API Hooking - 계산기, 한글을 배우다 의 글이 갑자기 안보이는데,
    그 뿐만 아니라 상당수 들이 많이 안보여요ㅠㅠ 무슨일이 있나요?

  12. 멍멍이 2013.10.22 13:58 신고 댓글주소 | 수정 | 삭제 | 댓글

    감사합니다.

  13. 무료 2017.02.13 05:43 댓글주소 | 수정 | 삭제 | 댓글

    관리자의 승인을 기다리고 있는 댓글입니다

  14. 무료 2017.04.02 04:48 댓글주소 | 수정 | 삭제 | 댓글

    관리자의 승인을 기다리고 있는 댓글입니다

  15. 코코넛냠냠 2018.03.27 16:38 댓글주소 | 수정 | 삭제 | 댓글

    관리자의 승인을 기다리고 있는 댓글입니다


리버싱의 참 맛

column 2009.12.04 02:08


<photo : skedonk on flickr>

"끓을 만큼 끓어야 밥이 되지, 생쌀이 재촉한다고 밥이 되나."

윤오영님의 수필 [방망이 깎던 노인] 에 나오는 구절입니다.
필수적인 과정을 거쳐야 제대로 된 결과가 나온다는 뜻이지요.


리버싱을 제대로 하려면 공부해야 할 내용이 무척 많다는 것을 잘 아실 것입니다.
우리는 리버싱 공부에 시간과 노력을 쏟아야 합니다.

하지만 조급한 마음이 사람을 초조하게 만들고 반복된 실패를 참을 수 없게 만드는 것 같습니다.
리버싱을 하다 보면 매 순간마다 (내가 알지 못하는) '벽'에 부딪힙니다.
이러한 '벽'을 도전 과제로 삼고 극복하는 과정에서 희열이 느껴집니다.
제 생각에는 이게 바로 리버싱의 본질이 아닐까 생각합니다.

잘 안 된다고 스트레스 받지 마세요.
리버싱은 원래 "잘 안 되는 속성"을 가지고 있습니다.
마음을 편안하게 먹고 차근차근 정보를 수집하세요.
성공할 때까지 계속 시도해보는 겁니다.
머리 아프면 쉬었다 하세요.
중요한 건 포기하지 말고 꾸준히 하는 것입니다.

마치 퍼즐 조각을 맞추는 것과 같습니다.
해결 방법은 분명히 있습니다.
노력과 시간을 투자한다면 결국에는 성공할 수 있습니다.

어찌 보면 모든 엔지니어링의 본질적인 속성이 이와 같다고 생각됩니다.
결국 시간을 투자하고 노력할 수록 실력이 늘어나는 이치는 똑 같은 것이니까요.

"시간과 노력을 투자한 만큼 정직하게 실력이 쌓여간다."

전 이 맛에 리버싱을 하나 봅니다.

여러분은 어떠신가요?


+---+


요즘 과도한 업무에 심신이 많이 지쳤답니다.
피곤하고, 스트레스 받고, 시간에 쫓기면 사람은 초심을 잃게 되지요.
제 스스로 초심을 되새기고 목표를 향해 끊임없이 나아가고자 다짐하며 글을 올려봅니다.

ReverseCore

  1. 행인 2009.12.04 03:09 신고 댓글주소 | 수정 | 삭제 | 댓글

    .. 전 일주일에 3시간씩밖에 못퍼부어서 실력이 안늘어나는것 같습니당
    ㅠㅠ

  2. L4c0 2009.12.04 11:48 신고 댓글주소 | 수정 | 삭제 | 댓글

    예전에 방망이 깎던 노인.. 프로그래머 버젼이 유행했었죠.. 리버싱 버젼으로 한번.. 만들어보는것도 재미있겠네요 ㅋㅋ 아무튼 좋은말씀 잘 보구 갑니다. 리버싱을 취미로 시작했다보니 실력두 없고.. 다른것에 치여서 끈기를 가지고 하기가 힘드네요. 여기저기 관련 글을 읽기는 많이 읽지만 제가 직접 올리를 켜본게 얼마나 되었는지..

    • ReverseCore 2009.12.04 16:43 신고 댓글주소 | 수정 | 삭제

      zXEr님, 안녕하세요~

      다른 업무에 바쁘신가 봐요~

      꼭 리버싱 목적이 아니더라도 OS 동작 원리 같은 것들은 잘 공부해놓으면 개발 업무에도 크게 도움이 될 것입니다.

      감사합니다.

  3. RED_BIT 2009.12.04 15:49 신고 댓글주소 | 수정 | 삭제 | 댓글

    왠지 코드를 만들어내는 사람과의 싸움... 재밌는거 같아요,
    꼭 이길 필요는 없지만, 이기면 좋은...
    마치 전략게임을 하듯이 상대방의 전략을 파악하고 공략해나가는것이 정말 중요한 포인트가 아닐까 생각해요,
    그러면서 코드는 점점 더러워지는 경향을 뛰기는 하지만 정말 잘만든 코드는 아름답더라고요...
    더려운 코드가 필수적인 과정을 거치지 않고 막아내는데 급급한 코드라면... 아름다운 코드는 오랫경험을 바탕으로 만들어진 안티코드겠죠..

    • ReverseCore 2009.12.04 16:46 신고 댓글주소 | 수정 | 삭제

      RED BIT님, 안녕하세요.

      말씀하신대로 안티 디버깅기법을 연구하는 사람과 그걸 어떻게든 분석하려는 사람들의 전략 싸움은 정말 흥미롭죠.

      그런것들을 분석하는 과정에서 실력도 향상되고 말이죠.

      댓글을 읽어보니 RED BIT 님께서는 리버싱을 재밌게 즐기시는 분 같습니다.

      감사합니다.

  4. 철이 2009.12.05 00:32 신고 댓글주소 | 수정 | 삭제 | 댓글

    많은 반성하고 갑니다.

  5. HS 2009.12.05 01:03 신고 댓글주소 | 수정 | 삭제 | 댓글

    좋은글 잘 보고 갑니다..^^

  6. 늅늅 2009.12.07 09:05 신고 댓글주소 | 수정 | 삭제 | 댓글

    월요일 아침 상큼하게 리버스코어님 블로그로 시작합니다 ^ㅡ^*

  7. 못다한꿈 2009.12.07 22:58 신고 댓글주소 | 수정 | 삭제 | 댓글

    큰 힘이 되었습니다 앞으로 자주들릴께요!^_^

  8. lily marlene 2010.05.04 16:17 신고 댓글주소 | 수정 | 삭제 | 댓글

    개발은 잘 못하면서 리버싱만 할 줄 알게되면, 항상 남이 짜놓은 것만 바라보게 되는 치명적인 결점을 안게 됩니다. 창의력이 엉뚱한 쪽으로 발전할 것 같습니다.
    항상 개발과 리버싱은 병행해야한다고 생각합니다.

    • reversecore 2010.05.05 21:58 신고 댓글주소 | 수정 | 삭제

      lily marlene님, 안녕하세요.

      개발과 리버싱을 겸비하면 여러가지 장점이 무척 많지요.
      내 손에 꼭 맞는 툴을 직접 만들수도 있고요.
      다른 프로그램의 아쉬운 부분을 보강할 수도 있지요..

      저도 (가능하다면) 양쪽을 다 겸비하면 좋다고 생각합니다.

      좋은 말씀 감사합니다.

  9. 화이트해커로의도약 2011.01.31 17:03 신고 댓글주소 | 수정 | 삭제 | 댓글

    제가 이 블로그를 알게된 경위는 요즘 이대역 중***학원에 세미해커과정에 다니면서
    리버스 기초과정 중 crackme문제풀이를 풀다가 도무지 이해가 안가서 검색하던 중
    이렇게 좋은 불로그를 찾게 되었네요^^ 영자님이 꾸며놓으신 블로그 넘넘 좋아서 즐겨
    찾기에 등록해놓고 매일매일 공부하고 있답니다. 정말 감사하게 생각하고요...리버스 정말
    처음 접했을땐 외계언어처럼 풀리지 않는 수수께끼 같았는데 기초서 부터 조금씩 조금씩
    공부하다 보니 어느새 문제를 풀고 있는 나 자신을 발견하게 되었답니다. (crackme에 나오는
    명령어들 개념파악하는데 4일걸림 ㅠ.ㅠ) 그래도 다행인건 포기하지 않고 이해안되는곳을 15번
    정도 다시 읽고 생각하고 하니깐 신기하게도 이해가 되더라고요 ㅡ0ㅡ;; 좋은 자료 올려주신
    운영자님께 다시한번 감사의 말씀 드리면서 좋은글 읽고 갑니다. 자주자주 올께요^^*

    • reversecore 2011.02.09 22:03 신고 댓글주소 | 수정 | 삭제

      안녕하세요.

      칭찬 감사합니다. ^^

      화이트해커(보안전문가)가 되길 원하시는군요.

      공부 열심히 하셔서 꼭 바램을 이루시기 바랍니다.

      감사합니다.

  10. 반벽이 2012.04.04 00:10 신고 댓글주소 | 수정 | 삭제 | 댓글

    좋은글 감사합니다.
    리버서가 되고자 하는는 첫걸음에 선생님(?)의 블로그를 통해 정말 좋은 공부하고 있습니다.^^.


API Hooking - Tech Map

study 2009.09.29 06:39

API Hooking 에서 사용되는 각종 방법들에 대한 Tech Map 을 소개하고 간략한 설명을 하겠습니다.

API Hooking 의 기본 소개는 아래 글을 참고해주세요.

참고: API Hooking - 리버싱의 '꽃'



API Hooking Tech Map


아래 그림이 API Hooking 의 모든 기술적 범주를 포함하는 Tech Map 입니다.


<Fig. 1>

위 Tech Map 을 이용하면 그 동안 막연하게만 보였던 API 후킹이 (기술적으로) 단번에 파악됩니다.

API 후킹 작업을 할 때 상황에 맞게 위의 Tech Map 에서 적절한 기법을 골라서 적용하시면 됩니다. (가장 널리 사용되는 기법은 빨간색으로 표시하였습니다.)


[ Method – Object (what) ]

API 후킹 방식(Method)에 대한 대분류 입니다.

API 후킹 방식(Method)는 작업 대상(Object)에 따라서 크게 static 방식dynamic 방식으로 나눌 수 있습니다.

static 방식은 작업 대상(Object)이 ‘파일’이며, dynamic 방식은 작업 대상이 프로세스 ‘메모리’ 입니다.
일반적으로 API 후킹이라고 하면 dynamic 방식을 말하며, 매우 특수한 상황에서 static 방식을 사용할 때도 있습니다.

각각에 대한 설명은 아래의 표에 정리하였습니다.


<Fig. 2>

* static 방식은 여러 가지 단점 때문에 일반적으로 사용하기에 어려운 부분이 많이 있습니다. 다만 특수한 경우에 사용되기도 하므로 여기서는 소개 정도만 하고 넘어갑니다.


[ Location (where) ]

대상의 어느 부분을 공략(조작)해야 하는지에 대한 내용입니다.

일반적으로 3 군데의 공략 위치가 있습니다.

1) IAT

IAT 에 있는 API 주소를 후킹 함수 주소로 변경하는 방법입니다.

장점은 가장 단순하며, 구현 방법이 가장 쉽습니다.

단점으로는 IAT 에 없는데 프로그램에서 사용되는 API 들에 대해서는 후킹할 수 없습니다. (예: DLL 을 동적으로 로딩해서 사용하는 API)

2) Code

프로세스 메모리에 매핑된 시스템 라이브러리(*.dll)에서 API 의 실제 주소를 찾아가 코드를 직접 수정해버리는 방법입니다.

참고로 이 방법이 가장 널리 사용되는 방법이며, 구현에 있어서 아래와 같은 여러 가지 다양한 옵션이 있습니다.
 
- 처음 5 byte 를 JMP XXXXXXXX 명령어로 패치하는 방법
- 함수 일부를 덮어쓰는 방법
- 필요한 부분만 일부 변경하는 방법

3) EAT

DLL 의 EAT(Export Address Table) 에 기록된 API 의 시작 주소를 후킹 함수 주소로 변경하는 방법입니다.

개념은 간단하지만 코드 구현에 있어서 위 2) 번 방법이 더 간단하고 강력하므로 EAT 수정 방법은 잘 사용되지 않습니다.


[ Technique (How) ]

후킹 대상 프로세스 메모리에 침투하여 후킹 함수를 설치하는 구체적 기법(Technique)에 대한 내용입니다.

크게 Debug 와 Injection 기법으로 나눌 수 있으며, Injection 기법은 다시 Code 와 Dll 기법으로 나뉘어 집니다.

A) Debug

대상 프로세스를 디버깅하면서 API 후킹을 하는 방법입니다.

아마 이 말이 무슨 의미인지 이해가 잘 안 되는 분들이 계실 것입니다.
“그게 디버깅이지 무슨 API 후킹이야?” 하고 말이죠.

디버거(Debugger)는 디버깅 당하는 프로세스(Debuggee)에 대한 모든 권한(실행 제어, 메모리 액세스, 기타)을 가지기 때문에, Debuggee 의 프로세스 메모리에 후킹 함수를 자유롭게 설치 할 수 있습니다.

여기서 얘기하는 Debugger 는 일반적인 OllyDbg, Windbg, IDAPro 등이 아니라, 후킹을 위하여 사용자가 직접 제작한 프로그램입니다.
즉, 프로그램 내에서 Debug API 를 이용하여 대상 프로세스에 Attach 하고 (실행이 잠깐 멈춰진 상태에서) 후킹 함수를 설치합니다. 그 후 실행을 재개시키면 완벽한 API Hooking 이 이뤄지는 것입니다. (XP 이상의 시스템에서는 Debuggee 의 종료 없이 Debugger 를 Detach 시킬 수 도 있습니다.)

물론 기존 디버거(OllyDbg, Windbg, IDAPro)에 자동화 스크립트를 사용하여 API 후킹을 자동화 시키는 방법도 있습니다. (특히 Immunity Debugger 같은 경우 강력한 전용 Python 스크립트를 지원하고 있습니다.)

이 방식의 장점은 구현만 완벽하다면 (하나의 프로세스에 대한) 가장 강력한 후킹 방법입니다. API 후킹 뿐만 아니라 필요에 따라서 실행 흐름 까지도 완벽히 제어할 수 있습니다.

따라서 API 후킹 도중이라도 사용자가 Interactive 하게 프로그램의 실행을 멈추고 API 후킹을 추가/수정/제거 등의 작업을 할 수 있습니다. (다른 방식과 가장 큰 차이점입니다.)

단점은 Debugger 에 대한 지식(혹은 자동화 스크립트에 대한 지식)이 필요합니다. 또한 안정적인 동작을 위해서는 많은 테스트가 요구됩니다. 이와 같은 단점들 때문에 (강력함에도 불구하고) 범용적으로는 사용하기는 쉽지 않습니다.

B) Injection

Injection 기법은 해당 프로세스 메모리 영역에 침투하는 기술로써 Injection 대상에 따라 B-1) Code InjectionB-2) DLL Injection 으로 나눌 수 있습니다. 그 중에서 DLL Injection 기법이 가장 널리 사용됩니다.

DLL Injection 기법은 대상 프로세스로 하여금 강제로 사용자가 원하는 DLL file 을 로딩하게 만드는 기술입니다. (DLL Injection 에 대한 자세한 설명은 예전의 제 글을 참고하세요. DLL Injection - 다른 프로세스에 침투하기 (1))

Injection 할 DLL 에 미리 후킹 코드와 설치 코드를 만들고 DllMain() 에서 설치 코드를 호출해 주면 Injection 되는 순간에 API 후킹이 완료됩니다.

Code Injection 기법은 기존 DLL Injection 보다 좀 더 발전된 (복잡한) 기술이며, 주로 악성코드(바이러스, 쉘코드, 기타)에서 많이 사용됩니다. (DLL Injection 은 AV 제품에서 탐지가 잘 되므로, 악성 코드들은 좀 더 탐지하기 어려운 Code Injection 을 많이 시도하고 있습니다.)

Code Injection 기법의 구현방법은 상당히 까다로운 편입니다. 그 이유는 DLL Injection 처럼 완전한 형태의 PE 이미지가 아니라 실행 코드와 데이터만 Injection 된 상태에서 자신이 필요한 API 주소를 직접 구해서 사용해야 하며, 코드 내의 메모리 주소에 접근할 때 잘못된 주소를 액세스 하지 않도록 매우 주의해야 하기 때문입니다.

말로만 설명하면 어렵습니다. 나중에 코드를 보며 직접 실습을 해보도록 하겠습니다.
(직접 해보시면 왜 어렵다고 말씀 드렸는지 느낌이 팍 오실 것입니다.)

[ API ]

Tech Map 에 소개된 방법들을 실제로 구현하기 위해서 사용되는 API 들을 소개합니다.

한번씩 읽어 보시고 향후 실습할 때 사용법에 대해서 자세히 살펴보도록 하겠습니다.

참고로 위에 소개된 API 말고도 OpenProcess(), WriteProcessMemory(), ReadProcessMemory() API 들은 다른 프로세스 메모리에 접근하려고 할 때 항상 사용되는 API 들입니다.


+---+

설명이 많이 길었습니다.
다소 지루하시더라도 세부 기술 설명에 앞서 이러한 이론적인 설명은 꼭 필요합니다.

위와 같이 Tech Map 으로 전체 기술에 대해 이론적으로 잘 정리해 두면 기술에 대해서 더 잘 이해할 수 있고, 실전에서 (상황에 맞게) API Hooking 을 적용하기 쉬워집니다.

다음 번 포스트에서는 위 방법을 하나씩 실습해 보도록 하겠습니다. (static 방법에 대한 설명은 생략하겠습니다.) 각 경우에 대한 실습을 진행하면서 그때그때 필요한 설명은 자세히 추가하겠습니다.




ReverseCore


  1. 이승철 2009.09.30 11:07 신고 댓글주소 | 수정 | 삭제 | 댓글

    기대됩니다. ㅜㅜ 추석이 오기 전에 빨리 보고 싶네요 ㅜㅜ

    이번 추석은 리버싱과 함께

  2. 2009.10.01 17:04 댓글주소 | 수정 | 삭제 | 댓글

    비밀댓글입니다

  3. 2009.10.02 01:28 댓글주소 | 수정 | 삭제 | 댓글

    비밀댓글입니다

  4. nettok 2009.10.02 07:43 신고 댓글주소 | 수정 | 삭제 | 댓글

    좋은글 잘보고 갑니다.
    앞으로 자주 들러야겠네요 와방 기대됩니다 ^_^

  5. 2009.10.14 15:38 댓글주소 | 수정 | 삭제 | 댓글

    비밀댓글입니다

  6. JWP Programs 2012.02.18 13:03 신고 댓글주소 | 수정 | 삭제 | 댓글

    DebugActiveProcess 를 이용하여 디버그를 하니
    프로세스가 얼어버리는데 어떻게 해결할 수 없을까요??

  7. gsndae 2012.08.21 23:09 신고 댓글주소 | 수정 | 삭제 | 댓글

    안녕하세요. 코어님 덕분에 공부 잘 하고있습니다. 댓글은 처음달아 보네요. 여쭤보고 싶은게 있는데, location의 IAT주소를 변경하는 방법은 IAT에 없지만 사용되는 API를 대상으로는 사용할 수 없다고 하셨는데, 구체적으로 어떤 것들이 있나요??

  8. 2013.03.21 17:25 댓글주소 | 수정 | 삭제 | 댓글

    비밀댓글입니다

    • reversecore 2013.04.01 22:18 신고 댓글주소 | 수정 | 삭제

      안녕하세요.

      아, 죄송합니다.
      저도 최대한 글을 남겨두고 싶었습니다만...
      출판사와 책 구매자분들 때문에 삭제를 하였구요.

      위 본문에 링크를 없애지 못한건 제 실수입니다.
      (수정하였습니다.)

      감사합니다.



API Hooking 에 대한 강좌입니다.
User 에서 API Hooking의 다양한 기법들에 대해서 자세히 설명하도록 하겠습니다.



후킹 (Hooking)

리버싱에서 후킹은 정보를 가로채고, 실행 흐름을 변경하고, 원래와는 다른 기능을 제공하게 하는 기술입니다.

후킹의 전체 프로세스는 아래와 같습니다.

- 디스어셈블러/디버거를 이용하여 프로그램의 구조와 동작원리를 파악
- 버그 수정 또는 기능 개선에 필요한 Hook 코드를 개발 [1]
- 실행 파일과 프로세스 메모리를 자유롭게 조작하여 Hook 코드 설치

위와 같은 일련의 작업들은 그야말로 리버스 엔지니어링 기술의 핵심(Core) 이라고 할 수 있습니다.

그래서 전 후킹을 "리버싱의 꽃" 이라고 부릅니다.

여러가지 후킹 기술이 있지만 그중에서도 API 를 후킹하는 기술을 API Hooking 이라고 하고, User mode 후킹 중에서 메시지 후킹[2]과 함께 가장 널리 사용되는 기술입니다.


[1] 프로그램 소스가 있다면 대부분의 경우 후킹은 필요하지 않을 것입니다. 하지만 특수한 상황(소스 코드가 없거나, 소스 코드의 수정이 여의치 않은 상황)에서는 후킹 기술이 요긴하게 사용될 수 있습니다.

[2] 메시지 후킹(Message Hooking) 에 대한 내용은 제 글을 참고하시기 바랍니다.

- Windows Message Hooking (윈도우 메시지 후킹)



API (Application Programming Interface)


API Hooking 을 설명하려면 먼저 API(Application Programming Interface) 에 대해서 짚고 넘어가야 합니다.

Windows OS 에서는 사용자 어플리케이션이 시스템 자원(메모리, 파일, 네트워크, 비디오, 사운드, 기타)을 사용하고 싶을 때 직접 할 수 있는 방법이 없습니다. 왜냐하면 그것들은 OS 가 직접 관리하며, 여러 가지 이유(안정성, 보안, 효율, 기타)로 사용자 어플리케이션의 직접적인 접근을 막아놓았기 때문입니다.

이럴 때 사용자 어플리케이션은 시스템 커널에게 요청해야 합니다. 요청 방법이 바로 MS 에서 제공한 Win32 API 를 이용하는 것입니다. (API 는 해당 OS 제작사에서 제공합니다.)

즉, API 함수 없이는 어떤 의미 있는 프로그램을 만들어 낼 수 없습니다.

아래 그림은 32 bit Windows OS 의 프로세스 메모리를 간략히 나타낸 것입니다.


<Fig. 1>

실제 어플리케이션 코드를 실행 시키기 위해 많은 시스템 라이브러리(DLL) 들이 로딩됩니다. [3] 모든 프로세스에는 기본적으로 kernel32.dll 이 로딩되구요, kernel32.dll 은 ntdll.dll 을 로딩합니다. (참고로 GUI 어플리케이션에서는 user32.dll 과 gdi32.dll 또한 필수 라이브러리 입니다.)

ntdll.dll 의 역할이 바로 유저 모드 어플리케이션의 코드에서 발생하는 시스템 자원에 대한 접근을 커널 모드에게 요청 하는 것입니다.


간단한 를 들어보겠습니다.
notepad.exe 에서 c:\abc.txt 라는 파일을 열고자 합니다.
코드에서는 msvcrt!fopen() API 를 호출합니다. 그 이후의 API 호출 흐름을 보면 아래와 같습니다.

msvcrt!fopen()
 
kernel32!CreateFileW()
    ntdll!ZwCreateFile()
      ntdll!KiFastSystemCall()
        SYSENTER                     // Intel IA-32 Op Code
          => 커널 모드 진입


일반적인 시스템 자원을 사용하는 API 는 kernel32.dll 과 ntdll.dll 을 타고 가다가 결국 SYSENTER 명령을 통해 커널 모드로 진입하게 됩니다.


[3] 'DLL 로딩(loading)' 이라는 용어보다는 'DLL 매핑(mapping)' 이라는 용어가 더 정확한 표현입니다. Windows 운영체제는 DLL 을 최초 한번만 메모리에 적재(loading) 하고, 그 이후부터는 프로세스에게 매핑(mapping) 시켜주는 메커니즘을 사용합니다.



API Hooking


API Hooking 이란 Win32 API 호출을 중간에서 가로채서 제어권을 얻어내는 것입니다.

API Hooking 의 이점은 다음과 같습니다.

- API 호출 전/후에 사용자의 훅 코드(Hook Code)를 실행시킬 수 있습니다.
- API 에 넘어온 파라미터 혹은 API 함수의 리턴값을 엿보거나 조작 할 수 있습니다.
- API 호출 자체를 취소시키거나 사용자 코드로 실행 흐름을 변경시킬 수 있습니다.

이해를 돕기 위해 아래 그림을 봐주시기 바랍니다.

먼저 정상적인 API 호출입니다.


<Fig. 2>

코드 영역 주소에서 CreateFile() API 를 호출하였습니다. [4]

CreateFile() API 는 kernel32.dll 에서 서비스(export) 하므로 kernel32.dll 영역의 CreateFile() API 가 실행되고 정상적으로 리턴합니다.

[4] 실제 kernel32 에서 서비스되는 API 이름은 CreateFileA() 와 CreateFileW() 입니다. 프로그래밍할 때 CreateFile() 만 써주면 컴파일 시에 적절히 CreateFileA()/CreateFileW() 중에서 결정됩니다. 여기서는 설명의 편의상 CreateFile() 로 하였습니다.


다음은 kernel32!CreateFile() 가 후킹된 경우입니다.


<Fig. 3>

사용자가 DLL Injection 기술로 hook.dll 을 프로세스 메모리 공간에 침투 시킵니다. 그리고 kernel32!CreateFile() 를 hook!MyCreateFile() 로 후킹하였습니다. (후킹 함수 설치 방법은 DLL Injection 말고도 더 있습니다.)

이제부터 해당 프로세스에서 CreateFile() API 가 호출 될 때마다 kernel32!CreateFile() 이 호출 되는 것이 아니라, hook!MyCreateFile() 이 호출 됩니다.

후킹 함수(MyCreateFile)와 원본 함수(CreateFile)의 호출 순서는 경우에 따라 달라집니다.
입력된 파라미터를 조작하고 싶을 때는 후킹 함수가 먼저 실행되고 나중에 원본 함수가 실행됩니다. 또한 API 리턴값을 조작하고 싶을 때는 원본 함수가 먼저 실행된 후 후킹 함수가 나중에 실행됩니다.

이 외에도 후킹 목적에 따라서 원본 함수 호출 전/후에 후킹 함수를 실행시키거나 원본 함수를 아예 호출하지 않는 등의 여러 가지 변형이 가능합니다. 따라서 후킹 목적과 상황에 따라서 적절히 사용해 주시면 되겠습니다.

이것이 바로 API Hooking 의 기본 개념입니다.

API Hooking 을 구현하는 방법은 다양합니다. 하지만 후킹의 기본 개념은 변하지 않습니다.

위의 개념을 잘 이해하시면 이후에 설명 드리는 구현 방법에 대해서도 쉽게 이해하실 수 있습니다.


+---+

다음 포스트로 이어집니다.

API Hooking - Tech Map


ReverseCore

  1. 마플 2009.09.29 16:01 신고 댓글주소 | 수정 | 삭제 | 댓글

    글 잘 봤습니다.
    정말 깔끔하네요. 멋져요~

  2. alex 2009.11.12 13:39 신고 댓글주소 | 수정 | 삭제 | 댓글

    정말 글쓰는데 재주가 있으세요!
    너무너무 잘 쉽게 풀어쓰셨네요!
    좋은글 많이보고 많은 지식얻어갑니다!!

    많은글 써주세요!! >.<

  3. alex 2009.11.12 13:40 신고 댓글주소 | 수정 | 삭제 | 댓글

    책 한권 쓰심이... ㅎㅎ 그림들도 넘 깔끔하고 좋네요 ㅋ

    • reversecore 2010.04.01 10:08 신고 댓글주소 | 수정 | 삭제

      alex님, 안녕하세요.

      제가 예전에 이 댓글을 못 보고 지나쳤군요. ㅠㅠ

      책도 쓰고 싶은 욕심이 있습니다.

      칭찬 감사합니다. ^^

  4. 정기욱 2010.03.31 13:43 신고 댓글주소 | 수정 | 삭제 | 댓글

    후킹에대해서 찾던중 잘보고갑니다. 깔금하네요..^^

  5. 안정현 2010.06.17 11:04 신고 댓글주소 | 수정 | 삭제 | 댓글

    윈도우 구조대충. 어셈블리어대충 해석할정도.허접실력인데요/..
    HACK.DLL 의소스처럼 C언어 로 소슨나열해놓은게 해석이 안돼네요 ㅜㅜ,.
    그 소스들이 C언어인가요? C언어는 배웠는데 .. 뭐가뭔지 몰르겟어요 ㅜㅜ
    일단 뭐부터공부를해나가야할지막막하네요.. 하고는싶은데 .

    • reversecore 2010.06.17 23:59 신고 댓글주소 | 수정 | 삭제

      리버싱을 처음 시작할 때는 막막한 느낌이 드는게 사실이죠.

      제 경험상 리버싱은 디버깅부터 시작하시는게 좋을것 같습니다.

      아주 간단한 프로그램을 디버깅 하면서 하나씩 배우는 것이죠.

      제 블로그의 처음 부터 읽어보시기 바랍니다.

      감사합니다.

  6. BM 2010.06.24 17:41 신고 댓글주소 | 수정 | 삭제 | 댓글

    안녕하세요?

    후킹 함수 설치 방법에 DLL Injection 말고 다른 어떤 방법이 있는지 구체적으로 알고 싶습니다.

    • reversecore 2010.06.25 10:21 신고 댓글주소 | 수정 | 삭제

      아래 강좌의 TechMap 그림에 정리를 해 놓았습니다.

      http://www.reversecore.com/55

      유저모드에서 크게 아래와 같은 방법이 있구요...
      DLL Injection
      Code Injection
      Debug
      Static patch
      ...

      각 방법별로 구현하는 기법들이 다양하게 존재합니다.

      또 궁금하신 점은 다시 질문 올려주세요

      감사합니다.

  7. 2010.12.10 19:14 댓글주소 | 수정 | 삭제 | 댓글

    비밀댓글입니다

  8. 박은선 2011.01.05 01:08 신고 댓글주소 | 수정 | 삭제 | 댓글

    언제나 검색엔진을 통해 들어오지만, 늘 감동이네요! 윗분 말씀처럼, 책을 쓰셔도 되실 내공인듯!

  9. 박정운 2011.08.06 10:20 신고 댓글주소 | 수정 | 삭제 | 댓글

    당신은 정말 정말 천재입니다.
    이런방법까지 동원할수 있다는게 그저 신기할따름이고
    읽고 또 읽고 그러지만, 책으로 이런 내용들이 나와서 퍼지게 되면 정말 골치아파질수도 있겠다 생각이 듭니다. 물론 악의적으로 이용하지 않는다면 문제가 안되겠지만,
    정말이지 글 잘 보고 인쇄까지 해서 분석하고 있습니다. 감사합니다.

    • reversecore 2011.09.19 20:24 신고 댓글주소 | 수정 | 삭제

      API Hooking 을 비롯한 리버싱 기술들은 제가 만들어낸 것은 하나도 없구요. 저또한 다른 사람들이 해놓은 지식과 경험을 배운것 뿐입니다.

      그사람들이 천재인 셈이지요. ^^

      감사합니다.

  10. 2011.08.13 20:39 댓글주소 | 수정 | 삭제 | 댓글

    비밀댓글입니다

  11. sizn 2011.09.07 11:00 신고 댓글주소 | 수정 | 삭제 | 댓글

    글쓰기도 잘하시고 글 이해도를 높히게 그림도 적절히 넣어주시는 센스
    잘보고 갑니다.

    아이폰 개발자로 현재 WM개발을 하면서 들리게 되었네요 ㅎ
    항상 건승하세요!~바잇!

  12. 알려주세요 2012.06.30 23:14 신고 댓글주소 | 수정 | 삭제 | 댓글

    글을 읽다가 한가지 궁금점이 생겨서 올립니다.

    Window에서는 웬만한 프로그램 전부 OS의 개입이 필요하니 무슨 언어든 결국 WIN32 API를 호출하

    는 건가요?

  13. imovator 2012.07.12 13:26 신고 댓글주소 | 수정 | 삭제 | 댓글

    리버싱이라! 좋은 개념 배우고 갑니다.
    후킹이란걸 처음 들어본 저에게 단번에 이해를 시켜주는 좋은 글이었습니다.



지금까지 우리가 원하는 DLL 을 "실행중인" 프로세스에 강제로 Injection 시키는 방법에 대해서 알아봤습니다.

이번에는 접근 방법을 바꿔서 아예 대상 프로그램 "파일을 직접 수정"하여 DLL 을 강제로 로딩하도록 해보겠습니다.
이 방법은 한 번 적용해 놓으면 (별도의 Injection 과정없이) 프로세스가 시작할 때마다 원하는 DLL 을 로딩하게 만들 수 있습니다. 일종의 크랙이라고 생각하시면 됩니다.

목표는 notepad.exe 파일을 직접 수정하여 실행 시 myhack3.dll 을 로딩하도록 만드는 것입니다.
이를 위해서는 PE Header 를 자유자재로 다룰 수 있는 실력이 필요합니다.

IDT(Import Directory Table)와 기타 PE File Format 에 대해서는 아래의 글을 참조하시기 바랍니다.

- PE(Portable Executable) File Format (6) - PE Header



myhack3.dll


먼저 로딩 시킬 DLL 의 소스를 보겠습니다.

// myhack2.cpp
// ReverseCore

include "windows.h"

#define DEF_CMD  "c:\\Program Files\\Internet Explorer\\iexplore.exe"
#define DEF_ADDR "www.naver.com"

#ifdef __cplusplus
extern "C" {
#endif
__declspec(dllexport) BOOL start()
{
    char szCmd[MAX_PATH] = {0,};
    STARTUPINFO si = {0,};
    PROCESS_INFORMATION pi = {0,};

    si.cb = sizeof(STARTUPINFO);
    si.dwFlags = STARTF_USESHOWWINDOW;
    si.wShowWindow = SW_HIDE;

    // IE 를 hidden window 로 실행시켜 naver 에 접속합니다.
    wsprintf(szCmd, "%s %s", DEF_CMD, DEF_ADDR);
    if( !CreateProcess(NULL, (LPTSTR)(LPCTSTR)szCmd, 
                       NULL, NULL, FALSE,
                       NORMAL_PRIORITY_CLASS,
                       NULL, NULL, &si, &pi) )
        return FALSE;

    if( pi.hProcess != NULL )
        CloseHandle(pi.hProcess);

    return TRUE;
}
#ifdef __cplusplus
}
#endif

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    switch( fdwReason )
    {
        case DLL_PROCESS_ATTACH :
            start();
            break;
    }
  
    return TRUE;
}

myhack3.dll


기능은 지난번과 마찬가지로 IE 를 hidden 속성으로 실행시켜 Naver 초기화면에 접속시키는 것입니다.

가장 눈에 띄는 것은 start() EXPORT 함수입니다.

PE 파일에서 어떤 DLL 을 IMPORT 한다는 것은 코드내에서 그 DLL 의 EXPORT 함수를 호출한다는 의미입니다. 그래서 myhack3.dll 파일은 형식적인 완전성을 위해 EXPORT 함수를 제공해야 합니다. (실제로 notepad.exe 내부에는 myhack3.dll!start() 함수를 호출하는 코드 같은건 존재하지 않습니다.)

프로그래밍에서 DLL 의 IMPORT 는 컴파일러/링커가 해주지만, 저는 이 작업을 PE View 와 Hex Editor 만을 가지고 수동으로 해보겠습니다. (제 환경은 WinXP SP3 KOR 버전입니다. OS 와 SP 버전에 따라서 방법이 약간 틀려질 수 있습니다.)



파일 변경 아이디어 

notepad.exe 파일이 실행될 때 자동으로 myhack3.dll 파일을 로딩하기 위해서는 PE Header 의 IMPORT DIRECTORY TABLE 에 myhack3.dll 을 (IMPORT 하도록) 추가해야 합니다.

notepad.exe 원본과 제가 수정한 notepad_hack.exe 를 첨부합니다.

notepad.exe

notepad_hack.exe


PE View 를 이용하여 notepad.exe 의 IDT 의 주소를 확인해 보겠습니다. IMAGE_OPTIONAL_HEADER 의 IMPORT Table RVA 값이 바로 IDT 의 RVA 입니다.


<Fig. 1>

위 그림에서 IDT 주소는 RVA 로 7604 입니다. 이를 PE View 로 따라가 보겠습니다. (PE View 의 주소 보기 옵션을 "RVA" 로 해주세요.)



<Fig. 2>

IDT 는 <Fig. 2> 와 같이 IMAGE_IMPORT_DESCRIPTOR(이하 IID) 구조체 배열로 되어 있으며, 마지막은 NULL 구조체로 끝납니다. IMPORT 하는 DLL 파일 하나당 IID 구조체 하나가 필요합니다. (IID 구조체 하나의 크기는 14h bytes)

PE View 의 주소 보기 옵션을 "File Offset" 으로 변환하면 IDT 의 file offset 은 6A04 입니다.
Hex editor 를 이용해 6A04 주소를 찾으면 아래 그림과 같습니다.


<Fig. 3>

IDT 는 file offset 으로 6A04 ~ 6ACC 범위에 있으며, 전체 크기는 C8 입니다.
마지막 NULL 구조체를 포함하여 총 10개의 IID 구조체가 있습니다. 

처음에 전 IDT 마지막에 myhack3.dll 을 위한 IID 구조체를 추가하려 했습니다만, 더 이상 추가할 공간이 없습니다. (마지막 NULL 구조체는 꼭 필요하거든요.)

그래서 Hex editor 로 notepad.exe 의 빈 영역(사용되지 않는 영역)을 찾아 보았습니다.
<Fig. 4> 에서 보이는 것처럼 마침 파일 끝부분에 알맞은 크기가 비어 있네요.

* 만약 파일에 빈 영역이 보이지 않는다면 파일 끝에 새로운 섹션을 추가하거나, 또는 마지막 섹션의 크기를 늘리는 방법을 사용해야 합니다.


<Fig. 4>

바로 이 위치(file offset = 10710, RVA = 13310)에 새로운 IID 를 만들것입니다.

주의 하실 점은 저 영역(file:10710 ~ 107FF, RVA:13310 ~ 133FF)이 과연 메모리에 로딩되는 영역인지 확인하는 것입니다.
파일에 존재한다고 해서 반드시 메모리에 로딩되는 것은 아닙니다. 섹션 헤더에 명시된 영역만 메모리에 로딩됩니다.


notepad 의 마지막 섹션 헤더(".rsrc") 를 살펴보겠습니다.


<Fig. 5>

RVA = B000 이고 VirtualSize = 8304 이므로 메모리에 로딩되는 영역은 RVA = 13304 까지입니다.
하지만 <Fig. 4> 의 파란색 영역(RVA:13310 ~ 133FF)은 포함되지 않는 영역입니다.

그렇다면 이부분은 메모리에 로딩되지 않을까요?
실제로는 메모리에 로딩됩니다. 이유는 notepad 에서 IMAGE_OPTIONAL_HEADER 의 SectionAlignment 값이 1000 이기 때문에 마지막 섹션(".rsrc")헤더에 명시된 위치(RVA=13304)는 실제로 14000 까지 확장됩니다. (기본 단위의 배수)

디버거에서 확인해 보겠습니다.

<Fig. 6>

위 그림을 보시면 notepad 프로세스 메모리에서 마지막 섹션(".rsrc")의 VirtualSize 값이 9000 으로 확장된 것을 보실 수 있습니다. <Fig. 5> 의 실제 VirtualSize 값은 8304 였으나 SectionAlignment (1000) 의 배수인 9000 으로 자동 확장된 것입니다.

따라서 RVA = 13310 위치에 새로운 IID 를 만드는 것은 문제가 없습니다.



IDT(Import Directory Table) 변경


notepad.exe 를 복사하셔서 이름을 notepad_hack.exe 로 변경해주세요.
이제부터 notepad_hack.exe 파일을 가지고 변경 작업을 진행합니다.

#1. IMPORT Table 의 RVA 값 변경

PE View 를 기준으로 설명드리겠습니다.
IMAGE_OPTIONAL_HEADER 의 IMPORT Table 구조체 멤버는 IDT 의 위치와 크기를 알려줍니다. <Fig. 1> 을 보시면 현재 IMPORT Table 의 RVA 값은 7604 입니다. Hex editor 에서 이 값을 새로운 IDT 의 RVA 값인 13310 으로 변경합니다. 그리고 Size 값을 기존 C8 에 14 (IID 구조체 크기) 를 더한 값인 DC 로 변경합니다. (Size 멤버는 수정 하지 않아도 됩니다.)


<Fig. 7>

PE View 로 확인하면 아래 그림과 같습니다.

<Fig. 8>

이제 notepad 실행 시 PE Loader 는 IDT 가 RVA = 13310 에 존재한다고 간주합니다.

#2. BOUND IMPORT TABLE 사용 안함


PE HEADER 에서 BOUND IMPORT TABLE 은 DLL 로딩 속도를 조금 향상시킬 수 있는 기법입니다. 이 값을 그냥 놔둬도 문제 없는 경우가 많지만, 제가 테스트할 때는 myhack3.dll 이 정상동작하지 않았습니다. (편하게 작업하시려면 이 값을 무조건 0 으로 밀어버리시기 바랍니다.)

Hex editor 를 이용해서 BOUND IMPORT Table 영역(RVA, Size)을 0 으로 밀어버립니다.

<Fig. 9>

PE View 로 확인해 볼까요?

<Fig. 10>

#3. 새로운 IDT 생성

기존 IDT (file = 6A04 ~ 6ACB, RVA = 7604 ~ 76CB) 를 복사하여 새로운 위치(file = 10710, RVA = 13310)에 붙여넣고, 나머지 지저분한 데이타들은 깔끔하게 NULL 로 밀어버립니다.

<Fig. 11>

이 상태에서 아래와 같이 myhack3.dll 을 위한 IID 를 구성하여 새로운 IDT 끝에 추가시킵니다.
(각 멤버의 데이타에 대해서는 아래에서 따로 설명드리겠습니다.)

typedef struct _IMAGE_IMPORT_DESCRIPTOR {
    union {
        DWORD   Characteristics;            
        DWORD   OriginalFirstThunk;       // INT(Import Name Table) => 8750
    };

    DWORD   TimeDateStamp;                // => FFFFFFFF

    DWORD   ForwarderChain;               // => FFFFFFFF
    DWORD   Name;                         // library name => 8760
    DWORD   FirstThunk;                   // IAT(Import Address Table) => 1348
} IMAGE_IMPORT_DESCRIPTOR;


아래는 Hex editor 로 작업한 그림입니다. (IDT 마지막에 myhack3.dll 을 위한 IID 를 추가)

<Fig. 12>

#4. IID(IMAGE_IMPORT_DESCRIPTOR) 구성

앞 단계에서 추가한 IID 구조체 멤버들이 정상적으로 동작하기 위해서 적절한 세팅이 필요합니다.

먼저 INT(Import Name Table) 와 Name 멤버 설명입니다. 
이 값들은 각각 RVA = 8750 (file = 7B50), RVA = 8760 (file = 7B60) 입니다.

참고로 이 위치는 첫번째 섹션(".text")의 끝부분으로써 빈 영역입니다. 제가 편의상 이 영역을 선정한 것이며 다른 위치에 선정하셔도 상관 없습니다.

일단 Hex Editor 로 RVA = 8750 (file = 7B50) 위치로 가서 아래 그림과 같이 값을 입력합니다.

<Fig. 13>

위 그림에 나타난 값들의 의미를 설명드리겠습니다.

INT 는 쉽게 말해서 RVA 배열인데요, 배열의 각 원소는 Import 하는 함수의 Ordinal(2 bytes) + Func Name String 구조체의 주소(RVA) 를 나타내며 배열의 끝은 NULL 입니다. 

<Fig. 13> 에서 INT 에는 1 개의 원소가 있고 그 값은 RVA 8770 입니다. RVA 8770 으로 가보면 Import 하려는 함수의 Ordinal (2 bytes) 와 함수 이름 문자열이 나타납니다.

Name 은 Import 하는 함수를 제공하는 DLL 파일의 이름 문자열 입니다. "myhack3.dll" 이라고 보이시죠?

마지막으로 IID 의 IAT(Import Address Table) 멤버에 대해 설명드리겠습니다.

#3 에서 IAT 값을 RVA = 1348 (file = 748) 로 세팅하였습니다. 참고로 이 위치는 원래 notepad 의 IAT 영역의 끝 부분입니다.
(INT 데이타와 IAT 데이타는 각각 뭉쳐서 존재합니다.)


<Fig. 14>

IAT 역시 RVA 배열입니다. 각 원소는 INT 와 같은 값을 가져도 좋고 NULL 을 가져도 좋습니다. INT 가 정확하다면 IAT 는 다른 값을 가져도 상관없습니다. 어차피 실행 시에 PE Loader 에 의해 메모리 상에서 실제 함수 주소로 덮어써집니다. (간혹 NULL 을 넣었을때 에러는 발생하지 않지만 DLL 이 정상 동작하지 않을 때가 있습니다. 확실한 건 INT 와 같은 값을 써주면 정확히 동작합니다.)

* 반드시 IAT 를 기존 IAT 영역에 쓸 필요는 없습니다만, 프로세스에 따라서 혹은 DLL 에 따라서 정상 동작하지 않는 경우가 있습니다. 세심한 테스트가 필요한 부분입니다.

여기까지 제대로 따라 하셨으면 작업끝입니다.



검증 (Test)


새로 만든 notepad_hack.exe 파일을 PE View 로 열어보겠습니다.


<Fig. 15>

마지막 섹션(".rsrc")로 IDT 가 옮겨졌으며, myhack3.dll 을 IMPORT 시키기 위한 IID 구조체가 정상적으로 세팅된 것을 확인 하실 수 있습니다.


<Fig. 16>

<Fig. 16> 에서 추가된 INT 도 확인 하실 수 있습니다.

notepad_hack.exe 와 myhack3.dll 파일을 같은 폴더에 넣고 notepad_hack.exe 를 실행해 보겠습니다.
Process Explorer 로 확인하면 아래 그림과 같습니다.


<Fig. 17>

notepad_hack.exe 에 myhack3.dll 이 로딩되어서 IE 가 정확하게 실행되는 화면을 보실 수 있습니다.

성공입니다!



Epilogue


설명이 길어서 자칫 복잡하게 느끼실 수 있습니다.

Import Directory Table 에 내가 원하는 dll 을 추가시켜서 실행 시 자동으로 로딩하게 한다는 기본 원리만 확실히 이해하시고, 관련된 PE Header 를 참고하시면 쉽게 하실 수 있으실 겁니다.

단, OS 와 SP 버전에 따라서 PE Loader 의 구현이 조금씩 다를 수 있으니 처음 하시는 분들께서는 약간의 시행 착오를 거치셔야 합니다. 또한 대상 프로세스와 DLL 파일의 프로그래밍에 따라서 약간씩 방법을 달리 적용해야 하는 경우도 있습니다.

그러나 위의 원리를 이해하신다면 어렵지 않게 해내실 걸로 생각합니다.


+---+


다음번에는 프로세스에 Injection 된 DLL 을 강제로 꺼내는 기법인 DLL Ejection 에 대해서 알아보도록 하겠습니다.


ReverseCore



  1. NIKA 2009.08.14 14:27 신고 댓글주소 | 수정 | 삭제 | 댓글

    멋진글 잘보고 있습니다 ^^

  2. lscpjyoon 2009.09.17 21:52 신고 댓글주소 | 수정 | 삭제 | 댓글

    정말로 명 강의다.

    이 글을 읽으면서 문득 한가지 궁금한것이 있다면

    무슨일을 하시는분 인지 갑자기 궁금해 지네요 ;

    • reversecore 2009.09.17 22:46 신고 댓글주소 | 수정 | 삭제

      lscpjyoon님, 칭찬 감사합니다. ^^
      저는 Reverse Code Engineer 입니다.
      국내의 리버싱 기술 향상, 교류, 전파에 관심이 많습니다.

  3. juhens 2010.01.20 23:10 신고 댓글주소 | 수정 | 삭제 | 댓글

    아우..제가 궁금해했던것입니다...
    고등학생때 거진 3년정도......전공이 이쪽계열이 아니라
    네이버에 질문을해봐도 대답을 해주는사람은 없고........
    우연히 여기서 궁금증을 해결하네요... 정말 감사합니다.

    • reversecore 2010.01.21 01:28 신고 댓글주소 | 수정 | 삭제

      juhens님, 안녕하세요.

      고등학교 때부터 벌써 리버싱에 관심이 있으셨군요.

      도움이 되셨다니 제가 기쁘네요~ ^^

      감사합니다.

  4. LHS 2010.04.04 17:51 신고 댓글주소 | 수정 | 삭제 | 댓글

    와... 현재 리버싱에 관심이 많은 고2 학생에게는 단비와 같은 곳이네요...

    그런데 질문 하나 드려도 될까요?? 제가 이 글을 읽고 적당한 프로그램을 고르고 직접 시도해 보려고 했는데 위의 사진과 좀 다른 점이 있어서요...

    제가 DLL Injection을 시도한 프로그램에서는 모든 DLL의 IMPORT Directory Table에서 Import Name Table RVA, Time Data Stamp, Forwarder Chain이 모두 00000000이네요... 이 글을 읽고 따라해 봤지만 계속 오류 메시지만 뜨고... 어떻게 해야 하나요??
    (아, 또 이상한 점이 있네요... 제가 시도한 프로그램에서는 IMPORT Directory Table, IMPORT Address Table, IMPORT DLL Names, IMPORTS Hints/Names 항목(?)이 모두 rdata 섹션에 있네요... 원래 rdata섹션은 리소스가 있는 곳 아닌가요??

    • reversecore 2010.04.05 23:04 신고 댓글주소 | 수정 | 삭제

      LHS님, 안녕하세요.
      반갑습니다. ^^

      PE 파일에 따라서는 지적하신 3 가지 항목이 0 인 파일도 있을 수 있습니다. 보통 packer 류에 많지요.

      하지만 그런 파일도 Import Address Table RVA 항목은 값이 있을테니, 그걸 따라가면 Import Name Table RVA 와 같은 역할을 합니다.

      그리고 섹션 이름은 개발 도구에 따라서 달라지고요,
      packer 를 사용하면 변경할 수 있으며, 사용자가 수동으로 조작할 수 도 있습니다. 그리 중요한 의미는 없지요.

      또한 Import Directory Table 이 딱히 어느 섹션에 있어야 한다는 규칙같은건 없습니다. 그리고 그 섹션의 이름도 정해진건 없구요.

      리소스는 보통 .rsrc 섹션에 있는 경우도 많지만 위에서 설명드린바와 같이 다른 섹션 이름을 가지기도 합니다.

      PE File Format 은 상당히 느슨한 편이라서 어떤 절대적인 규칙이라고 할 만한 내용은 몇 개 되지 않습니다. 또한 그 규칙들 또한 OS 버전에 따라서 조금씩 다르게 적용되는 현실입니다.

      다른 질문 있으시면 또 올려주세요~

      감사합니다.

  5. gamjadory 2010.04.11 00:56 신고 댓글주소 | 수정 | 삭제 | 댓글

    잘 보고 갑니다. 혹 dll 파일을 이용한 메모리 영역 변환에 대한 강좌는 없는지요... ㅠㅠ

    • reversecore 2010.04.11 23:04 신고 댓글주소 | 수정 | 삭제

      gamjadory님, 안녕하세요.

      메모리 영역 변환이란게 어떤 의미인지요?

      일단 프로세스에 침투하고 나면 프로세스 메모리의 내용 혹은 메모리 영역의 속성등은 전부 변경 가능해 집니다.

      혹시 질문하신 내용이 이와 다른 것인가요?

      감사합니다.

  6. 리버싱나그네 2010.08.06 12:58 신고 댓글주소 | 수정 | 삭제 | 댓글

    정말 열심히 강좌를 따라가고 있는데..ㅡㅜ 그림처럼 되지 않는 부분이 있어서요 ㅜㅜ 노트패드의 빈영역 그러니까 사용하지 않는 영역을 어떻게 찾죠? ㅜㅜ 그냥 00000 ~~ 이렇게 쭉~ 되어있는 곳에 복사해서 넣고 import table 값을 복사해서 넣은 주소로 바꿧는데, 자꾸 오류가 나구.. 그림처럼 되지를 않아요 ㅜㅜ 설명을 보면, DINGPADDINGXXPAD 라고 써져있는 곳이 있던데 저는 헥사로 봐두 그런 영역은 없어요 ㅜㅜ 문제가 뭘까요 리버스 코어님 ㅜㅜ(환경 : 윈도우 7)

  7. 리버싱나그네 2010.08.09 20:36 신고 댓글주소 | 수정 | 삭제 | 댓글

    감사합니다 ^^

    • reversecore 2010.08.10 12:39 신고 댓글주소 | 수정 | 삭제

      안녕하세요.

      제가 마침 예전에 월간 마소에 기고한 글이 있는데,
      바로 위 글의 내용을 Windows 7 으로 변경한 것입니다.

      아마 원하시는 내용이 이곳에 있을 것 같네요.

      제가 댓글로 따로 써드릴려고 보니... 아무래도 그림과 같이 보시는게 이해가 쉬우실것 같습니다...

      메일 주소를 알려주시면 해당 문서를 보내드리겠습니다. (잡지사와 협업한 문서라 원본 전체를 보내드릴 수 없음을 양해해 주시기 바랍니다.)

      감사합니다.

  8. 2010.08.10 21:02 댓글주소 | 수정 | 삭제 | 댓글

    비밀댓글입니다

  9. BlueH4G 2010.08.13 21:52 신고 댓글주소 | 수정 | 삭제 | 댓글

    헛,, 이번 글 보고 괜찮은 워게임이 떠올라서, 하나 만들어보네요 ㅋㅋ

    항상 리버스코어에서 많은 정보 얻어갑니다. ㅋ 앞으로도 좋은 글 많이 부탁드려요 xD

  10. binish 2010.08.17 11:47 신고 댓글주소 | 수정 | 삭제 | 댓글

    정말 모든 글에 정성이 깃들여져 있고 내공이 느껴집니다.
    훌륭한 강의에 감사드립니다.

  11. jaew 2011.02.15 16:50 신고 댓글주소 | 수정 | 삭제 | 댓글

    우연히 들어와서 그동안 궁금했던 것들이 해소되네요. 좋은 강의 잘 보았습니다. 감사합니다. !

  12. LinkC 2011.02.16 09:02 신고 댓글주소 | 수정 | 삭제 | 댓글

    IDT를 다른 section 으로 옮길 때 간혹 기존에 IDT가 있던 section 에

    쓰기 속성이 없으면 Access Violation 이 나는 경우가 있더군요.

    좀 더 조사해보면 나올거 같긴 한데 혹시 이 점에 관해 알고 계신가요?

    • reversecore 2011.02.18 22:41 신고 댓글주소 | 수정 | 삭제

      안녕하세요.

      수작업으로 IDT 를 변경하고 계신가요?

      ACCESS_VIOLATION 은 아마 IAT 때문일 것으로 생각됩니다. IAT 를 수작업으로 재작성 할때는 쓰기 속성을 주시는 것이 안전합니다. (IAT 는 로딩시에 로더가 실제 주소값을 채워주기 때문입니다.)

      혹시 다른 이유 때문이라면 해당 파일을 간략한 설명과 함께 저에게 보내주시면 제가 한번 봐드리겠습니다.

      reversecore@gmail.com

      감사합니다.

  13. Rony 2011.03.30 11:17 신고 댓글주소 | 수정 | 삭제 | 댓글

    글읽다가 질문이 있어서 글 남깁니다..

    optional_hearer의 import_table 주소를 7604에서 13310으로 변경 한 후에

    왜 size값을 dc로 변경하는지 모르겠습니다. 7606 rva가 가르키는 곳은 import table이고 이곳은

    IDT, 즉 IID구조체의 배열일 탠데요.. 새로 IID를 하나 더 작성한 것도 아닌데 14h를 왜 더해주는거죠?

    • reversecore 2011.04.13 00:11 신고 댓글주소 | 수정 | 삭제

      안녕하세요.

      myhack3.dll 을 import 시키기 위해서 실제로 IID 구조체 하나를 추가하였습니다. 그래서 구조체 크기(0x14) 만큼 늘려준 것입니다.

      감사합니다.

  14. SmartSnake 2011.10.27 17:42 신고 댓글주소 | 수정 | 삭제 | 댓글

    위에 virtualAddress는 어디에 명시되있어서 b0000 - (virtualaddress) + 8400 해야되는데
    버추얼 어드레스는어떻게 아셧나요.. ㅠㅠ;;

  15. 알려주세요 2012.06.30 19:06 신고 댓글주소 | 수정 | 삭제 | 댓글

    myhack.dll을 보면은 CreateThread를 통해 ThreadProc을

    호출했는데 이런거를 제외하면 전부 export를 해줘야 하나

    요?

  16. louboutin uk 2013.04.21 00:11 신고 댓글주소 | 수정 | 삭제 | 댓글

    착한 아내와 건강은 남자의 가장 훌륭 한재산이다.

  17. chlehd 2014.01.10 18:17 신고 댓글주소 | 수정 | 삭제 | 댓글

    안녕하세요. 내주신 책 읽고 열심히 공부하는 한 뉴비입니다.
    제가 어떤 패커로 packing된 프로그램을 뚫어보려고 하는데요,
    ollydbg로 하나하나 진행하려다 안되서 dll injection으로 뚫을 수 없을까 하는데,
    아무래도 그 프로그램이 CreateRemoteThread() 함수를 감지하는 것 같아서 이전 방법들은 아예
    쓸 수가 없어서 이 방법으로 시도해보려고 합니다.
    만약 패킹이 다 풀린 그 시점에서 jmp하고 난 바로 그때를 감지하는 방법이 있을까요?

  18. yoo870701 2014.08.16 16:15 신고 댓글주소 | 수정 | 삭제 | 댓글

    안녕하세요
    잘 안되는 것이 있어 질문드립니다.
    책 내용대로 INT, IAT 모두 셋팅해서 PeView 로 올바르게 셋팅된것을 확인후
    TestView_Patched.exe 를 실행하니
    프로시저 시작지점 을 DLL myhack3.dll 에서 찾을수 없습니다.
    라는 에러를 뿜어냅니다.

    환경은 xp sp3, visual c++ 2010 express입니다.
    myhack3.dll과 TestView_Patched.exe은 당연히 같은폴더에 있습니다.
    뭐가 문제일까요

  19. ㅇㅇ 2015.05.25 02:39 댓글주소 | 수정 | 삭제 | 댓글

    관리자의 승인을 기다리고 있는 댓글입니다

  20. 리버싱스터디 2017.03.31 18:43 댓글주소 | 수정 | 삭제 | 댓글

    관리자의 승인을 기다리고 있는 댓글입니다





티스토리 툴바