AC3LuCiFer

 ▣ 실행 포맷

윈도우 실행파일 포맷인 PE(Portable Executable)의 기본적인 구조 이해

●    기본 개념

-       실행파인은 재배치 될 수 있음(로드될 때마다 다른 가상 메모리 주소에 로드될 수 있음)

-       OS는 각 프로세서마다 고유한 주소 공간을 제공하지만 주소 공간에는 여러 개의 실행 바이너리들이 로드됨

-       프로그램은 자신의 주소 공간에 실행파일뿐만 아니라 DLL과 같은 추가적인 실행 모듈들을 로드함

-       기존에 사용하고 있는 주소에 다른 프로그램이 해당 주소를 사용하려고 하는 경우 다른 주소에 로딩해야 되는데 이때 재배치 작업을 수행함

# 재배치가 중요한 이유

-       실행모듈헤더에서는 절대주소가 사용되지 않고 코드에서만 절대주소가 사용되기 때문

-       실행 모듈 헤더에서는 항상 상대가상주소(RVA, Relative Virtual Address : 단순 offset값)를 상요함

-       실행 모듈이 로드되고 가상주소를 할당받을 때 로더는 실제 가상주소를 계산함

(모듈의 Based Address + RVA = 실제 가상주소)

●    이미지 섹션

-       실행이미지는 여러가지 섹션으로 나누어 짐

-       코드(text)섹션 : 실행모듈의 코드 포함

-       데이터섹션 : 데이터 포함

-       실행 모듈 로딩 시 메모리 관리자는 섹션 헤더의 설정 내용에 따라 각 섹션에 해당하는 메모리 페이지에 대한 접근 권한 설정함

●    섹션 정렬

-       메모리에 로드되는 섹션의 크기는 일반적으로 페이지 크기의 배수

-       반대로 실행 이미지를 페이지 크기 단뒤로 디스크에 저장하면 실제 필요한 용량보다 훨씬 큰 용량을 차지함(디스크 낭비)

→ 위의 이유로 인해 PE헤더는 섹션정렬을 위한 두개의 필드가 존재함

섹션정렬 필드 : 실행 이미지를 메모리에 로드할 때 사용

파일정렬 필드 : 파일을 디스크에 저장할 때 사용

●    동적 링크 라이브러리(DLL)

-       동적 링크 라이브러리의 개념

프로그램은 하나 이상의 실행 파일로 분리될 수 있고, 각 실행 파일은 프로그램 기능의 일부분이나 일부 기능을 수행하는 것

           장점 : 필요한 기능을 제공하는 실행 모듈만 로드해서 사용함(메모리 낭비를 줄임)

                  프로그램의 기능 변경시 해당 모듈만 변경하거나 추가하면 됨

●    정적 라이브러리(.lib)

-       실행 모듈에 영구히 링크됨

-       프로그램이 빌드될 때 .lib파일안의 코드를 원래 소스코드의 일부분인 것처럼 실행 모듈에 정적으로 링크시킴

-       실행 모듈이 로드될 때 OS는 로드된 실행 모듈안에 정적라이브러리가 있다는 것을 알지 못함. 이는 같은 정정적라이브러리가 포함된 A, B프로그램이 있다면 정정라이브러리가 중복되서 로드될 것임(메모리 낭비가 발생할 수 있음)

●    윈도우 프로그램 실행 시 DLL로드 방법

(1)   정적링크

-       실행 이미지의 임포트 테이블 안에 다른 실행모듈에 대한 정보를 포함시키는 과정

-       실행 이미지가 사용하는 모듈들도 같이 로드함

-       해당 모듈들에 대한 모든 외부 레퍼런스 정보를 올바르게 맞춤

(2)   동적링크

-       실행 이미지가 런타임 시에 다른 실행 모듈에 대한 로드여부를 판단함

-       런타임 시에 모듈을 직접 로드하고 로드한 모듈 이미지의 헤더를 검색해서 호출하고자 하는 함수를 찾아야만 함

  ＃ 리버싱 관점에서 볼 때 정적 링크 방법은 어떤 모듈의 어떤 함수를 사용하는지 전부 할 수 있으므로 좀더 다루기 쉽다

●    헤더(Header)

-       PE파일은 DOS헤더로 시작함

-       하위 호환을 위한 부분으로 DOS시스템에서 PE파일이 실행될 때 에러처리를 하기 위함

(ex: “This program connot be run in DOS mode”라는 메시지가 나타나는 경우가 있는데, DOS상에서 PE실행 이미지를 실행 시킬 수 없다는 의미 → 이 메시지를 출력하기 위해서 PE실행 이미지에는 작은 16bit DOS 프로그램을 포함)

-       헤더 안의 모든 포인터는 절대주소가 아닌 RAV값임

-       유용한 정보들은 PE헤더 안의 추가적인 데이터 구조체 배열인 DataDirectory 구조체 안에 포함됨

(1)   DOS 헤더

-       e_lfanew : 실제 PE 헤더를 가리키는 포인터

(2)   PE헤더

-       DOS헤더가 확장된 것임

●    임포트와 익스포트

-       실행 이미지의 동적링크를 가능하게 해주는 메커니즘

-       컴파일러와 링커는 임포트하는 함수의 실제 주소를 알지 못함 → 실행 시에만 알 수 있음

(임포트 테이블 : 실행 이미지가 사용하는 각 모듈목록과 그 모듈에서 사용하는 함수 목록의 정보가 저장되어 있음)

-       모듈이 모드될 때 로더는 임포트 테이블에 명시된 모든 모듈을 로드 함

-       로드한 각 모듈의 함수 목록에 있는 함수들의 주소를 산출

-       함수 주소는 임포트한 모듈의 익스포트 테이블을 통해 산출

(익스포트 테이블 : 해당 모듈이 익스포트하는 모든 함수의 이름과 RVA를 가지고 있음)

●    디렉토리

-       데이터 구조체

 [ PE파일 포맷의 디렉토리]

▣ Application Programming Interface(API)

-       API는 OS가 App과 통신하기 위해서 제공하는 함수 모음

■    Win32 API

-       로우레벨 프로그래밍 인터페이스 → 향후 하이레벨 인터페이스로 개발됨

-       계층적 구조 : 프로그래머들에게는 프로그래밍하기에 친숙하지만, OS는 모든 호출이 상위계층을 거치므로 다소 성능이 저하됨

-       윈도우에서 핵심적인 Win32 API는 약2,000개

[Win32 인터페이스 DLL과 커널 컴포넌트와의 관계]

●    Kernel API

-       Based API라고도 불리움

-       KERNEL32.DLL 모듈 안에 구현되어 있음

-       GUI와 관련되지 않은 서비스들, 즉 파일I/O, 메모리 관리, 객체 관리, 프로세스와 스레드 관리 등

-       NTDLL.DLL의 네이티브 API를 호출하여 다양한 서비스를 구현함

●    Native API

-       Window NT 시스템의 실질적인 인터페이스

-       Win32 API는 네이티브 API에 상위 계층일 뿐

-       그래픽 관련 서비스를 포함하지 않음

-       메모리 관리자, I/O 시스템, 객체 관리자, 프로세스와 쓰레드 등에 직접 접근할 수 있는 인터페이스 제공(윈도우 커널에 대한 가장 직접적인 인터페이스)

-       App 프로그램은 Win9x와 호환성을 유지하기 위해서 네이티브 API를 직접 호출하면 안됨

-       NTDLL.DLL(user mode 호출자를 위한)과 NTOSKRNL.EXE(kernel mode 호출자를 위한)에서 익스포트된 함수들의 집합

-       네이티브 API 이름은 항상 Nt, Zw로 시작됨

∙ Nt 버전 API : 해당 API를 실질적으로 구현하는 함수

∙ Zw 버전 API : 시스템 콜 메커니즘이 수행되는 함수

＃시스템 콜 메커님즘을 통해 커널 모드 API를 호출하는 이유?

→API를 커널 모드에서 호출한다는 것을 알려주기 위해서이다.

이런 구분 없이 API를 무작정 호출하면 자신이 유저 모드에서 호출되지는 커널 모드에서 호출되는 알 수 없게 된다. 유저 모드에서 커널 모드 API를 호출하면 유저 모드에서 호출했다고 판단해 유저 모드 주소를 포함하고 있는 모든 파라미터를 조사할 것이다. 이는 유저 모드에서 커널 메모리 주소를 전달함으로써 발생할 수 있는 시스템 충돌을 방지하기 위한 메커니즘이다.

-       커널에서의 작업이 완료되고 다시 유저모드로 되돌아갈 때 단순히 스택에 저장된 주소로 돌아감(따라서, 7ffe0304의 ret명령은 실제 실행되지 않음)

▣ 동기화 객체

-       멀티 쓰레드 소프트웨어 설계에서 가장 중요한 측면은 데이터 구조체와 데이터의 유효성을 보증하기 위한 동기화 메커니즘을 설계하는 방법임

-       스케줄러는 쓰레드의 대기 상태 조건이 언제 만족되고 그 때 어느 쓰레드가 실행되어야 하는지 알기 위해서 동기화 객체가 존재하는지 알아야만 함

[흔히 사용되는 동기화 객체]

▣ 프로세스 초기화 과정

▣ 프로세스와 쓰레드

● 프로세스(process)

 - 윈도우 기본 요소

 - 프로세스 메모리 주소 공간 :

· 프로그램을 실행시키기 위해 사용

  · 각 프로그램은 자신만의 고유한 주소 공간에서 실행되는 것을 보장하기 위한 것

· 시스템은 프로세스 주소공간 안에 코드 모듈을 로드

· 실행되는 프로세스는 반드시 최소 하나 이상의 쓰레드를 가져야 함

● 쓰레드(thread)

 - 가장 기본적인 코드 실행 유닛

 - 매 순간마다 프로세스는 항상 쓰레드를 실행 시킴(즉, 실행코드를 실행함)

 - 쓰레드가 마지막으로 실행됐을 때의 프로세스 상태를 시스템에게 알려주는 CONTEXT Data 구조체와 스택공간으로 사용된 하나 또는 두개의 메모리 공간이 결합된 데이터 구조체일 뿐

- 유저모드코드와 커널모드커널을 번갈아 가면서 실행(하나의 쓰레드는 두개의 스택을 가질 수 있음)

-  유저모드스택과 커널모드스택 분리(보안성, 안정성)

● scheduler and dispatcher

- 스케줄러와 디스페처에 의해 쓰레드 관리

- 어느 쓰레드를 얼마만큼의 시간동안 실행시킬지 판단하고, 현재 실행 중인 쓰레드를 다른 쓰레드로 바꾸기 위한 실질적인 컨텍스트 스위칭을 수행함

# 윈도우 커널은 선점형이고 인터럽트 가능함 → 이는 커널 모드에서 실행되고 있는 쓰레드는 유저모드의 쓰레드와 만찬가지로 인터럽트될 수 있음을 의미함

● 컨텍스트 스위칭

EX: 쓰레드가 CPU를 점유하고 그 쓰레드에 대한 실질적인 인터럽트를 수행하면 안되는 경우가 있음(예:GetMessage 처리 시)

이 때 커널은 프로세서의 전체상태를 저장하고 다른 쓰레드로 스위칭해서 그 쓰레드를 실행 시킴

어느 한 프로그램의 실행이 한가한 시점에는 충분히 다른 프로그램이 CPU를 사용할 수 있고 프로세서의 실행이 지연되는 것을 막기 위해 쓰레드 스위칭을 수행함

● 퀀텀(Quantum)

 - 모든 쓰레드가 연속적으로 실행될 수 있는 최대 크기의 시간

 - 커널은 로우레벨 하드웨어 타이머를 이용해서 쓰레드가 얼마 동안 실행되고 있는지 모니터링함

▣ 네임드 객체

 - 일부 커널 객체는 시스템 상에서 자신을 고유하게 구별할 수 있는 이름을 가질 수 있음

 - 여러 프로세스가 동일한 이름의 객체를 사용하면 각 프로세스가 사용하는 해당 객체는 동일하다는 것이 보장됨

 - 이미 존재하는 객체에 대해 CreateMutex와 같이 객체를 생성하는 API가 호출되면 커널은 자동으로 해당 객체를 글로벌 테이블에 위치시키고 해당 객체에 대한 핸들을 반환함

 - 네임드 객체는 계층 디렉토리 구조로 배치됨(User Mode에 Win32 API로 접근 불가능)

[주요 객체 디렉토리]

▶ BaseNamedObjects

- 전통적인 Win32네임드 객체 저장

- 모든 네임드 객체 Win32 API는 자동으로 이 디렉토리를 사용(APP는 이를 변경 할 수 없다)

▶ Devices

- 현재 활성화된 시스템 디바이스의 디바이스 객체를 저장

 - TCP와 같은 논리적이 디바이스뿐만 아니라 Harddisk0와 같은 물리적인 디바이스인 경우에도 모두 해당됨

 - Win32 API는 직접 접근 불가능 à 심볼릭 링크를 통해 접근 가능

▶ GLOBAL

 - 심볼릭 링크 디렉토리

 - 커널객체의 예전 스타일 이름(DOS 네이밍 체계를 따름)

 - Win32 App에서는 디바이스에 접근하려면 반드시 심볼릭 링크 이름을 이용해야 함

▣ 객체와 핸들

 - 원도우 커널은 객체 관리자에 의해서 객체가 관리됨

 - 커널 관련 객체만 관리(섹션, 파일, 디바이스 드라이버, 동기화 객체, 프로세스, 쓰레드 등)

 - 모든 객체는 단순희 nonpaged pool 커널 메모리에 저장된 데이터 구조체임

 - 객체는 해당 객체의 표준 객체 헤더만 알고 있음

● 핸들

- App는 객체 데이터 구조체에 직접 접근 못함 → 핸들을 이용해 객체 접근

 - 프로세스 안에서 객체를 구별하기 위한 숫자로 이뤄진 구분자

 - 핸들 값은 프로세스 핸들 테이블에서의 해당 객체에 대한 인덱스 값

[객체와 프로세스 핸들 테이블]

○ 액세스 마스크(Access Mask) : 두개의 16bit 액세스 플래그 워드로 구성(32bit)된 정수

- 상위워드 : GENERIC_WORD, GENERIC_WRITE와 같은 일반적인 액세스 플래그를 포함

 - 하위워드 : PROCESS_TERMINATE(핸들을 이용해서 프로세스를 종료시킬 수 있음)

             KEY_ENUMERATE_SUB_KEYS 플래그(레지스트리 키 안의 하위 키들을 열거)

○ 커널은 모든 객체에 대해 두개의 레퍼런스 카운트를 관리함

  - 커널 레퍼런스 카운트(kernel reference count)

  - 핸들 카운트(handle counter)
위의 두개 카운트 모두 0일 때 삭제됨

국내 출시된 안드로이드폰인 모토리이와 안드로-1에서 악성코드가 발견되었다고 '쉬프트웍스'가 30일 밝혔다.

쉬트프웍스에 따르면 현재 발견된 안드로이드폰의 악성코드는 약 50가지가 되며, 현재 해당 악성코드로 인한 신고건수는 총 700~800건에 달한다고 밝혔다.

이러한 결과는 지난 22일부터 쉬트프웍스가 미래에셋과 동양증권에 공급하기 시작한 'VGUARD'라는 스마트폰용 백신을 통해서 확인된 것으로서 주로 사용자 스마트폰에 저장된 휴대전화 번호 등의 개인정보를 수집하거나, 스팸광고를 하는 기능이 주를 이루고 있다.

쉬트프웍스의 VGUARD는 현재 안드로이드 뿐만이 아니라 윈도우 모바일 및 아이폰 플랫폼 용으로도 출시되어 있으며. 스마트폰 내의 악성코드 및 실시간 감시, 예약검사, 해킹폰 탐지 기능을 갖추고 있는 스마트폰용 백신 어플리케이션이다. 아이폰용 VGUARD는 아이폰의 Jail Break 및 악성코드 검색기능만을 제공하고 있다.

쉬트프웍스의 이러한 발표에 일부 네티즌들은 자사의 백신 프로그램을 홍보하기 위한 과장된 광고가 아니겠느냐라는 의심의 눈치를 보이고 있으나, 사용자가 늘어가는 스마트폰을 이용한 악성코드에 관한 해외 사례가 잇따르는 등 스마트폰의 보안에 대해 관심을 가지고 있다.

■ 색션 객체

- OS가 관리하는 특별한 메모리

- 하나 이상의 공간에 매핑 될 수 있음(App간에 공유메모리 설정이 쉬워진다)

- 시스템은 색션객체를 이용하여 커널모드 프로세스와 유저모드 프로세스 간에 메모리를 공유할 수 있음

- Win32에서는 “메모리 맵 파일”이라고 부름

• Pagefile-Backed : 정보를 일시적으로 저장하고 프로세스 간이나 App 간, 커널과의 데이터 공유를 위해서 사용됨.

• File-Backed : 하드 드라이브의 물리 파일을 매핑함

이 섹션은 매핑되면서 매핑 대상의 파일의 내용을 포함하며, 매핑된 메모리 내용이 변경되면 파일의 내용도 그대로 변경됨. 이는 메모리 영역의 포인터만을 이용해서 직접 파일의 내용에 접근이 가능함을 의미함

■ VAD 트리(Virtual Address Descriptor)

- VAD트리는 개별 프로세서의 주소할당을 관리하기 위해 윈도우가 사용하는 데이터 구조체

- 바이너리 트리 구조

- 각 프로세스마다 고유한 자신의 VAD트리를 보유

• Mapped allocation : 주소 간 안에 매핑된 메모리 맵 파일(프로세스 주소공간에 로드된 모든 실행 바이너리와 모든 메모리 맵 파일)

• Private allocation : 프로세스 안에 지역적으로 할당된 메모리(ex: Heap, Stack)

■ 유저 모드 메모리

• Private Allocation

 - 프로세스에서 가장 기본적인 형태의 메모리 할당

 - App이 virtualAlloc Win32 API를 이용해서 메모리 블록을 요청

 - 항상 페이지 크기 단위

 - 시스템이 스택이나 힙을 할당할 때 사용

• Heap

 - 힙 메모리 할당을 위해서는 virtualAlloc API를 사용하지 않음 à 런타임 라이브러리 함수 malloc이나 시스템 힘 API인 HeapAlloc을 사용함

 - App는 VirtualAlloc API를 이용해서 메모리 블록을 직접 할당함으로써 자신만의 힙을 구할 수 있음

• Stack

 - 스레드가 생성되는 동안에 해당 스레드를 위한 스택을 자동 할당

 - 유저모드 스택은 스레드 내부에서만 사용됨

• 실행

 - 시스템은 App 코드를 실행하기 위해 코드를 메모리 맵 파일로서 메모리에 로드함

• 맵 뷰(섹션)

 - App은 메모리 맵 파일을 생성해서 그것을 주소 공간에 매핑시킬 수 있음(두개 이상의 프로그램이 메모리를 공유할 수 있는 일반적임 방법)

■ 메모리 관리 API

＋Win32 로우레벨 메모리 관리 API

• VirtualAlloc

 - 유저모드 주소 공간에 메모리 블록을 할당

 - 메모리 블록의 크기는 항상 페이지 크기의 배수

    reserve type : 실제로 주소 공간에 메모리를 할당하지 않고 단순히 예약만 함

    commit type : 실제로 시스템 페이지 파일 안에 메모리 공간을 할당

• VirtualProtect

  - 메모리 영역의 보호 설정 값을 변경함

• VirtualQuery

  - 메모리 블록의 종류가 무엇인지, 사용되지 않고 있는 메모릴 블록인지 등과 같은 메모리 정보 질의

• VirtualFree

  - 할당된 메모리 블록 해제