Linux reversing study_basic_1

LINUX REVERSING BASIC #1 ELF 파일 포맷

앞으로 공부할 것
• Linux
• 리눅스용 프로그램 리버싱
• ELF 파일 형식
• 리눅스 환경에서 툴 이용하기
• 디버거, 분석 툴 등
• Windows
• PE 자세히 보기
• IDA Pro 이용하기
• 대회 문제 풀어 보기

목차
• ELF File Format
• File Header(ELF Header)
• Program Header
• Section Header
• Symbol & Relocation
• Linking
• Static Linking
• Symbol
• Relocation
• Symbol&Relocation
• ELF Dynamic Linking
• Dynamic Segment
• Dynamic Linking
• 개요
• 자세히 보기
• 부록
• 참고 사이트

ELF FILE FORMAT
• File Header(ELF Header)
• Program Header
• Section Header

ELF FILE FORMAT
•ELF file format
• ELF : Executable and Linkable Format
• UNIX의 표준 바이너리 파일 포맷
• 대부분의 UNIX, UNIX 기반 OS들이 지원한다.
•ELF file type
• 실행 파일
• 목적 파일
• 공유 라이브러리
• 코어 덤프
• 프로그램의 특정 시점에 작업중이던 메모리 상태를 기록한 것
• 프로그램이 비정상적으로 종료했을 때 만들어진다
• gdb등을 이용하여 오류의 원인을 찾을 때 이용
• 시그널을 보내 코어 덤프 후 종료하게 할 수도 있다

ELF FILE FORMAT
•readelf 프로그램
• 대부분 리눅스에 기본으로 설치되어 있다
• elf 파일을 분석해주는 프로그램
• 터미널에서 커맨드로 실행 가능
• readelf –옵션 파일이름 형태로 이용
•man 페이지
• 터미널에서 man elf 커맨드를 치면 elf에 대한 매뉴얼을 보여준다
• 인터넷에 똑같이 검색해도 얻을 수 있다

ELF FILE FORMAT
• 전체 구조
• 하나의 ELF 헤더(파일 헤더)와 파일 데이터들로 이루어진다
• 파일 헤더 : ELF 헤더
• 파일 데이터 : 0개 이상의 세그먼트들을 정의하는 프로그램 헤더 테이블
• 0개 이상의 섹션들을 정의하는 섹션 헤더 테이블
• 프로그램 헤더 테이블 또는 섹션 헤더 테이블의 엔트리들에 의해 참조되는 데이터
• 프로그램을 실행하기 위해 이용되는 실제 데이터들

ELF FILE FORMAT – 파일 헤더(ELF 헤더)
• ELF File Format – 파일 헤더 (ELF 헤더)
• 이 ELF 파일의 속성을 알려준다
• 뒤따라올 헤더에 대한 위치/크기 정보를 알려준다

•ELF File Format – 파일 헤더 (ELF 헤더)
• man 페이지에서 얻은 ELF Header 구조체 원형
• ElfN_으로 시작하는 자료형은 이 파일이 32비트인지 64비
트인지에 따라 달라진다
• 32비트면 보통 4바이트, 64비트면 보통 8바이트

• e_ident
• unsigned char 배열
• 각 배열의 인덱스마다 정해진 역할이 있다
• 앞으로 이 파일을 어떻게 해석해야 하는지 등에 대한 정보
• 배열의 크기는 0x10로 정해져 있다

• e_ident[0]
• 이 파일이 ELF 파일임을 의미하는 magic number
• 0x7F
• e_ident[1]~ e_ident[3]
• 이 파일이 ELF 파일임을 의미하는 magic number
• E, L, F의 아스키 코드

• e_ident[4]
• 32bit / 64bit 구분
• 예제 파일에서는 1로, 32비트 용 ELF 파일임을 표
시하고 있다

• e_ident[5]
• 이 파일이 이용하고 있는 데이터 인코딩
• Little endian / Big endian 표시
• 예제 파일에서는 1로, 리틀 엔디안임을 알 수 있
다

• e_ident[6]
• 이 파일의 ELF 버전
• 요즘은 무조건 1 이상

• e_ident[7]
• 타겟인 OS ABI
• ABI : 바이너리 수준의 API
• 꼭 정확히 맞아야만 되는 건 아님
• 정확히 맞지 않을 때 안 될 수도 있음
• 예전엔 NULL padding이었기에 옛날 프로그램은 0일수 있음

• e_ident[8]
• e_ident[7]의 내용에 따라 해석됨
• ABI의 버전을 더 명시하기 위한 필드
• 예전엔 NULL padding이었기에 옛날 프로그램은
0일수 있음

• e_ident[9]~e_ident[15]
• NULL padding
• 미래에 필드가 추가되면 이용하기 위한 여유 공간

• e_type
• ELF 파일의 타입
• 실행파일/오브젝트 파일/동적 라이브러리/코어덤프 등 파일타입을 의미
• 2바이트 크기

• e_type
• 예제 파일에서는 2로, 실행 파일을 의미

• e_machine
• 대상 architecture를 명시 (대상 명령어 집합 명시)

• e_machine
• 예제 파일에서는 3으로, 인텔 32비트 CPU를 의
미(386 컴퓨터)
• 아래 define외에도 많음
• 부록 – 참고 사이트에 적혀 있음

• e_version
• 이 파일의 ELF 버전
• 요즘은 무조건 1 이상

• e_entry
• 32비트 ELF : 4바이트 크기
• Entry point의 주소
• VA 형태
• 예제 파일에서는 0x8048380

• e_phoff
• Program Header Table의 시작을 가리킨다
• File Offset (Byte 단위)

• e_shoff
• Section Header Table의 시작을 가리킨다
• File Offset (Byte 단위)

• e_flags
• 대상 아키텍처에 따라 이 필드의 해석이 달라진다
• 요즘 Intel용 파일에서는 그냥 0

• e_ehsize
• 파일 헤더(ELF 헤더)의 크기를 나타낸다 (바이트 단위)
• 32비트 ELF 파일의 경우 일반적으로 52 (0x34)
• 64비트 ELF 파일의 경우 일반적으로 64 (0x40)

• e_phentsize
• 프로그램 헤더 테이블 엔트리의 크기를 나타낸다(바이트 단위)

• e_phnum
• 프로그램 헤더 테이블의 엔트리 수를 나타낸다

• e_shentsize
• 섹션 헤더 테이블 엔트리의 크기를 나타낸다.

• e_shnum
• 섹션 헤더 테이블의 엔트리 수를 나타낸다
• 예제 파일에서는 0x1C

• e_shstrndx
• 섹션 헤더 테이블의 엔트리 중에서, 섹션의 이름들을 포함하는 섹션인 섹션 헤더
스트링 테이블이 있는 인덱스
• = 섹션 헤더 배열에서, '섹션 헤더 스트링 테이블' 섹션이 있는 인덱스

• e_shstrndx
• 예제 파일에서는 0x1B
• 옆 표는 특수 값

• readelf를 이용하여 파일 헤더(ELF 헤더) 읽기
• 옵션으로 h를 주면 파일 헤더만 읽을 수 있다

ELF FILE FORMAT – 프로그램 헤더
• ELF File Format – 프로그램 헤더
• ELF 헤더의 e_phoff 필드의 값이 프로그램 헤더의 파일 오프셋을 나타냄
• 로더에게 제공할 정보를 담고 있음
• 어느 부분을 메모리로 로드 해 프로세스를 만들 것인가에 대한 정보
• 세그먼트에 대한 정보를 가지고 있다
• 세그먼트 : 하나 이상의 섹션을 묶은 것
• 프로그램 헤더는 실행 파일이나 공유 오브젝트 파일에서만 의미가 있음

•ELF File Format – 프로그램 헤더
• man 페이지에서 얻은 Program Header 구조체 원형
• 이 구조체가 배열로 있다 (프로그램 헤더 테이블)
• 최종으로 만들어진 실행 파일은 반드시 프로그램 헤더 테이블이
있어야 한다
• 32비트, 64비트에 따라 다른 구조체를 이용한다
• 몇 멤버의 크기가 다르고, p_flags 위치가 다르다는 차이가 있다
• 32비트를 자세히 보겠음

• p_type
• 이 프로그램 헤더가 정보를 가지고 있는 세그먼트의 타입

• p_type
• 예제 파일의 첫 번째 프로그램 헤더에
서는 0x6
• 이 프로그램 헤더 테이블을 위한 엔
트리임을 의미

• p_type
• PT_LOAD 타입
• 실행 가능 파일에는 적어도 하나 이
상의 PT_LOAD타입 세그먼트가 있어
야 한다.
• 메모리에 로드할 세그먼트를 의미
• 이 세그먼트에는 주로 text 세그먼
트와 data 세그먼트 등이 속한다

• p_type
• PT_DYNAMIC 타입
• 동적 링킹과 관련된 세그먼트

• p_offset
• 이 프로그램 헤더가 정보를 가지고 있는 세그먼트의 파일 오프셋
• 예제 파일의 첫 번째 프로그램 헤더에서는 0x34
• 이 프로그램 헤더 테이블의 시작 오프셋과 같음

• p_vaddr
• 이 프로그램 헤더가 정보를 가지고 있는 세그먼트의 VA
• 이 프로그램 헤더 테이블이 올라올 메모리 주소를 의미

• p_vaddr
• 실제로 이 프로그램을 edb(ollydbg와 비슷한
인터페이스의 디버거)에 올린 후, 메모리 덤프
를 보면 0x8048034 주소부터 프로그램 헤더가
올라와 있음을 확인할 수 있다.

• p_paddr
• 이 프로그램 헤더가 정보를 가지고 있는 세그먼트의 physical address
• physical address를 이용하는 시스템에서 관련있음

• p_filesz
• 이 프로그램 헤더가 정보를 가지고 있는 세그먼트의 파일에서의 크기
• 실제로 ELF 헤더에서 얻은 크기(0x20)와 엔트리 수(0x9)를 곱하면 0x120이 나옴
• 프로그램 헤더 테이블의 전체 크기

• p_memsz
• 이 프로그램 헤더가 정보를 가지고 있는 세그먼트의 메모리에서의 크기
• bss 섹션 등으로 인해 크기가 파일에서와 달라질 수 있음

• p_flgas
• 이 프로그램 헤더가 정보를 가지고 있는 세그먼트의 권한, OR를 이용해 설정
• 읽기/쓰기/실행
• Read, Execute 가능

• p_align
• 이 프로그램 헤더가 정보를 가지고 있는 세그먼트의 메모리와 파일에서의 Alignment
• p_offset mod p_align == p_vaddr mod p_align 을 만족해야 한다.
• alignment를 맞추기 위해 남는 자리에는 NULL padding이 들어 감

•readelf를 이용
하여 프로그램
헤더 읽기
• 옵션으로 l를 주
면 프로그램 헤
더만 읽을 수 있
다

•프로그램 헤더 내용들
• 첫 번째에 Program Header와 관련된 세그먼트에 대한 내용
• 실행 파일이므로 PT_LOAD 타입의 세그먼트에 대한 정보도 있다
• PT_DYNAMIC 타입의, 동적 링킹과 관련된 필드도 보인다.
• 아래는 각 프로그램 헤더가 가리키는 세그먼트에 속하는 섹션들이다

ELF FILE FORMAT – 섹션 헤더
• ELF File Format – 섹션 헤더
• ELF 헤더의 e_shoff 필드의 값이 프로그램 헤더의 파일 오프셋을 나타낸다.
• 각 섹션에 대한 정보를 담고있다.

•ELF File Format – 섹션 헤더
• man 페이지에서 얻은 Section Header 구조체 원형
• 이 구조체가 배열로 있다 (섹션 헤더 테이블)
• 32비트, 64비트에 따라 다른 구조체를 이용한다
• 몇 멤버의 크기가 다를 뿐 큰 차이는 없음
• 32비트를 자세히 보겠음
• 섹션 헤더는 링킹과 디버깅을 위해 있는 헤더이다
• 없어도 실행에 지장 없음
• 실행을 위해 필요한 정보는 프로그램 헤더만으로 충분
• gdb나 objdump 프로그램이 섹션 헤더를 많이 이용
• 섹션 헤더가 없다면 이 툴들을 쓰기 어려워 짐

•ELF File Format – 섹션 헤더
• Section VS Segment
• 실행파일을 만드는 과정 중 링킹시 섹션 헤더를
참조하여 비슷한 성질의 섹션들을 모아 세그먼
트에 모은다.

• sh_name
• 이 섹션 헤더가 설명하는 섹션 이름의 위치
• Section header String Table이라는, 문자열을 모아 놓은 배열에서의 offset
• 예제 파일의 두 번째 헤더에서는 0xB

• sh_name
처음 시작으로 부터 0xB만큼 뒤에 .interp 문자열이 있다

• sh_type
• 이 섹션 헤더가 설명하는 섹션의 타입
• 많은 타입이 정의되어 있다
• 대표적인 타입
• SHT_PROGBITS : 프로그램에 의해 정의된 타입, 프로그램이 역할을 정함
• SHT_SYMTAB : 심볼 테이블과 관련
• SHT_DYNSYN : 동적 링킹과 관련
• SHT_NOBITS : 파일에서는 실제 데이터가 없지만 메모리에서는 SHT_PROGBITS과 유사 (Ex : bss)

• sh_type
• 예제 파일의 두 번째 헤더에서
는 0x1
• SHT_PROGBITS 타입

• sh_flags
• 이 섹션 헤더가 설명하는 섹션의 성질
• Wirte / Alloc / Execute가 대표적
• alloc : 실행했을 때 실제로 메모리에 올라옴
• Ex) 디버깅 정보같은 section은 프로그램 실행 시 필요가 없으므로 alloc 플래그를
off함

• sh_flags
• 예제 파일의 두 번째 헤더에서는 0x2
• Alloc 성질로, 메모리에 올라올 것임
을 의미

• sh_addr
• 이 섹션 헤더가 설명하는 섹션이 시작하는 주소 (VA)
• 메모리에 올리지 않는 섹션은 0으로 설정
• 4바이트 크기 (32비트 ELF)

• sh_offset
• 이 섹션 헤더가 설명하는 섹션의 파일 오프셋
• 메모리에만 올라오는 섹션은 별 의미 없음
• 4바이트 크기 (32비트 ELF)

• sh_size
• 이 섹션 헤더가 설명하는 섹션의 크기
• 메모리에만 올라오는 섹션은 파일에서는 없지만, 메모리에서는 있다.

• sh_link
• 이 섹션 헤더가 설명하는 섹션과 관련 있는 다른 섹션을 가리킴 (섹션 헤더 인덱스를 저장)
• 주로 정해진 타입의 섹션이 이용
• Ex) 동적 링킹 관련 섹션에서, 심볼이나 스트링 테이블 등을 연결

• sh_info
• 이 섹션 헤더가 설명하는 섹션에 대한 추가 정보
• 주로 정해진 타입의 섹션이 이용

• sh_link와 sh_info
• 섹션의 특성에 따라 해석

• sh_addralign
• 이 섹션 헤더가 설명하는 섹션에 적용할 alignment
• sh_addr mod sh_addralign == 0 이어야 한다

• sh_entsize
• 이 섹션 헤더가 설명하는 섹션이 특정 섹션이라면 필요한 필드
• Ex) 해당 섹션의 내용이 배열일 때, 한 엔트리의 크기를 나타냄

• 일반적으로 컴파일러는 다음과 같은 이름으로 섹션을 나누고, 타입을 설정한다
• .text
• 프로그램 코드가 들어가고, 일반적으로 프로그램 헤더도 포함된다
• SHT_PROGBITS type
• .data
• 초기화된 전역변수가 들어간다
• .bss
• 초기화되지 않은 전역변수가 들어간다
• SHT_NOBITS type
• .rodata
• Read-Only data가 들어간다.

• .plt
• Procedure Linkage Table(PLT)가 위치한다
• 동적 링킹에 사용
• .got.plt
• Global Offset Table(GOT)가 위치한다.
• PLT와 함께 동적 링킹에 사용
• .dynsym
• Dynamic symbol table
• import/export하는 모든 심볼을 담고 있음
• SHT_DYNSYM type
• .dynstr
• .dynsym에 의해 참조되는 데이터로, 심볼의 실제 이름을 담고 있음
• SHT_STRTAB type

• .rel.*
• 재배치와 관련된 정보들을 담고 있음
• SHT_REL type
• .hash (또는 .gnu.hash)
• 동적 링커가 심볼을 빨리 찾을 수 있도록 만들어 놓은 해시 테이블
• SHT_GNU_HASH type
• .ctor
• main 이전에 호출될 초기화 루틴, constructor
• .dtor
• main이 끝나고 호출될 종료 루틴, destructor
• SHT_PROTBITS type

•readelf를 이용하여 섹션 헤더 읽기
• 옵션으로 S(대문자)를 주면 섹션 헤더만 읽을 수 있다

SYMBOL & RELOCATION
• Symbol
• Relocation

LINKING
• Symbol과 Relocation은 링킹과 밀접하게 관련이 있다.
• 링킹에는 정적 링킹과 동적 링킹이 있다.
• 정적 링킹 : 실행 파일을 만들 때, 여러 오브젝트 파일들을 통합해 주는 것
• 동적 링킹 : 프로그램을 실행할 때, 오브젝트 파일이 합쳐지는 것
오브젝트
파일
오브젝트
파일
오브젝트
파일
실행 파일
<정적 링킹>
실행 파일
<동적 링킹>
실행 파일
<파일> <메모리>
공유
오브젝트
파일
연결

STATIC LINKING
• 정적 링킹과 동적 링킹 모두 Symbol 테이블과 Relocation 테이블을 이용한다.
• 정적 링킹의 예를 먼저 보자.
Code1.c에서
정의된 전역 심볼
• num
• main
Code1.c Code2.c
Code2.c에서
정의된 전역 심볼
• func
Code1.c에서
참조하는 전역
심볼
• func
Code2.c에서
참조하는 전역
심볼
• num

STATIC LINKING
• 앞의 코드를 재배치 가능 목적 코드로 컴파일하면 아래와 같이 심볼 테이블과 재배치 테이블이
생성된다.
Code1.o
이름 : num
타입 : 내가 정의함/변수
파일 offset : 0x50
이름 : main
타입 : 내가 정의함/함수
이름 : func
타입 : 참조/함수
파일 offset : ??
10 00 00 00
main함수 코드
위치: 0x110
심볼 테이블 인덱스 : 2
call 00000000
Code2.o
이름 : num
타입 : 참조/변수
파일 offset : ??
이름 : func
func 함수 코드
위치: 0x90
mov eax, dword ptr [0]

STATIC LINKING
• 두 재배치 가능 목적 파일을 합치면 각자의 심볼 테이블을 참조하여 재배치 테이블이 가리키고
있는 위치에 있는 값이 적절한 주소를 가지게 한다
Code1.o
이름 : num
타입 : 내가 정의함/변수
이름 : main
이름 : func
파일 offset : ??
10 00 00 00
main함수 코드
위치: 0x110
call 00000000
Code2.o
이름 : num
타입 : 참조/변수
파일 offset : ??
이름 : func
func 함수 코드
위치: 0x90
mov eax, dword ptr [0]
ExecutableFile
main함수 코드
func 함수 코드
call &func
mov eax, dword ptr [&num]
10 00 00 00

SYMBOL
• Symbol
• 실제 주소를 가질 수 있는 단위
• 보통은 전역변수이름과 함수이름
• 종류
• 전역 심볼 1 : 모듈에 의해 정의되고 다른 모듈들에 의해서 참조 될 수 있는 심볼 (not static 함수, not static 전역 변수)
• 전역 심볼 2 : 모듈에 의해 참조되지만 다른 모듈에 의해 정의된 심볼 (extern)
• 지역 심볼 : 모듈에 의해 자신만이 쓸 수 있는 것 (static 선언, 일반 지역 변수는 포함 되지 않는다.)
• 지역 심볼은 실행파일을 생성하기 위해 링킹할 때만 의미가 있다.
• 일반적으로 오브젝트 파일들을 링킹할 때 이용
• Dynamic Linking에서도 이용
• Relocation(재배치) 됨
• 함수나 전역변수의 주소가 고정되어 있지 않음
• 직접 주소를 찾아야 한다
• ->이 때 Symbol을 이용

SYMBOL
• 대부분의 공유 라이브러리와 동적 링킹을 하는 실행 파일은 심볼과 관련된 두
테이블을 갖는다
• .symtab과 .dymsym
• .symtab
• 주로 모든 심볼을 포함
• 디버깅/링킹에 이용
• .dymsym
• 동적 링킹에 필요한 전역 심볼만을 포함
• 동적 링킹에 이용
• ->주목할 부분

SYMBOL
• Symbol
• 심볼 정보를 담는 구조체
• 32, 64bit에 따라 다르다
• 32bit 중심으로 살펴볼 것
• st_name : 심볼의 이름을 가리키는 심볼 스트링 테이블에서의 바이트 오프셋
• st_value : 파일 종류와 상황에 따라 해석이 다름
• 실행 파일과 공유 라이브러리의 경우 해당 심볼의 VA
• st_size : 객체의 크기(바이트)
• st_info : 상위 4bit는 심볼이 어느 지역에 있는 지, 하위 4bit는 심볼 타입 알려줌
• Ex) 0x12라면 1은 Global, 2는 Function임을 의미
• 정의된 값은 다음 슬라이드 참고
• st_other : 심볼의 visibility
• 0이면 default – 지역 심볼은 숨겨지고, Global은 보임
• st_shndx : 관련이 있는 섹션의 섹션 헤더 테이블 인덱스
• 16bit 크기

SYMBOL
• Symbol
• readelf에 s(소문자) 옵션을 주면 심볼과 관련된 정보를 얻을 수 있다.
• .dynsym이 사용하는 문자열은 .dynstr 섹션에 있다.

SYMBOL
• st_info 멤버의 정의된 값 의미

RELOCATION
• Relocation
• 보통 .rel.* 형태의 섹션 이름을 가짐
• Relocation 정보를 담는 구조체
• 32, 64bit에 따라 다르다
• 32bit 중심으로 살펴볼 것
• r_addend 필드를 사용하는 구조체를 쓸지 말지는 상황에 따라 다르다.
• r_offset : 재배치에 의해 영향을 받는 곳의 위치
• 공유 라이브러리나 실행 파일에서는 VA
• Ex) Call XXXX 의 XXXX를 relocation 하고싶을 때, XXXX가 위치하는 주소
• r_info : 심볼 테이블 인덱스와 재배치 유형 정보
• r_addend : 재배치 가능한 필드에 저장될 값을 계산하기 위해 사용되는 가수(더하는 값)
• r_info에 따라 다르지만, 용도는 정확한 위치를 계산하기 위해 이용된다.

RELOCATION
• Relocation
• r_info
• 상위 1바이트 : 재배치 타입
• 하위 3바이트 : 심볼 테이블에서의 index
• 파일에는 리틀 엔디안으로 써 짐에 주의!
• 재배치 타입에 따라 재배치된 주소를 적어주는 방식이 달라진다.

RELOCATION
• Relocation
• readelf에 r 옵션을 주면 Relocation 관련 정보를 읽을 수 있다.

SYMBOL&RELOCATION
•Symbol&Relocation
• Relocation Table은 어느 부분에 있는 값을 바꿀지를 가리킨다.
• 바뀌는 값은 Symbol Table을 이용한다.
• 이름(또는 해시)을 이용하여 Symbol Table에서 찾고, 해당 심볼의 값을 얻는다
• 얻어온 값을 Relocation Table에서 가리키는 주소에 넣어 줌
• 간단히 생각하자면
• Symbol Table : 이름과 해당 이름을 가진 값의 위치에 대한 정보
• Relocation Table : 어느 곳을 수정할지에 대한 정보

ELF DYNAMIC LINKING
• Dynamic Segment
• Dynamic Linking 개요
• Dynamic Linking 자세히 보기

DYNAMIC LINKING
• 정적 링킹과 동적 링킹 모두 Symbol 테이블과 Relocation 테이블을 이용한다.
• 동적 링킹의 예를 보자.
• 정적 링킹 예에서 생략했던 printf를 동적링킹을 이용하여 이용하는 예
Code1.c Code2.c
Code1.c에서
참조하는 전역
심볼
• printf
Code2.c에서
참조하는 전역
심볼
• printf

DYNAMIC LINKING
• 동적 링킹을 하는 함수는 심볼 테이블과 재배치 테이블을 가지고 있다.
ExecutableFile
main함수 코드
func 함수 코드
이름 : printf
VA : ??
위치: 0x40001C (VA)
GOT[0]
call printf@plt
call printf@plt
GOT[1] GOT[2] GOT[3]

DYNAMIC LINKING
• 실행파일을 실행하면 공유 라이브러리를 프로세스
의 메모리에 올린다.
• 함수를 처음 호출하면 got에 실제 함수 주소를 설정하는
루틴이 호출된다
• 이 루틴은 찾고자 하는 함수의 이름을 알아낸 뒤, 메모
리에 올라와 있는 공유 라이브러리의 심볼 테이블에서
해당 심볼을 찾아내어 함수의 주소를 알아낸다.
ExecutableFile
main함수 코드
func 함수 코드
이름 : printf
VA: ??
위치: 0x40001C (VA)
GOT[0]
call printf@plt
call printf@plt
main함수 코드
func 함수 코드
이름 : printf
VA : ??
위치: 0x40001C (VA)
GOT[0]
call printf@plt
call printf@plt
메모리에 로드된 공유 오브젝트 파일
ExecutableFile 프로세스의 메모리
이름 : printf
타입 : 내가 정의 함/함수
VA : 0x601200
printf 함수 코드

DYNAMIC SEGMENT
• Dynamic Segment
• 동적 링킹과 관련된 세그먼트
• 오른쪽 구조체의 배열이 저장된다.
• 32, 64비트에 따라 다르다
• 32비트 기준으로 알아볼 것

DYNAMIC SEGMENT
• Dynamic Segment
• d_tag
• 이 배열 엔트리가 의미하는 것을 표시
• 대표적인 값
• DT_NULL
• 이 구조체 배열의 끝을 의미
• DT_NEEDED
• 필요한 라이브러리 이름이 저장된 스트링 테이블
• DT_PLTGOT
• PLT와 GOT와 관련된 정보임을 의미
• DT_STRTAB
• 스트링 테이블임을 의미
• DT_SYMTAB
• 심볼 테이블임을 의미

DYNAMIC SEGMENT
• Dynamic Segment
• d_tag
• 이 배열 엔트리가 의미하는 것을 표시
• 예제 파일의 첫 번째 구조체에서는 0x1
• DT_NEEDED : 필요한 라이브러리 이름이 저장된 스트링 테이블에서의 오프셋
임을 의미

DYNAMIC SEGMENT
• Dynamic Segment
• d_un
• d_tag에 따라 여러가지로 해석될 수 있는 값을 저장
• 값 또는 주소

DYNAMIC SEGMENT
• Dynamic Segment
• d_un
• 예제 파일의 첫 번째 구조체에서는 0x10
• DT_NEEDED이므로 d_val로 해석된다.
• 라이브러리 이름 libc.so.6을 얻을 수 있다.

DYNAMIC SEGMENT
• Dynamic Segment
• readelf에 d 옵션을 주면 dynamic segment의 값을 읽을 수 있다.

ELF DYNAMIC LINKING
• 리눅스는 동적 라이브러리를 지원한다
• PLT와 GOT를 이용하여 동적 라이브러리를 이용한다
• PLT : Procedure Linkage Table
• 외부 프로시저를 연결해주는 테이블
• GOT에 써 있는 주소(함수 주소)를 호출하는 코드
• GOT : Global Offset Table
• PLT가 참조하는 테이블
• 프로시저들의 주소의 배열
• GOT[0], GOT[1], GOT[2] 는 약속된 값을 저장한다
• GOT[0] : Dynamic 세그먼트의 주소
• GOT[1] : link-map 구조체의 주소
• GOT[2] : _dl_runtime_reslove 함수의 주소

ELF DYNAMIC LINKING
• 리눅스는 디폴트로 Lazy Linking을 지원한다.
• 함수가 처음 사용될 때 링킹한다.
• 함수가 사용된 적이 없을 때, GOT에는 GOT에 적절한 함수 주소를 등록하기 위해 사용될 코드의 주소가 저장되어 있다.
• 함수가 처음 호출되면, GOT에 실제 함수 주소를 등록한다.
• 다음 호출부터는 등록 절차 없이 바로 GOT에 등록된 주소를 이용하여 함수를 호출한다.
• 여기서 말하는 GOT는 .got.plt 섹션이다
• .got섹션은 global 데이터와 관련된 섹션이다. 로드 시간에 relocation을 해결한다.
• .got.plt섹션은 함수 호출과 관련되는 영역이다.

ELF DYNAMIC LINKING 개요
• 첫 번째 함수 호출 시 과정
PLT
해당하는 GOT 참조 코드
GOT
링킹 코드 주소
참조
코드
동적 라이브러리 함수에
해당하는 PLT 주소 call
동적 라이브러리
함수 코드
GOT에 함수 실제 주소를
설정하는 코드
링킹 코드

ELF DYNAMIC LINKING 개요
• Lazy Linking이 완료된 후 동적 라이브러리 함수 호출 과정
PLT
해당하는 GOT 참조 코드
GOT
함수 실제 주소
참조
코드
동적 라이브러리 함수에
해당하는 PLT 주소 call
동적 라이브러리
함수 코드

ELF DYNAMIC LINKING 자세히 보기
• 동적 라이브러리를 이용하는 예를 보자

• 컴파일된 코드는 실제 함수의 주소 대신 해당 함수를 위한
PLT를 참조한다.
• 이 예에서, .plt 섹션의 0x80482E0 주소를 호출한다.

• 위는 PLT의 코드이다.
• 주소를 참조하여 점프하는 코드가 있다.
• 이 예에서, 0x804a00c에 저장된 값을 참조하여 다시 점프한다.
• 0x804a00c 는 .got.plt 섹션에 해당한다.

•PLT의 코드는 .got.plt 섹션에 존재하는 데이터를 참조하여 점프한다.
• 이 예에서, 0x804a00c에 저장 되어있는 주소인 0x80482e6으로 간다.
• 이 역시 .plt에 속하는 주소이다

• 숫자를 push하고, 다시 점프한다.
• push하는 숫자는 GOT 에서 위치와 JMPREL에서의 위치 계산하기 위한
offset
• JMPREL
• 재배치 정보를 담고있는 재배치 테이블
• ELF32_Rel 구조체로 이루어짐
• .rel.plt 섹션에 위치
• 다시 점프하는 주소는 .plt의 시작주소이다.
• PLT 섹션의 맨 앞에는 실제 함수 주소를 구해오고 GOT에 넣기 위한 코
드가 있다.
• 이 부분을 PLT-0 라고도 한다.

•PLT-0에서 다시 숫자를 push하고, 점프한다.
• push하는 숫자는 GOT[1]의 주소이다
• GOT[1]에는 link_map 구조체의 주소가 있다.
• 동적 링커가 필요한 심볼을 알아내기 위해 이용하는 구조체
• jmp하는 주소는 GOT[2]에 저장된 주소이다.
• GOT[2]에는 _dl_runtime_reslove 함수의 주소가 있다.
• 실제 함수 주소를 알아오고, GOT에 그 주소를 씀

• link_map 구조체
• 위와 같은 멤버를 가진다.
• 구조체가 리스트 형태로 저장된다.
• l_addr : 메모리에 올라왔을 때는 라이브러리의 base address
• l_name : 공유 오브젝트의 절대 경로가 저장된 문자열 주소
• l_ld : dynamic linking information segment (PT_DYNAMIC)가 올라온 메모리 주소
• l_next : 다음 노드의 주소
• l_prev : 이전 노드의 주소
• 이 부분은 공개된 부분이고, 각 노드에는 link된 라이브러리에 대한 정보들이 더 포함되어 있음

•_dl_runtime_reslove 함수
• 내부에서 _dl_fixup 함수를 호출한다.
• esp + 0x10에 있는 offset과 esp+0xC에 있는 link_map 구조체의 주소를
셋팅하고 함수 호출
• _dl_fixup 함수는 함수 이름을 얻고, dl_lookup_symbol_x 함수를 호출하여
실제 함수 주소를 구하고, GOT에 값을 넣는다.

•_dl_fixup 함수
• 사용하고자 하는 함수에 해당하는 GOT 주소와 심볼 테이블 엔트리 주소를 얻는다.
• 내부에서 dl_lookup_symbol_x 함수를 호출하여 라이브러리 시작 주소와 라이브러리
에 존재하는 실제 함수 주소들의 offset을 얻어온다.
• export 측 정보를 얻어 옴
• GOT에 값을 넣는다.

•_dl_fixup 함수
• link_map으로부터 정보를 얻어와 edx와 eax에 넣
는다.
• EDX : 사용하고자 하는 함수에 해당하는 JMPREL
엔트리의 주소
• EAX : 스트링 테이블의 시작주소를 얻어온다.
• JMPREL
• Relocation 관련 구조체의 배열
• 각 엔트리의 앞 4바이트는 GOT의 주소, 뒤 4바이
트는 여러 정보를 나타낸다.
• 뒤 4바이트 중 앞 1바이트 : 재배치 타입
• 뒤 4바이트 중 뒤 3바이트 : DYNSYM이라는 테
이블에서의 index (동적 링킹을 위한 심볼 테
이블의 인덱스)

•_dl_fixup 함수
• 앞에서 push 0 한 것에 JMPREL 시작주소를 더하여, 찾고있는 JMPREL 엔트리 주소를 얻음
• 0x8048298로, 첫 번째 엔트리에 해당
• 이 주소에 있는 값을 보면 첫 4바이트에는 GOT 주소가, 뒤 4바이트에는 정보가 있음
• 정보의 첫 1바이트는 7, 뒤 3바이트는 1 (리틀 엔디안)
• 결론은 업데이트 할 GOT 주소와 Symbol을 얻었다는 것

•_dl_fixup 함수
• SymbolTable[1]을 직접 찾아보았다.
• 스트링 테이블 시작부분에서 name에 저장된 offset
1A만큼을 가면 puts 문자열을 찾을 수 있다.

•_dl_fixup 함수
• 함수의 마지막 부분에서 GOT에 값을 설정해준다.
• (EBP에 해당하는 주소를 넣어 놨음..)

• 처음 함수를 실행하여 링킹된 이후에 GOT에는 실제 함수의 시작 주소가 들어간다.
• 이후 함수 호출 시 바로 실제 함수를 호출하게 된다.
<처음 함수를 호출> <처음 이후 함수 호출>

ELF DYNAMIC LINKING
<처음 함수를 호출> <처음 이후 함수 호출>

참고 사이트
• ELF 헤더 – 구조, define 값
• www.sco.com/developers/gabi/latest/ch4.eheader.html
• www.hte.sourceforge.net/doxygenized-0.8.0pre1/elfstruc_8h-source.html
• https://docs.oracle.com/cd/E19957-01/806-0641/6j9vuqujr/index.html#chapter6-35342
• Symbol
• http://timewizhan.tistory.com/entry/%EC%8B%AC%EB%B3%BCSymbol%EC%9D%B4%EB%9E%80
• https://docs.oracle.com/cd/E19683-01/816-1386/6m7qcoblj/index.html#chapter6-tbl-21
• Relocation
• https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-54839.html#scrolltoc

참고 사이트
• Dynamic Segment
• http://osr507doc.sco.com/en/topics/ELF_dynam_section.html
• http://www.sco.com/developers/gabi/latest/ch5.dynamic.html
• PLT와 GOT
• http://ezbeat.tistory.com/374
• http://blog.naver.com/sttng/140004608654
• https://bpsecblog.wordpress.com/2016/03/07/about_got_plt_1/
• https://bpsecblog.wordpress.com/2016/03/09/about_got_plt_2/
• http://9oat.tistory.com/2
• ROP
• http://shayete.tistory.com/entry/6-Return-Oriented-Programming

Linux reversing study_basic_1

More Related Content

What's hot (20)

Similar to Linux reversing study_basic_1 (20)

More from J J (19)

Linux reversing study_basic_1