[Windows] injection & hooking
Dll injection
#1
- ``c OpenProcess()``로 HANDLE을 얻는다.
- ``c VirtualAllocEx()``로 타겟 프로세스에 injection할 dll의 path를 쓸 공간을 할당한다.
- ``c WriteProcessMemory()``로 step 2의 주소에 path를 쓴다.
- ``c GetProcAddress()``로 LoadLibraryA의 주소를 얻는다.
- ``c CreateRemoteThread()``의 네번째 인자로 실행할 함수( LoadLibraryA )의 주소를, 다섯번째 인자로 그 함수가 실행할 인자(path)를 전달한다.
1) pid를 모른다면 CreateToolhelp32Snapshot, Process32First/Next로 pid를 먼저 구한다.
2) VirtualAllocEx에 인자로 넘기는 HANDLE은 `` PROCESS_VM_OPERATION`` 접근 권한을 갖고 있어야 한다.
즉, 프로세스가 이 권한을 넘기지 않으면 막을 수 있지 않을까 싶다.
#2
#3
PE를 직접 수정해서 자체적으로 dll import하도록 만든다.
이 때 IDT는 위치를 빈공간으로 지정해서 IID구조체를 새로 만드는 것이 가능하지만 IAT의 경우 되는지 모르겠다.
일단 IAT 크기가 들어갈 빈 공간이 없고, 위치를 옮겨도 실행이 되는건지 의문.
아무튼, 그래서 남는 IAT에 injection할 dll 정보를 넣어야 되는데 IAT가 다 차있어 남는 공간이 없을 경우 쓸모없어보이는 dll을 삭제하고 거기 넣는 방식으로 해결 가능하다.
IAT 크기를 늘려서 끝에 추가하는 것도 해봤는데, IAT 밑에 뭐가 있는건지 값 수정하면 안열린다. IAT를 당기는 것도 안된다.
Dll injection이라고 Global하게 동작하는게 아니다.
Code injection
dll injection에서는, ``c WriteProcessMemory()``에 injection할 dll의 path를 넣고 이를 ``c CreateRemoteThread()``의 인자로 전달해서 실행할 Thread의 인자로 넘긴다. 따라서 실행되는 Thread는 LoadLibrary다.
반면 code injection은 ``c WriteProcessMemory()``를 Thread 인자를 위해 한 번, Thread 코드를 위해 한 번. 총 두 번 사용한다.
``c CreateRemoteThread()``에 이 두 주소를 인자로 전달한다.
dll injection에서 LoadLibrary 주소를 미리 구해서 전달하는 것과 차이가 있다.
결과적으로 remote process가 직접 정의한 Thread를 실행하게 되어 ThreadProc가 실행된다.
hooking
- hooking을 수행하는 함수(hooking_func)
- hooked_func가 `` jmp``하게 될 fake 함수(hookfunc)
code flow #1 ( restore )
이 경우 hooking point를 어디로 잡든, 원래의 함수가 실행되기 때문에 프로그램이 정상적으로 동작하게 된다.
code flow #2 ( go-ahead )
hookfunc에서 원래 함수를 복원하지 않고 일단 실행한 다음, hooked_func으로 되돌아가 이어서 실행하는 방법. context를 적절히 저장해두고 복원해야 crash나지 않는다.
이 경우 원래 함수로 복원하지 않기 때문에, 주로 함수에 크게 영향을 주지 않는`` jmp``계열 명령어가 있는 곳을 hooking point로 잡는다.
참고
보안 프로그램에서 dll을 사용할 때는 compile time에 명시하는 방법과 LoadLibrary 중 후자를 사용한다고 한다.
컴파일 타임에 올리는 방식은 dll을 변조해버리면 exe 파일이 아예 실행이 안된다. 그래서 LoadLibrary로 올리고 예외처리를 하는 편이라고 한다.
'Security > Reversing & Dbg' 카테고리의 다른 글
python decompile (0) | 2017.11.19 |
---|---|
MPRESS unpacking (0) | 2017.11.19 |
[Linux] injection (0) | 2017.08.07 |
gdb peda / gdb-multiarch (0) | 2017.07.13 |
gdb (0) | 2017.07.12 |