debugging을 이용해서 후킹 1. DebugActiveProcess()함수를 통해 PID에 해당하는 프로세스를 디버깅을 셋팅한다. 2. WaitForDebugEvent를 통해 debug event debug event 예 = CREATE_PROCESS_DEBUG_EVENT : 프로세스 생성 or attach EXCEPTION_DEBUG_EVENT : 디버거한테 전해지는 예외 (ex : int 3(0xcc) ) EXIT_PROCESS_DEBUG_EVENT : 디버깅 중인 프로세스 종료 3. CREATE_PROCESS_DEBUG_EVENT일 경우, 즉 처음 attach 될 때 3 - 1. GetProcAddres() 와 GetModuleHandle()을 이용해 후킹할 API 주소 알아내기 3 - 2. ..
윈도우 후킹 테크 맵 https://reversecore.com/55?category=216978
code injection도 결국엔 CreateRemoteThread()라는 함수를 불르는 것이다. 1. OpenProcess()로 process handle 얻기 2. VirtualAllocEx()로 메모리 할당 3. WriteProcessMemory() 함수를 통해 실행할 (함수 주소와 인자) 구조체 주소 저장 4. VirtualAllocEx()로 메모리 할당 5. WriteProcessMemory() 함수를 통해 실행할 코드 저장 6. CreateRemoteThread()함수를 사용하여 5번과정에서 저장한 코드의 주소와 3번 과정에서 저장한 인자로 호출
CreateRemoteThread 1. OpenProcess() 함수로 dll injection할 프로세스 HANDLE 구하기 2. VirtualAllocEx() 함수를 통해 dll injection할 프로세스에 메모리 할당 3. WriteProcessMemory()함수를 통해 로드할 dll dll이름을 입력한다. 4. LoadLibraryW함수의 주소를 구한다. - kernel32.dll 은 프로그램마다 시작 위치가 똑같다. 5. CreateRemoteThread()함수를 통해 원격 스레드를 생성시켜 거기서 LoadLibraryW함수를 실행시켜 우리가 원하는 dll 로드 4번 에서 우리는 LoadLibrary()함수로 쓰는데 LoadLibraryW함수의 주소를 구하는 이유는 http://javahawk..
처음에 ida로 열게되면 함수 이름들이 sub~어쩌구로 되어있는데 메뉴를 이용해서 복구를 시키게 되면 main은 일케 된다. 먼저 setup함수를 보면 대부분의 문제들은 setvbuf를 통해 stdin과 stdout을 버퍼링을 하지 않도록 하게 두는데 왜냐하면 버퍼링을 사용하게 되면 heap영역에 할당을 받아서 버퍼링을 하기 때문에 방해요소가 될 수 있기 때문이다. 여기서 stdout만 버퍼링을 하는 것으로 보아 stdin을 이용해야 될 것이라고 추측할 수 있다. 다음은 input()함수로 입력을 받아서 숫자로 변환시켜준다. free부분인데 여기서 ptr에 있는것을 free하는데 ptr을 초기화하지 않는다. 그래서 취약점이 발생하게 된다. 여기가 중요한데 보통의 문제에서 give_up처럼 포기하는 메뉴가..
가상머신을 쓰게 되면 속도나 용량면에서 손실이 있기 때문에 도커를 활용하는 방법이 더 낫다고 판단하여 도커를 설치하게 되었다. 자세한 Dockerfile은 https://github.com/youngsouk/docker_ubuntu_16.04 https://github.com/youngsouk/docker_ubuntu_18.04 여기에 올려져있다. image파일은 docker pull young34844/ctf_ubuntu_16.04 docker pull young34844/ctf_ubuntu_18.04 이런식으로 해서 받을 수 있다. 기본적으로 pwntools, python, gef ,zsh 등등이 설치되어있다. 그리고 내가 좋아하는 쉘 프롬프트인 pure도 설치를 해놓았다. 추가로 alias pwn1..
문제를 ida로 디스어셈을 봤을 때 구조는 단순하다. malloc을 해주고 free를 해주게 된다. 이 문제를 익스 플로잇하는 방법은 간단하다. 1. fastbin 크기로 malloc (순서 조심) - libc leak 2. stdin _IO_buf_base 수정 3. 다시 stdin _IO_buf_base 수정 4. one_gadget 또는 system 주소 입력 첫번째로 fastbin 크기로 작은것 1개 그것보다 큰 크기로 1개를 할당한뒤 다시 한번 할당을 하면 libc leak이 이루어지게 되는데 그 이유는 malloc_consolidate라는 함수 때문이다. 코드로 나타내면 이렇게 되는데 ### libc leak malloc(24,'a' *24) malloc(50, 'a') malloc(200, ..
z이전 글들과 같이 setvbuf를 이용한 프로그램을 하나 짜고 실행을 시켜보면서 함수들을 알아내고 glibc에서 그 함수들을 볼 수 있습니다. #include int main(){ setvbuf(stdin, 0LL, 2, 0); } #define _IOFBF 0 /* 완전 버퍼링. */ #define _IOLBF 1 /* 줄 버퍼링. */ #define _IONBF 2 /* 버퍼링 하지 않음. */ int _IO_setvbuf (_IO_FILE *fp, char *buf, int mode, _IO_size_t size) { int result; CHECK_FILE (fp, EOF); _IO_acquire_lock (fp); switch (mode) // mode에 따라 다르게 작동한다. { case _..