posted by 블르샤이닝 2013. 6. 11. 14:15
728x90

1.     A번 올리로 악성파일에서 CreateProcess를 통해서 IE의 프로세스가 생성된다.



2.     생성된 프로세스에 또 다른 올리디버거로(B번 올리) Attach를 시켜 로드 시킨다.


3.     A번 올리를 통해서 코드가 VirtualAllocEX를 통해 메모리 할당을 한 값을 EAX으로 주소를 확인 할 수 있으며, 이 값을 B번 올리값에 가보면 해당 메모리가 할당된 것을 확인 할 수 있다.


[그림 1] A번 올리


[그림 2] B번 올리

 

 

 

4.     이제 B번 올리에서 ATTACH되어 동작하는 악성코드주소에 BP를 걸고 분석 하면 된다.

 




인젝션되어 동작하는 코드 분석시.docx


728x90
posted by 블르샤이닝 2013. 6. 10. 16:11
728x90

 출처 : http://blog.naver.com/koheung?Redirect=Log&logNo=120054818133


이 내용은 뽑아서 항상 보도록! FS 세그먼트는 매우 중요한 부분중 하나다 


Position Length Windows Versions Description
FS:[0x00] 4 Win9x and NT Current Structured Exception Handling (SEH) frame
FS:[0x04] 4 Win9x and NT Top of stack
FS:[0x08] 4 Win9x and NT Current bottom of stack
FS:[0x10] 4 NT Fiber data
FS:[0x14] 4 Win9x and NT Arbitrary data slot
FS:[0x18] 4 Win9x and NT Linear address of TIB or TEB
- - NT End of NT subsystem independent part
FS:[0x1C] 4 NT Environment Pointer
FS:[0x20] 4 NT Process ID
FS:[0x24] 4 NT Current thread ID
FS:[0x28] 4 NT Active RPC Handle
FS:[0x2C] 4 Win9x and NT Linear address of the thread-local storage array
FS:[0x30] 4 NT Linear address of Process Environment Block (PEB)
FS:[0x34] 4 NT Last error number
FS:[0x38] 4 NT Count of owned critical sections
FS:[0x3C] 4 NT Address of CSR Client Thread
FS:[0x40] 4 NT Win32 Thread Information
FS:[0x44] 124 NT,Wine Win32 client information (NT), user32 private data (Wine), 0x60 = LastError (Win95), 0x74 = LastError (WinME)
FS:[0xC0] 4 NT Reserved for Wow32
FS:[0xC4] 4 NT Current Locale
FS:[0xC8] 4 NT FP Software Status Register
FS:[0xCC] 216 NT,Wine Reserved for OS (NT), kernel32 private data (Wine)
FS:[0x1A4] 4 NT Exception code
FS:[0x1A8] 18 NT Activation context stack
FS:[0x1BC] 24 NT,Wine Spare bytes (NT), ntdll private data (Wine)
FS:[0x1D4] 40 NT,Wine Reserved for OS (NT), ntdll private data (Wine)
FS:[0x1FC] 1248 NT,Wine GDI TEB Batch (OS), vm86 private data (Wine)
FS:[0x6DC] 4 NT GDI Region
FS:[0x6E0] 4 NT GDI Pen
FS:[0x6E4] 4 NT GDI Brush
FS:[0x6E8] 4 NT Real Process ID
FS:[0x6EC] 4 NT Real Thread ID
FS:[0x6F0] 4 NT GDI cached process handle
FS:[0x6F4] 4 NT GDI client process ID (PID)
FS:[0x6F8] 4 NT GDI client thread ID (TID)
FS:[0x6FC] 4 NT GDI thread locale information
FS:[0x700] 20 NT Reserved for user application
FS:[0x714] 1248 NT Reserved for GL
FS:[0xBF4] 4 NT Last Status Value
FS:[0xBF8] 214 NT Reserved for advapi32
FS:[0xE0C] 4 NT Pointer to deallocation stack
FS:[0xE10] 256 NT TLS slots, 4 byte per slot
FS:[0xF10] 8 NT TLS links (LIST_ENTRY structure)
FS:[0xF18] 4 NT VDM
FS:[0xF1C] 4 NT Reserved for RPC


728x90
posted by 블르샤이닝 2013. 6. 3. 10:42
728x90

리버싱을 잘하게 되면 어셈코드만 봐도 c코드가 보인다는데..아쉽게도 난 아직 그정도 실력이 되질않아서 ida를 연동해서 봐야한다;;ㅠ 


하지만 이번 분석을 하면서 하나하나 어셈코드로 분석하기에는 시간이 너무 걸리고 또한 코드도 헷갈리게 된다. 이래저래 분석하는데 시간을 허비하다 불현듯 옛날에 어깨넘어로 들었던 이야기...바이너리 코드를 저장해서 ida에 올리는 방법이 생각났다...아우..ㅠㅠ 삽질한 시간이 아깝네;;ㅠㅠ



매우 간단한 방법인데;;; 그냥 ida로 볼래요 전~_~ ㅋㅋㅋ



아 이얼마나 보기 편한가...ㅠㅠ 까먹지 않기 위해 기록을 남긴다. 이리 간단한걸...ㅠㅠ



728x90
posted by 블르샤이닝 2013. 5. 27. 11:15
728x90


from 공부해서 남주나요/MFC/C++ 2010/09/08 18:14

VC 6.0 로 UI작업 시 , GDI 가 사용되는 경우가 많다.v
그래서 현장에서 여러 노트북으로 디버깅 시 Setting 하는게 쉽지가 않다. 
Direct x / PlatForm SDK 설치에 VC 6.0 툴 셋팅까지, 번거롭기 그지없다.
그래도 기존 소스를 보려면 해줘야한다.
한번 해놓고 안까먹으면 좋겠지만 자주 까먹는 나를 위해서 적어놓는 센스:D

새로 산 컴퓨터에 VC 6.0을 깔고 디버깅을 했더니 에러가 574개나 떴다.
문제는 error C2501: 'LPDIRECTDRAWSURFACE7' : missing storage-class or type specifiers 등등.
이 부분은 Direct X SDK 설치로 해결된다. 이외에도 GdiPlus.lib 설정이 되있지 않아 생기는 문제점등.



머리 속을 쏵 비우고 천천히 설치하고 Setting 하자.


1. DirectX 9.0 SDK Update - (Summer 2004) 설치
최신 버전을 설치할 수는 있으나 호환이 잘 안맞거나 문제가 생길 수 있다. 그러므로 이 버전이 제일 무난하다.




2. Windows Server 2003 PSDK (February 2003) 설치
설치 후 시작버튼을 눌러 등록해준다.




시작->프로그램->Microsoft Platform SDK February 2003
->Visual Studio Registration->Register PSDK Directories with Visual Studio 실행

VC 6.0 자동 Setting 된다. 밑에 수동 Setting도 참고.


3. SDK 설치가 완료, 그 다음은 VC 6.0 에서 Setting 을 해줘야 할 차례

메뉴에서 Tool - Options - Directories 에서 설치한 Direct / Platform SDK 를 셋팅해 준다.



* 위의 캡쳐는 보여주기 위한 것이다.
즉, INCLUDE 는 Show directories for 에서 Include files 로 리스트를 놓고 Directories 추가해야한다.
나머지의 경우, Lib file, Source file 은 그에 맞게 추가해줘야한다.

- C:\PROGRAM FILES\MICROSOFT DIRECTX 9.0 SDK (SUMMER 2004)\INCLUDE
- C:\PROGRAM FILES\MICROSOFT DIRECTX 9.0 SDK (SUMMER 2004)\LIB
- C:\PROGRAM FILES\MICROSOFT PLATFORM SDK\INCLUDE
- C:\PROGRAM FILES\MICROSOFT PLATFORM SDK\LIB
- C:\PROGRAM FILES\MICROSOFT PLATFORM SDK\SRC

4. 설정은 완료. 이후 lib 설정하는 법.

만약 LINK : fatal error LNK1104: cannot open file "GdiPlus.lib" 이 뜨는 경우  Lib Setting 해준다.

Project - Settings - Link - Object/library modules: 부분에 사용하려는 lib 를 추가


728x90
posted by 블르샤이닝 2013. 5. 24. 16:18
728x90
안티 디버깅에는 2가지의 그룹이 있습니다.

static그룹 -> 맨 처음 실행될 때 안티 디버깅이 실행, 한번만 해제하면 되는것 입니다.

dymamic그룹 -> 실행 중에 계속 해제를 해주어야 함, 디버거 트레이싱을 방해하는 것 입니다.

 

디버깅 트레이싱이란? F8

 

안티 디버깅은 디버기 프로세스에서 자신이 디버기 당하는지 여부를 파악하는 기법

발견하면 종료코드를 실행하거나(대부분) 실행에 방해를 하는 코드를 실행

 

안티디버깅의 목적

디버거 탐지방법

디버거 환경탐지

디버거 강제 분리

회피 방법은 탐지 코드에서 얻어오는 정보를 변경함

 

현재 프로세스 디버깅을 판단하기 위해 PEB 구조체 정보 이용 합니다.

PEB 구조체 정보를 이용하는 것이 현재 가장 잘 사용되는 안티 디버깅 기법입니다.

PEB 구조체 주소는 FS 세그먼트 레지스터가 가르키는 TEB 구조체를 이용하여 구할 수 있습니다.

 

안티디버깅에 사용되는 중요 PEB 멤버

+0x002 BeingDebugged : Uchar

+0x00c Ldr                  : ptr32 _PEB_LDR_DATA

+0x018 ProcessHeap       : Ptr32 Void

+0x068 NtGlobalFlag       : Uint4B


 

TEB

TEB는 이미지 로더와 다양한 윈도우 DLL에 대한 컨텍스트 정보를 담고 있으며이들 요소들이 유저모드에서 구동되기 때문에 유저모드에서 쓰기가 가능한 구조체가 필요 했습니다. 그래서 이 구조체는 커널모드에서만 쓰기가 가능한 시스템 주소 공간이 아닌 프로세스 주소 공간에 위치합니다.


 

PEB

유저 주소상에 존재하는 PEB는 이미지 로더힙관리자그외 윈도우 시스템 DLL등 유저모드상에서 접근할 필요가 있는 정보를 가지고 있습니다.

 

FS 레지스터

08386부터 등장 하였으며 BASE Address 0xffdf000이며 커널 모드 에서는 KPCR(Kernel’s Processor Control Regin) 구조체를 유저모드에서는 TEB 구조체를 가르키고 있습니다.

 FS:[0] TEB의 시작 위치를 가지고 있습니다.





PEB구조체를 구하는 방법은 4가지가 있습니다.
[1] FS 레지스터를 사용하는 방법
[2] NtCurrentTeb()
를 사용하는 방법
[3] ZwQueryInformationProcess()
를 사용하는 방법
[4] GetThreadContext(), GetThreadSelectorEntry()
를 사용하는 방법


[1]
FS
라는 세그먼트 레지스터가 존재하는데, 이 레지스터가 TEB를 지정합니다
따라서 PEB를 구하기 위해 FS:[0x30]을 가져옵니다.


[2]
ntdll.dll
NtCurrentTeb() 함수를 사용하는 방법입니다. 이 함수는 내부적으로 첫번째 방법과 마찬가지로 FS 레지스터를 사용합니다.
TEB
를 구하고 TEB+0x30을 가져옵니다.

[3]
ZwQueryInformationProcess
의 두번째 인자에 ProcessBasicInformation를 넣어 호출하면 PROCESS_BASIC_INFORMATION를 얻을 수 있습니다
[4]
첫번째 방법과 마찬가지로 FS 레지스터를 읽어오는데, API를 이용합니다.

 

안티 디버깅은 OS 의존성이 있기 때문에 사전에 이를 확인하는 것이 좋습니다.

다양한 디버거 플러그인들이 있고, 계속 변형된 버전이 나오고, 플러그인에서 지원되지 않는 방법이 존재하기 때문에 동작 원리와 기본 회피 방법을 공부하는 것이 큰 도움이 됩니다.


 

IsDebuggerPresent()

IsDebuggerPresent() API PEB.BeingDebugged(PEB 구조체 +0x002)의 값을 참조하여 디버깅 여부를 판별 합니다.



IsDebugg가 실행됨을 확인 할수 있습니다.

F7을 따라서 가보도록 하겠습니다.



 

네 괜히 따라갔다가 피 봤습니다.

여기가 아니었네요. 한 시간 헤맸습니다. 왜 없지? 하면서 하하 ㅠㅠㅠ

 



isDebuggerpresent()는 함수 이기 때문에, 함수 호출을 할거 생각해서 calls 함수들의 목록을 살펴 보았습니다.

 




커널영역에서 호출됨을 확인하고, 브레이크 포인터를 걸어주고 따라가서 확인해 보겠습니다.


 


TEB 구조체를 이용해서 PEB 구조체를 찾는모습이 보입니다.

TEB 주소를 구하고 FS[0x18] -> TEB

여기서 DS[EAX+0x30] -> PEB

그리고 PEB에서 +0x2한 것이, +0x002 BeingDebugged : Uchar 이 값입니다.

이 값이 디버거로 실행될시 1로 셋팅되고, 그냥 실행될시 0으로 셋팅이 됩니다.



따라가서 패치를 해주면은

 



 

디버거없다라고 출력이되면서 우회함을 알수 있습니다.

 

 

 

+0x068 NtGlobalFlag : Uint4B

프로세스가 디버깅 중일 때는 NtGlobalFlag 0x70으로 셋팅 되어 집니다.

 



아래는 0x70과 비교해서 디버깅의 여부를 확인하는 코드이며 PEB의 주소값 +68인 것을 알고 있으니



FS:[30]의 주소로가서, 주소값 +68을 하게 되면은 0x70이 박혀있음을 확인할 수 있습니다.

이 값을 변경해준다면은 우회할 수 있게 됩니다.

 

Ldr(+0xc)

디버깅 프로세스는 힙 메모리 영역에 자신이 디버깅 당하는 프로세스라는 표시를 합니다.

힙영역에 사용하지 않은 영역을 0xFEEEFEEE값으로 채워버리는 것 입니다.

 

같은방식으로 FS:[30]으로 찾아간 뒤에 주소값에서 +c를 해 줍니다.



이 주소를 찾아 아래로 내려가면은 FEEEFEEE가 가득 차있는 것을 볼 수 있습니다.

NULL로 덮어쓰면은 회피 가능 합니다.

 



 




 

GetProcessHeap(+0x18)

PEB.ProcessHeap멤버에서 Flags멤버(+0xc) FoceFlags멤버(+0x10)은 정상 실행일 때는 2 0으로 셋팅이 됩니다. 디버거로 실행될때는특정한 값으로 셋팅 됩니다.



즉 저 값들을 2 0으로 셋팅 해주면은 우회 할 수 있습니다.

 

 

 

NtQueryinformationProcess()

 

디버거 탐지에 사용되는 것은 ProcessDebugPort(0x7) ProcessDebugObjectHandle(0x1E) ProcessDebugFlags(0x1F) 입니다.

 

이중 0x7은 프로세스가 디버깅 중일 때 할당 됩니다. ProcessInformationClass 파라미터에 0x값을 입력하면 debugPort를 얻을 수 있습니다.

ProcessDebugPort(0x7)이 디버깅중이 아니라면 0이 셋팅 되고, 디버깅중 이라면 0xffffff가 셋팅 됩니다. 그래서 이 값을 바꿔주면 우회가 가능 합니다.

 

 

 

CheckRemoteDebuggerPresent() 안티디버깅

[i] IsDebuggerPresent()Api와 비슷하게 디버깅 여부를 판별해주는 함수 입니다.

안에 NtQueryinformationProcess API를 이용 하고 있습니다.

 



 

CheckRemoteDebuggerPresent()의 정보를 받아와서 Call로 실행을 시킵니다.

저 내부함수로 들어가게 되면은 NtQueryInformationProcess를 이용함을 알 수 있습니다.

 

 







내부 함수의 모습 입니다.

우회방법은 그 밑에 점프문을 우회시켜주는 방법과 ProcessDebugFlags(0x1f)의 인자값 bDebugFlag값을 변경해주는 것 입니다.

 

 

FindWindow 함수 회피



이 함수는 잘 알려져있는 이름 혹은 환경등을 검색하여 그 조건이 맞다면은 디버깅을 중지시키는 안티디버깅 입니다.

즉 디버거가 시스템 안에서 구동되어 질 때 쉽게 찾을 수 있습니다.

chFind = FindWindow(L”ollydbg”,0);등의 소스 입니다.

chind NULL이 아니면 윈도우의 핸들을 찾은것이고, 종료 시킬것 입니다.

 

 

우회하는 방법으로는 find call 함수로 FindWindowA 를 찾고, class에서의 값을 변조시키는 방법으로 우회가 가능하다. GetWinddowText등도 비슷한 함수 입니다.

 

 

NtQuerySystemInformation()

디버깅 환경을 체크하는 안티 디버깅 기법에 대한 설명

이 기법은 현재 OS Debug Mode로 부팅되었는지 판단하는 안티 디버깅 기법이다.

ntdll!NtQuerySystemInformatin()API는 현재 동작중인 OS 시스템에 대한 다양 한 정보를 구할수 있는 함수입니다.

API가 리턴되면 시스템 디버그 모드인 경우 debugger Enabled 1이 셋팅 됩니다.

회피 방법으로는 올리디버거로 불가능하고 boot파일을 수정하거나 명령입력을 해야 합니다.

그러면 OS가 일반 모드로 부팅 됩니다.

 

 

 

 

NtQueryObject

 

디버거가 실행 중일 경우 : DebugObject 타입의 객체가 생성

 -> DebugObject 타입의 객체 생성 유무를 검사하여 디버깅 여부 검사

TypeName 필드를 유니코드  “DebugObject”와 비교 후

   TotalNumberOfObject 필드 또는 TotalNumberHandles 필드 검사

→ 0이라면 정상 상태

→ 0보다 크다면 디버깅 상태

 

우회방법 : 스택에 저장되는 “DebugObject” 대신 다른 값을 넣어줌

 

 

 

 

NtSetInformationThread
ntdll!NtSetInformationThread
ZwSetInformationThread 시스템 함수를 감싸고 있습니다.

아래는 함수 타입 설명이다.

NTSYSAPI NTSTATUS NTAPI NtSetInformationThread(
    IN HANDLE ThreadHandle,
    IN THREAD_INFORMATION_CLASS ThreadInformationClass,
    IN PVOID ThreadInformation,
    IN ULONG ThreadInformationLength
);

 

디버깅 당하는 쪽(디버기)에서 강제로 디버거를 떼어내는 기법에 대한 설명 입니다.

ZwSetInformationThread() API를 사용하면 자신을 디버깅하고 있는 디버거를 뗴어낼 수 있습니다.

첫째 인자 - 스레드에게 정보 셋팅

두째 인자 에 ThreadHide From Debugger(0x11) 값을 입력하면 디버거 프로세스가 분리 됩니다. 그래서 이 두째 인자를 0으로 셋팅 해주거나 API를 후킹 하는 방식으로 파라미터를 조작 할 수 있다.

 

728x90