반응형

특정 프로세스를 감추는 은폐(stealth) 기법에 대해 설명하고, 예제 파일을 통해서 실습을 해보도록 하겠습니다.

 

<photo : mashleymorgan on flickr>


아래 내용은 이전 포스트에서 이어지는 내용입니다.
API Hooking – '스텔스' 프로세스 (1)



프로세스 은폐(stealth) 동작 원리 (User Mode)


프로세스 은폐(stealth)에 관한 내용은 이미 많은 정보가 공개되어 있습니다.
그 중에서 유저 모드(User Mode)에서 가장 널리 사용되는 "ntdll!ZwQuerySystemInformation() API 후킹 방법"에 대해서 살펴보겠습니다.

* 커널 모드의 프로세스 은폐 기법은 (유저 모드에 비해) 더 강력하고, 더 고급 기법입니다. 향후 제 블로그에서 자세히 다루도록 하겠습니다.


#1. 프로세스 은폐(stealth) 개념

스텔스 전투기는 레이다에 포착되지 않기 위해서 각종 첨단 과학을 동원하여 전투기 자체를 (기존 전투기와 다르게) 완전히 새롭게 개발 하였습니다. 즉, 작업 대상이 스텔스 전투기 자신입니다.

반면에 은폐 프로세스의 개념은 이와는 정반대입니다.
특정 프로세스를 은폐시키기 위해서 나머지 모든 프로세스들의 메모리에 침투하여 API 를 후킹합니다. 즉, 작업 대상은 다른 프로세스입니다.

은폐 프로세스의 개념을 스텔스 전투기의 설명에 적용해보면 아래와 같습니다.

그냥 일반 전투기를 띄워 보낸 후 모든 레이다를 고장내면(조작하면), 그 일반 전투기는 그 순간부터 스텔스 전투기가 되는 것과 같은 이치입니다.

이것이 바로 은폐(stealth) 프로세스의 개념입니다.


#2. 관련 API

프로세스(Process)는 커널 객체이기 때문에 (유저 모드 프로그램은) API 를 통해서만 접근이 가능합니다. 일반적으로 유저 모드에서 프로세스를 검색하기 위한 API 는 아래와 같이 2 종류가 있습니다.

HANDLE WINAPI CreateToolhelp32Snapshot(
    DWORD    dwFlags,
    DWORD    th32ProcessID
);

* 출처 : http://msdn.microsoft.com/en-us/library/ms682489(VS.85).aspx

BOOL EnumProcesses(
    DWORD*   pProcessIds,
    DWORD    cb,
    DWORD*   pBytesReturned
);

* 출처 : http://msdn.microsoft.com/en-us/library/ms682629(VS.85).aspx

위 2 가지 API 모두 내부적으로 ntdll!ZwQuerySystemInformation() API 를 호출합니다.

NTSTATUS ZwQuerySystemInformation(
    SYSTEM_INFORMATION_CLASS    SystemInformationClass,
    PVOID    SystemInformation,
    ULONG    SystemInformationLength,
    PULONG   ReturnLength
);

* 출처 : http://msdn.microsoft.com/en-us/library/ms725506(VS.85).aspx

ZwQuerySystemInformation() API 를 이용하여 실행중인 모든 프로세스들의 정보(구조체)를 연결 리스트 형태로 얻을 수 있습니다.

그 연결 리스트를 조작하면(리스트에서 빼내면) 해당 프로세스는 은폐 되는 것입니다.

따라서 유저 모드에서는 CreateToolhelp32Snapshot() 나 EnumProcess() API 를 후킹할 필요 없이  ZwQuerySystemInformation() API 하나만 후킹하면 확실하게 특정 프로세스를 은폐 시킬 수 있습니다.


#3. Global Hooking 개념

우리가 은폐하고자 하는 프로세스를 test.exe 라고 하겠습니다.
실행중인 ProcExp.exe (또는 taskmgr.exe) 프로세스의 ZwQuerySystemInformation() API 를 후킹 하면 ProcExp.exe 는 test.exe 를 찾지 못할 것입니다.

* ProcExp.exe = 프로세스 익스플로러, taskmgr.exe = 윈도우 작업 관리자

위와 같이 하면 ProcExp.exe(또는 taskmgr.exe) 프로세스 하나에 대해서 test.exe 가 은폐되었다고 말할 수 있습니다.

하지만 이 방법에는 두 가지 문제점 이 있습니다.

첫 번째 문제점은 후킹 대상 프로세스 개수 입니다.
프로세스 검색 유틸리티가 과연 이 두 가지뿐 일까요?
이들 외에도 수 많은 프로세스 검색 유틸리티가 있을 것이며, 사용자가 직접 만든 유틸리티도 있을 수 있습니다. 따라서 시스템에 실행중인 모든 프로세스를 후킹 해야만 내 프로세스가 은폐되었다고 확신할 수 있습니다.

두 번째 문제점은 새로 생성되는 프로세스입니다.
만약 사용자가 ProcExp.exe (또는 taskmgr.exe) 를 하나 더 실행하면 어떻게 될까요?
첫 번째 ProcExp.exe 프로스세는 이미 후킹이 되어 있으므로 test.exe 프로세스를 찾지 못하겠지만, 두 번째 실행된 ProcExp.exe 프로세스는 후킹 되지 않았으므로 test.exe 프로세스를 정상적으로 찾아 낼 것입니다.

이 두 가지 문제를 정리해 보면 우리는 test.exe 프로세스를 완전히 숨기기 위해서 시스템에 실행 중인 모든 프로세스의 ZwQuerySystemInformation() API 를 후킹해야 하며, 추가적으로 나중에 실행되는 모든 프로세스에 대해서도 똑 같이 후킹을 해줘야 합니다. (물론 자동으로 해줘야겠지요.)

이것이 바로 global hooking 의 개념입니다.
(이러한 global hooking 에 대해서는 뒷부분에서 따로 설명하도록 하겠습니다.)



실습


HideProc.exe

stealth.dll


HideProc.exe 는 실행중인 모든 프로세스에게 Stealth.dll 파일을 인젝션 시키는 역할을 합니다.
Stealth.dll 은 인젝션 된 프로세스의 ntdll!ZwQuerySystemInformation() API 를 후킹하는 역할을 합니다.

위 두 파일을 이용해서 notepad.exe 프로세스를 은폐시켜 보도록 하겠습니다.

* 참고!
위 실습 파일은 “global hooking – 새로운 프로세스”에 대한 대책이 없는 버전입니다.
따라서 HideProc.exe 실행 이후에 생성된 프로세스는 자동으로 후킹 되지 않습니다.
그에 대해서는 따로 설명 드릴 예정입니다. 참고하세요.



#1. notepad.exe, procexp.exe, taskmgr.exe 를 실행시켜 주세요.


#2. 아래와 같이 HideProc.exe 를 실행합니다.

<Fig. 1>

실행 파라미터에 대해서 간략히 설명 드리겠습니다.

-hide/-show : 은폐 시킬 때는 –hide, 은폐 해제 시에는 –show
process name : 은폐 시킬 프로세스 이름
dll path  : 인젝션 시킬 DLL 파일 경로


#3. 모든 프로세스에 stealth.dll 파일이 제대로 인젝션 되었는지 확인합니다.

Process Explorer 을 이용해서 stealth.dll 을 검색합니다.

<Fig. 2>

실행중인 모든 프로세스에 stealth.dll 파일이 인젝션 된 것을 확인 할 수 있습니다.

* 사실은 시스템 프로세스들(PID 0 & PID 4)에 대해서는 (시스템 안정성을 위해) 인젝션 시키지 않았습니다. (notepad.exe 프로세스 은폐에는 아무 상관 없습니다.)


#4. procexp.exe 와 taskmgr.exe 에서 notepad.exe 프로세스가 사라진걸 확인합니다.

<Fig. 3>

<Fig. 4>

위의 <Fig. 3> 과 <Fig. 4> 를 보시면 notepad.exe 프로세스가 분명히 실행 중이지만, procexp.exe 와 taskmgr.exe 에서 notepad.exe 프로세스가 사라진걸 확인하실 수 있습니다.

* 메모장의 윈도우가 보이기 때문에 프로세스가 완벽히 숨은 게 아니라고 생각하실 수 있겠습니다만, 우리의 목표는 프로세스 은폐이기 때문에 윈도우는 그냥 놔뒀습니다. 참고로 윈도우를 사라지게 하려면 SetWindowPos() API 등을 사용하시면 됩니다.


#5. notepad.exe 프로세스를 다시 보이도록 합니다.

HideProc.exe 를 –show 모드로 실행시킵니다. (stealth.dll 을 ejection 시켜줍니다.)

<Fig. 5>

procexp.exe 와 taskmgr.exe 에서 notepad.exe 프로세스가 정상적으로 보이는지 직접 확인해보시기 바랍니다.


다음 번에는 예제 소스 파일을 상세하게 분석해보도록 하겠습니다.

API Hooking – '스텔스' 프로세스 (3)


ReverseCore

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

반응형
반응형
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) 부탁 드려요~

반응형
반응형


<photo : skedonk on flickr>

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

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


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

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

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

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

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

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

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

여러분은 어떠신가요?


+---+


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

ReverseCore

반응형
반응형

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


반응형
반응형


리버스 엔지니어링 분야에 대해 질문이 있으시면 아래의 댓글로 올려주세요. 역시 댓글로 답변을 올려드리겠습니다. 공개하기 어려운 내용은 '비밀글' 에 체크해주세요.

"비도덕적, 불법적" 인 내용은 답변 드릴 수 없음을 이해해 주시기 바랍니다.


댓글, 방명록, 이메일 등으로 많은 분들께서 여러 가지 질문들을 해주십니다.
그중에 정말 좋은 질문들이 많아서 여러분들과 공유하면 좋겠다고 생각하였습니다.

이제부터 저에게 들어오는 모든 질문과 답변들을 이곳으로 모을 것입니다.
앞으로 질문과 답변은 이곳에서 해주세요~

질문에 대한 답변은 저 뿐만 아니라 제 블로그에 오시는 모든 분들께서 하실 수 있습니다.
문제 해결을 위한 방법은 다양합니다. 저 말고도 다른 분들의 답변은 언제나 환영입니다.

"질문은 좋은 것 입니다. 많이 해주세요. ^^ "

* 댓글로 질문하기 어려운 내용들(긴내용, 첨부파일 등)은 제 이메일(reversecore@gmail.com)로 문의해 주세요.

* 댓글이 너무 많이 달리면 제가 질문/답변 빈 포스트를 또 올릴 겁니다. 그쪽으로 계속 질문 댓글 달아주시면 됩니다.

감사합니다.


ReverseCore



반응형

'q&a' 카테고리의 다른 글

질문/답변 코너입니다. (3)  (381) 2011.04.13
질문/답변 코너입니다. (2)  (223) 2010.01.28

+ Recent posts