table = {'a': 1,'b': 2,'c': 3,'d': 4,'e': 5,'f': 6,'g': 7,'h': 8,'i': 9} v = table.values() k = table.keys() table.clear() for x, y in zip(v, k) : table[x] = y
mov eax, datamov edi, destmov ecx, sizerep stos(d) 이런식의 어셈블리어가 함수 프롤로그 다음에 있으면edi주소에 해당하는 크기*size만큼 eax로 채운다.b = 1, w = 2, d = 4 byte 이다. 따라서 만약 0x1234에 다가 0을 4바이트씩 100바이트 채우기 위해서는 lea ebx, [0x1234]mov eax, 0mov edx, 25mov edi, ebxmov ecx, edxrep stosd 대충 이런식의 명령어로 memset기능을 할 수 있다. 간단하면서도 memset함수보다 빠른 장점이 있다.
핵스뷰를 eax에 싱크를 맞춰놓고 트레이싱을 하다보면 FindResource함수를 호출하고 난 뒤 헥스뷰를 보면 밑에 exe파일 같은 데이터가 보인다.이게 뭐지 하고 binwalk로 돌려보았다. pe파일이 한개 숨어있다.바로 추출한뒤 트레이싱해보았다. decrypted문자열 주위를 트레이싱 하다보면 위와 같이 ARIA_IS_GOOOD!~!가 스택에 잠시동안 박힌다. decrypted된것이 ARIA_IS_GOOOG!~!임을 알 수있다.
문제는 우선 처음에 serial키를 맞춰야지 메뉴가 나오면서 시작된다. 따라서 serial을 우선 맞춘다음 취약점을 알아내야한다. ascii값으로 57보다 작은값이 12글자이면 오른쪽 화살표로 이동해서 값이 유효한지 확인을 한다. IDA에서 봤지만 연산과정이 복잡한건진 몰라도 핵스레이가 제대로 해석하지 못한다. 따라서 핸드레이(직접 손으로)를 통해서 serial키를 알아내야한다. 과정이 복잡한거 같지만 비슷한 과정을 반복하기 때문에 금방 serial키를 알아낼 수 있다. 1. - a == (AAAA ^ ((44204 ^ 43947 ^ 4080) + ((3855 >> 8) | (3855 11)))) 3. - c == (CCCC ^ ((4080 ^ b ^ a) + ( (b > 13)))) 4. - (((((..
이런 문제이다.직접 서버의 몇개의 명령어를 popen을 통해 실행 시킬 수 있고,user의 정보를 삽입, 수정, 확인 할 수 있다. 문제를 풀때는 insert, modify, show 쪽을 뒤져서 공격을 하려고 삽질을 많이 했다.특히 64bit고 중간에 헷갈리게 많이 해놔서 찾는데 오래 걸렸다....취약점은 명령어 중에 ifconfig를 실행하면 입력을 한번 더 받는다.이상하다. ifconfig는 보통 옵션없이 많이 쓰기 때문에 ida로 살펴 보았다. 빨간색 네모부분이 명령어를 실행 시키는 부분인데check함수에 들어가보면 여러가지 ascii문자들이 필터링 되어있다.근데 $,(,),등이 빠져있다.strcat을 이용해 ifconfig+입력한 문자열을 실행시키기 때문에ifconfig$(sh)이렇게 입력을 하..
문제 자체는 간단한 fsb문제인데, no RELRO이다. fini_array를 overwrite할 수 있다. 원하는 정보를 얻은 후 다시 main함수로 트리거할 때 fini_array 배열을 사용하면 된다. 정적분석과 동적분석을 해보면 스택의 구조는 위 그림과 같다. 나는 저기서 fsboffset 264,267부분을 이용해서 공격을 했다. fsb offset이 264인 부분을 leak한 후, -24를 하면 ebp값을 알아낼 수 있고, 267인 부분을 leak하면 실제 __libc_start_main으로 돌아가는 ret 주소를 알아 낼 수 있다. libc가 주어지므로 offset을 바로 gdb로 확인하여, system함수와 '/bin/sh/주소를 알아 낼 수 있었다. 위 과정을 통해 필요한 주소값들을 알아..
GDB에서는 fork/exec() 이후에도 프로그램을 계속 디버깅 할 수 있는 기능을 제공한다. (GNU/Linux, HP-UX only) 기본적으로는 fork() 이후에는 parent process 만이 계속 디버깅되며 child에 breakpoint를 설정하면 SIGTRAP을 받고 종료되어 버린다. 이를 해결하기 위한 전통적인 방법은 child에 sleep을 걸고 ps 명령 등으로 child의 pid를 알아낸 후에 attach 하는 방식이 사용되었다. 하지만 Linux (커널 2.5.60 이상) 에서는 다음과 같이 GDB에서 직접 처리할 수 있다. set follow-fork-mode child 위와 같이 설정하면 fork() 후에 child process를 디버깅 상태로 만들고 parent는 계속 ..
문제에는 NX말고는 다른 보호기법은 딱히 안걸려있다. 문제 자체도 name입력, 서버상의 랜덤번호 6개를 맞추는 식으로 되어있다. 취약점은 서버의 랜덤번호 6개를 맞추면 이동하는곳에 있다. 보면 printf 함수를 호출하는데 name을 입력받은 버퍼의 주소를 그대로 인자로 넣어주고있다. 따라서 여기서 FSB취약점이 발생한다. 일단 FSB공격을 하기위해 서버의 랜덤번호를 맞추야 하는데 스택의 구조를 잘 살펴보면 name의 길이를 100으로 채우면 뒤에 4바이트에 seed값이 있기 때문에 seed값을 leak할 수 있다. 이러한 스택프레임 구조를 가진다. 먼저 seed값을 leak한 뒤, 그 값을 이용해 랜덤번호를 먼저 맞추고 난 뒤 fsb취약점을 이용해 libc의 주소를 leak하고, exit의 got를 ..
문제는 name을 입력하고 음악과 아티스트를 add, view, modify 하는 프로그램이다. 파일은 32bit 리눅스 실행파일이고, canary와 nx가 적용되어있다. main함수를 보면 memset을 통해 esp + 1C에다가 0x44C * 4만큼 0으로 초기화 해주고 있다. 그리고 바로 뒤에 canary가 들어가는 구조이다. esp를 0xfffffff0와 and연산하므로 일단 ret까지의 dummy가 8 + (0~16) + 4 만큼 필요하다. 그리고 name을 입력하는데 전역변수에 입력을 하기 때문에 원하는 문자열을 입력해서 사용할 수 있다. 이제 취약점이 있는 함수를 살펴보겠다. 여기서 구조체의 구조를 알 수있다. 이러한 구조로 되어있고 크기는 44바이트지만 music과 artist는 21바이트..
문제는 disk를 정하고 그 disk에 값을 write, read, modify하는 기능은 간단한 프로그램이다. 보호기법으로는 NX와 PIE가 적용되어있다... PIE는 라이브러리에 적용되는 aslr이라고 생각하면 된다. 보통 __libc_start_main으로 돌아가는 ret주소를 이용해 offset을 알아낸 후 익스플로잇을 한다. 함수프롤로그 부분과, disk의 해당하는 주소에 구조체를 만드는것을 볼 수 있다. write함수에서 구조체의 구조를 알 수 있다. flag(4), &data(4), description(10), empty(2), datasize(4) 이런 구조로 되어있다. ebp-0c에는 선택되어 있는 disk구조체의 주소가 저장되어있다. 위의 정보들을 종합하여보면 대충 이러한 스택프레임 ..