somma님의 노트

simsimi

Mon, 04 Aug 2008 11:30:14 +0900

심심이 소개
모듈 구성
1. Spider
2. PlgnPE
3. SPDisas
4. SPDriver
5. SPDriverLoader
6. SPInjector
7. SPSymbol

심심이 소개^#

심심이는 Windows system 을 살펴보기 위한 툴입니다.

Sysinternals 의 Process explorer 는 두말 할 필요없이 Windows system 을 살펴보기 위한 최고의 툴이지만 사용하기에 몇 가지 불편한 점들이 있어 직접 만들게 되었습니다.

심심할때 개인적인 필요에 의해서 만들기 시작한 프로젝트여서 '심심이' 라는 이름을 가지게 되었습니다. :-)

심심이는

실행 중인 프로세스의 목록 및 프로세스의 세부 정보
IDT (Interrupt Descriptor Table) 보여주기
커널 메모리 읽기 / 쓰기
user mode module (dll, exe, etc.) 의 변경 사항 추적 및 복원 (user mode api hooking 탐지 / 복원)
kernel mode module (sys, ntoskrnl.exe, etc) 의 변경 사항 추적 및 복원 (kernel mode api hooking 탐지 / 복원)

등의 기능이 있습니다.

부가적으로

향상된 disassembler 를 제공하며 (disassembler 엔진을 사용할 수 있게 해주신 matt conover 씨께 감사를 드립니다)
Windows debugging symbol 을 지원해서 좀 더 편한 분석환경을 제공합니다.

앞으로 어떤 기능들이 추가 될 지는 아직 미정입니다.

필요하다 생각되면.. 만들면 되니까요 ^^

모듈 구성^#

Spider^#

각 엔진을 호출하는 GUI 모듈

PlgnPE^#

실행파일의 구조를 분석하기 위한 플러그인 파일

PE 헤더 구조 분석 (헤더, IAT, EAT, etc)
유저모드 프로세스 메모리 덤프
Borland 계열 링커 처럼 INT (Import Name Table) 이 뭉개져 있는 경우에도 IAT, EAT 분석 가능 (오오~~~ nice !~)
디스크상의 PE 이미지와 메모리상의 PE 이미지 모두 분석 가능
Base relocation 자동 지원 ( cool ~ )
etc...

SPDisas^#

디스어셈블러 엔진

디스어셈블러 코어는 matt conover 씨의 x64 dis 엔진( http://mconover.openrce.org/ )

(소스코드를 제공 해 주고, 사용을 허가 해 준 matt conover 씨에게 감사드립니다.)
x64dis 엔진을 C++ 로 래핑하고, 범용적으로 사용가능한 dll 로 모듈화 시킴
debugging symbol engine 내장 (SPSymbol.dll)

SPDriver^#

커널 모드 드라이버

응용프로그램 레벨에서 접근 불가능한 모든 처리

SPDriverLoader^#

SPDriver 를 커널에 로드하고, 드라이버와 통신을 위한 모듈

여러개의 드라이버를 로드할 수 있으며 각각의 드라이버 인스턴스를 관리
user mode process 가 비 정상 종료되어도 로드한 드라이버의 언로드를 확실히 보장 (cool ~~~ )

SPInjector^#

유저모드 dll injection 프레임 워크

injection 된 dll 과의 통신 채널 유지 가능
Plugin 인터페이스를 지원
injection 후 injection 한 dll 과 통신을 주고 받을 수 있으며 injection 된 dll 의 메소드 호출이 가능

SPSymbol^#

Microsoft debugging symbol support library that embeded in SPDisas

스크린 샷

TODO

공통

함수 단위 덤프
- Base Address 유지 (로드된 기준 주소등의 이미지 정보 및 심볼 정보 포함)
- Image 단위로 덤프하기 보단 함수단위 덤프가 분석에 유용할 듯

RING0

RING3

ASLR: Address Space Layout Randomization

Mon, 18 Jun 2007 23:31:04 +0900

원문은 아래의 URL 에서 볼 수 있습니다.

http://www.dumpanalysis.org/blog/index.php/2007/05/22/aslr-address-space-layout-randomization/

Michael Howard 와 David LeBlanc 의 Writing Secure Code for Windows Vista 책에서 Vista 는 새로운 ASLR 에 대해서 설명합니다.

Load address randomization (/dynamicbase linker option)
Stack address randomization (/dynamicbase linker option)
Heap randomization

앞의 두가지 vista 가 리부팅 할 때 마다 랜덤하게 바뀝니다.

세 번째는 링커 옵션 /dynamicbase 의 사용 여부와 관계없이 항상 발생합니다.

책에서는 이 기능(ASLR) 을 보여주기 위해 몇 가지 모듈과 함수 그리고 로컬 파라미터의 주소를 출력하는 소스 코드를 보여줍니다.

저는 calc, notepad 그리고 pre-Vista 어플리케이션인 TestDefaultDebugger 를 WinDbg 에 붙여서 확인하기로 했습니다.

명백하게 Vista 의 응용프로그램들은 ASLR 을 사용합니다.

리부팅 전의 calc.exe 프로세스와 리부팅 후의 calc.exe 프로세스를 비교해 보면 메인 모듈과 system dll 들이 서로 다른 load address 를 가짐을 알 수 있습니다.

before

after

0:000> lm

start end module name
009f0000 00a1e000 calc
74710000 748a4000 comctl32
75b10000 75bba000 msvcrt
76f00000 76fbf000 ADVAPI32
770d0000 771a8000 kernel32
771b0000 7724e000 USER32
77250000 7736e000 ntdll

0:000> lm

start end module name
00470000 0049e000 calc
743e0000 74574000 comctl32
75730000 757da000 msvcrt
757e0000 7589f000 ADVAPI32
75e20000 75ebe000 USER32
76cf0000 76dc8000 kernel32
76dd0000 76eee000 ntdll

메인 모듈의 주소중 3번째 바이트가 다릅니다. 0x00 은 허용되지 않을 것이므로(이게 허용되면 image base 가 0x00000000 이 가능하단 얘기가 되므로) 255 개의 랜덤한 기준 주소를 가질 수 있게 됩니다.

(역주: 이부분에 대한 자세한 내용은 symantec 에서 나온 ASLR 관련 자료를 찾아보시면 도움이 될 겁니다 :-)

스택 어드레스 :

before	after
0:000> k ChildEBP RetAddr 000ffc8c 771d199a ntdll!KiFastSystemCallRet 000ffc90 771d19cd USER32!NtUserGetMessage+0xc 000ffcac 009f24e8 USER32!GetMessageW+0×33 000ffd08 00a02588 calc!WinMain+0×278 000ffd98 77113833 calc!_initterm_e+0×1a1 000ffda4 7728a9bd kernel32!BaseThreadInitThunk+0xe 000ffde4 00000000 ntdll!_RtlUserThreadStart+0×23	0:000> k ChildEBP RetAddr 0007fbe4 75e4199a ntdll!KiFastSystemCallRet 0007fbe8 75e419cd USER32!NtUserGetMessage+0xc 0007fc04 004724e8 USER32!GetMessageW+0×33 0007fc60 00482588 calc!WinMain+0×278 0007fcf0 76d33833 calc!_initterm_e+0×1a1 0007fcfc 76e0a9bd kernel32!BaseThreadInitThunk+0xe 0007fd3c 00000000 ntdll!_RtlUserThreadStart+0×23

모듈의 베이스 주소가 다르니 콜스택의 리턴 주소도 당연히 다른겁니다.

Heap 베이스 주소 :

before	after
0:000> !heap Index Address 1: 00120000 2: 00010000 3: 00760000 4: 00990000 5: 00700000 6: 00670000 7: 01320000	0:000> !heap Index Address 1: 001b0000 2: 00010000 3: 00a00000 4: 009c0000 5: 00400000 6: 00900000 7: 01260000

PEB and environment addresses are different:

before

after

notepad.exe (PID 1248):

0:000> !peb
PEB at 7ffd4000
...
Environment: 000507e8

notepad.exe (PID 1370):

0:000> !peb
PEB at 7ffd9000
...
Environment: 003a07e8

TEB 내부를 살펴보면 exception handler 리스트 포인터와 stack base 또한 다름을 확인 할 수 있습니다.

before

after

notepad.exe (PID 1248):

0:000> !teb

TEB at 7ffdf000
    ExceptionList:        0023ff34
    StackBase:            00240000
    StackLimit:           0022f000
    SubSystemTib:         00000000
    FiberData:            00001e00
    ArbitraryUserPointer: 00000000
    Self:                 7ffdf000
    EnvironmentPointer:   00000000
    ClientId:             00001248 . 000004e0
    RpcHandle:            00000000
    Tls Storage:          7ffdf02c
    PEB Address:          7ffd4000
    LastErrorValue:       0
    LastStatusValue:      c0000034
    Count Owned Locks:    0
    HardErrorMode:        0

notepad.exe (PID 1370):
0:000> !teb
TEB at 7ffdf000
    ExceptionList:        001ffa00
    StackBase:            00200000
    StackLimit:           001ef000
    SubSystemTib:         00000000
    FiberData:            00001e00
    ArbitraryUserPointer: 00000000
    Self:                 7ffdf000
    EnvironmentPointer:   00000000
    ClientId:             00001370 . 00001454
    RpcHandle:            00000000
    Tls Storage:          7ffdf02c
    PEB Address:          7ffd9000
    LastErrorValue:       5
    LastStatusValue:      c0000008
    Count Owned Locks:    0
    HardErrorMode:        0

그러나 /dynamicbase 옵션을 이용해서 링크하지 않은 예전의 어플리케이션을 보면 메인 모듈과 dll 베이스가 동일함을 확인 할 수 있습니다.

0:000> lm start end module name 00400000 00435000 TestDefaultDebugger 20000000 2000d000 LvHook

0:000> lm
start end module name
00400000 00435000 TestDefaultDebugger
20000000 2000d000 LvHook

To summarize different alternatives I created the following table where

“New” column - /dynamicbase 옵션 적용, 리부팅 안함
“New/Reboot” column - /dynamicbase 옵션 적용, 리부팅 함
“Old” column - 예전 프로세스, 리부팅 안함 ( no /dynamicbase )
“Old/Reboot” column - 예전 프로세스, 리부팅 함 ( no /dynamicbase )

PEB 와 process heap base address 에서 environment address 는 항상 heap 과 연관되어있음을 알 수 있습니다.

0:000> !heap Index Address Name Debugging options enabled 1: 005f0000 0:000> !peb PEB at 7ffd7000 ... ... ... ProcessHeap: 005f0000 ProcessParameters: 005f1540 Environment: 005f07e8

0:000> !heap
Index   Address Name      Debugging options enabled
1:   005f0000

0:000> !peb
PEB at 7ffd7000
...
...
...
    ProcessHeap:       005f0000
    ProcessParameters: 005f1540
    Environment:       005f07e8

I think the reason why Microsoft didn’t enable ASLR by default is to prevent Changed Environment pattern from appearing.

- Dmitry Vostokov -

somma님의 노트

simsimi

심심이 소개#

모듈 구성#

Spider#

PlgnPE#

SPDisas#

SPDriver#

SPDriverLoader#

SPInjector#

SPSymbol#

스크린 샷

TODO

공통

RING0

RING3

ASLR: Address Space Layout Randomization

심심이 소개^#

모듈 구성^#

Spider^#

PlgnPE^#

SPDisas^#

SPDriver^#

SPDriverLoader^#

SPInjector^#

SPSymbol^#