일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 윈도우 커널 디버깅
- Windows Kernel Driver
- 윈도우 커널
- vcruntime140.dll
- 포너블
- Windows Kernel Debug
- ucrtbase.dll
- 바이트 오더
- Msvcrt.dll
- pwnable
- 네트워크 바이트 오더
- C언어 패킷캡쳐
- windows kernel debugging
- Network Byte Order
- 윈도우 커널 드라이버
- hacking
- apphelp.dll
- Windows
- packet capture
- 개발하기
- pcap packet capture
- vcruntime.dll
- HackCTF
- 개발 환경 준비
- arudino
- 해킹
- pcap packet
- 시스템해킹
- Windows Kernel
- IAT Hooking
- Today
- Total
목록Hacking/HackCTF (8)
미친해커
┌──(root💀DESKTOP-H0EJIE2)-[~/Hacking/Pwnable/HackCTF/offset] └─# checksec offset [*] '/root/HackCTF/offset/offset' Arch: i386-32-little RELRO: Full RELRO Stack: No canary found NX: NX enabled PIE: PIE enabled 보호기법은 스택 카나리를 제외한 모든 보호기법이 걸렸이다. 생각 외로 어려운 문제가 될수도 있다고 생각한다. Funtions window를 확인해보니 main 함수 이외에도 사용자 정의 함수가 여럿보인다. 아무래도 print_flag 함수를 실행시키면 flag를 따낼 수 있을것으로 보인다. int print_flag() { char i;..
보호기법은 아무것도 걸려있지 않은걸로 보아 간단하게 풀 수 있는 문제라고 예상된다. main 함수를 분석해보자. main 함수를 보니 이번에는 친절하게 s의 버퍼가 128 바이트라고 명시되어 있다. scanf를 이용하여 개행문자(엔터)가 나오기 전까지 입력을 받고 현재 버퍼의 주소를 출력 후 16바이트 만큼 문자를 출력한다. 그 이상 문자가 있다면 그 다음 주소를 출력하고 또 다시 16바이트 만큼 출력하는 걸 반복하는것 같다. 한번 입력을 시도한 후 출력이 끝나면 다시 입력할건지에 대한 질문이 나온다. 코드만 봐서는 자세히 알 수 없으니 한번 실행을 해보자 한번 실행을 해보니 확실히 알 수 있었다. 버퍼의 주소는 바뀌지 않고 null을 기준으로 출력하기 때문에 뒤에 문자가 더 있어도 출력을 멈추는것 같다..
먼저 보호기법을 확인하자 보호 기법은 아무것도 안 걸려 있다. 어떤 공격을 시도해도 가능할 것 같다. 우선 함수를 살펴보면 v4의 사이즈가 엄청난걸 확인할 수 있다. 무려 27,952 (0x6D30) 바이트다. gets 함수에서 BOF가 발생하는데 그 전에 printf 함수에서 v4의 주소를 출럭해준다. 한번 실행을 해보자 v4의 주소를 출력해주고 입력을 받은 뒤 종료하는걸 볼 수 있다. v4의 주소를 알 수 있으니 shellcode를 넣고 ret 주소를 v4로 덮어쓰면 Shell이 따지면서 flag를 얻을 수 있을 것 같다. ASLR때문에 계속 stack의 주소가 바뀌지만 v4의 주소를 출력해주기때문에 문제 없다. # file : Simple_size_bof.py from pwn import * p =..
이번에는 HackCTF의 첫 64Bit Pwnable 문제이다. 기존까지 IDA 32Bit를 이용해서 디스어셈블을 했지만 이번 문제는 IDA 64Bit를 이용해야 한다, (혹시라도 IDA가 없다면 어둠의 경로를 추천..) 그리고 지금까지는 생략했지만 앞으로 문제를 풀기 전에 checksec를 활용해서 꼭 보호기법을 확인하도록 하자 Full RELRO와 NX가 걸려있다. Full RELRO은 GOT Overwrite 기법을 사용할 수 없고 NX는 shellcode를 삽입하여 실행할 수 없다. main 함수이다. 처음에 scanf에서 Buffer OverFlow가 발생하는걸 확인했다. 그 후에는 별 다른 취약점이 발생하는 부분이 없어보인다. 아마 ret 주소를 덮어씌우는 문제로 보인다. 보통 NX가 걸려있으..
IDA로 디스어셈블을 한번 해보자 이번에는 main 함수 외에 다른 함수는 보이지 않는다. 지역변수 s가 20 (0x14) 바이트 할당이 되어 있고 name은 전역변수로 BSS 영역에 할당되어 있다. gets 함수에서 Buffer OverFlow가 발생 main 함수의 ret 주소를 조작할 수 있을 것으로 보인다. 적용된 보호 기법을 확인해보니 바이너리에는 아무런 보호 기법도 적용되어 있지 않다. 그렇다는 건 바이너리 내에 모든 영역에 읽기, 쓰기, 실행 권한이 존재하며 주소도 변하지 않는다는 말이다. 위와 같이 read 함수가 실행되었을 때 shellcode 코드를 BSS 영역에 작성한다. 그 후 gets 함수에서 Buffer OverFlow를 발생시켜 main 함수의 ret 주소를 BSS (name)..
이번에는 FSB (Format String Bug) 문제이다. IDA를 이용해 디스어셈블해보자 vuln 함수가 정의되어 있는것으로 보인다. vuln 함수를 확인해보자 vuln 함수에서 fgets로 입력을 받고 입력받은 문자열을 snprintf를 이용하여 format으로 복사한다. 이때 Format String에 맞춰 format에 쓰여진다. 하지만 s에 받은 문자열에 서식문자가 있다면 Format String Bug가 발생한다. 만약 취약점이 발생하지 않도록 한다면 '%s' 서식문자를 사용해 format에 쓰면 된다. printf에서는 단순히 format에 쓰여진 문자를 출력한다. 이 외에도 flag 함수도 찾을 수 있다. 이번에도 flag 함수를 실행시키면 flag를 따낼 수 있을 것으로 보인다. 서식..