************************************************************************ 제목: 발전된 IA32 함수 후킹(프랙 58호) 번역: vangelis(http://www.wowhacker.org) * 대충 했으니 혹시라도 오역이나 오타 있으면 말씀해주시길 바랍니다. ************************************************************************ ==Phrack Inc.== Volume 0x0b, Issue 0x3a, Phile #0x08 of 0x0e |=------------------------=[ 발전된 IA32 함수 후킹 ]=--------------------------=| |=---------------------------------------------------------------------------=| |=-------------------=[ mayhem ]=---------------------=| |=--------------------------=[ December 08th 2001 ]=-------------------------=| --[ 내용 1 - 도입 1.1 - 역사 1.2 - 새로운 요구사항들 2 - 후킹의 기본들 2.1 - 일반적인 테크닉들 2.2 - 잊어서는 안되는 것들 3 - 코드 설명 4 - 라이브러리 이용하기 4.1 - API 4.2 - 커널 심볼 분석 4.3 - hook_t 오브젝트 5 - 코드 테스트 5.1 - 모듈 로딩 5.2 - 놀아보자 5.3 - 코드 6 - 참고문헌 --[ 1 - 도입 남용, 로깅, 패치, 또는 심지어 디버깅 이것들은 후킹 문제에 대해 생각할 분명한 이유들이다. 우리는 어떻게 그것이 작동할 것인지 이해하려고 노력할 것이다. 여기서의 기본 환경은 리눅스 커널이다. 이 글은 커널 2.4.5에서 개발되었고, IA32가 실행되고 있는 리눅스 커널 2.4 시리즈의 일반적인 목적의 후킹 라이브러리에 대해서 다루고 있으며, 그것은 LKH(Linux Kernel Hooker)라고 불린다. ----[ 1.1 - 역사 함수 하이재킹 주제에 대한 참고문헌들 중의 하나가 1999년 11월에 발표되었으며, Silvio Cesare에 의해 쓰여졌다. 이 구현은 커널의 acct_process 함수로 접근하는 것을 필터링 하기 위해 특정 프로세스가 차지되는 것을 막으면서 후킹이 다른 코드로 jump하는 함수의 첫 바이트를 수정하는 것으로 구성되어 있기 때문에 아주 직선적이다. ----[ 1.2 - 새로운 요구 사항들 그 이후 몇 가지 작업이 이루어졌다: - 리다이렉션의 실용적인 사용은 종종(항상?) 그것들의 번호와 사이즈에 상관없이 원래의 인자에 접근할 필요가 있다.(예를 들어 만약 우리가 IP 패킷을 수정하거나 포워딩 하기를 원한다면) - 우리는 요구가 있는 즉시 후크를 비활성화시킬 필요가 있는데, 그것은 런타임 커널 설정을 위해 완벽하다. 우리는 원래의 함수를 호출하기를 원할 수도 있거나(모니터링 프로그램에 의해 사용되는 분리된 후킹), 또는 커널 오브젝트에 대해서는 아닐 수 있다.(ACL(Access Control Lists)을 관리하기 위한 보안 패치에 의해 사용되는 공격적인 후킹) - 어떤 경우에 우리는 첫 번째 호출 이후 예를 들어 통계(매초 또는 매분마다 한번씩 후킹할 수 있는)를 내기 위해 후크를 파괴하기를 원할 수 있다. --[ 2 - 후킹 기본 ----[ 2.1 일반적인 테크닉 물론 핵심적인 후킹 코드는 어셈블리어에서 이루어져야 하지만 후킹 랩핑 코드는 C로 이루어진다. LKH의 높은 수준의 인터페이스는 API 섹션에서 기술된다. 먼저 몇 가지 후킹 기본에 대해서 이해해보자. 다음이 기본적인 후킹이다. - 다른 하나의 코드('후킹 코드'라고 불림)를 지시하기 위해 함수 코드의 시작을 변경한다. 이것은 우리가 원하는 것을 하기 위한 아주 오래되고 효율적인 방법이다. 다른 방법은 함수를 참고하는 코드 세그먼트의 모든 호출을 패치하는 것이다. 두 번째 방법은 몇 가지 장점들을 가지고 있지만(아주 은밀하다) 그 구현은 약간 복잡하고(메모리 영역은 파싱을 블록하고, 그런 다음 코드 스캐닝을 블록한다), 그리고 아주 빠르지 않다. - 런타임 때 후크된 함수 실행이 끝났을 때 통제권을 잡기 위해 함수의 리턴 어드레스를 변경한다. - 후크 코드는 두 가지 다른 부분을 가지고 있어야 하는데, 첫 번째 것은 함수 앞에서 실행되어야 하며(인자에 접근하기 위한 스택을 준비, callback 실행, 이전 함수 코드를 복구), 두 번째는 함수 뒤에 실행되어야 한다.(필요하다면 후크를 다시 리셋 한다.) - 디폴트 인자(후크 행위를 정의하는 것)들은 후크를 만들 동안(함수 코드를 수정하기 전) 설정되어야 한다. 함수 의존적인 인자들은 지금 확정되어야 한다. - callback을 추가한다. 각 callback은 원래의 함수 인자에 접근할 수 있거나 심지어 수정도 할 수 있다. - 인자들을 활성화, 비활성화, 변경하고, 우리가 원할 때 callback을 추가하거나 제거한다. ----[ 2.2 - 잊지 말아야 할 것들 -> 프레임 포인터 없는 함수: 중요한 기능은 -fomit-frame-pointer gcc 옵션으로 컴파일된 함수들을 후크하기 위한 능력이다. 이 기능은 %ebp로부터 자유롭기 위해 후킹 코드를 요구한다. 이것이 왜 우리가 단지 %esp가 스택 오퍼레이션을 위해 사용할 것인가의 이유이다. 우리는 후크 코드에 있는 %ebp 관련 offset을 수정하기 위해 몇 부분을 업데이트해야만 한다.(몇 부분에 몇 바이트씩) 이에 관해 더 자세한 것은 lkh.c의 khook_create()를 보아라. 후크 코드는 또한 위치와 독립되어 있다. 이것이 왜 그렇게 많은 후크 코드에 offset이 런타임시 고정되어 있는가의 이유이다.(우리가 커널에 있기 때문에 offset은 후크를 만드는 동안 고정되어야 하지만, 아주 유사한 테크닉이 런타임 프로세스에 함수 후킹 동안 사용될 수 있다.) -> 재귀 우리는 callback으로부터 원래의 함수를 호출할 수 있어야 하며, 그래서 원래의 코드는 어떤 callback의 실행 이전에 저장되어야 한다. -> 리턴 값 우리가 callback을 가지고 있던 아니던, 원래의 함수가 호출되던 아니던 %eax에 정확한 값을 리턴해야 한다. 마지막으로 실행된 callback의 리턴값은 만약 원래의 함수가 호출되지 않을 경우 리턴된다. 만약 어떤 callback이나 원래의 함수도 호출되지 않는다면 리턴값은 통제할 수 없다. -> POST callback 만약 원래의 함수 뒤에 callback을 실행할 경우 함수 인자들에 접근할 수 없다. 그것이 왜 나쁜 생각인가의 이유이다. 하지만, 그것을 하는 테크닉이 있다. - 후크를 aggressive로 설정 - PRE callback을 호출 - 자신의 인자로 callback으로부터 원래 함수를 호출 - POST callback을 호출 --[ 3 - 코드 설명 먼저 후크를 설치한다. A - 후크 코드 영역을 가리키고 있는 간접적인 jump로 하이재킹된 루틴의 처음 7바이트를 덮어쓴다. %eax에 입력된 offset은 후크 코드의 절대 주소이며, 그래서 우리가 hijack_me() 함수를 호출할 때마다, 후크 코드는 통제될 것이다. 하이재킹 전: 0x80485ec : mov 0x4(%esp,1),%eax 0x80485f0 : push %eax 0x80485f1 : push $0x8048e00 0x80485f6 : call 0x80484f0 0x80485fb : add $0x8,%esp 하이재킹 후: 0x80485ec : mov $0x804a323,%eax 0x80485f1 : jmp *%eax 0x80485f3 : movl (%eax,%ecx,1),%es 0x80485f6 : call 0x80484f0 0x80485fb : add $0x8,%esp jmp 다음에 드러난 3개의 명령은 어떤 것도 의미하지 않는다. 왜냐하면 gdb는 우리의 후크에 의해 농락 당한 것이기 때문이다. B - 후크된 함수의 원래 바이트를 리셋, 만약 우리가 어떤 것을 파괴하지 않고 원래의 함수를 호출하길 원한다면 그것이 필요하다. pusha movl $0x00, %esi (1) movl $0x00, %edi (2) push %ds pop %es cld xor %ecx, %ecx movb $0x07, %cl rep movsl 두 개의 NULL offset은 후크를 만들 동안 실제로 변경되었다.(그들의 값이 후크된 함수의 offset에 의존하기 때문에 우리는 런타임시 후크 코드를 패치해야 한다.) (1)은 원래 함수의 첫번째 저장된 7 바이트를 포함하고 있는 버퍼의 offset에 고정되어 있다. (2)는 원래의 함수 어드레스로 고정되어 있다. 만약 x86 어셈블리어를 잘 알고 있다면 당신은 이 명령들이 %ds:%esi로부터 %es:%edi로 %ecx 바이트를 복사할 것이라는 것을 알아야 한다. 이에 대한 것은 [2]를 참고해라. C - 인수들이 우리의 callback을 읽고/쓰기 권한을 갖고 callback을 실행하도록 스택을 초기화한다. 우리는 첫 번째 원래 파라미터 주소를 %eax에 이동시키고, 그런 다음 그것을 push 한다. leal 8(%esp), %eax push %eax nop; nop; nop; nop; nop nop; nop; nop; nop; nop nop; nop; nop; nop; nop nop; nop; nop; nop; nop nop; nop; nop; nop; nop nop; nop; nop; nop; nop nop; nop; nop; nop; nop nop; nop; nop; nop; nop 빈 슬롯은 NOP 명령(opcode 0x90)으로 가득 차 있다는 것을 주목해라. 이것은 어떤 오퍼레이션도 없다는 것을 의미한다. 어떤 슬롯이 khook_add_entry 함수를 사용해 가득 차 있다면 5 바이트가 사용된다. - 호출 opcode (opcode 0xE8) - callback offset (4 bytes relative address) 우리는 최대 8개의 callback을 설정하도록 선택했다. 삽입된 각각의 callback은 하나의 인자로 호출된다.(%eax가 push 된 값은 스택을 다시 배치하면서 원래의 함수 파라미터의 주소를 포함하고 있다.) D - 스택 리셋 add $0x04, %esp 우리는 이제 (C)에서 push된 원래 함수의 인자 주소를 제거한다. 그런 식으로 %esp는 그것의 이전 값(C 단계로 들어가기 이전의 것)으로 리셋된다. 이 순간에 스택은 A단계에서 덮어쓰였기 때문에 원래 함수의 스택 프레임을 포함하고 있지는 않다. E - 스택에 원래 함수의 리턴 어드레스를 변경한다. 인텔 프로세스에서는 함수의 리턴 어드레스는 스택에 저장된다.(이것은 보안상으로는 좋은 생각은 아니다.) 이 변경은 원래의 함수 실행 이후 우리가 원하는 곳(hook-code로)으로 리턴하게 해준다. 그런 다음 우리는 원래의 함수를 호출한다. 리턴시 후크 코드는 통제권을 재획득한다. 그것을 조심스럽게 살펴보자. -> 먼저 우리는 실제 %eip를 구하고, 그것을 %esi에 저장한다.(마지막 라벨은 E5 단계에서 쉽게 확인할 수 있는 몇몇 코드를 가리킨다) 이 트릭은 항상 위치와 독립된 코드에서 사용된다. 1. jmp end begin: pop %esi -> 그런 다음 우리는 4(%esp)에 재배치하면서 이전 리턴 어드레스를 만회하고, 그것을 %eax에 저장한다. 2. movl 4(%esp), %eax -> 우리는 후크 코드의 끝에 4 바이트 offset으로 저장된 리턴 어드레스를 사용한다.(H 단계에서 NULL 포인터를 보라) 그래서 우리는 후킹 프로세스의 끝에 올바른 곳으로 리턴할 수 있다. 3. movl %eax, 20(%esi) -> 우리는 원래 함수의 리턴 어드레스를 변경하고, 그래서 'call begin' 명령 바로 다음에 리턴할 수 있다. 4. movl %esi, 4(%esp) movl $0x00, %eax -> 우리는 원래 함수를 호출한다. 'end' 라벨이 1단계에서 사용되고, 'begin' 라벨은 "jmp end"(여전히 1단계에 있음) 바로 다음의 코드를 가리킨다. 원래의 함수는 'call begin' 명령 바로 다음에 리턴한다. 왜냐하면 우리가 그것의 리턴 어드레스를 변경했기 때문이다. 5. jmp *%eax end: call begin F - 후킹 코드로 돌아간다. 우리는 원래 함수의 코드에 7 바이트를 다시 설정한다. 이 바이트는 그 함수를 호출하기 전에 원래의 값으로 리셋 되었다. 그래서 우리는 A 단계에서처럼 다시 그 함수를 후킹할 필요가 있다. 이 단계는 만약 후크가 영원하지 않고 단발적이라면 NOP 명령에 의해 대체된다. 그래서 우리의 악의적인 간접적 jump(A 단계)의 7 바이트는 다시 복사되지 않는다. 이 단계는 같은 copy 매커니즘(rep movs* 명령을 사용)을 사용하기 때문에 B 단계와 아주 가깝다. 코드에서 NULL offset은 후킹 과정동안 고정되어야 한다. - 첫 번째 것(출발지 버퍼)은 악의적인 바이트 버퍼에 의해 대체되었다. - 두 번째 것(목적지 버퍼)은 원래 함수의 엔트리 포인터 어드레스에 의해 대체되었다. movl $0x00, %esi movl $0x00, %edi push %ds pop %es cld xor %ecx, %ecx movb $0x07, %cl rep movsb G - E2 단계에서 저장된 원래 리턴 어드레스를 사용하고, 원래의 호출 함수로 돌아간다. NULL offset(* 표시 부분)은 원래의 함수 리턴 어드레스와 더불어 E2 단계에서 고정되어야 한다. %ecx 값은 스택에 push되고, 그래서 다음 ret 명령은 마치 그것이 스택에 저장된 %eip 레지스터인 것처럼 그것을 사용할 것이다. 이것은 정확한 원래의 장소로 리턴 한다. movl $0x00, %ecx * pushl %ecx ret --[ 4 - 라이브러리 사용하기 ----[ 4.1 - API LKH API는 사용하기에 아주 쉽다 : hook_t *khook_create(int addr, int mask); 어드레스 'addr'에 후크를 생성. 디폴트 타입(HOOK_PERMANENT or HOOK_SINGLESHOT), 디폴트 상태(HOOK_ENABLED or HOOK_DISABLED), 그리고 디폴트 모드(HOOK_AGGRESSIVE or HOOK_DISCRETE)를 준다. 타입, 상태, 그리고 모드는 'mask' 인자에서 OR'd이다. void khook_destroy(hook_t *h); 후크 자원을 비활성화, 파괴, 그리고 자유롭게 함 int khook_add_entry(hook_t *h, char *routine, int range); 'range' rank에 있는 후크에 callback을 추가. 만약 주어진 rank가 유효하지 않다면 -1을 리턴하고, 다른 경우에 0을 리턴 int khook_remove_entry(hook_t *h, int range); 슬롯 'range'에 callback put을 제거하고, 주어진 rank가 유효하지 않을 경우 -1을 리턴하고, 다른 경우 0을 리턴한다. void khook_purge(hook_t *h); 이 후크에 있는 모든 callback을 제거 int khook_set_type(hook_t *h, char type); 후크 'h' 타입을 변경한다. 이 타입은 HOOK_PERMANENT(후크코드는 후크된 함수가 호출될 때마다 실행된다.) 또는 HOOK_SINGLESHOT(후크코드는 단지 1 하이재크에만 실행되고, 그런 다음 후크는 깨끗하게 제거된다.) int khook_set_state(hook_t *h, char state); 후크 'h'용 state를 변경. state는 HOOK_ENABLED(후크는 활성화) 또는 HOOK_DISABLED(후크는 비활성화)가 될 수 있다. int khook_set_mode(hook_t *h, char mode); 후크 'h'용 모드를 변경. 모드는 HOOK_AGGRESSIVE(후크는 하이재크된 함수를 호출하지 않는다) 또는 HOOK_DISCRETE(후크는 callback 루틴을 실행한 이후 하이재크된 함수를 호출한다)가 될 수 있다. 후크 코드의 몇 부분은 만약 후크가 공격적이라면(E 및 H 단계) nop화 된다.(no operation 명령에 의해 덮어 쓰임) int khook_set_attr(hook_t *h, int mask); 독특한 함수 호출을 통해 모드, state, 그리고/또는 타입을 변경한다. 이 함수는 성공할 경우 0을 리턴하고, 또는 만약 지정된 mask가 양립되지 않은 옵션을 포함하고 있을 경우 -1을 리턴한다. 우리가 원할 때마다 사용된 후크의 어떤 state, 타입, 그리고 모드라도 추가하거나 제거할 수 있다는 것을 기억하자. ----[ 4.2 - 커널 심볼 분석 심볼 분석 함수가 export된 함수값에 접근하는 것을 허용하도록 LKH에 추가되었다. int ksym_lookup(char *name); 만약 심볼이 결정되지 않은 경우 NULL을 리턴한다는 것을 주목하자. 이 lookup은 커널의 __ksymtab 섹션에 포함된 심볼들을 결정할 수 있다. 이 심볼들의 목록은 'ksyms -a'을 실행하면 인쇄된다. bash-2.03# ksyms -a | wc -l 1136 bash-2.03# wc -l /boot/System.map 14647 /boot/System.map bash-2.03# elfsh -f /usr/src/linux/vmlinux -s # displaying sections [SECTION HEADER TABLE] (nil) --- foffset: (nil) 0 bytes [*Unknown*] (...) 0xc024d9e0 a-- __ex_table foffset: 0x14e9e0 5520 bytes [Program data] 0xc024ef70 a-- __ksymtab foffset: 0x14ff70 9008 bytes [Program data] 0xc02512a0 aw- .data foffset: 0x1522a0 99616 bytes [Program data] (...) (nil) --- .shstrtab foffset: 0x1ad260 216 bytes [String table] (nil) --- .symtab foffset: 0x1ad680 245440 bytes [Symbol table] (nil) --- .strtab foffset: 0x1e9540 263805 bytes [String table] [END] 사실, 메모리가 맵핑된 섹션 __ksymtab은 우리가 하이재킹하고자 원하는 모든 커널 심볼을 포함하고 있지는 않다. 다시 말해, 맵핑되지 않은 섹션 .symtab은 확실히 더 크다(245440 바이트 vs 9008 바이트). 'ksyms'를 사용할 때 __NR_query_module syscall (또는 이전 커널용 __NR_get_kernel_syms)은 내부적으로 사용되며, __ksymtab에 포함된 완벽한 커널 심볼 테이블이 메모리에 로딩되지 않기 때문에 이 syscall은 __ksymtab 섹션에만 접근할 수 있다. 전체 심볼 테이블로 접근하는 것의 해결책은 우리의 System.map 파일(`nm -a vmlinux > System.map`을 사용해 만든다)에 offset을 픽업하는 것이다. bash-2.03# ksyms -a | grep sys_fork bash-2.03# grep sys_fork /boot/System.map c0105898 T sys_fork bash-2.03# #define SYS_FORK 0xc0105898 if ((s = khook_create((int) SYS_FORK, HOOK_PERMANENT, HOOK_ENABLED)) == NULL) KFATAL("init_module: Cant set hook on function *sys_fork* ! \n", -1); khook_add_entry(s, (int) fork_callback, 0); #undef SYS_FORK 시스템이 System.map 또는 압축되지 않은 커널 이미지(vmlinux)를 가지고 있지 않기 때문에 vmlinux 파일을 압축을 푸는 것이 받아들여질 수 있다.(이것이 표준 gzip 포맷이 아님을 기억해라.) [3]은 이것에 대한 아주 유용한 정보를 가지고 있으며), 그리고 직접 새로운 System.map 파일을 만든다. 또 다른 방법은 통계 기반의 조사이다. 커널 16진수 코드에서 레퍼런스를 분석하는 것은 우리가 심볼 값을 예상하는 것을 가능하게 하고(호출 또는 jmp 명령을 불러오는 것), 커널 코드는 버전마다 다르기 때문에 이 툴의 어려움은 이식이 가능하다는 것이다. SYS_FORK를 당신 자신의 sys_fork offset 값으로 변경하는 것을 잊지 마라. ----[ 4.3 - LKH Internals: hook_t 오브젝트 hook_t 구조(메모리에서 후크 항목)를 살펴보자. typedef struct s_hook { int addr; int offset; char saved_bytes[7]; char voodoo_bytes[7]; char hook[HOOK_SIZE]; char cache1[CACHE1_SIZE]; char cache2[CACHE2_SIZE]; } hook_t; h->addr 원래 함수의 주소. 후크를 활성화 또는 비활성화 하는데 사용됨 h->offset 이 필드는 h->addr으로부터의 offset을 포함하고 있다. 여기서 하이재킹을 설정하기 위해 덮어쓰기를 시작. 그것의 값은 3 또는 0이며, 함수가 스택 프레임을 가지고 있는냐 아니냐에 따라 달라진다. h->original_bytes 원래 함수의 덮어 쓰여진 7바이트 h->voodoo_bytes 리다이렉트하기 위해 함수의 시작부분에 입력할 필요가 있는 7바이트(3문단의 A 단계에서 본 간접적인 jump 코드를 포함하고 있다.) h->hook 후킹 코드를 포함하고 있는 opcode 버퍼, 여기에 khook_add_entry()를 사용해 callback 레퍼런스를 삽입한다. cache1 및 cache2 버퍼는 우리가 모드 HOOK_AGGRESSIVE를 설정할 때 후크 코드를 백업하기 위해 사용된다. (원래의 함수 호출을 nop 해야하기 때문에 이 코드를 저장하는 것이 필요하다. 후크를 만들 때마다 hook_t의 예가 선언되고 할당된다. 하이재킹 하고자 원하는 함수마다 하나의 후크를 만들어야 한다. ----[ 5 - 코드 테스트 먼저 새로운 코드에 대해서는 http://www.devhell.org/~mayhem/를 확인해보아라. 이 패키지(버전 1.1)는 이 글의 끝부분에 주어져 있다. #include "lkh.c"로 족하다. LKH를 사용하는 이 모듈의 예에서 우리는 다음을 후킹하기를 원한다. - hijack_me() 함수, 여기서 좋은 파라미터가 지나가는 것과 callback을 통한 수정을 체크할 수 있다. - schedule() 함수, SINGLESHOT 하이재킹. - sys_fork() 함수, PERMANENT 하이재킹. ------[ 5.1 - 모듈 로딩 bash-2.03# make load insmod lkh.o Testing a permanent, aggressive, enabled hook with 3 callbacks: A in hijack_one = 0 -OK- B in hijack_one = 1 -OK- A in hijack_zero = 1 -OK- B in hijack_zero = 2 -OK- A in hijack_two = 2 -OK- B in hijack_two = 3 -OK- -------------------- Testing a disabled hook: A in HIJACKME!!! = 10 -OK- B in HIJACKME!!! = 20 -OK- -------------------- Calling hijack_me after the hook destruction A in HIJACKME!!! = 1 -OK- B in HIJACKME!!! = 2 -OK- SCHEDULING! ------[ 5.2 - 놀아보자 bash-2.05# ls FORKING! Makefile doc example.c lkh.c lkh.h lkh.o user user.c user.h user.o bash-2.05# pwd /usr/src/coding/LKH (FORKING!을 프린터하지 않았다. 왜냐하면 pwd는 쉘 기반의 명령이기 때문이다.) bash-2.05# make unload FORKING! rmmod lkh; LKH unloaded - sponsorized by the /dev/hell crew! bash-2.05# ls Makefile doc example.c lkh.c lkh.h lkh.o user user.c user.h user.o bash-2.05# sys_fork() 커널 함수가 호출될 때마다 ""FORKING!"을 볼 수 있으며(후크는 영원함), schedule() 커널 함수가 처음으로 호출될 때마다 "SCHEDULING!"을 볼 수 있다.(이 후크는 SINGLESHOT이기 때문에 schedule() 함수는 단지 한번만 하이재킹되고, 그런 다음 후크가 제거된다. ------[ 5.3 - 코드 /* ** LKH demonstration code, developped and tested on Linux x86 2.4.5 ** ** The Library code is attached . ** Please check http://www.devhell.org/~mayhem/ for updates . ** ** This tarball includes a userland code (runnable from GDB), the LKH ** kernel module and its include file, and this file (lkm-example.c) ** ** Suggestions {and,or} bug reports are welcomed ! LKH 1.2 already ** in development . ** ** Special thanks to b1nf for quality control ;) ** Shoutout to kraken, keep the good work on psh man ! ** ** Thanks to csp0t (one work to describe you : *elite*) ** and cma4 (EPITECH powa, favorite win32 kernel hax0r) ** ** BigKaas to the devhell crew (r1x and nitrogen fux0r) ** Lightman, Gab and Xfred from chx-labs (stop smoking you junkies ;) ** ** Thanks to the phrackstaff and particulary skyper for his ** great support . Le Havre en force ! Case mais oui je t'aime ;) */ #include "lkh.c" int hijack_me(int a, int b); /* hooked function */ int hijack_zero(void *ptr); /* first callback */ int hijack_one(void *ptr); /* second callback */ int hijack_two(void *ptr); /* third callback */ void hijack_fork(void *ptr); /* sys_fork callback */ void hijack_schedule(void *ptr); /* schedule callback */ static hook_t *h = NULL; static hook_t *i = NULL; static hook_t *j = NULL; int init_module() { int ret; printk(KERN_ALERT "Change the SYS_FORK value then remove the return \n"); return (-1); /* ** Create the hooks */ #define SYS_FORK 0xc010584c j = khook_create(SYS_FORK , HOOK_PERMANENT | HOOK_ENABLED | HOOK_DISCRETE); #undef SYS_FORK h = khook_create(ksym_lookup("hijack_me") , HOOK_PERMANENT | HOOK_ENABLED | HOOK_AGGRESSIVE); i = khook_create(ksym_lookup("schedule") , HOOK_SINGLESHOT | HOOK_ENABLED | HOOK_DISCRETE); /* ** Yet another check */ if (!h || !i || !j) { printk(KERN_ALERT "Cannot hook kernel functions \n"); return (-1); } /* ** Adding some callbacks for the sys_fork and schedule functions */ khook_add_entry(i, (int) hijack_schedule, 0); khook_add_entry(j, (int) hijack_fork, 0); /* ** Testing the hijack_me() hook . */ printk(KERN_ALERT "LKH: perm, aggressive, enabled hook, 3 callbacks:\n"); khook_add_entry(h, (int) hijack_zero, 1); khook_add_entry(h, (int) hijack_one, 0); khook_add_entry(h, (int) hijack_two, 2); ret = hijack_me(0, 1); printk(KERN_ALERT "--------------------\n"); printk(KERN_ALERT "Testing a disabled hook :\n"); khook_set_state(h, HOOK_DISABLED); ret = hijack_me(10, 20); khook_destroy(h); printk(KERN_ALERT "------------------\n"); printk(KERN_ALERT "Calling hijack_me after the hook destruction\n"); hijack_me(1, 2); return (0); } void cleanup_module() { khook_destroy(i); khook_destroy(j); printk(KERN_ALERT "LKH unloaded - sponsorized by the /dev/hell crew!\n"); } /* ** Function to hijack */ int hijack_me(int a, int b) { printk(KERN_ALERT "A in HIJACKME!!! = %u \t -OK- \n", a); printk(KERN_ALERT "B in HIJACKME!!! = %u \t -OK- \n", b); return (42); } /* ** First callback for hijack_me() */ int hijack_zero(void *ptr) { int *a; int *b; a = ptr; b = a + 1; printk(KERN_ALERT "A in hijack_zero = %u \t -OK- \n", *a); printk(KERN_ALERT "B in hijack_zero = %u \t -OK- \n", *b); (*b)++; (*a)++; return (0); } /* ** Second callback for hijack_me() */ int hijack_one(void *ptr) { int *a; int *b; a = ptr; b = a + 1; printk(KERN_ALERT "A in hijack_one = %u \t -OK- \n", *a); printk(KERN_ALERT "B in hijack_one = %u \t -OK- \n", *b); (*a)++; (*b)++; return (1); } /* ** Third callback for hijack_me() */ int hijack_two(void *ptr) { int *a; int *b; a = ptr; b = a + 1; printk(KERN_ALERT "A in hijack_two = %u \t -OK- \n", *a); printk(KERN_ALERT "B in hijack_two = %u \t -OK- \n", *b); (*a)++; (*b)++; return (2); } /* ** Callback for schedule() (kernel exported symbol) */ void hijack_schedule(void *ptr) { printk(KERN_ALERT "SCHEDULING! \n"); } /* ** Callbacks for sys_fork() (kernel non exported symbol) */ void hijack_fork(void *ptr) { printk(KERN_ALERT "FORKING! \n"); } --[ 6 - 참고문헌 [1] Kernel function hijacking http://www.big.net.au/~silvio/ [2] INTEL Developers manual http://developers.intel.com/design/pentiu m4/manuals/ [3] Linux Kernel Internals http://www.linuxdoc.org/guides.html |=[ EOF ]=---------------------------------------------------------------=|