느리지만 꾸준히 하는 나는 거부기

소스코드가 너무 길어서 중요한 부분만 캡처했습니다.(위에 권한을 해결하는 부분이 있는데 복사해서 코드만 위치만 바꿔주면 되므로...)결국 execve 함수를 이용해서 풀어보라는 것인데... 이게 또 생각없이 접근하면 머리가 아파지는 문제입니다. 먼저 execve 주소는 0x400a9d48 이곳입니다.(p execve로 구하거나 프로그램을 실행하면 그냥 주소를 출력해줍니다.)그렇다면 공격 코드는 ./giant `python -c 'print "A"*44 + "execve 주소" + "AAAA" + "인자1" + "인자2" + "인자3"'` 으로 구성되어야 합니다. 인자 1은 /bin/sh의 주소를 전달하면 되고, 인자 2는 {"/bin/sh", 0}으로 전달해야 하고, 인자 3의 경우는 4 바이트가 0인 ..

쉬운(?) RTL 문제를 풀어보겠습니다.조건도 그렇고 푸는 것 자체가 RTL이죠 ? 스택을 이용하려하면 스택이 널 배신했다고 나오네요.간단한만큼 빠르게 풀어보겠습니다. 일단 시스템 함수의 위치를 찾아보죠 ~시스템 함수의 위치는 0x40058ae0 입니다. 그런데 하나 필요한 것이 더 있죠 ? /bin/sh을 찾아보겠습니다 ~Redhat 7.3에서 했던 것을 우려먹어봅시다... 아무튼 결과적으로,그럼 공격코드는 로 구성되네요.바로 공격해보겠습니다.new divide !

앞에서 설명드린 개념을 이해하셨다면 이제 이 문제를 혼자서도 해결하실 수 있을 것입니다.그래도... 풀이는 해야하니... 소스코드는 (1)에서 보셨을테니 gdb로 바로 분석하면서 가보죠 !main 함수의 leave; ret 부분과 problem_child 함수의 leave; ret 부분에 브레이크포인트를 걸어줍니다.그리고 run `python -c 'print "B"*4 + "A"*36 + "\x40"'` 으로 실행해주세요.앞의 두 부분은 problem_child 함수의 leave; ret 부분인데요. (1)에서 해드렸던 대로 분석해보세요.(아마 제가 (1)에서 언급했던 것들에 대해서 알 수 있으실 겁니다.)아무튼 전 main 함수의 leave 전에 멈춰있습니다. leave 를 수행하기 전에 스택의 상황..

소스코드 바로 보겠습니다.보시면 빨간색으로 네모친 부분에서 strncpy 함수로 할당한 버퍼보다 1 바이트 더 큰 값을 입력받습니다.gdb를 이용해서 공격해보겠습니다.ebp 값을 유지하기 위해서 39 바이트만 넣어봤습니다.(마지막 널값.)그랬더니 0x42424242로 리턴해버리네요 ?? 왜 그럴까요 ? 왜 이와같은 결과가 나오는지 알기 위해서는 leave; ret 에 대해서 알 필요가 있습니다.프로그램의 프롤로그 부분인 push ebp; mov esp, ebp(인텔기준)은 많이 보셨겠지만, leave; ret은 생소한(?) 분들도 계실겁니다.(사실 leave가 생소하죠...)문제를 풀기 전에 leave; ret의 동작을 파악해보도록 하겠습니다.(그만큼 중요하고 앞으로는 설명안합니다.)위와 같이 브레이크포..

소스 코드 먼저 보고 시작해보죠 !정말 어마어마한 코드입니다. 스택을 모조리 0으로 초기화시켜버리네요...(RET 빼고서요.)일단, buffer 보다 높은 주소는 절대 사용할 수 없습니다.그렇다면 일단 이곳을 보고 오세요... 와... 정말 감탄스럽습니다 !그래서 그냥 한 번 질러봤습니다.절대 stdio.h를 포함하지 마세요.이후에 URL에 나와있는대로 컴파일 옵션을 주어 컴파일 한후, export LD_PRELOAD=./printf.so로 등록합니다.등록이 완료되었습니다. 먼저 복사한 gole1 을 실행해보겠습니다.오... 마이 갓... 쉘이 따였습니다 ! 이제 실제 golem에 적용해보죠.안되네요 ... ? 이유는 바로... setuid가 걸려있어서 그렇습니다.권한이 바뀌어서 실행되면서 LD_PREL..

풀긴 풀었습니다만.... 조건이 어려운게 아니라 쉘코드가 왜 안먹히는지 이해가 잘 안되네요 -_-;;추측컨데 전에 썻던 \x2f가 없는 쉘코드에는 특수문자가 존재하는데,argv[0]에 특문이 포함되면 원래 기계어가 실행이 안되는건지... 흠... 모르겠습니다.알게 되면 다시 쓰겠습니다. 풀긴 풀었는데 깨름직 하네요...물론 이번 문제도 디렉토리를 생성해서 25 Bytes 쉘코드로 풀 수 있습니다.9번까지 따라해보셨다면 왜 제가 이번 문제를 쉽게 풀었다는지 알 수 있으실겁니다.Hint: 스택의 끝부분에는 왜인지는 모르겠지만 argv[0]의 값이 존재합니다...P.S. 찾아보니 스택 자체의 형태가 원래 그렇다네요 ~ 여기

이번에는 꼭 소스코드를 봐야하기에 첨부합니다.이번에 추가된 조건은 0xbfff를 사용하지 못하게 되었습니다.그러다보니 기존에 존재하던 필터들도 모두 사라졌군요... 하지만 ! 프로그램이 스택에 어떤식으로 올라가는지 아신다면, 꽤나 쉬운 문제일 수도 있습니다. 간단한 예제를 준비했습니다.차이가 느껴지시나요 ??왜 이런 현상이 일어나는 걸까요 ? 이유는 환경변수의 크기는 고정되어 있기 때문입니다.그래서 환경변수를 침범 할 정도로 많은 값이 들어가면 스택이 점점 위로 이동하면서 크기를 줄입니다.이제 문제를 어떻게 푸실지 감이 오시나요 ?이래도 안오신다면 아래 그림을 보세요.뒤의 A의 갯수를 10만으로 줬을 때의 값입니다.스택의 주소가 어떤가요 ? 이제 어떻게 풀지 감 오시죠 ?바로 풀어보겠습니다.공격코드는 ...

휴... 가면 갈수록 보호하는 종류가 많아지네요.이번엔 상황의 심각성(?)을 깨닫기 위해 소스코드를 한 번 보도록 하죠.보시면 이제 argv[1]까지만 사용가능하며, 그나마 memset으로 argv[1]를 초기화시켜버리네요...하지만 ! argv[0] 필터링이 없어져서 argv[0]를 이용해야 한다는 감이 딱! 왔습니다.그래서 전과 같이 '링크'를 이용해서 풀려고 했으나...계속 오류가 발생하여 찾아보니, '링크'는 '\x2f'(/)가 들어가면 원래 존재하는 디렉토리가 아닌 이상 링크를 안시킨다고 합니다.생각해보면 당연한거죠. 디렉토리가 없는데 그걸 생성하고 그 밑에 또 파일을 생성한다는 것이요.생각을해보다가 그냥 mkdir -p 명령으로 부모디렉토리를 생성하면서 그 밑에 '링크'를 걸고 Exploit을..

너무 길어져서 더 이상의 소스코드를 올리기는 좀 힘들 것 같네요.앞으로는 추가되는 부분이나 새로운 부분만 올리겠습니다.프로그램을 실행할 때 길이가 77글자가 안되면 종료되네요...이 부분은 리눅스의 '링크'를 이용하면 우회할 수 있습니다. 오히려 그 전 문제들에서 추가되는 트릭보다 더 쉬웠던 것 같기도 합니다.일단 orge.c 를 org1.c로 복사한 후에 소스코드에 dumpcode.h를 추가시키고 argv[2]를 이용해서 풀겠습니다.org1.c 에 아래와 같이 추가해주세요.(buffer가 아니라 argv[2]를 보겠습니다.)지금까지와 구조는 똑같으니 RET가 어디있는지는 아실겁니다.그리고나서 프로그램의 길이는 gcc를 이용해서 조작해줍시다.(전 orgeorge... 해서 77자로 만들었어요.)강조하면 ..

문제 6번에는 조건이 하나 더 붙었네요.이번에는 바로 복사해서 dumpcode.h 를 추가하고 밑에 dumpcode(~)를 추가해주세요.여러분들이 어떻게 생각하실지는 모르겠지만 전 아래와 같이 생각했습니다. 1. 기존의 조건이 있으니 환경변수와 버퍼는 제외.2. argv[1]의 길이를 제한.- argv[1]를 이용하지 말자.- 어차피 argv의 값들은 **(이중 포인터)이니 어딘가에 저장이 스택 높은 주소 어딘가에 존재한다.(위의 부분은 프로그램을 자세히 분석 안해보셨다면 처음 아시는 분들도 있을 겁니다.) 그래서 ! 결론적으로 dumpcode(buffer, 1000)으로 스택의 끝까지 살펴보았습니다.사진이 크지만 제가 네모 친 부분만 보세요. argv는 주소를 두 번 참조하기 때문에 결국에는 맨 아래에..