API Hooking

출처(클릭)

API후킹이란?...


1. API는 DLL파일안에 들어있습니다.
API함수를 사용한다는것은 윈도우가 제공하는 DLL안에 들어있는 함수를 사용하는겁니다.
그러므로 API후킹을 한다는것은 다른 프로그램이 DLL의 함수를 사용하는것을 내가 가로채는것을 말합니다.


API 후킹의 목적...


2. 가로채서? 그 다음은 그 함수의 기능을 사용하지 못하게 할수도 있고 어떻게 사용하는지 감시만 할 수도 있고 전혀 다른 내용으로 바뀌게끔 할 수도 있습니다. 그러므로 이것을 이용해서 할 수 있는 일을 두가지 정도로만 야그해보면...

3. 다른 프로그램을 디버깅하거나 리버스엔지니어링들을 위해서 사용할 수 있습니다. API함수만 알아가지고 뭘 알수 있겠냐라고 생각할 수도 있겠지만.. 사실 우리가 사용하는 모든 델파이 문법과 라이브러리는 결국 API함수를 사용하기위한 과정에 불과합니다. 윈도우는 디바이스에 내용을 출력하고 키보드 마우스로 입력받고, 다른 장비와 통신하고하는 모든 과정을 API, 메세지, ActiveX 이 세가지로 다 합니다.

4. API후킹을.. 디버깅하는데만 사용하지는 않고 어떤 특별한 기능을 구현할때도 사용합니다. 가장 좋은 예로 노클릭 영한사전이 있습니다. 글씨에 커서를 가져가면 번역을 보여주는.. 그런것을 할때도 API후킹이 필요합니다. 그때는 Text에 관련된 함수들을 후킹하겠지요..

5. DLL의 구조를 좀 알아야합니다. 여기서 DLL의 구조를 안다는것을 PE포맷을 알아야 한다는것과 유사한데 그렇다고 핵사에디터로 DLL을 열어서 바이너리를 들여다 보라는 야그가 아니라 적어도 DLL의 도스헤더, NT헤더(PE헤더) 그리고 임포트테이블 정도까지는 아..그런게 있구나 하는 정도는 알아야한다는겁니다. 물론 그것들을 위한 스트럭쳐(레코드)가 있으므로 그것을 우선 확보해서 사용방법을 알면 되겠습니다.


두 가지 기술...


6. 남의 역역으로 쳐들어가기.. API후킹을 할려면 다른 프로그램의 메모리 영역으로 내가 만든 코드를 침투시켜야합니다. 왜냐하면 NT의 버쳘메모리메니져가 기본적으로 남의 영역을 침범하지 못하게 만들어 놨기 때문입니다. 물론 그것은 9x계열도 마찬가집니다. 그래서.... API 후킹을 하는데 있어서 남의 영역으로 쳐들어 가는 방법은 상당히 중요한 부분입니다.

7. 함수 가로채기.. 일단 쳐들어가면 그 다음에는 함수를 가로채야합니다. 목적이 그것이니깐여... 함수를 가로채는데도 여러가지 방법이 있습니다.


남의 영역으로 쳐들어가기


8. 메세지훅을 이용하는 방법... 메세지 후킹을 시스템 전역으로 설치하면 다른 프로그램이 내가 만든 DLL을 로드하게 됩니다.
그것을 이용해서 남의 프로그램의 영역에 침투시키는데 이 방법이 가장 일반적입니다.
그래서 메세지 후킹도 알아야 하는데 잘 할 필요는 없습니다. 그냥 남이 만든거 배껴서 고쳐서 쓸수 있는 정도면 되겠습니다.
본문에서는 메세지훅을 윈도우즈후크라고 표현했습니다.

메세지훅을 이용했을때의 장점은 모든 윈도우에서 동일한 방법으로 지원한다.
미래의 윈도우즈에서도 계속 지원이 유지될것이다.
훅의 시작과 해제를 자유롭게 제어할수있다..라고 본문에서 설명하고 있는데..
양병규가 좀더 덧붙이자면 메세지훅은 윈도우가 지원하는 표준적인 방법이라는것이 가장 큰 매력인것같고요...
본문는 미래에도 이 방법은 바뀌지 않을것같다라고 했는데 제 생각은 좀 다릅니다.
그렇게 생각하는 가장 큰 이유는 이 방법이 문서화 되어있는 표준적인 개발 방법이기때문에 호환성을 위해서라도 없앨수 없다라고 라고 생각하는?.
그것은 맞는 말이지만.... 메세지 훅을 통해서 로드된 DLL이 프로그램의 모든 버쳘메모리 영역에 침투할 수 있다..라는 사실은 MSDN어디에도 명시되어있지 않습니다.
그것이 그렇게 되어있는 이유는 현재의 윈도우 버쳘메모리 메니져가 그렇게 만들어져 있기때문이고 앞으로 MS가 그것이 문제가 심각하다라고 판단하면 언제든지 변경을 할 수 있는 내용입니다.

메세지훅을 이용하는 방법의 단점은... 시스템의 성능을 확연하게 저하시킵니다. 메세지의 체계에 하나가 더 끼어들기때문에 어쩔수 없이 그렇게 됩니다.
하지만... 제 생각은 조금 다릅니다. 시스템 성능이 저하는 되지만 확연하게..는 아닙니다... 현저하게 저하되는 경우는 훅프로시져에서 많은 일을 할수록 시스템성능이 더 많이 저하됩니다.
그런데 API훅의 침투용으로 사용하는 훅프로시져는 대부분 아무일도 안합니다.
그리고 메세지 훅도 훅 나름입니다. WB_GETMESSAGE훅의 경우 메세지가 발생하는 대부분의 윈도우에 걸립니다. 그러므로 한 프로그램에 윈도가 100개면 그만큼 훅프로시도 많이 동작하게 됩니다.
WB_CBT훅의 경우는 시스템메뉴메세지가 동작할때 발생하므로 윈도가100개라도 그중에 가장 parent에 있는 윈도만 그 훅을 받아들이고 발생도 자주 안합니다.
고로...메세지훅의 종류와 사용법에 따라 많이 달라집니다. 암튼.. 그러므로 메세지훅을 잘 이용하면 성능저하가 피부로 느끼지 못하게 할수도 있습니다.
본문에서 "어떤 특별한 상황(버그 발생)에서는 복구하기 위해 시스템을 리부팅해야만 한다"고 했는데...
메세지훅이 걸린 상태에서 에러가 발생하는등 훅을 건 프로그램이 정상기능을 수행하지 못하게 되버리면 훅을 해제할 수도 없고 훅용DLL이 사용중이니 재 컴파일 할수 없으므로 재부팅을 해야한다는 말입니다.
제가 생각하는 메세지훅의 또 다른 단점은 윈도우가 없는 어플리케이션에는 침투할 수 없다는 단점이 있습니다.
좌우지간 메세지훅을 이용하는 방법은 까다로운면도 많고 장점도 많고... 단점도 있고.... 머 그렇습니다.

9. USER32.DLL의 초기화 부분을 이용하는 방법 USER32.DLL은.. 초기화 부분이 실행될때 레지스트리에 등록된 USER32초기화 DLL목록을 읽어와서 거기에 등록되어진 DLL을 로드하게 되어있습니다.
흠... 그렇게 만든 이유는 아마도 USER32는 윈도우에서 사용하는 대부분의 객체가 구현되어져 있기때문에 그것과 관련이 있지 않나 싶습니다.
본문에서 소개하고 있는 레지스트리 경로에 DLL파일을 추가하면됩니다.
이 방법의 장점은 비교적 손쉽다라는 장점이 있습니다.. 더 이상 다른 장점은 없습니다. ^^;
단점은 USER32.DLL을 안쓰는 프로그램에는 효과가 없고 NT계열만 되고.. 설치후 재부팅을 해야하고...훅의 시작와 해제를 맘대로 제어할 수 없습니다.
고로 이방법은 일반 어플리케이션에 적용하기에는 좀 그렇고 거의 디버깅용으로 밖에 쓸 수 없습니다.

10. CreateRemoteThread를 이용하는 방법을 본문의 저자가 젤루 선호한다고 했는데....
CreateRemoteThread함수를 이용할때 콜백함수를 지정하게 되는데 그 콜백함수의 구조가 LoadLibrary함수의 구조와 동일합니다.
그래서 콜백함수로 LoadLibrary를 지정해서 로드하게 만든다... 머 그런겁니다.
이 방법의 단점은 시스템 전역으로 사용하기에는 무리가 있고 주로 디버깅용으로 많이 사용합니다. 글구 NT계열에서만 됩니다.

11. 본문에서 그 외 소개하는 방법은 익스플로러나 오프스등의 플러그인 기능을 이용한다는 방법인데...
요즘 이걸 이용한 바이러스들이 아주 지랄입니다. 이 넘이 하나 깔리면 V3로 치료를 해도 또 살아나고 그럽니다.
그래서 바탕화면까지 몽땅 죽여놓은 상태에서 백신을 돌려야 치료가 되곤합니다.
사실 저도 예전에 민성기님과 이런 저런 야그를 하면서 폴더카피훅을 이용해서 쳐들어가곤 했는데.... 암튼 이방법은 아주 허접합니다. ^^;;
단점은 걸리면 무쟈게 욕을 먹고 요즘엔 이런것만 잡고 다니는 프로그램도 많습니다.


함수 가로채기...


12. 본문에서는 커널레벨훅과 서브클래싱을 소개하고 있는데 그것은 API후킹이 아닙니다... --;

13. DLL바꿔치기... 본문에서는 Proxy DLL (Trojan DLL)(대리자 DLL)라고 소개하고 있는데...
API함수를 가지고 있는 DLL을 똑같이 새로 만드는 방법입니다.
그 DLL에는 원래 DLL이 가지고 있는 API함수를 똑같은 구조로 만들어서 그 함수들은 원래의 DLL함수의 똑같은 함수를 호출합니다.
아~~주 단순무식한 방법인데 수 년전에 내가 하영재씨와 민성기씨에게 이 방법을 소개했드만 낄낄대고 웃더라... ^^;
하지만 기술적으로 아주 쉬운방법이긴합니다 ^^;; 물론 실용성은 없슴다 --;

14. Code overwriting(코드 덮어쓰기)
이 방법은... 메모리상에있는 함수들을 싸그리 뒤져서 CALL명령($E9)을 찾아다가 그 바로 뒤 네바이트(포인터값)을 봐서 그 값이 API함수의 어드레스면 그것을 내가 만든 함수의 어드레스로 바꿔치고 내가 만든 함수에다가 하고싶은 일을 다하고 다시 원래 API함수를 호출하는 .. 머 그런 방법인데...
잘 만들면 괜찮은 방법인데 이 방법을 써서 제대로 돌아가는 프로그램을 못봤슴다. 1분안에 에러가 안나면 기적이다.. ^^;;

15. Spying by a debugger(디버거를 이용한 스파이)
이 방법은 아무리 생각해봐도...... API후킹이라고 말하기에는 좀 그렇슴다....
본문을 쓴 원작자는... API후킹을 주로 크랙이나 리버스엔지니어링으로 많이 사용하는 경향이 있는것같슴다... 쩝....

16. 임포트테이블 바꾸기
이 부분은 상당히 길게 설명하고 있는데... 많이 보편화 되어있습니다.... 실제로 피씨방에서 감시용 프로그램등에 많이 사용되고 있지여..
EXE에는 DLL함수를 연결하는 함수 임포트테이블이란걸 가지고 있습니다. (DLL에도 있따)
실행이 되면 윈도우가 DLL에 있는 함수의 주소를 그 테이블에 써줍니다. 그래서 그 주소로 점프하게 되는데...
그 주소를 바꿔치기하는 방법입니다.
장점은 9x, NT모두 사용할수 있고 비교적 쉽습니다.
제가 덧붙이면.. 단점이 하나있는데 UPX, ASPack등으로 압축된 실행파일은 임포트테이블을 제거하고 LoadLibrary로 대치하는등 임포트테이블을 망가뜨려버리기때문에 이 방법이 안통합니다.


그 외....


17. 나머지 설명들은 API후킹을 이용하는 프로그램의 구성등에 대해 설명하고 있슴다....
그러므로 뒷부분은 일단 API후킹을 성공한 후부터 보면될것 같습니다.


그리고 본문에서 소개하는 방법외에도 몇가지를 더 소개하면....


18. 심플코드오버라이팅이라는 방법이 있는데 제가 젤루 선호하는 ^^ 방법입니다.
원래의 API함수 자체를 수정하는 방법인데 내가 만든 함수로 점프하게하는 코드를 써넣습니다.

19. 익스포트테이블을 수정하는 방법도 있는데 임포트테이블을 수정하는 방법하고 유사합니다.
다른 점은 임포트테이블을 수정하는 방법은 EXE에 있는 테이블을 수정하는것이고 이 방법은 API함수가 있는 DLL에서 익스포트테이블을 고치는 방법인데(물론 모두 메모리에서 벌어지는 일입니다. 실제 파일을 수정하는게 아닙니다.)
EXE의 경우 UPX등으로 압축할 수 있지만 API함수가 있는 DLL을 UPX로 압축해서 쓰는 사람은 없으므로 위에서 말한 단점을 보완할수 있다는 장점이 있습니다.


제가 생각하기에는...


20. API후킹을 이용해서 프로젝트를 할 때는 반드시 그것이 통하는 범위를 제한해야합니다.
예컨데 노클릭영한 사전을 만들면서 한글로된 모든 텍스트를 다 후킹할수 있따...라고 호언장담하지말고..
캡쳐방지를 만들면서 모든 캡쳐프로그램을 다 막을수 있습니다....라고 장담하지 말라는 야급니다.