Dynamic 안티 디버깅(Anti Debugging) 기법과 우회

오늘은 Dynamic 안티 디버깅 기법에 대해 알아보겠습니다.

Dynamic 안티 디버깅 기법은 핵심 코드(OEP)로 가지 못하도록 트레이싱을 지속적으로 방해합니다.

 

 

1. 예외 (Exception)

첫 번째는 예외를 이용한 방법입니다.

일반 실행과 디버거 실행의 차이를 이용하는 것입니다. 일반 실행은 예외 발생 시 SEH를 호출하지만 디버깅을 통해 실행하면 디버거가 처리하도록 동작됩니다. 예외를 만나면 디버거가 자체적으로 (가로채서) 처리해주기 때문입니다.

 

 

1.1. SEH (Structured Exception Handling)

SEH는 예외 처리 메커니즘으로 체인 형태로 구성되어 있습니다. 첫 번째 예외 처리기에서 해당 예외를 처리하지 못하면 다음 예외 처리기로 예외를 넘겨주는 형식입니다. 예외 처리기는 4개의 파라미터를 입력받습니다.

 

SEH 함수(예외 처리기) 정의

EXCEPTION_DISPOSITION _except_handler
(
       EXCEPTION_RECORD 		*pRecord,
       EXCEPTION_REGISTRATION_RECORD 	*pFrame,
       CONTEXT 				*pContext,
       PVOID 				pValue
);

 

실행되는 프로세스에서 예외가 발생하면 SEH가 호출되고, 이때 OS는 해당 스레드의 CONTEXT 구조체 포인터를 예외 처리기의 파라미터로 넘겨줍니다. 나중에 쓰임이 있기 때문에 첫 번째 파라미터 _EXCEPTION_RECORD와 세 번째 파라미터 CONTEXT의 구조체는 더 자세히 볼 필요가 있습니다.

 

 

_EXCEPTION_RECORD 구조체 정의

typedef struct _EXCEPTION_RECORD {
    DWORD	ExceptionCode;					     // 예외 코드
    DWORD	ExceptionFlags;					     // 예외 플래그
    struct	_EXCEPTION_RECORD *ExceptionRecord;		     // 예외가 중첩되었을 경우 이전 예외 기록
    PVOID	ExceptionAddress;				     // 예외가 발생한 주소
    DWORD	NumberParameters;				     // 예외와 관련된 매개변수 개수
    ULONG_PTR	ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];  // 예외 관련 정보
} EXCEPTION_RECORD, *PEXCEPTION_RECORD;

 

CONTEXT 구조체 정의 (IA-32)

typedef struct _CONTEXT {
  ULONG              ContextFlags;
  
  ULONG              Dr0;	// 04h
  ULONG              Dr1;	// 08h
  ULONG              Dr2;	// 0ch
  ULONG              Dr3;	// 10h
  ULONG              Dr6;	// 14h
  ULONG              Dr7;	// 18h
  
  FLOATING_SAVE_AREA FloatSave;
  
  ULONG              SegGs;	// 88h
  ULONG              SegFs;	// 90h
  ULONG              SegEs;	// 94h
  ULONG              SegDs;	// 98h
  
  ULONG              Edi;	// 9ch
  ULONG              Esi;	// A0h
  ULONG              Ebx;	// A4h
  ULONG              Edx;	// A8h
  ULONG              Ecx;	// ACh
  ULONG              Eax;	// B0h
  
  ULONG              Ebp;	// B4h
  ULONG              Eip;	// B8h
  ULONG              SegCs;	// BCh
  ULONG              EFlags;	// C0h
  ULONG              Esp;	// C4h
  ULONG              SegSs;	// C8h
  
  UCHAR              ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];
} CONTEXT;

스레드마다 하나씩 가지고 있는 CONTEXT 구조체에는 CPU 레지스터 값이 백업되어 저장됩니다. 이를 통해 멀티 스레드 환경에서도 스레드 단위별로 실행할 수 있습니다

 

 

대표적 예외(EXCEPTION) 목록

EXCEPTION_DATATYPE_MISALIGNMENT		(0x80000002)
EXCEPTION_BREAKPOINT			(0x80000003)
EXCEPTION_SINGLE_STEP			(0x80000004)
EXCEPTION_ACCESS_VIOLATION		(0xC0000005)
EXCEPTION_IN_PAGE_ERROR			(0xC0000006)
EXCEPTION_ILLEGAL_INSTRUCTION		(0xC000001D)
EXCEPTION_NONCONTINUABLE_EXCEPTION	(0xC0000025)
EXCEPTION_INVALID_DISPOSITION		(0xC0000026)
EXCEPTION_ARRAY_BOUNDS_EXCEEDED		(0xC000008C)
EXCEPTION_FLT_DENORMAL_OPERAND		(0xC000008D)
EXCEPTION_FLT_DIVIDE_BY_ZERO		(0xC000008E)
EXCEPTION_FLT_INEXACT_RESULT		(0xC000008F)
EXCEPTION_FLT_INVALUD_OPERATION		(0xC0000090)
EXCEPTION_FLT_OPERATION			(0xC0000091)
EXCEPTION_FLT_STACK_CHECK		(0xC0000092)
EXCEPTION_FLT_UNDERFLOW			(0xC0000093)
EXCEPTION_INT_DIVIDE_BY_ZERO		(0xC0000094)
EXCEPTION_INT_OVERFLOW			(0xC0000095)
EXCEPTION_PRIV_INSTUCTION		(0xC0000096)
EXCEPTION_STACK_OVERFLOW		(0xC00000FD)

 

 

 

그중 가장 대표적 예외인 EXCEPTION_BREAKPOINT를 이용한 안티 디버깅 기법에 대해 알아보겠습니다.

breakpoint로 인한 예외 발생 시, 일반적으로 실행 중이면 등록된 SEH로 넘어가고 디버깅 중이면 디버거에 의해 예외가 처리됩니다.

 

INT3(BP)에 의해 예외가 발생합니다.

 

 

디버거로 실행한다면 미리 등록된 SEH가 실행되지 않습니다. 그래서 예외가 발생한 다음 코드가 실행되는데 해당 코드는 0xFFFFFFFF 주소로 이동하여 비정상적으로 종료하게 합니다.

비정상 종료

 

 

ollydbg의 debugging options의 INT3 breaks 옵션을 체크하면 쉽게 우회할 수 있습니다.

 

 

INT3 예외를 무시하도록 설정하면 등록된 SEH 코드가 실행됩니다.

우회된 BP 예외

 

 

 

 

 

1.2. SetUnhandledExceptionFilter()

프로세스에서 예외가 발생했을 때 SEH에서 처리되지 않거나 등록된 SEH가 없을 때 호출되는 API입니다. 이 함수는 Top Level Exception Filter(또는 Last Exception Filter)라는 예외 처리기를 등록하고, 예외가 발생했을 때 해당 필터 함수가 호출되도록 합니다. 시스템의 마지막 예외 처리기를 실행시키는 것입니다.

 

 

SetUnhandledExceptionFilter 정의

LPTOP_LEVEL_EXCEPTION_FILTER SetUnhandledExceptionFilter(
  LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter
);

 

• lpTopLevelExceptionFilter
  • 처리되지 않은 예외가 발생할 때 호출될 함수의 포인터
  • Top Level Exception Filter 함수 주소가 저장된다.

 

SetUnhandledExceptionFilter 함수의 리턴값은 이전 Top Level Exception Filter 함수 주소입니다.

 

 

 

TopLevelExceptionFilter 정의

LONG WINAPI TopLevelExceptionFilter(
  EXCEPTION_POINTERS *ExceptionInfo
);

 

• ExceptionInfo
  • EXCEPTION_POINTERS 구조체에 대한 포인터
  • 예외가 발생한 정보(예: 예외 코드, 예외 발생 위치, 레지스터 상태 등)를 포함한다.

 

 

EXCEPTION_POINTERS 구조체는 예외가 발생했을 때 예외 처리기에게 전달되는 중요한 데이터 구조입니다.

 

EXCEPTION_POINTER 구조체

typedef struct _EXCEPTION_POINTERS {
  EXCEPTION_RECORD   *ExceptionRecord;
  CONTEXT            *ContextRecord;
} EXCEPTION_POINTERS;

 

• ExceptionRecord
  • EXCEPTION_RECORD 구조체에 대한 포인터로, 해당 구조체는 예외의 세부 정보를 담고 있다.
  • 예외 코드, 예외 발생 위치, 예외의 원인 등을 포함
    
    
• ContextRecord
  • CONTEXT 구조체에 대한 포인터로, 해당 구조체는 예외 발생 시 CPU 레지스터와 같은 프로세서 상태 정보를 포함한다.
  • 프로그램 카운터(PC), 스택 포인터, 레지스터 값 등이 포함되어 있어 예외 발생 시 시스템 상태를 분석하는데 사용된다.

 

 

 

프로그램은 먼저 SetUnhandledExceptionFilter 함수 호출 시 실행될 Top Level Exception Filter(예외처리기)를 등록합니다. Top Level Exception Filter는 0x401000 주소입니다.

 

 

계속 실행하게 되면 0x401052 주소에서 Invalid Memory Access Violation 예외(EXCEPTION_ACCESS_VIOLATION)가 발생하여 디버깅이 중지됩니다.

 

 

 

이를 우회하기 위해서는 SetUnhandledExceptionFilter 함수로 등록된 예외 처리 코드로 이동되어야 합니다. 그러기 위해서 먼저 디버거가 해당 Access Violation 예외를 무시하도록 설정합니다.

 

 

 

디버거가 Access Violation 예외를 무시하면 이미 등록되어 있는 예외 처리 코드로 이동합니다.

 

예외 처리 코드는 4를 리턴하여 EIP 주소에 4를 더해 줍니다. 예외 발생 코드 주소는 401052였으므로 4를 더하면 401056입니다. 예외 처리기를 리턴하면 401056부터 실행되게 됩니다.

 

 

예외 처리 코드 이후 실행되는 0x401056

디버깅 탐지 우회

 

 

 

 

 

2. Timing Check

디버거 실행 시 일반 실행보다 훨씬 오랜 시간이 소요되기 때문에 이를 측정하여 디버깅 여부를 판단하는 기법입니다.

이는 구해온 시간을 조작하여 간단히 우회할 수 있기 때문에 보통 다른 안티 디버깅 기법들과 함께 사용됩니다.

 

시간을 확인하는 방법은 크게 두 가지로 나뉩니다.

1. CPU의 카운터(Counter) 이용

• RDTSC(Read Time Stamp Counter)
• QueryPerformanceCounter / NtQueryPerformanceCounter
• GetTickCount

 

2. 시스템의 실제 시간(Time) 이용

• timeGetTime
• _ftime

 

 

그 중 가장 정확하고 많이 사용되는 RDTSC에 대해 알아보겠습니다.

 

RDTSC

CPU는 Clock Cycle을 카운트하여 64비트 레지스터 TSC(Time Stamp Counter)에 저장합니다. RDTSC는 그 TSC 값을 EDX와 EAX 레지스터에 저장하는 어셈블리 명령입니다. EDX와 EAX에 각 상/하위 32비트씩 저장합니다.

안티디버깅에 주로 사용되는 이유는 매우 빠르고 CPU의 클럭 주기를 직접 읽기 때문에 디버깅 중 CPU 속도가 느려지거나 중단점에서 시간을 측정하는 방식이 다를 때 이를 탐지하기 유리합니다.

 

 

rdtsc를 통해 현재 시간을 구하고, 3E8h번 루프를 돌려 (일부러) 시간을 소모한 후, 다시 시간을 측정합니다.

 

 

측정한 두 시간의 차이를 구하여 디버깅 여부를 판별합니다.

두 시간의 차이가 FFFFFFh 보다 크면 디버깅 중이라고 판단하여 점프합니다.

 

 

이를 우회하기 위해서는 다음과 같은 방법이 있습니다.

1. 트레이싱 없이 해당 코드 run하기

  - 시간 소모를 없애 시간차가 많이 안 나도록

2. EAX, EDX 값 수정하기

3. Jcc에 맞게 플래그 ZF 또는 CF 변경하기

 

 

 

 

3. Trap Flag

Trap Flag(TF)는 EFLAGS 레지스터의 9번째(index 8) 비트로, Trap Flag가 설정되면 Single Step 모드로 변경되어 명령어를 한 번에 실행하는 것이 아니라 한 명령어씩 실행하게 합니다. 그리고 EXCEPTION_SINGLE_STEP 예외를 발생시킨 후 Trap Flag는 0으로 자동 초기화됩니다.

 

 

먼저 TF 값을 1로 세팅합니다.

 

 

그리고 다음 명령을 실행하면 EXCEPTION_SINGLE_STEP 예외가 발생합니다.

 

TF는 자동으로 초기화되었습니다.

이는 EXCEPTION_SINGLE_STEP 발생 후 정상 실행 모드로 전환되어 그대로 계속 진행되는 것을 뜻합니다.

그대로 진행되면 0xFFFFFFFF로 점프하여 프로세스가 비정상 종료되게 됩니다.

비정상 종료 코드

 

 

디버거 실행이 아니라 일반 실행 중이었다면 미리 설정해둔 SEH 코드로 진행됐을테지만 디버거로 실행하여 비정상 종료되는 코드로 진행한 것입니다.

SEH 코드

 

 

ollydbg의 debugging options의 Single-step break 옵션을 체크하면 쉽게 우회할 수 있습니다.

 

디버거 탐지 우회

 

 

 

 

4. INT 2D

INT 2D는 커널 모드에서 작동하는 Break point 예외를 발생시키는 명령어로, 유저 모드에서도 예외를 발생시킵니다. INT 2D 또한 디버거로 실행하면 예외를 발생시키지 않고 넘어가기 때문에 이를 이용하여 안티 디버깅에 활용합니다.

 

 

INT 2D 특징

1. 1바이트 무시

디버깅 모드에서 INT 2D를 실행하면 다음 명령어의 첫 바이트는 무시되고 그 다음 바이트부터 실행됩니다.

 

INT 2D(CD 2D) 명령을 실행하기 전, 다음 명령은 mov eax,5DEB(E8 EB5D0000)이었지만

INT 2D 호출 전

 

INT 2D(CD 2D) 명령을 실행한 후의 다음 명령은 1바이트 E8이 무시된 EB 5D 0000로 변경되어 다른 명령으로 인식되어 실행됩니다.

INT 2D 호출 후

 

이렇게 코드 바이트 순서를 변경하여 원래의 명령과 다른 명령을 수행하도록 합니다. 이를 코드 난독화(code obfuscating)이라고도 하며 dynamic 안티 디버깅 기법에 자주 사용됩니다. 

 

 

2. BP까지 그대로 실행

INT 2D 명령을 실행하고 트레이싱하면 그 다음 명령어 시작에서 멈추지 않고 BP를 만날 때까지 계속 실행됩니다. 1번째 이유 때문에 코드 바이트 순서가 변경되어 멈추지 못하고 그대로 진행하게 됩니다.

 

INT 2D를 이용한 안티 디버깅을 우회하기 위해서는  INT 2D로 인한 예외가 발생하면 등록되어 있는 SEH 코드로 이동해야 합니다. 이를 위해 Trap Flag를 이용해서 SEH로 이동하는 방법이 있습니다. Single Step 모드로 명령어가 실행되면 EXCEPTION_SINGLE_STEP 예외가 발생되어 SEH 코드로 이동하도록 하는 것입니다.

 

 

먼저 EXCEPTION_SINGLE_STEP 예외를 무시하도록 설정합니다.

그리고 INT 2D 명령 실행 직전 TF를 1로 세팅합니다.

 

 

 

INT 2D 명령이 원래 kernel 명령어이기 때문에 user 모드 디버거에서는 정상적인 명령으로 인식되지 않아 바로 예외가 발생하지 않습니다. 그래서 TF 값도 그대로입니다.

그대로인 TF

 

TF가 0이었다면 INT 2D에 의해 다음 1바이트가 무시되어 진행되겠지만, TF가 1이기 떄문에 무시되지 않고 원래 코드대로 진행됩니다. 그렇기 때문에 다음 명령인 NOP이 Single Step 모드인 상태로 실행되고, 예외에 의해 SEH 코드로 넘어갑니다.

SEH로 이동하여 우회됨

 

 

 

 

5. 0xCC 탐지

프로그램을 디버깅할 때 설치하는 Software Breakpoint를 이용한 안티 디버깅 기법이 있습니다.

Breakpoint의 instruction인 0xCC를 탐지하여 디버깅 여부를 판별합니다.

 

 

5.1. API Break Point

프로그램을 디버깅할 때 특정 API에 Breakpoint를 설치 및 실행하여 분석하는 방법이 많이 사용되고 있습니다. 그렇기 때문에 API에 설치된 BP를 확인해서 현재 디버깅을 당하는지 판별하는 안티 디버깅 기법이 존재합니다. 일반적으로 API 시작 부분에 BP를 설치하므로 첫 바이트가 CC인지 검사해서 디버깅 여부를 판단합니다. 리버서들이 관심을 가지는 API는 다음과 같습니다.

 

API 리스트

[프로세스]

CreateProcess	CreateProcessAsUser	CreateRemoteThread
CreateThread	GetThreadContext	SetThreadContext
EnumProcesses	EnumProcessModules	OpenProcess
CreateToolhelp32Snapshot	Process32First	Process32Next
ShellExecuteA	WinExec	TerminateProcess

[메모리]

ReadProcessMemory	WriteProcessMemory	VirtualAlloc
VirtualAlloEx	VirtualProtect	VirtualProtecEX
VirtualQuery	VirtualQueryEx

[파일]

CreateFile	ReadFile	WriteFile
CopyFile	CreateDirectory	DeleteFile
MoveFile	MoveFileEx	FindFirstFile
FindNextFile	GetFileSize	GetWindowsDirectory
GetSystemDirectory	GetFileAttributes	SetFileAttributes
SetFilePointer	CreateFileMapping	MapViewOfFile
MapViewOfFileEx	UnmapViewOfFile	_open
_write	_read	_lseek
_tell

[레지스트리]

RegCreateKeyEx	RegDeleteKey	RegDeleteValue
RegEnumKeyEx	RegQueryValueEx	RegSetValue
RegSetValueEx

[네트워크]

WSAStartup	socket	inet_addr
closesocket	getservbyname	gethostbyname
htons	connect	inet)htoa
recv	send	HttpOpenRequest
HttpSendRequest	HttpQueryInfo	InternetCloseHandle
InternetConnect	InternetGetConnectedState	InternetOpen
InternetOpenUrl	InternetReadFile	URLDownloadToFile

[기타]

OpenProcessToken	LookupPrivilegeValue	AdjustTokenPrivileges
OpenSCManager	CreateService	OpenService
ControlService	DeleteService	RegisterServiceCtrlHandler
SetServiceStatus	QueryServiceStatusEx	CreateMutex
OpenMutex	FindWindow	LoadLibrary
GetProcAddress	GetModuleFileNameA	GetCommandLine
OutputDebugString	...

 

이러한 API의 시작 첫 바이트에 BP를 설치하여 분석하기 때문에 API의 시작 주소를 구해서 첫 바이트를 검사해보면 디버깅 여부를 판단합니다.

이를 우회하기 위해서는 API 시작 주소를 피해서 BP를 설치하여 분석하는 방법으로 회피할 수 있습니다. 또는 Hardware BP를 설치하여 분석하는 방법도 있습니다.

 

 

 

5.2. Checksum 비교

Software Breakpoint를 확인하는 또 다른 방법은 특정 코드 영역의 checksum 값을 비교하는 것입니다. 특정 코드 영역에 BP(0xCC)를 하나라도 설치했다면 원래의 checksum 값과 달라지기 때문에 디버깅 여부를 판단할 수 있습니다.

 

 

 

특정 영역을 미리 지정합니다. 0x401000(ESI)부터 0x70만큼의 영역을 지정했습니다.

 

 

지정된 영역의 checksum을 구하는 루프문

 

 

BP를 설치했다면 디버거에서는 보이지 않지만, instruction이 달라졌기 때문에 checksum 값이 달라집니다.

미리 계산해둔 checksum 값인 0xF5934986과 루프문을 통해 계산되어 EAX에 저장된 0x7E0A498B 값이 다르므로 BP를 사용한 디버깅 실행중이라고 판단합니다.

 

 

 

이런 상황을 우회하는 방법에는 checksum 값을 비교하는 구문을 패치하는 방법이 있습니다.

비교 구문(cmp) 다음의 명령을 무조건 다른 주소로 점프하도록 바꾸어 줬습니다. (jmp 40105D)

 

우회된 checksum 탐지 기법

 

 

 

Ref) 리버싱 핵심원리, 이승원