posted by 블르샤이닝 2015. 9. 9. 10:43
728x90

출처 : http://btd86.tistory.com/66



WinDbg

 

Command

option

usage

Desc

종료

q

 

 

디버깅 종료

qd

 

 

디버깅 종료;연결해제

디버깅 환경정보

vertarget

 

 

타겟 컴퓨터 정보 표시

version

 

 

디버그 환경 정보 표시

.lastevent

 

 

마지막 디버그 이벤트 정보 표시

||

 

 

디버깅 세션 정보 표시

sumble & sorurce

.symfix

 

 

MS 심볼경로 설정

.sympath

 

 

심볼경로 확인/설정

.sym noisy

 

 

심볼파일 검색 과정을 출력

.srcpath

 

 

소스경로 설정

.srcnoisy

 

.srcnoisy 1

소스경로 검색 과정을 출력

모듈

lm

 

l

로드된 모듈만 표시

 

 

m [pattern]

패턴과 일치되는 모듈만 표시

 

 

v

모듈 상세정보 표시

!lmi

!lmi ntdll.dll

 

모듈 상세정보 표시

.reload

 

/f [m_name]

심볼을 즉시 로드

x

X ntdll!*

X *!*abc*

/v

/t

/n

심볼 타입을 표시.

데이터 타입을 표시

이름순으로 정렬

ln

 

ln [address]

해당 주소에 근접한 심볼의 정보 표시

레지스터

r

 

 

레지스터 정보 표시

r $proc

 

 

현재 프로세스의 PEB주소( user-mode)

현재 프로세스의 EPROcESS주소( kernel-mode)

r $thread

 

 

현재 스레드의 TEB주소( user-mode)

현재 스레드의 ETHREAD주소( kernel-mode)

r $tpid

 

 

현재 프로세스 ID(PID)

r $tid

 

 

현재 스레드 ID(TID)

언어셈블

u

 

 

f

b

언어셈블

언어셈블(함수전체)

언어셈블(ip이전의 8개 명령어)

콜스택

k

 

[n]

p

b

n

v

f

콜스택 정보표시

함수정보 출력

인자표시

프레임번호

FPO정보 표시

스택 사용량 표시

break point

bp

bp 0x123456

 

bp 설정

bl

 

 

bp 리스트 출력

bc

bc * | [frame_no]

 

bp 삭제

bd,be

bc * | [frame_no]

 

bp disable/enable

bm

bm notepad!*Win*

 

패턴과 일치하는 모든심볼에 bp설정

bu

bu aaa!bbb

 

로드되지 않은 심볼에 대한 bp설정

ba

 

 

특정 주소에 access bp

지역변수

dv

dv modulr!test*

 

/i

/V

 

심볼유형과 인자유형 표시

변수저장 위치 표시( register or address )

데이터유형

dt

df _EPROCESS 0xaddr

 

주소를 특정 데이터 형으로 변환해서 표시

du

 

 

Unicode string 표시

da

 

 

Ansi string 표시

dc

 

 

 

db

 

 

 

dy

 

 

 

 

 

 

 

!address

!address

!address [address]

 

 

프로세스 & 스레드 정보

!peb

 

 

PEB(Process Environment Block)표시

!teb

 

 

TEB(Thread Environment Block) 표시

 

 

 

 

!gle

 

 

API의 마지막 에러코드 표시

실행 제어

t[F11]

 

 

Trace

~.t

 

 

다른 스레드를 중지시킨 상태에서 하나의 statementt실행

g

 

 

 

p[F10]

 

 

Step Over

gu

gu

~0 gu

 

현재함수가 복귀할 때 까지 실행

스레드 0을 제외한 모든 스레드를 freeze

wt

 

 

내부에서 호출된 함수와 함수호출 횟수등의 정보 표시

.cxr

 

 

컨텍스트 변경

!ready

 

 

 

.thread

 

 

 

!thread

 

 

 

.trap

 

 

 

.process

 

 

 

!process

 

 

 

ed

 

 

 

eb

eb .-6 90 90 90 90 90 90

 

6byte NOP(0x90)으로 변경

!error

!error [error code]

 

에러코드 정보표시

 ---------------------------------------------------------------------------------------------------------------


지속적으로 추가될 예정 (1차 수정 2015/09/17)



windbg 사용법.docx


728x90
posted by 블르샤이닝 2014. 11. 5. 10:25
728x90

참조 : http://mylabs.tistory.com/m/post/17


여기서 중요한점은 


[ 디스어셈블 하고자 하는 드라이버의 EP부터 트레이싱 하기 위한 방법 ]
    - EP의 첫 바이트를 CC(int 3)으로 변경, checksum 을 수정 (커널 드라이버 로드시, 체크섬값 검사)
    - breakpoint 가 설정된 곳에서 멈추면, 해당 바이트를 다시 원래 코드로 수정
    - Trace 시작~!


 자, 감염된 상태의 시스템에서 로드된 NDIS가 악성인지 아닌지 어떻게 알수 있을까?!
 가장 간단하게 섹션의 정보 부터 확인해보자.


에서 드라이버를 분석하기위해 ep부분에 cc로 변경 후 다시 원래 바이너리로 수정하는거


---------------------------------------------------------------------------------


 작성한 6월 보안칼럼에서 ndis.sys를 변조시키는 악성코드에 관해서 언급했었다.

 당시 Sality 파일바이러스 심층분석으로 골머리를 썩고있는 상황이어서, 미루고 미뤄두었던 악성코드이다.

 CodeEngn 2009에서 고흥환님께서 발표하신 내용중에 일부이기도 한 악성코드이다. 
 간단하게 분석한 내용을 적어본다.

 [ Win32.Protector.A ~ C ]
 정상파일을 변조시키는 행동은 파일바이러스와 일맥상통하는 부분이지만, 추가적인 2차 감염을 발생시키지는 않는다.
 Virut 파일 바이러스들 중 일부가 ndis.sys 커널 드라이버를 변조시키는 사례가 많이 발생됐었다.
 그리고 최근에 다시 이슈화 된 AntiVirus 2010 계열의 허위백신은 같은 골격으로 ntfs.sys를 변조시키며,
 해외와 국내에 agp440.sys도 변조되고 있는 상황이다.

 커널드라이버 악성코드는 윈도우시스템에 필수 드라이버 파일인 ndis.sys 와 ntfs.sys 등 여러 드라이버를 타겟으로 하고있으며, 이는 여타 다른 드라이버파일도 안전할수 없다는 것을 의미한다.
 변조된 악성코드는 정상 드라이버의 이름을 가지고 있기때문에 커널 로드시 악성코드가 그대로 같이 메모리에 올려진다.
 커널에 로드된 악성 ndis.sys는 정상 ndis와는 확연히 다른 형태의 PE인것을 한눈으로 확인이 가능하며, 실행되어진 상태의 메모리 모습이기 때문에 최종으로 복호화 되어진 HEX값 역시도 확인 가능하다.

 변조된 드라이버 파일을 이용하여 시스템을 감염시켜보자.

 아래의 [그림1] 은 

 변조된 드라이버파일이 로드된 시스템을 windbg 커널 디버그 모드로 Attach 시킨 후에 로드된 NDIS 주소값이다.  
   이미지[그림1] kernel에서의 NDIS드라이버가 로드된 주소값
 
 ndis.sys 의 EP(Entry Point) 부터의 어셈블리코드
   이미지[그림2] Disassembly EP : f839c500

[ 디스어셈블 하고자 하는 드라이버의 EP부터 트레이싱 하기 위한 방법 ]
    - EP의 첫 바이트를 CC(int 3)으로 변경, checksum 을 수정 (커널 드라이버 로드시, 체크섬값 검사)
    - breakpoint 가 설정된 곳에서 멈추면, 해당 바이트를 다시 원래 코드로 수정
    - Trace 시작~!


 자, 감염된 상태의 시스템에서 로드된 NDIS가 악성인지 아닌지 어떻게 알수 있을까?!
 가장 간단하게 섹션의 정보 부터 확인해보자.

 먼저 정상 NDIS의 섹션정보를 보자.
  이미지[그림3] 정상 NDIS의 섹션정보

 정상 ndis는 위와 같은 섹션 정보를 헤더에 가지고 있지만, 감염된 상태의 ndis는 확연히 차이나는 섹션구조를 가지고 있다.

  이미지[그림4] 변조된 NDIS의 섹션정보
 [그림4] 는 windbg에서 커널에 로드된 상태의 헤더부분이지만, 실제 변조된 ndis 파일의 헤더정보도 위와 동일한 형태를 취하고 있다. (변종에 따라 INIT 섹션이 있는 경우도 있다.)


 이 글을 포스팅하기 한참전에 로직은 이미 완성된 상태였다. 최초엔 진단명을 특정 드라이버파일만을 변경한다는 의미에서 
Mndis, Mntfs 등으로 만들었지만,,, 동일한 감염로직으로 최근 다른 드라이버들도 피해를 보고있는 실정이다. 
 그래서 보편적으로 사용하고 있는 Protector 진단명으로 변경하게 되었다. Protector 진단명은 최초 카스퍼스키에서 만든것으로 추정되며, 진단명은 악성코드의 디버그 정보를 참조한 것 같다.
  - Conficker 도 그랬고, 대부분의 악성코드 제작자가 Release 버젼이 아닌 debug버젼으로 컴파일해서 배포를 하는듯 한데, 그 과정에서 파일상에 정보가 조금씩 남는 경우가 많다.

  이미지[그림5] 파일상에 남아있는 디버그 정보
 
 [ Protector 주요 특징 ]

이미지[그림6] 메모리상에 복호화된 정상 NDIS
 [그림1] 에서 로드된 드라이버 메모리를 잘 살펴보면, 또 하나의 PE 파일이 붙어있는 것을 볼수 있다. 눈으로 확인 가능한 것은 암호화된 내용이 메모리에는 복호화 되어 올라가기 때문이다.
 ( 커널에서 로드시에 이미 해당 루틴들을 다 수행한 상태이기 때문 )
 
 Protector.A~C 는 전체적인 구조는 같으나, 정상
 드라이버파일을 품고있는 암호화 로직이 다르다.

 













 

 



 대표적인 샘플A의 코드는 아래 [그림7] 과 같다.

빨간색으로 표시해둔 부분이 주요 코드 부분이다.

 복호화에 필요한 로컬 변수들을 초기화 하고, 구하는 루틴들을 포함하고 있으며, EP부터 조금 아래 부분을 살펴보면 똑같은 함수를 호출하는 부분을 볼 수 있다.
 바로 그 두번의 호출이 복호화 루틴인 것이다.

 복호화 로직은 아주 간단하며, 어셈을 조금만 공부하면 간단하게 풀수있는 로직이다.

 복호화는 두번의 호출로 정상 driver와 악성 driver를 복호화 하며, 특히 ndis.sys가 변조된 파일의 악성 driver는 IoCallDriver를 Hook하는 루틴을 포함하고 있다. 이는 안티바이러스 제품들의 접근을 회피하기 위한 방법으로 사용된다. 
 AntiVirus2010 에 의해서 변조되는 ntfs.sys 와 agp440.sys 는 IoCallDriver Hook 루틴이 없으며, 일반적인 로직으로 접근 및 원복이 가능하다.

 일반적인 Winapi로 파일을 접근할 시엔 감염된 상태를 정상적인 상태로 보여주면서 진단을 회피하게 된다.

  
 이미지[그림7] 변조된 드라이버파일의 코드
 

  // 분명히 스킨부분의 소스를 고쳐서 글자색을 검은색으로 했는데,, 언제부턴가 회색으로...@.@
      다시 다 검은색으로 바꾸는 엄청난 작업을... 
      Tistory 어렵네요... 괜찬은 팁이 있으신 분은 알려주세요~! ㅠ



728x90
posted by 블르샤이닝 2013. 4. 3. 16:48
728x90

시작전에 파일을 감염시킨후 windows가 올라오기전 windbg로 정지시키고 해당 드라이버에 bp를 건다.

---------------------------------------------------------------


드라이버 분석.rtf

---------------------------------------------------------------

출처 : http://muhan56.tistory.com/66

DriverEntry - 드라이버 시작점 부터 디버깅 하기

드라이버(.sys)파일의 시작점(Entry-Point)부터 디버깅 하는 방법 입니다. 커널 디버깅 환경이 준비 되어야 하며 분석대상 드라이버 PDB 파일의 유무에 따라 분석 방법이 조금 달라 집니다. 먼저 디버기 시스템(Virtual PC 2007)에서 드라이버를 등록(Register Service)하고 나서 디버거(WinDBG)에 입력되는 명령어는 아래와 같습니다. [예제 드라이버 소스코드 경로]

 

1. 디버깅 대상 드라이버 파일의 PDB 있을 경우

nt!RtlpBreakWithStatusInstruction:
804e3592 cc              int     3
kd> sxe ld cr0.sys          // cr0.sys 드라이버 로드 시점에 BP 설정
kd> g
nt!DebugService2+0x10:
80506d3e cc              int     3          // BP가 걸렸습니다 (cr0.sys 드라이버 로딩)
kd> lm
start    end        module name
7c900000 7c9b2000   ntdll      (pdb symbols)
...
f8c8a000 f8c8a800   cr0        (private pdb symbols)     // cr0.sys pdb 확인
kd> bp cr0!DriverEntry          // cr0.sys 코드시작(DriverEntry)점에 BP 설정
kd> bl
 0 e f8c8a4c0     0001 (0001) cr0!DriverEntry
kd> g
Breakpoint 0 hit
cr0!DriverEntry:          // BP가 걸렸습니다 (DriverEntry)
f8c8a4c0 8bff            mov     edi,edi
kd> u
cr0!DriverEntry [c:\sdt_cr0\set_cr0.cpp @ 22]:
f8c8a4c0 8bff            mov     edi,edi
f8c8a4c2 55              push    ebp
f8c8a4c3 8bec            mov     ebp,esp
f8c8a4c5 6810a5c8f8      push    offset cr0! ?? ::FNODOBFM::`string' (f8c8a510)
f8c8a4ca e825000000      call    cr0!DbgPrint (f8c8a4f4)
f8c8a4cf 83c404          add     esp,4
f8c8a4d2 8b4508          mov     eax,dword ptr [ebp+8]
f8c8a4d5 c7403490a4c8f8  mov     dword ptr [eax+34h],offset cr0!OnUnload (f8c8a490)
kd> db f8c8a510          // DbgPrint 인자값 확인
f8c8a510  44 72 69 76 65 72 45 6e-74 72 79 28 29 20 53 74  DriverEntry() St
f8c8a520  61 72 74 0a 00 00 00 00-00 00 00 00 00 00 00 00  art.............
f8c8a530  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8c8a540  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8c8a550  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8c8a560  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8c8a570  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8c8a580  00 20 55 80 79 f0 4f 80-00 00 00 00 00 00 00 00  . U.y.O.........


2. 디버깅 대상 드라이버 파일의 PDB 없을 경우

nt!RtlpBreakWithStatusInstruction:
804e3592 cc              int     3
kd> sxe ld cr0.sys          // cr0.sys 드라이버 로드 시점에 BP 설정
kd> g
nt!DebugService2+0x10:
80506d3e cc              int     3          // BP가 걸렸습니다 (cr0.sys 드라이버 로딩)
kd> lm
start    end        module name
7c900000 7c9b2000   ntdll      (pdb symbols)
...
f8b84000 f8b84800   cr0        (deferred)          // cr0.sys pdb 없음
kd> bp cr0!DriverEntry
*** ERROR: Module load completed but symbols could not be loaded for cr0.sys
Couldn't resolve error at 'cr0!DriverEntry'          // DriverEntry 지점에 BP를 걸 수 없습니다
kd> u f8b846be          // cr0 start address(f8b84000) + cr0 Address Entry Point(6be)
cr0+0x6be:
f8b846be 8bff            mov     edi,edi
f8b846c0 55              push    ebp
f8b846c1 8bec            mov     ebp,esp
f8b846c3 e8bdffffff      call    cr0+0x685 (f8b84685)
f8b846c8 5d              pop     ebp
f8b846c9 e9f2fdffff      jmp     cr0+0x4c0 (f8b844c0)
f8b846ce cc              int     3
f8b846cf cc              int     3
kd> bp f8b844c0          // cr0.sys 코드시작(DriverEntry)점에 BP 설정
kd> bl
0 e f8b844c0     0001 (0001) cr0+0x4c0
kd> g
Breakpoint 0 hit
cr0+0x4c0:          // BP가 걸렸습니다 (DriverEntry)
f8b844c0 8bff            mov     edi,edi
kd> u
cr0+0x4c0:
f8b844c0 8bff            mov     edi,edi
f8b844c2 55              push    ebp
f8b844c3 8bec            mov     ebp,esp
f8b844c5 681045b8f8      push    offset cr0+0x510 (f8b84510)
f8b844ca e825000000      call    cr0+0x4f4 (f8b844f4)
f8b844cf 83c404          add     esp,4
f8b844d2 8b4508          mov     eax,dword ptr [ebp+8]
f8b844d5 c740349044b8f8  mov     dword ptr [eax+34h],offset cr0+0x490 (f8b84490)
kd> db f8b84510         // DbgPrint 인자값 확인
f8b84510  44 72 69 76 65 72 45 6e-74 72 79 28 29 20 53 74  DriverEntry() St
f8b84520  61 72 74 0a 00 00 00 00-00 00 00 00 00 00 00 00  art.............
f8b84530  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8b84540  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8b84550  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8b84560  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8b84570  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
f8b84580  00 20 55 80 79 f0 4f 80-00 00 00 00 00 00 00 00  . U.y.O........
.



u : 코드를 페이지식으로 누른다. u를 또 누르면 다음 페이지가 보여진다.
u main : 이 명령어 치면 메인 화면이 보인다.
g : 실행하는 명령어다.

r : 레지스터 값을 보여준다.
p : 스퉵오버
t : 스텝인투

728x90
posted by 블르샤이닝 2013. 1. 9. 17:54
728x90
kd> dds kiservicetable 0 l250 -> kiservicetable 목록을 250개 정도로 해서 보여준다인가.. 아우 어려워 ㅠㅠ Ahnurl_분석보고서.docx
728x90
posted by 블르샤이닝 2011. 11. 9. 15:27
728x90
해당 문제점이 발생하여서 글을 찾다가 좋은정보를 찾았다 


종종 프로젝트 설정을 잘 못 만지면 pre compiled header 에 대한 오류를 볼 수 있습니다. (나만 그런가?)
그냥 pre compiled header 를 사용안함으로 해버리면 해결 됩니다.




728x90

'디바이스 드라이버' 카테고리의 다른 글

windbg로 이용한 파일 분석  (2) 2013.04.03
windbg  (0) 2013.01.09
[MFC] 빌드 시 _WIN32_WINNT 문제  (0) 2011.10.06
create 파일에 대한 간단한 소스  (0) 2011.09.17
2010에서 wdk 환경 설정하는법  (0) 2011.08.18
posted by 블르샤이닝 2011. 10. 6. 16:43
728x90

인터넷에서 구한 소스를 VB2010로 프로젝트 빌드하면서 다음과 같은 에러가 발생하였다...젠장..처음에는 주석으로 처리했더니 에러 대박..



그래서 찾아본 결과 확인결과 atlcore.h에 윗 구분같이 #error가 있기 때문에 빌드를 하지 못한거였고 이것은 아주 간단하게 수정하면 컴파일에 문제없는것이다.


자 stdafx.h로 가서

 #define _WIN32_WINNT 0X400(다른 숫자값일 수 도 잇다.) 


의 값을 아래 값들중에 맞는것을 찾아 넣어주면 된다. 


728x90
posted by 블르샤이닝 2011. 9. 17. 17:06
728x90
제목대로
728x90