Dreamhack_System

welcome 문제이다.

📒 Description 보호기법들은 적용되어있지 않은 것을 확인할 수 있다. 📒 C code 분석을 해보자. 먼저 buf의 주소를 알려주고 있다. stack을 따로 leak할 필요는 없을 것 같다. 이후 141바이트를 받으므로 BOF가 발생하게 된다. (0x

이전 문제와 다르게 NX Bit가 설정되어 있다. 그러므로 shellcode는 불가능할 것이다.BOF를 발생시켜 main stack의 RET부분에 read_flag 주소를 넣으면 되겠다.저번 문제와 마찬가지로 buf와 SFP 사이에 dummy가 있는 지만 확인해보자.l

Partial RELRO가 걸려있으며 NX 또한 걸려있다.이전 문제와 마찬가지로 get_shell을 실행시켜야 하겠다.print(buf) 이 부분에서 format string bug 취약점이 존재함을 알 수 있다.또한 exit(0)이 존재하므로 exit_got을 ge

NX만 걸려있고, Partial RELRO로 걸려있다. 쉬운 문제의 마지막이다 ..heap_buf에는 0x80만큼, stack_buf에는 0x90만큼 할당되어 있다. 그렇기에 stack_buf를 완전히 덮는게 불가능해 보일 수도 있긴 sprintf를 통해 전달하므로

Reference의 내용들이 자꾸 힌트가 되는 것 같다.NX와 Canary가 걸려있으며 Partial RELRO 또한 적용되어있다.system("/bin/sh")를 실행할 수 있으면 되겠다. 우리는 system에 인자로 commandidx를 전달한다.이 때 idx의

main함수가 아니면 execve, execveat 시스템 콜 사용 불가능하다고 하다.open -> read -> write를 해주면 풀리지 않을까 ?shellcode를 실행하게 되므로 위에서 말한 대로 flag 파일에 대해 orw를 하도록 하자.자세한 설명은 생략한다

SIGSEGV가 뜨면 get_shell 함수가 실행됨.size 값은 0 이상, 255 이하여야 함 => size가 0이라면?size가 0이라면 read(0, buf, -1)이 실행된다.read 함수의 세 번째 인자는 size_t 자료형으로 받고, 이는 unsigned

문제를 풀어보자.read_str 함수를 보면 read(0, ptr, 20)을 하며 ptrlen = 0으로 맞추게 된다.만약 우리가 20바이트를 입려갛게 되면 ptr20 = 0이 되고, 그 값은 age를 0으로 바꾼다.따라서 get_shell을 실행하게 된다.

libc 파일도 함께 주었다.read 함수에서 BOF가 발생한다. libc_base를 구하고 system을 실행해주면 되겠다.첫 번째 ROP에서 write_plt + pppr + 1 + write_got + 4 + main 을 해주어 write_addr을 구할 수 있게

64비트 rop이다.솔직히 rop는 64비트가 32비트보다 쉬운 것 같다.https://velog.io/@mm0ck3r/Dreamhack-basicropx86위의 문제와 똑같은 문제이다. 하지만 64비트인 점 !pop rsi; pop r16; ret 가젯을

으음... buf에는 제한 없이 입력을 받고 있다. ret주소를 get_shell로 옮기면 어떻게 될까?

libc.so.6 파일도 같이 준 점으로 보아 libc_base를 구해서 풀 수 있겠다.libc_base는 stdout 주소를 이용하여 구할 수 있겠다.원가젯은 특정 조건일 때만 풀리기에 안 풀릴까봐 걱정을 많이 하기는 했다. (사실 ROP하면 된다.)stdout이나

center_name에 100바이트를 받는다. 이 과정에서 오버플로우가 발생한다.그리고 strncmp(cmd_ip, "ifconfig", 8)의 결과가 같아야 하는데, 그렇다면 cmd_ip를 실행한다고 한다.우선 center_name에서 발생하는 BOF를 통해 cmd_

dreamhack hook 문제이다.RELRO, Canary, NX가 다 걸려있어서 어려울 수도 있겠다.c 코드를 보면 stdout을 출력하므로 libc_base는 구할 수 있겠다.우리가 원하는 size를 입력하고, 그 만큼 동적할당을 하는 부분을 확인할 수 있다.이후

그렇습니까 ?보호기법은 꽤 걸려있는 편이다.우선 감사하게도 system 함수를 사용하고 있다. libc 파일이 따로 존재하지 않으므로 매우 큰 도움이다.이 프로그램은 두 번 실행해야 하는데,1\. Leak Canary & Change RET to main2\. chan

이전 문제와 유사한 형태이다. 마찬가지로 canary를 leak해야 한다.https://velog.io/@mm0ck3r/Dreamhack-ReturntoLibrary이 문제와 똑같이 접근하면 된다.위의 링크와 동일하게 풀 수 있으므로 자세한 풀이는 생략한다.

이번에는 실행파일을 제외하고는 어떠한 파일도 제공하지 않았다.validator_dist를 가지고 문제를 해결해보고자 한다. ( validator_server와 같은 파일인 것 같다.)main function이다. memset을 한 후에 validate 함수를 실행하는

좀 길다 ...? 우선 서버 환경에서는 Double Free가 가능하다.Create -> Delete -> Delete -> Create(puts_got) -> Create('a') -> Create('get_shell')이렇게 페이로드를 전달하면 문제가 풀리겠다.

https://velog.io/@mm0ck3r/Dreamhack-hook이 문제와 비슷하게 풀면 되겠다. 근데 모든 보호기법이 다 걸려있네 ?buf에서 BOF가 발생한다. 여기서 libc_start_main을 통해 libc_base를 구해야겠다.주소와 값을 입

문제 값 하게 canary overwrite or leak 해주어야 할 것 같다.Canary를 leak할 방법은 마땅히 떠오르지 않는다.그렇다면 우리가 Canary를 임의로 설정해주면 되겠다. 실제로 thread_routine 내에서는 canary와 주소가 가까우므로

모든 보호기법이 다 적용되어있다. ㅎㅎ.코드가 굉장히 길다. 하지만 어렵지는 않다. 우리는 /home/pwnlibrary/flag.txt의 파일을 열어야 하는데,steal_book 함수를 보면 fopen 함수를 통해 우리가 입력한 경로를 연다는 것을 알 수 있다.그리

double free는 되지 않지만, 원하는 청크를 modify 할 수 있기에 사실상 같은 취약점이 존재한다고 봐도 무방하다.https://velog.io/@mm0ck3r/Dreamhack-tcachedup 참조 한 번 하도록 하자.got overwrite를

int mode = SECCOMP_MODE_STRICT;이것만 집중하자. shellcode를 실행하기 전에 syscall_filter()를 호출하는데그 전에 mode 값을 0이 아닌 100으로 바꾼다면 bypass를 할 수 있을 것이라고 생각하였다.

모든 보호기법이 다 걸려있다. ...우선 Human의 age가 Robot의 fptr로 들어가져야 한다.초기화를 진행하지 않으니 overwrite 취약점이 존재하겠다. 그렇다면 libc_base는 어떻게 leak 할 수 있을까?unsorted bin에 할당되었다가 해제된

\_IO_file Vtable에 관한 문제이다. 생소하기에 그만큼 어렵다고 느껴지기도 한다.vtable을 overwrite 해주어야 할 것 같다.https://lactea.kr/entry/pwnable-IOFILE-structure-and-vtable-ove

모든 보호기법이 다 적용되어있다.cpp이다. 그냥 readbuffer에 NULL 문자 없이 쫙 덮어버리면 show_contents 함수에서 flag까지 출력하지 않을까?

뭔가 canary 문제는 그래도 쉬운 감이 있다. overwrite 하거나 leak 하거나 ..(1) -> (2) 를 하게 되면 global_buffer는 thread_routine 내의 buf 주소를 가지게 된다.따라서 canary leak을 할 수 있게 된다. (f

get_string 함수에서는 딱히 취약점이라고 할 만한 것이 보이지 않았다. 따라서 buf에 0x20만큼 입력을 받는다고 생각을 해보자. 우리는 changeme 값을 1337로 바꾸어야 한다. 그렇다면 쉘을 딸 수 있다.buf에 입력을 받고 printf(buf)를 하

뭐 이런 ... 우선 pop rax; syscall; ret이 존재하므로 syscall을 사용할 수 있겠다.https://rninche01.tistory.com/entry/Linux-system-call-table-%EC%A0%95%EB%A6%ACx86-x64

우왓 모든 보호기법이 다 걸려있다.우음... 음.......... 원하는 주소의 값을 바꿔주는 것 이외로는 공격할 수 있는 방법이 없다.이 때 우리는 rtld라는 영역을 참조할 수 있다.https://aidencom.tistory.com/158 자세한 내용은

environ에 관한 문제인 듯 하다. 우리는 현재 스택의 주소를 모르는데, 그것이 environ에는 적혀있다. 또한 스택 간의 오프셋은 유지되기에 그 점을 이용하여 문제를 쉽게 해결할 수 있겠다.

우선 read로 fp에 값을 입력받는다. 하지만 중요한 것이 fp는 FILE Pointer이다. 그렇기에, 우리는 우리가 원하는 file 구조체를 만들 수 있다. 이후 밑을 보면 fread 함수를 실행하는데, 여기서 값이 작성되는 부분을 바꾸어버릴 수가 있다. IO_b

이 문제의 버전은 validate 포인터가 변경되었는 지를 검사한다. 따라서 우리는 vtable 포인터를 변경할 수는 없는 상태이다. \_IO_str_overflow를 이용해야 한다. 내가 생각한 풀이 방법이다. 위처럼 풀이하면 된다.

https://velog.io/@mm0ck3r/Dreamhack-IOFILE-Arbitrary-Address-Write이 문제처럼 풀이하면 되겠다.read_flag 함수를 호출하고 난 후에 flag_buf에는 flag의 내용들이 들어가지게 된다.read(0,

본 풀이를 진행하기 전에, 진짜 많이 시도한 문제이다.생각보다 코드가 그리 길지는 않다. 문제를 어떻게 풀어야 할까. 우선 Edit chunk를 통해 free된 chunk여도 그 값을 바꿀 수가 있다. 딱히 실행할 것이 보이지 않기에, 우선 stdout이나 stdin을

Partial RELRO만 걸려있으며 32비트 체제이다.cp_name을 256 바이트를 받는다. 마지막 바이트까지 받으므로 cpy 함수에서 SFP는 하위 1바이트 오염이 가능하다. 이는 Frame Pointer Overflow (FPO) 공격으로 이어진다.서브함수의

어려울 느낌이 든다.PIE는 걸려있지 않다. 우리가 원하는 주소를 원하는 값으로 바꿔쓸 수 있다. read(0, buf, 0x80) 에서 bof가 발생할 수 있다.get_shell 주소를 RET에 덮어 씌워야 할 것 같은 생각이 든다. 그런데 canary leak 때

호오 ...첫 번째로 P에서 범위 확인을 하지 않기에, 원하는 idx의 값을 출력받을 수 있다.두 번째로 E에서는 name 보다 큰 사이즈를 name_len 만큼 받아 BOF를 발생시킬 수 있다.Canary를 leak하고 RET를 get_shell로 덮으면 문제는 풀리

그냥 my_page.name과 my_page.age 모두 꽉꽉 담으면 풀릴 문제인 것 같다.my_page.name : "A" \* 16my_page.age : 2147483647이렇게 보내면 문제는 풀린다.

ptr에 크기 조건을 안 두고 입력을 받는데, 이 과정에서 overflow가 발생할 수 있다.그 오프셋 차이가 크지 않을 것 같아 Brute Force로 풀었다. ( 애초에 컴퓨터 환경과 서버 환경이 달라 계산이 실패했다.)

이것 역시 srop로 해결하는 문제인데, 이전에 풀었던 sigreturn 보다 쉬웠던 것 같다.sub_4010B6을 분석해봐야겠다.buf의 크기는 8바이트인데, 0x400만큼 입력을 받고 있다.이런 함수도 있는 걸로 보아 어딘가에 "/bin/sh" 문자열이 존재할 수

올 그린은 볼 때 마다 항상 설레는 것 같다.분석을 하기에 앞서 실행을 먼저 해보도록 하자.1은 명령을 실행, 2는 환경변수 관리, 3은 임시 디렉토리 생성, 4는 그 디렉토리 위에 파일을 만들기이정도로 생각할 수 있겠다.실제로 보면 v0는 함수포인터 sub_2D76

재미있겠다.어...뭐가 좀 길긴 하다.만약 rare_earth를 채굴해낸 다음에, 그 설명을 get_shell의 주소로 바꾸고 설명을 출력시킨다면? 문제는 해결된다.어려워 보이기는 하지만, 매우 쉬운 문제이므로 다른 설명까지 쓰진 않는다.payload를 보내는 구현까