Ho_use

혹시나 이상하거나 잘못된 것이 있다면 댓글 부탁드립니다. 이번 문제는 ROP를 알기전에 해두면 도움이되는 Ret Sled를 배울 수 있는 문제이다.(나는 ROP를 먼저했었다..ㅎㅎ) 이 문제를 풀려먼 에필로그에 대한 이해가 필요하다.에필로그는 보통 leave와 ret gadget으로 이루어져있으며 * leave gadget의 경우 *[ mov esp, ebp][ pop ebp] * ret gadget의 경우 *[ pop eip ][ jmp eip ] 형태로 이루어져있다.ret gadget이 진행되면 esp는 + 4가 되며[ pop eip ]의 eip에는 esp의 값이 저장되어지는데ret주소에 ret gadget을 넣어주고 그 뒤에 쉘코드를 넣어주게되면ret gadget이 한 번 더 일어나게되면서 esp가..

혹시나 이상하거나 잘못된 것이 있다면 댓글 부탁드립니다. 생각보다 오래걸렸다.. 어떻게 풀어야 할지는 알았으나 삽질을 많이 했다.우선 코드를 보도록 하자!!코드를 보게되면 fopen을 통해서 어떠한 결과값을 버퍼에 저장한다.버퍼에 저장된 값을 lib_addr과 execve_offset에 넣어 더해 ret에 넣어준 뒤argv[1][44]와 비교해서 다르면 프로그램이 종료된다. 그렇다면 우리는 execve 함수의 주소를 알아야 이 문제를 풀 수 있다는 것을 알 수 있었다.그럼 지금부터 하나씩 구해보자 디버깅을 위해 우선 복사본을 만든다. 코드를 보면 첫 번째 popen에서 구하려고 하는 것은 libc_base이고두 번째 popen에서 구하려고 하는 것은 execve함수의 offset이다. 우선 나와있는 명령..

혹시나 이상하거나 잘못된 것이 있다면 댓글 부탁드립니다. Darkknight에서 Bugbear로 가는 문제이다~우선 코드를 보자입력하는 문자열의 마지막이 "0xbf"이면 안된다는 제약이 걸려있다.이 의미는 이전에 사용했던 공격들에 제약이 생겼다는 의미이다.이름을 바꾸어서 하는 공격이라던지 스택의 특성을 이용한 크기를 늘려서 하는 공격들이 불가능하다는 것이다.그렇기 때문에 0xbf로 시작하는 주소가 아닌 다른 주소를 이용해서 공격을 해야한다.문제의 힌트를 보니 RTL을 사용하라는 거보니 RTL로 진행해서 풀면 될 것같다.이전에 이러한 문제들을 풀어봤기 때문에 굉장히 쉽게 접근할 수 있었다. * RTL구하는 방법 *1. ret 이전까지 덮을 수 있는 bufferoverflow 구하기2. libc_base 구..

혹시나 이상하거나 잘못된 것이 있다면 댓글 부탁드립니다. Golem에서 Darkknight로 가기위한 관문이다. 우선 코드를 보도록 하자힌트를 보니 FPO라고 쓰여있다.FPO란 Frame Pointer Overflow의 약자로 FPO를 이용해서 문제를 풀라는 의미이다.보면 strncpy함수에서 버퍼의 크기가 40인데 41개까지 입력을 받을 수 있는 것이보인다.그렇기 때문에 우리는 41번째의 버퍼 1Byte가 변조 가능하다. 즉, SFP -> Stack Frame Pointer를 변조하면된다. FPO를 진행하기위해서는 두 가지 조건이 필요하다.1. 서브함수가 있어야 한다.2. 서브함수에서 SFP 하위 1Byte를 덮어쓸 수 있어야한다. 우선 디버깅을 위해 복사를 해주자~ main함수에는 그다지 필요한 것이..

파일명이 깨져서 rm을 하고싶은데 지울 수 없는 상황이 있다. 예를 들어 아래와 같은 파일명인 경우 지울 방법이 없다. 파일명이 복사되지도 않으며 ?로 되어있지만 ?가 아니기 때문이다. 이럴 때 사용하는게 바로 find와 -inum 옵션이다.ls -li 명령어를 이용하여 파일의 고유번호를 알아낸다음 * find 사용법 *find [찾을 디렉토리경로] [옵션]/ : root에서부터 검색은 진행한다는 의미로 전체검색한다.. : 현재 디렉토리를 포함, 하위 디렉토리까지 검색한다는 의미이다./디렉토리명 : 지정된 디렉토리에서 검색 -exec command {} \; : 파일이 검색된 경우, 검색된 파일들에 대해 특정명령을 수행할 때 사용한다.{ } : 검색된 파일들을 의미함, 여러개의 파일이 검색되면 하나씩 치..

혹시나 이상하거나 잘못된 것이 있다면 댓글 부탁드립니다. Skeleton에서 Golem으로 가보도록 하자!!우선 코드를 보자~코드를 보면 stack destroyer라는 코드가 생겼다.stack에 우리가 넣을 수 있는 거의 모든 공간을 0으로 초기화해버린다. 물론 ret는 빼고! 그렇다면 어떤식으로 문제를 풀어야할까??무언가 초기화 되지 않는 부분이 필요하다는 의미이다.하지만 현재 가진 바이너리에서는 방법이 없다.그렇다면 조금만 더 깊게 생각해보자. 프로그램이 실행될 때실행 파일만 가지고 실행되지 않는다는 점을 생각하면 이 문제를 해결 할 수 있다.메모리에는 실행시킨 실행파일만이 로드되는 것이 아니라는 것이다. 해당 바이너리는 ldd와 file 명령어를 통해 확인한 결과 외부 라이브러리를 사용하고 있었다..

혹시나 이상하거나 잘못된 것이 있다면 댓글 부탁드립니다. 이번 문제는 Vampire에서 Skeleton으로 가는 문제이다.생각보다 쉬웠다ㅎㅎ 코드를 보자! 음 모든 인자들을 초기화하는 코드가 보여진다.하지만 걱정이 없던 이유는 저번에 문제를 풀다가 발견했던유저영역 바로직전의 메모리값이었다.참고 : https://xn--vj5b11biyw.kr/119 그렇기 때문에 우리는 argv[0] 값을 바꾸고 초기화하더라도초기화되지않는 메모리를 알고 있었고 그 부분을 활용하기로 했다. 심볼릭 링크와 nop sled 그리고 쉘코드를 이용해서 진행하였다. 뒤에도 nop을 준 이유는 혹시나 쓰레기값이 들어가서 쉘코드가 제대로 실행되지 않을까봐 넣어주었다. 역시나 초기화되지않은 우리가 넣어준 nop sled + shellc..

혹시나 이상하거나 잘못된 것이 있다면 댓글 부탁드립니다. 이번 문제를 보면 지금까지 있었던 제약들이 달라졌습니다.여러 제약이 사라지고 주소값이 0xbf로 시작하고 그 다음이 "ff"가 아니여야하는 제약이 생겼습니다.즉 최소한 0xbffeffff 부터 무언가 쉘코드를 넣어야한다는 것을 알 수 있었다. 하지만 스택이란 무엇인지 잘 고민해보면 이 문제는 굉장히 쉽게 풀 수 있다.스택은 커질 수록 낮은 주소를 사용해야한다는 점, 즉 스택이 거꾸로 자란다는 성질을 이용하면된다.0xbffeffff 영역에서부터 코드가 실행되게 하려면 nop sled를 사용하면 되고그 nop의 양을 크게 키우면 이 문제는 간단하게 풀 수 있게 된다.0xbffeffff에서부터 0xbfffffff까지의 차이는 0x10000이므로65536..

스택을 확인하다가 분명히 먼저선언되어있는 변수인데도 불구하고 자꾸 낮은 쪽에 쌓이는 현상이 발생했다...즉, 스택이 변수가 선언되어진 반대의 순서로 쌓였다.원인을 알아내기위해 많은 삽질을 했고 결국 친구를 통해 알아냈는데 그 이유는 바로 Reordering이라고 한다. * Thanks to Dongmin * Reordering이란재배치라는 의미로 컴파일러가 메모리 접근속도를 향상시키기위해서 진행하는 것으로최적화를 목적으로 제한된 범위 내에서 프로그램 명령의 위치를 바꾸는 것을 의미한다. 예를 들어 우리가 흔히 볼 수 있는 아주 쉬운 아래와 같은 코드가 있다. 아래는 어셈블리어로 본 소스코드이다. 한 가지 이상한점이 있다. 먼저 선언되어 스택에 쌓이면 스택 특성상 높은 곳부터 쌓여야 하는데위의 그림을 보면..

/proc : process의 약자이며 해당 디렉토리에 프로세들의 정보가 저장된다. /proc/self : 현재 실행 중인 프로세스의 정보가 담겨있는디렉토리이다./proc/ : 해당 PID에 대한 프로세스 정보가 담겨있는 디렉토리다. /proc//map : 현재 실행되고 있는 프로세스의 주소맵이다. procfs (proc filesystem)은 유닉스 기반 OS에서 프로세스에 대한 정보나시스템 정보를 파일 형식으로 제공하는 것을 의미한다. /proc/의 파일들을 확인해보면 크기가 0 이다. 그 이유는 procfs파일은 내부 자료구조에 접근하기 위한 인터페이스에 가깝기 때문이다. procfs 파일을 출력하려고하는 순간, procfs driver가 system call을 수행하여 procfs 파일에 대한 결..