안티 리버싱 핵심원리

pwn/study note

안티 리버싱 핵심원리

cyalume 2024. 10. 27. 23:20

Table of Contents

Dynamic Anti-Reversing

1. Exception

2. Software Breakpoint Detection

3. Hardware Breakpoint Detection

4. Timing Check

5. Single Step Execution Detection

6. Patching Detection

7. Anti-Disassembly

8. PE Image Switching

9. Self-Execution

10. Self-Debugging

11. Nanomite

12. Code Obfuscation

13. Encryption/Decryption

14. Stolen Bytes

15. Multi-Threaded Packers

16. Code Virtualization

17. API Redirection

18. API Wrapping

Static Anti-Reversing

1. PEB

2. TEB

3. Static Anti-Debugging with Native API (NT)

7. TLS Callback Function

8. Static Anti-Debugging with Normal API (WinAPI)

Attacking Debugger

1. NtSetInformationThread()

2. BlockInput()

3. Disable Breakpoint

4. UnhandledExceptionFilter()

5. Exploit Debugger with Format String Bug

6. ??

Dynamic Anti-Reversing Techniques

1. Using Exceptions

디버깅 중 디버기에서 예외가 발생하면 디버거가 기본적으로 이를 처리한다. 디버기에 정의된 Exception Handler가 있어도 말이다. 이 특성을 이용하여 예외를 발생시키고, 이를 처리하는 주체를 식별하여 anti-debugging 기법을 구현할 수 있다. 주로 SEH Chain을 이용하거나, kernel32.dll의 `SetUnhandledExceptionFilter()` 함수를 사용해 예외를 처리할 주체를 등록한다.

1) SEH (Structured Exception Handler)

SEH는 `_EXCEPTION_REGISTRATION_RECORD` 구조체의 연결 리스트로 구성되며, 이는 스택에 저장된다. (따라서 범위 종속적이다. -> 약간의 확인 필요, 범위를 넘어가 SEH top 요소가 덮어쓰이면 fs:\[0]은 어떻게 되는가?) 이를 가리켜 SEH Chain이라 칭한다. 첫 요소부터 마지막 요소까지, 예외가 처리될 때까지 순차적으로 실행된다.

(1) `_EXCEPTION_REGISTRATION_RECORD` 구조체

`_EXCEPTION_REGISTRASTION_RECORD` 구조체의 정의는 아래와 같다.

typedef struct _EXCEPTION_REGISTRATION_RECORD{
PEXCEPTION_REGISTRATION_RECORD Next;
PEXCEPTION_DISPOSITION Handler;
} EXCEPTION_REGISTRATION_RECORD, *PEXCEPTION_REGISTRATION_RECORD;

`Next` 멤버는 스택에 있는 다음 예외 처리기를 가리킨다. 이 값이 0xFFFFFFFF이라면 이 노드가 SEH Chain의 마지막 예외 처리기라는 것을 뜻한다.

`Handler` 멤버는 예외 처리에 사용될 함수의 주소를 저장한다. `Handler`는 시스템에 의해 호출되는 callback 함수로, 정의는 아래와 같다.
(a) `Handler` calllback function
func `_except_handler()` (winnt.h)

EXCEPTION_DISPOSITION _except_handler(
EXCEPTION_RECORD *pRecord,
EXCEPTION_REGISTRATION_RECORD *pFrame,
CONTEXT *pContext,
PVOID DispatcherContext // 시스템 내부에서 사용되는 값. 신경 쓸 필요 x
)

이 함수는 SEH Chain의 일부로, 발생한 예외를 처리하기 위해 존재한다. 예외 처리기(`handler`)가 세 번째 인자 `CONTEXT` 구조체의 시작점으로부터 0xB8만큼 떨어진 `Eip` 멤버를 적절히 변경함으로써 예외 발생 지점으로부터 실행 흐름을 옮기는 방식으로 예외를 처리할 수 있다. (bytecode에 대한 이해가 깊다면 예외가 발생한 `pRecord->ExceptionAddress`의 Opcode를 적절히 변경하는 방식으로도 처리할 수 있을 것이다. -> 이거 재미있어 보이는데 구현 ㄱㄱ)

아래는 `CONTEXT.Eip`를 2만큼 증가시켜 예외를 처리하는 간단한 `handler`의 코드이다.

mov eax, dword ptr ss:[esp + 0x04] 
// pContext의 주소 옮김. [esp] = pValue, [esp+8] = pFrame, [esp+C] = pRecord
mov ecx, dword ptr ds:[eax + 0xB8] // pContext.Eip 값을 eax에 옮김
add ecx, 2
mov dword ptr ds:[eax+0xB8], ecx
xor eax, eax
retn 4 // handler의 인자가 4개이므로, 이를 모두 정리한 뒤 return.
// 아마 __stdcall, win32에서는 가변인자함수를 제외한 모든 함수는 __stdcall 사용

(a-1) `Handler`'s 1st param: `_EXCEPTION_RECORD *` (winnt.h)

typedef struct _EXCEPTION_RECORD { 
DWORD ExceptionCode; // 시스템이 exception에 할당한 숫자
DWORD ExceptionFlags; //
struct _EXCEPTION_RECORD *ExceptionRecord; 
PVOID ExceptionAddress; // exception이 발생한 주소
DWORD NumberParameters; 
ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS]; 
} EXCEPTION_RECORD;

[Microsoft: EXCEPTION_RECORD structure (winnt.h)](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-exception_record)

`ExceptionCode`는 예외 번호인데, winnt.h에서 `#define STATUS_` 를 검색해 찾을 수 있다. 더 많은 exception code는 Windows NT DDK의 ntstatus.h에서 찾아볼 수 있다.

`ExceptionFlags`는 winnt.h에 다음과 같이 정의되어 있다.

#define EXCEPTION_NONCONTINUABLE 0x1    // Noncontinuable exception
#define EXCEPTION_UNWINDING 0x2         // Unwind is in progress
#define EXCEPTION_EXIT_UNWIND 0x4       // Exit unwind is in progress
#define EXCEPTION_STACK_INVALID 0x8     // Stack out of limits or unaligned
#define EXCEPTION_NESTED_CALL 0x10      // Nested exception handler call
#define EXCEPTION_TARGET_UNWIND 0x20    // Target unwind in progress
#define EXCEPTION_COLLIDED_UNWIND 0x40  // Collided exception handler call

(a-2) `Handler`'s 2nd param: `EXCEPTION_REGISTRATION_RECORD *` (winnt.h)
이 파라미터는 establisher frame structure를 나타낸다. 이는 호출된 SEH handler가 속한 `_EXCEPTION_REGISTRATION_RECORD` 구조체의 시작 주소를 나타낸다. (`*pFrame` = `Next`에 저장된 값, `**pFrame` = 다음 SEH 노드의 Next에 저장된 주소)

아래 코드를 통해 이를 확인할 수 있다.

// x86 debug, VS19
#include <Windows.h>
#include <stdio.h>

EXCEPTION_DISPOSITION 
_cdecl
handler(
EXCEPTION_RECORD* pRecord,
EXCEPTION_REGISTRATION_RECORD* pFrame,
CONTEXT* pContext,
PVOID pValue
) {
MessageBox(NULL,
L"Exception Occurred",
L"Exception Handler 1",
MB_ICONERROR);

printf("Exception Occurred at: %p\n", pRecord->ExceptionAddress);
printf("Exception filter 1 called at: %p\n", pFrame);

return ExceptionContinueSearch;
}

EXCEPTION_DISPOSITION
_cdecl
handler2(
EXCEPTION_RECORD* pRecord,
EXCEPTION_REGISTRATION_RECORD* pFrame,
CONTEXT* pContext,
PVOID pValue
) {
MessageBox(NULL,
L"Exception Occurred",
L"Exception Handler 2",
MB_ICONERROR);

pContext->Eip += 7;
printf("Exception Occurred at: %p\n", pRecord->ExceptionAddress);
printf("Exception filter 2 called at: %p\n", pFrame);

return ExceptionContinueExecution;
}

int main() {
DWORD handlerAddr = 0;
DWORD temp = 0;

__asm {
push handler2
push dword ptr fs:[0x00]

push handler
lea eax, [esp+4]
push eax

mov dword ptr fs:[0x00], esp

lea eax, [esp]
mov handlerAddr, eax
}

printf("SEH[0] is now set at  %p\n", (void*)handlerAddr);
printf("Handler 1 at %p\n", handler);
printf("Handler 2 at %p\n", handler2);

__asm {
xor eax, eax
mov dword ptr ds:[eax], 1 // Exception: Access Violation

mov eax, dword ptr fs:[0x00]
mov temp, eax
}

printf("Exception Successfully Handled\nContinue Execution...\n");

__asm {
xor eax, eax
mov dword ptr ds : [eax] , 1 // Exception: Access Violation
}

printf("Exception 2 Successfully Handled\nContinue Execution...\n");

__asm {
add esp, 0x10 // SEH 설치하면서 push 했던 것 정리.
}
}

`handler()`는 자신의 `pFrame`을 출력하고, 예외를 다음 SEH 노드로 넘긴다. 다음 SEH 노드에는 `handler2()`가 존재하며, 여기서 예외를 처리한 뒤 자신의 `pFrame`을 출력, 실행을 재개한다.
위 코드의 실행 결과는 아래와 같다.

SEH[0] is now set at  00CDFAC4
Handler 1 at 00D713CA
Handler 2 at 00D713CF
Exception Occurred at: 00D753DD
Exception filter 1 called at: 00CDFAC4
Exception Occurred at: 00D753DD
Exception filter 2 called at: 00CDFACC
Exception Successfully Handled
Continue Execution...
Exception Occurred at: 00D753FC
Exception filter 1 called at: 00CDFAC4
Exception Occurred at: 00D753FC
Exception filter 2 called at: 00CDFACC
Exception 2 Successfully Handled
Continue Execution...

뭐.. 주소야 실행 시마다 달라지겠지만, `FS:[0x00]`에 담긴 값이 첫 SEH 노드의 시작 주소, 즉 `handler()`의 주소가 포함된 `_EXCEPTION_REGISTRATION_RECORD` 구조체의 시작 주소이고 (스택 영역) 또한 `handler()`의 `pFrame`에 담긴 주소이다. 마찬가지로 `handler2()`의 `pFrame`으로는 `handler2()`의 주소가 포함된 `_EXCEPTION_REGISTRATION_RECORD` 구조체의 주소가 들어간다.

위 코드에서는 Stack에 `handler2()`를 위한 `_EXCEPTION_REGISTRATION_RECORD` 구조체를 만든 후 `handler()`를 위한 구조체를 만들고 있기 때문에 두 `pFrame`에 저장된 주소값의 차이가 `_EXCEPTION_REGISTRATION_RECORD` 구조체의 크기인 8byte만큼 발생한다.

이는 어디까지나 추가적인 증명일 뿐이고, 아래 SEH 구현 부분을 읽어야 이해가 될 것이다. 지금으로서는 넘어가도 좋다.
(a-3) `Handler`'s 3rd param: struct `_CONTEXT` (winnt.h)
`CONTEXT` 구조체는 multi-threading 환경을 위해 특정 thread의 레지스터 값을 백업해 놓는 용도의 구조체이다. 레지스터를 저장하다 보니 x86 버전과 x64 버전, amd나 arm 버전 등 아키텍처에 따라 정의가 조금씩 다른데, 이들 모두 winnt.h에서 확인할 수 있었다. 아래는 intel x86 (IA-32) 전용 `_CONTEXT` 구조체의 정의. (MSDN에 `CONTEXT` 구조체를 검색하면 나오는 코드는 x64 버전이다.)

typedef struct _CONTEXT {
  DWORD                    ContextFlags;
  DWORD                    Dr0;
  DWORD                    Dr1;
  DWORD                    Dr2;
  DWORD                    Dr3;
  DWORD                    Dr6;
  DWORD                    Dr7;
  FLOATING_SAVE_AREA FloatSave;
  DWORD                    SegGs;
  DWORD                    SegFs;
  DWORD                    SegEs;
  DWORD                    SegDs;
  DWORD                    Edi;
  DWORD                    Esi;
  DWORD                    Ebx;
  DWORD                    Edx;
  DWORD                    Ecx;
  DWORD                    Eax;
  DWORD                    Ebp;
  DWORD                    Eip; // B8h
  DWORD                    SegCs;
  DWORD                    EFlags;
  DWORD                    Esp;
  DWORD                    SegSs;
  BYTE                     ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];
};

64-bit Windows에서 32-bit 프로그램을 돌린다면 동일한 구성을 가진 `_WOW64_CONTEXT`을 찾아봐도 된다. 아마..
한 스레드를 실행하고 다른 스레드로 실행 흐름을 바꿀 때 레지스터들의 상태(context)를 이 구조체에 백업해놓고 다른 스레드를 실행, 다시 본 스레드로 돌아올 때에는 레지스터들을 이 구조체에 저장된 값으로 덮어 쓰고 실행을 재개한다.

winnt.h의 소스 코드는 아래 링크에서 확인할 수 있다.
[winnt.h](https://codemachine.com/downloads/win80/winnt.h)

(a-4) `Handler`'s 3rd param: PVOID `DispatcherContext`
(a-5) `Handler`'s return value: enum `EXCEPTION_DISPOSITION`

typedef enum _EXCEPTION_DISPOSITION {
         ExceptionContinueExecution = 0, // 예외 처리 완료, 코드 실행
         ExceptionContinueSearch = 1, // 처리 실패, SEH Chain의 다음 예외 처리기 실행
         ExceptionNestedException = 2, // OS에서 사용됨
         ExceptionCollidedUnwind = 3 // OS에서 사용됨
} EXCEPTION_DISPOSITION;

`Handler`의 예외 처리 후, 시스템의 동작을 지정하기 위해 사용된다. 근데 예외에 대한 처리를 안 하고 무작정 0을 반환하면, 시스템이 실행을 재개했을 때 똑같은 부분에서 다시 예외가 발생해 이 핸들러가 무한정 재호출되는 일이 생긴다. 아래의 코드가 그 예시이다.

//x86 debug, VS19
#include <stdio.h>

int handler(){
printf("Exception Occurred; And I, exception handler, will do nothing.\n");
return 0;
}

int main(){
__asm{
push handler
push dword ptr FS:[0]
mov dword ptr FS:[0], esp

xor eax, eax
mov dword ptr [eax], 1 // Exception: Access Violation
}
}

위 코드를 실행하면 `handler()` 함수가 계속해서 호출된다. Access Violation 예외가 해결되지 않은 채로 `ExceptionContinueExecution` 신호를 보내서, 처리가 완료된 줄 안 시스템이 예외가 발생한 코드 부분부터 다시 실행하여 계속 예외가 발생하고, 또 똑같은 `handler()`가 그걸 처리하기 때문이다. `handler()`가 1을 반환하게 코드를 수정하고 실행하면, `handler()`가 한 번 호출된 뒤 시스템이 설정한 기본 예외 처리기가 예외를 넘겨받아 프로세스를 종료한다.

보통은 이러한 일이 일어나지 않게끔, `handler()`에서 전달된 `CONTEXT` 구조체의 `Eip` 멤버(`&CONTEXT + 0xB8`)를 적절히 변경한 뒤 값을 반환하도록 구현한다. (아래 사용 예제를 참고.)

(2) SEH 설치하기

SEH의 시작 주소는 `TEB.NtTib.ExceptionList`에 저장되어 있다.
아래는 TEB와 TEB.NtTib의 구조이다. WinDbg를 사용했다.

(a) TEB (Thread Environment Block / TIB) 구조
Windbg에서 `dt _TEB` 혹은 `dt TEB` 명령어를 통해 구조를 확인할 수 있다. (x86 on x86, x64 on x64)
x86 debugee on x64 Windbg의 경우, `dt _TEB32` 명령어를 사용하여야 한다.

0:000> dt _TEB
ntdll!_TEB
   +0x000 NtTib            : _NT_TIB
   +0x01c EnvironmentPointer : Ptr32 Void
   +0x020 ClientId         : _CLIENT_ID
   +0x028 ActiveRpcHandle  : Ptr32 Void
   +0x02c ThreadLocalStoragePointer : Ptr32 Void
   +0x030 ProcessEnvironmentBlock : Ptr32 _PEB
   +0x034 LastErrorValue   : Uint4B
   +0x038 CountOfOwnedCriticalSections : Uint4B
   +0x03c CsrClientThread  : Ptr32 Void
   +0x040 Win32ThreadInfo  : Ptr32 Void
   +0x044 User32Reserved   : [26] Uint4B
   +0x0ac UserReserved     : [5] Uint4B
   +0x0c0 WOW32Reserved    : Ptr32 Void
   +0x0c4 CurrentLocale    : Uint4B
   +0x0c8 FpSoftwareStatusRegister : Uint4B
   +0x0cc ReservedForDebuggerInstrumentation : [16] Ptr32 Void
   +0x10c SystemReserved1  : [26] Ptr32 Void
   +0x174 PlaceholderCompatibilityMode : Char
   +0x175 PlaceholderHydrationAlwaysExplicit : UChar
   +0x176 PlaceholderReserved : [10] Char
   +0x180 ProxiedProcessId : Uint4B
   +0x184 _ActivationStack : _ACTIVATION_CONTEXT_STACK
   +0x19c WorkingOnBehalfTicket : [8] UChar
   +0x1a4 ExceptionCode    : Int4B
   +0x1a8 ActivationContextStackPointer : Ptr32 _ACTIVATION_CONTEXT_STACK
   +0x1ac InstrumentationCallbackSp : Uint4B
   +0x1b0 InstrumentationCallbackPreviousPc : Uint4B
   +0x1b4 InstrumentationCallbackPreviousSp : Uint4B
   +0x1b8 InstrumentationCallbackDisabled : UChar
   +0x1b9 SpareBytes       : [23] UChar
   +0x1d0 TxFsContext      : Uint4B
   +0x1d4 GdiTebBatch      : _GDI_TEB_BATCH
   +0x6b4 RealClientId     : _CLIENT_ID
   +0x6bc GdiCachedProcessHandle : Ptr32 Void
   +0x6c0 GdiClientPID     : Uint4B
   +0x6c4 GdiClientTID     : Uint4B
   +0x6c8 GdiThreadLocalInfo : Ptr32 Void
   +0x6cc Win32ClientInfo  : [62] Uint4B
   +0x7c4 glDispatchTable  : [233] Ptr32 Void
   +0xb68 glReserved1      : [29] Uint4B
   +0xbdc glReserved2      : Ptr32 Void
   +0xbe0 glSectionInfo    : Ptr32 Void
   +0xbe4 glSection        : Ptr32 Void
   +0xbe8 glTable          : Ptr32 Void
   +0xbec glCurrentRC      : Ptr32 Void
   +0xbf0 glContext        : Ptr32 Void
   +0xbf4 LastStatusValue  : Uint4B
   +0xbf8 StaticUnicodeString : _UNICODE_STRING
   +0xc00 StaticUnicodeBuffer : [261] Wchar
   +0xe0c DeallocationStack : Ptr32 Void
   +0xe10 TlsSlots         : [64] Ptr32 Void
   +0xf10 TlsLinks         : _LIST_ENTRY
   +0xf18 Vdm              : Ptr32 Void
   +0xf1c ReservedForNtRpc : Ptr32 Void
   +0xf20 DbgSsReserved    : [2] Ptr32 Void
   +0xf28 HardErrorMode    : Uint4B
   +0xf2c Instrumentation  : [9] Ptr32 Void
   +0xf50 ActivityId       : _GUID
   +0xf60 SubProcessTag    : Ptr32 Void
   +0xf64 PerflibData      : Ptr32 Void
   +0xf68 EtwTraceData     : Ptr32 Void
   +0xf6c WinSockData      : Ptr32 Void
   +0xf70 GdiBatchCount    : Uint4B
   +0xf74 CurrentIdealProcessor : _PROCESSOR_NUMBER
   +0xf74 IdealProcessorValue : Uint4B
   +0xf74 ReservedPad0     : UChar
   +0xf75 ReservedPad1     : UChar
   +0xf76 ReservedPad2     : UChar
   +0xf77 IdealProcessor   : UChar
   +0xf78 GuaranteedStackBytes : Uint4B
   +0xf7c ReservedForPerf  : Ptr32 Void
   +0xf80 ReservedForOle   : Ptr32 Void
   +0xf84 WaitingOnLoaderLock : Uint4B
   +0xf88 SavedPriorityState : Ptr32 Void
   +0xf8c ReservedForCodeCoverage : Uint4B
   +0xf90 ThreadPoolData   : Ptr32 Void
   +0xf94 TlsExpansionSlots : Ptr32 Ptr32 Void
   +0xf98 MuiGeneration    : Uint4B
   +0xf9c IsImpersonating  : Uint4B
   +0xfa0 NlsCache         : Ptr32 Void
   +0xfa4 pShimData        : Ptr32 Void
   +0xfa8 HeapData         : Uint4B
   +0xfac CurrentTransactionHandle : Ptr32 Void
   +0xfb0 ActiveFrame      : Ptr32 _TEB_ACTIVE_FRAME
   +0xfb4 FlsData          : Ptr32 Void
   +0xfb8 PreferredLanguages : Ptr32 Void
   +0xfbc UserPrefLanguages : Ptr32 Void
   +0xfc0 MergedPrefLanguages : Ptr32 Void
   +0xfc4 MuiImpersonation : Uint4B
   +0xfc8 CrossTebFlags    : Uint2B
   +0xfc8 SpareCrossTebBits : Pos 0, 16 Bits
   +0xfca SameTebFlags     : Uint2B
   +0xfca SafeThunkCall    : Pos 0, 1 Bit
   +0xfca InDebugPrint     : Pos 1, 1 Bit
   +0xfca HasFiberData     : Pos 2, 1 Bit
   +0xfca SkipThreadAttach : Pos 3, 1 Bit
   +0xfca WerInShipAssertCode : Pos 4, 1 Bit
   +0xfca RanProcessInit   : Pos 5, 1 Bit
   +0xfca ClonedThread     : Pos 6, 1 Bit
   +0xfca SuppressDebugMsg : Pos 7, 1 Bit
   +0xfca DisableUserStackWalk : Pos 8, 1 Bit
   +0xfca RtlExceptionAttached : Pos 9, 1 Bit
   +0xfca InitialThread    : Pos 10, 1 Bit
   +0xfca SessionAware     : Pos 11, 1 Bit
   +0xfca LoadOwner        : Pos 12, 1 Bit
   +0xfca LoaderWorker     : Pos 13, 1 Bit
   +0xfca SkipLoaderInit   : Pos 14, 1 Bit
   +0xfca SkipFileAPIBrokering : Pos 15, 1 Bit
   +0xfcc TxnScopeEnterCallback : Ptr32 Void
   +0xfd0 TxnScopeExitCallback : Ptr32 Void
   +0xfd4 TxnScopeContext  : Ptr32 Void
   +0xfd8 LockCount        : Uint4B
   +0xfdc WowTebOffset     : Int4B
   +0xfe0 ResourceRetValue : Ptr32 Void
   +0xfe4 ReservedForWdf   : Ptr32 Void
   +0xfe8 ReservedForCrt   : Uint8B
   +0xff0 EffectiveContainerId : _GUID
   +0x1000 LastSleepCounter : Uint8B
   +0x1008 SpinCallCount    : Uint4B
   +0x1010 ExtendedFeatureDisableMask : Uint8B

(b) PEB.NtTib 구조
TEB의 첫 번째 멤버인 `NtTib`의 구조이다. 물론 32bit PE에 쓰인다.

0:000> dt _NT_TIB
ntdll!_NT_TIB
   +0x000 ExceptionList    : Ptr32 _EXCEPTION_REGISTRATION_RECORD
   +0x004 StackBase        : Ptr32 Void
   +0x008 StackLimit       : Ptr32 Void
   +0x00c SubSystemTib     : Ptr32 Void
   +0x010 FiberData        : Ptr32 Void
   +0x010 Version          : Uint4B
   +0x014 ArbitraryUserPointer : Ptr32 Void
   +0x018 Self             : Ptr32 _NT_TIB

`ExceptionList` 멤버에 SEH Chain의 시작점이 저장된다.

(c) FS 레지스터로 SEH 접근하기
x86 usermode의 FS 레지스터는 `TEB` 의 시작 주소를 가리키고 있다. `NtTib`는 `TEB`의 첫 멤버, 그리고 `ExceptionList`는 `NtTib`의 첫 멤버이므로 `FS:[0]`을 통해 SEH Chain의 시작점에 접근할 수 있다.

FS:[0] == TEB.NtTib.ExceptionList
mov eax, dword ptr FS:[0x00] // eax: SEH Chain 시작 주소

x64 usermode에서는 `GS:[0x30]`에 `TEB`의 주소가 담겨있고, 마찬가지로 `GS:[0x60]`을 통해 `PEB`의 주소값을 얻을 수 있다만, 이런 방식의 예외 핸들링은 지원하지 않는 듯하다. (추가 조사 필요)

(d) SEH Chain에 Handler 추가하기
아래와 같은 일련의 명령어를 통해 SEH Chain의 Top에 새 핸들러를 추가할 수 있다.

push handler // Handler
push dword ptr FS:[0x00] // Next
mov dword ptr FS:[0x00], esp

`push handler`로 스택에 handler 함수의 주소가 저장되며, 뒤이은 `push dword ptr FS:[0x00]`으로 이전 SEH Chain의 시작점이 스택에 들어간다. 이로써 스택에 `_EXCEPTION_REGISTRATION_RECORD` 구조체가 자리잡는다. 마지막으로 `mov dword ptr FS:[0x00], esp` 명령어로 `TEB.NtTib.ExceptionList`에 새로운 `_EXCEPTION_REGISTRATION_RECORD` 구조체 주소를 저장한다. (이때 esp가 가리키는 주소에는 이전의 SEH Chain의 Top, 즉, 이전의 `FS:[0x00]` 값이 들어 있다.)

SEH Chain의 첫 `Handler` 콜백 함수의 주소는 아래와 같이 구할 수 있다.

mov eax, fs:[0x00] // stack 상의 SEH Chain 시작 주소
mov eax, [eax + 4] // SEH Chain의 시작점으로부터 4 떨어진 주소에 저장된 값 -> 핸들러 주소

(e) SEH 사용 예제
아래 코드는 직접 SEH Chain에 `handler()` 함수를 등록하고, Access Violation 예외를 발생시켜 `handler()`를 호출하게끔 한다.

// x86 debug, VS19
#include <Windows.h>
#include <stdio.h>

EXCEPTION_DISPOSITION 
_cdecl
handler(
EXCEPTION_RECORD* pRecord,
EXCEPTION_REGISTRATION_RECORD* pFrame,
CONTEXT* pContext,
PVOID pValue
) {
MessageBox(NULL,
L"Exception Occurred",
L"Exception Handler",
MB_ICONERROR);

pContext->Eip += 7;
printf("Exception Occurred at: %p\n", pRecord->ExceptionAddress);

return ExceptionContinueExecution;
}

int main() {
DWORD handlerAddr = 0;

__asm {
push handler
push dword ptr fs:[0x00]

mov dword ptr fs:[0x00], esp

mov eax, dword ptr fs:[0x00]
mov eax, dword ptr ds:[eax+4]
mov handlerAddr, eax 
// mov dword ptr [handlerAddr], eax 같은 표기도 동일하게 동작
}

printf("SEH handler is now set at  %p\n", (void*)handlerAddr);

__asm {
xor eax, eax
mov dword ptr ds:[eax], 1 // Exception 1: Access Violation
}

printf("Exception Successfully Handled\nContinue Execution...\n");

__asm {
xor eax, eax
mov dword ptr ds : [eax] , 1 // Exception 2: Access Violation
}

printf("Exception 2 Successfully Handled\nContinue Execution...\n");

__asm {
add esp, 8 
// SEH 설치하면서 두 번 push 했던 것 때문에 esp에 4*2 더해줘야 함.
// 안 그러면 잘못된 ESP 값 때문에 오류 발생. (__RTC_CheckEsp())
}
}

`handler()` 함수 내에서는 인자로 받은 `pContext->Eip`의 값을 7 증가시켜 예외 발생 코드를 건너 뜀으로써 예외를 처리한다.

위 코드를 x86 release mode로 컴파일하면 `mov dword ptr ds:[eax], 1` 부분에서 발생한 예외를 처리하기 위해 SEH Chain에 등록된 `handler()` 함수가 호출되는데, 이 호출 부분에서 또 한 번 예외가 발생한다. (STATUS_INVALID_EXCEPTION_HANDLER) 이는 Visual Studio의 release mode에서는 `/SAFESEH` 라는 링커 옵션을 기본적으로 활성화해놓기 때문이다. 프로젝트의 링커 옵션에서 `Image Has Safe Exception Handlers` 옵션을 끄고 컴파일한다면 의도한 동작을 하겠지만, SEH Overwrite 공격 등이 가능해진다. (물론 있어도 가능하다. 좀 복잡해질 뿐.)

자세한 건 [[WinPwn - SEH Overwrite]] 참고.

SafeSEH란, `Handler` 변수에 담긴 `__except_handler()`의 주소가 스택의 주소 범위에 포함될 때, 혹은 PE 헤더의 `IMAGE_LOAD_CONFIG_DIRECTORY`의 `SEHandlerTable` 값과 다를 때 이 핸들러를 호출하지 않는 기법이다. 위 코드를 release 모드로 컴파일한 경우 SafeSEH가 기본 적용되며, `handler()`의 주소가 `SEHandlerTable` 값과 달라 예외가 발생한 것이다.

(f) ntdll의 예외 핸들링 순서 (x86)
예외가 발생하면 다음과 같은 순으로 함수들이 실행된다.

ntdll!KiUserExceptionDispatcher()
ntdll!RtlDispatchException()
ntdll!RtlpExecuteHandlerForException()
ntdll!ExceptionHandler2()
SEH called here!

`ExceptionHandler2()` 함수의 어셈블리 코드는 아래와 같다.

77229CDC  | push ebp                                  |
77229CDD  | mov ebp,esp                               |
77229CDF  | push dword ptr ss:[ebp+C]                 |
77229CE2  | push edx                                  | edx: 77229D20
77229CE3  | push dword ptr fs:[0]                     |
77229CEA  | mov dword ptr fs:[0],esp                  |
77229CF1  | push dword ptr ss:[ebp+14]                |
77229CF4  | push dword ptr ss:[ebp+10]                |
77229CF7  | push dword ptr ss:[ebp+C]                 |
77229CFA  | push dword ptr ss:[ebp+8]                 |
77229CFD  | mov ecx,dword ptr ss:[ebp+18]             |
77229D00  | call ecx                                  | call _except_handler
77229D02  | mov esp,dword ptr fs:[0]                  |
77229D09  | pop dword ptr fs:[0]                      |
77229D10  | mov esp,ebp                               |
77229D12  | pop ebp                                   |
77229D13  | ret 14                                    |
77229D16  | lea esp,dword ptr ss:[esp]                | 
77229D1D  | lea ecx,dword ptr ds:[ecx]                |
77229D20  | mov ecx,dword ptr ss:[esp+4]              | SEH chain의 첫 노드로 삽입됨
77229D24  | test dword ptr ds:[ecx+4],6               |
77229D2B  | mov eax,1                                 |
77229D30  | jne ntdll.77229D44                        |
77229D32  | mov ecx,dword ptr ss:[esp+8]              |
77229D36  | mov edx,dword ptr ss:[esp+10]             | 
77229D3A  | 8mov eax,dword ptr ds:[ecx+8]             |
77229D3D  | mov dword ptr ds:[edx],eax                | 
77229D3F  | mov eax,2                                 |
77229D44  | ret 10                                    |
77229D47  | lea esp,dword ptr ss:[esp]                | 
77229D4E  | mov edi,edi                               |
77229D50  | mov ecx,dword ptr ss:[esp+4]              |
77229D54  | test dword ptr ds:[ecx+4],6               |
77229D5B  | mov eax,1                                 |
77229D60  | je ntdll.77229D74                         |
77229D62  | mov ecx,dword ptr ss:[esp+8]              |
77229D66  | mov edx,dword ptr ss:[esp+10]             | 
77229D6A  | mov eax,dword ptr ds:[ecx+8]              |
77229D6D  | mov dword ptr ds:[edx],eax                | 
77229D6F  | mov eax,3                                 |
77229D74  | ret 10                                    |

이 함수의 시작 부분에서 `push ebp -> push fs:[0] -> mov fs:[0], esp`를 통해 SEH Chain의 시작 지점에 ntdll 영역의 주소를 예외 핸들러의 주소로 포함한 새 노드를 연결한다. 예외 처리기에서 예외가 발생할 경우 처리를 위한 것이고, 새로 등록된 핸들러의 코드는 다음과 같다. 이 역시 handler callback function의 구조를 따른다.

77229D20  | mov ecx,dword ptr ss:[esp+4]         | pRecord
77229D24  | test dword ptr ds:[ecx+4],6          | pRecord->ExceptionFlag와 6을 비교
77229D2B  | mov eax,1                            | ExceptionContinueExecution
77229D30  | jne ntdll.77229D44                   | return
77229D32  | mov ecx,dword ptr ss:[esp+8]         | pFrame
77229D36  | mov edx,dword ptr ss:[esp+10]        | 4th param, DispatcherContext
77229D3A  | mov eax,dword ptr ds:[ecx+8]         | 이거 호출 전 SEH 노드의 Frame 주소
77229D3D  | mov dword ptr ds:[edx],eax           | 
77229D3F  | mov eax,2                            | ExceptionNestedException
77229D44  | ret 10                               |

이 콜백 함수는 예외 처리 중 예외가 발생할 경우 호출된다. 이 함수가 호출되었을 때의 `pRecord->ExceptionFlags` 값과 6을 and 연산한 값이 0이 아니라면 `ExceptionNestedException`을 반환한다. (사실상 `ExceptionFlags`가 `EXCEPTION_UNWINDING(0x02)`, `EXCEPTION_EXIT_UNWIND(0x04)` 가 아니라면 모두 `ExceptionNestedException`을 반환하게 된다.)

이 예외 처리 함수가 반환한 값은 `RtlDispatchException()`으로 그대로 전달된다. 이 함수는 내부적으로 호출하는 `RtlpExecuteHandlerForException()` 함수의 반환 값에 따라서 예외를 해제하는 경우에는 `DISPOSION_DISMISS`를, 예외 캡슐화 처리기 수준까지 예외를 전달해야 하는 경우에는 `DISPOSION_CONTINUE_SEARCH`와 같은 결과를 반환한다. [__except_handler3](https://learn.microsoft.com/ko-kr/cpp/c-runtime-library/except-handler3?view=msvc-170)

유저 모드 예외 처리의 가장 바깥쪽에서 호출되는 함수는 `KiUserExceptionDispatcher()`이다. 예외가 발생하고 커널에서 이를 인지한 뒤 유저모드로 복귀할 때 이 함수가 실행된다. 이 함수는 커널에서 호출될 때 `ExceptionRecord`와 `Context`를 인자로 받는다. `KiUserExceptionDispatcher()`는 내부적으로 `RtlDispatchException()` 함수를 실행하는데, 이의 반환 값에 따라 `NtContinue()`로 예외 발생 코드부터 실행되거나(`DISPOSITION_DISMISS`의 경우) `NtRaiseException()`으로 예외를 다시 발생시켜(`DISPOSITION_CONTINUE_SEARCH`의 경우) 디버거/윈도우의 예외 핸들러를 찾기도 한다. `NtContinue()`를 호출하는 경우 인자로 `Context`를 넘겨주는데, `NtContinue()`는 `Context` 구조체의 시작 지점으로부터 0xB8 오프셋만큼 떨어진 곳에 위치한 멤버인 `pContext->Eip`를 보고 실행을 재개할 위치를 판단한다.

여기까지는 어셈블리어 수준에서 SEH를 만들었을 때의 이야기고, Windows에서 제공하는 `__try{}__except(){}` 문을 이용한 SEH는 custom handler 함수가 아니라 `__exception_handler3()`가 호출된다. (그렇지만 역시 `FS:[0]`에 이를 등록해놓고 사용한다.) 이 때에는 Scope Table과 TryLevel이 존재한다. (이건 잘 모르겠으니 검색 ㄱㄱ)

VC++에서 /GS 옵션을 활성화하고 컴파일하면 `__except_handler3()` 대신 `__except_handler4()`가 호출되는데, 이는 TryLevel 초깃값이 `0xFFFFFFFE`라는 것과 Stack cookie 검사를 한다는 것 외에는 `__except_handler3()`과 딱히 다른 점이 없다.

2) kernel32!SetUnhandledExceptionFilter()

SEH에서 예외가 처리되지 않았거나 등록된 SEH가 없을 경우 kernel32!UnhandledExceptionFilter() API가 호출된다. kernel32!UnhandledExceptionFilter() 함수에서는 Top Level Exception Filter라는 시스템의 마지막 예외 처리기를 실행해, '작동이 중지되었습니다' 경고 창을 띄우고 프로세스를 종료한다. 이 함수에서는 내부적으로 ntdll!NtQueryInformationProcess(ProcessDebugPort) API를 호출하여 디버깅 여부를 판단, 디버깅 중이라면 디버거에 제어권을 넘기고, 디버깅 중이 아니라면 시스템 예외 처리기에 전달한다.

kernel32!SetUnhandledExceptionFilter() 함수를 통해 시스템의 Top Level Exception Filter를 변경할 수 있다. 이 함수의 원형은 아래와 같다.

LPTOP_LEVEL_EXCEPTION_FILTER SetUnhandledExceptionFilter( 
[in] LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter 
);

[Microsoft: SetUnhandledExceptionFilter function (errhandlingapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-setunhandledexceptionfilter)
`lpTopLevelExceptionFilter` 인자에 새로 등록할 Top Level Exception Filter의 함수 주소를 넘겨주면 된다. 반환 값은 이전의 Top Level Exception Filter 함수 주소. (없다면 NULL.)

프로세스에서 고의로 예외를 발생시키고 사용자 정의 Top Level Exception Filter를 통해 EIP 값을 올바르게 수정하면, 디버깅 실행 시에는 예외가 디버거에서 처리될 수 없으므로 종료되지만, 디버깅 중이 아닐 때에는 예외가 Top Level Exception Filter에 전달되어 처리되므로 정상 실행이 가능하다.

#### (1) `SetUnhandledExceptionFilter()` 사용 예제
아래와 같이 코드를 작성할 수 있다.

// x86 debug, VS19
#include <stdio.h>
#include <Windows.h>
#include <errhandlingapi.h>

LONG WINAPI handler(PEXCEPTION_POINTERS ExceptionInfo) {
MessageBox(NULL,
L"Handler called!",
L"Exception Handler",
MB_ICONERROR);

ExceptionInfo->ContextRecord->Eip += 7;
printf("Exception at %p\n", ExceptionInfo->ExceptionRecord->ExceptionAddress);

return EXCEPTION_CONTINUE_EXECUTION;
}

int main() {
SetUnhandledExceptionFilter(handler);

__asm {
xor eax, eax
mov dword ptr ds:[eax], 1 // Exception: Access Violation
}

printf("Exception Successfully Handled!\nContinue Execution... \n");

}

인자로 받은 `EXCEPTION_POINTERS` 구조체 포인터의 `->ContextRecord->Eip`의 값을 직접 수정해 예외 발생 코드를 건너뛰는 방식으로 예외를 처리하는 `handler()` 함수를 구현하였다.

위 코드를 디버거에서 실행하면 `mov dword ptr ds:[eax], 1` 명령에서 예외가 발생하고, 디버거가 예외를 처리하지 못하여 디버깅이 중지된다.

x64 환경에서는 아래와 같이, `Eip` 대신 `Rip` 멤버를 수정해야 한다.

//x64 debug, VS19
#include <stdio.h>
#include <Windows.h>
#include <errhandlingapi.h>

LONG WINAPI handler(PEXCEPTION_POINTERS ExceptionInfo) {
MessageBox(NULL,
L"Handler called!",
L"Exception Handler",
MB_ICONERROR);

ExceptionInfo->ContextRecord->Rip += 6;
printf("Exception at %p\n", ExceptionInfo->ExceptionRecord->ExceptionAddress);

return EXCEPTION_CONTINUE_EXECUTION;
}

int main() {
SetUnhandledExceptionFilter(handler);

int zero = 0;
int value = 3;
value = value / zero; // Exception: Division by 0

printf("Exception Successfully Handled!\nContinue Execution... \n");

}

### 3) 우회
그냥 실행시킨 뒤 예외 발생 지점을 지나 debugger를 attach하거나, `Shift+F7/F8/F9` 등의 키를 통해 `StepIn/StepOver/Run` 시 예외 처리를 debugee에게 넘기거나 하면 된다. 예외 처리기를 디버깅하고 싶으면 SEH Chain 등록 부분에서 push하는 주소 (일반화하자면 x86기준 `fs:[0]`에 옮겨지는 esp에 4를 더한 주소에 저장된 값)를 살펴보고 그 주소의 코드에 breakpoint를 걸면 되고, `SetUnhandledExceptionFilter()`를 이용한 경우에도 인자로 들어가는 `handler` 함수의 시작 지점에 bp를 설치하면 된다. (물론 `Shift+F7/F8/F9`로 실행해야 이 핸들러가 제대로 호출된다.)
(x64dbg에서는 이를 erun/ego 등으로 부르며, first change exception을 debuggee에 넘겨 처리한다. Swallow exception and run은 `Ctrl+Alt+Shift+F7/F8/F9`이다.)

## 2. Software Breakpoint Detection
프로세스는 메모리를 검사함으로써 debugger의 존재를 알 수 있다. Debugger는 실행을 멈추고자 하는 instruction의 첫 1바이트를 0xCC (INT3)으로 패치하여 software breakpoint를 구현한다. 이 점을 이용하여 코드 영역의 메모리를 검사함으로써 software bp가 적용되었는지 판단하고 안티디버깅 루틴을 적용할 수 있다.

###### +TODO!("undefined instruction(0f 0b)를 사용해 software bp를 구현하는 경우도 있으므로 이것을 cover할만한 구현체도 필요")

아래는 software bp를 탐지하는 C++ 코드이다.

#include <Windows.h>
#include <wtypes.h>
#include <WinDNS.h>

#include <stdio.h>

BOOL checkByte(BYTE, PVOID, SIZE_T);
BOOL checkBP(PVOID, SIZE_T);
BOOL isJmpTable(PVOID);

int critical() {
printf("This function is critical!\n");
return 0;
}

int main() {
BOOL flag = checkBP((PVOID)critical, 0x50);

if (flag) {
printf("Software BP detected.\n");
}
else {
printf("Software BP not detected.\n");
}
}

BOOL checkByte(BYTE bByte, PVOID pMem, SIZE_T nSize = 0) {
PBYTE bMem = (PBYTE)pMem;

for (SIZE_T i = 0; i < nSize; i++) {
if (*(bMem + i) == 0xC3) {
break;
}

if (*(bMem + i) == bByte) {
return 1;
}
}

return 0;
}

BOOL checkBP(PVOID pMem, SIZE_T n) {
BOOL result = 0;

if (isJmpTable(pMem)) {
DWORD dwOffset = *(DWORD*)((PBYTE)pMem + 1) + 5; // 5: size of 1 complete jmp instruction (with operand)
PVOID pFunc = (PBYTE)pMem + dwOffset;

result = checkByte(0xCC, pFunc, n);
} else {
result = checkByte(0xCC, pMem, n); // when using real addr of function
}

return result;

/* [false positives]
- EncStackInitStart : 
moves 0xCCCCCCCC to [edi] <- mov eax, 0xCCCCCCCC; rep stosd; (only x86)
- 0xCC as data : 
some offset/data can include 0xCC 
(how to detect them, then? -> needs to disassemble the function (WTF))

[false negatives]
- ret (0xC3) in the middle of the function

[shortcomings]
- Detecting function scope with just using machine code

Debugger inserts 0xCC to the start of the instruction to stop at. -> Then, increase index by the size of instruction (WTF2)
*/
}

BOOL isJmpTable(PVOID pMem) {
int i = 0, j = 0;

while (*((PBYTE)pMem + 5 * i) == 0xE9) { // if pattern is `jmp rel32`
i++;
}

while (*((PBYTE)pMem - 5 * j) == 0xE9) {
j++;
}

if (i + j > 0x10) { // false negative: small jmp tables
return 1;
} else {
return 0;
}
}

함수 자체가 high level의 개념이기 때문에 기계어 코드만 갖고 판단하기에는 한계가 있다. 함수의 주소로부터 정해진 바이트 수만큼 읽고 검사하도록 구현할수도, `ret`까지만 읽고 검사하도록 구현할 수도 있지만 (역시 리버서 마음대로) 여기서는 최대 주어진 길이까지 읽되 `ret` 명령을 만나면 검사를 종료하도록 만들었다. (사용자가 함수의 실제 크기를 모르며, 함수의 크기보다 더 큰 값을 인자로 넣을 것을 가정.)

msvc로 컴파일하니 함수 호출 시 jmp table을 만들어 주고, 함수(주소)를 인자로 전달할 때에도 이 jmp table의 주소를 넣어준다. 이 때문에 함수의 메모리 영역에서 software bp의 유무를 검사하고 싶다면 jmp table에 위치하는 jmp instruction의 인자 (offset)와 jmp instruction 하나의 크기인 5byte를 인자로 주어진 주소에 더하면 된다. 이와 같은 기능을 수행하는 코드는 `checkBP()` 안에 위치한다.

DWORD dwOffset = *(DWORD*)((PBYTE)pMem + 1) + 5;
PVOID pFunc = (PBYTE)pMem + dwOffset;

물론 이 경우도 내 환경에 specific한 구현이기 때문에 쓰실 때에는 본인 환경에 맞춰 잘 구성해 쓰시면 되겠다. 인자로 전달된 함수의 주소가 jmp table의 주소인지를 판단하기 위해 `isJmpTable()`이라는 함수를 작성해 놓았는데, 앞 뒤로 jmp 명령어의 개수를 세서 이 값이 특정 값 이상이라면 jmp table로 판단한다. (휴리스틱에 의존)

구현이 단순할수록 false positive가 많아지는 방법이므로 기계어 코드를 instruction 단위로 처리할 것이 아니라면 사용하는 것을 추천하지 않는다. false positive의 한 예시로, msvc x86 debug mode로 컴파일하면 기본 `/RTC` 옵션이 추가되어 아래와 비슷한 어셈블리어 코드가 추가된다. (uninitialized stack memory를 구별하기 위함)
```asm
mov edi, ebp
mov eax, 0xCCCCCCCC
rep stosd
```
`checkByte()`는 위 코드의 데이터로 들어간 0xCC 바이트를 읽고 software bp라 판단하여 true를 반환한다. 데이터와 코드를 정교하게 구분하려면 인자로 받은 함수의 코드를 instruction 단위로 처리하여야 하며, 이 방식은 함수 내에서 명령어의 중간으로 jmp하는 경우 불완전한 결과를 낼 수 있다.

###### + TODO!("x86 release, x86-64 debug-release 모드에 대한 software bp detection code 작성 for msvc & gcc"), 간단하게 설명이라도..

## 3. Hardware Breakpoint Detection
Hardware breakpoint는 thread의 debug register에 실행을 멈추고자 하는 주소를 넣는 방식으로 사용할 수 있다. Hardware bp는 thread 내에서 Dr0~Dr3에 저장된 주소에 접근/쓰기/실행 등의 이벤트가 발생할 때 single step interrupt (INT1)를 트리거한다. (Hardware bp mechanism이 현재 실행되는 명령의 주소를 계속해서 확인함) Hardware bp에 의해 INT1 이벤트가 발생하면, JTAG module이 프로세서의 제어권을 가져간다. Software breakpoint와 다르게 hardware breakpoint는 아키텍처에 의존적이므로, cpu 설계에 따라 작동 방식이 다를 수 있다. 본 문서에서는 Intel x86을 기준으로 설명할 것이다.

### 1) Debug Registers
Intel x86에는 총 7개의 debug register가 존재한다. (Dr0 ~ Dr7). winnt.h 헤더 파일에 정의되어 있는 `CONTEXT` 구조체의 Dr0 ~ Dr7이 바로 debug register이다. 아래는 `CONTEXT` 구조체의 원형. winnt.h에 주석으로 설명이 잘 되어있다.

typedef struct DECLSPEC_NOINITALL _CONTEXT {
    DWORD ContextFlags;

    DWORD   Dr0;
    DWORD   Dr1;
    DWORD   Dr2;
    DWORD   Dr3;
    DWORD   Dr6;
    DWORD   Dr7;

    FLOATING_SAVE_AREA FloatSave;
    
    DWORD   SegGs;
    DWORD   SegFs;
    DWORD   SegEs;
    DWORD   SegDs;
    
    DWORD   Edi;
    DWORD   Esi;
    DWORD   Ebx;
    DWORD   Edx;
    DWORD   Ecx;
    DWORD   Eax;

    DWORD   Ebp;
    DWORD   Eip;
    DWORD   SegCs;
    DWORD   EFlags;
    DWORD   Esp;
    DWORD   SegSs;

    BYTE    ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];

} CONTEXT;

Dr0~Dr3 레지스터에는 hardware bp를 설정할 선형 주소(linear address)가 저장된다. Dr6에는 비트 단위로 debug status가 저장되는데, 이는 debug exception handler로 제어권이 넘어가기 전에 설정된다. Dr6의 각 비트가 의미하는 바는 아래와 같다.

###### +TODO!("아래 표 정리")

| Bits | Abbreviation | Description |
| ----- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 0 | B0 | Breakpoint #0 (Dr0) Condition Detected |
| 1 | B1 | Breakpoint #1 (Dr1) Condition Detected |
| 2 | B2 | Breakpoint #2 (Dr2) Condition Detected |
| 3 | B3 | Breakpoint #3 (Dr3) Condition Detected |
| 10:4 | — | Reserved. Read as all-0s on 386/486 processors, all-1s on later processors. |
| 11 | BLD | Cleared to 0 by the processor for Bus Lock Trap exceptions. On processors that don't support Bus Lock Trap exceptions, bit 11 of DR6 is a read-only bit, acting in the same way as bits 10:4. |
| 12 | BK, SMMS | (386/486 only) SMM or ICE mode entered (see also DR7, bit 12). Reserved and read as 0 on all later processors. |
| 13 | BD | Debug Register Access Detected (see also DR7, bit 13). (Never cleared by hardware - manually cleaning this bits in debug handler is recommended) |
| 14 | BS | Single-Step execution (enabled by EFLAGS.TF) (Never cleared by hardware - manually cleaning this bits in debug handler is recommended)(Never cleared by hardware - manually cleaning this bits in debug handler is recommended) |
| 15 | BT | Task Switch breakpoint. Occurs when a task switch is done with a [TSS](https://en.wikipedia.org/wiki/Task_state_segment "Task state segment") that has the T (debug trap flag) bit set. (Never cleared by hardware - manually cleaning this bits in debug handler is recommended) |
| 16 | RTM | (Processors with [Intel TSX](https://en.wikipedia.org/wiki/Intel_TSX "Intel TSX") only) Cleared to 0 by the processor for debug exceptions inside RTM transactions, set to 1 for all debug exceptions outside transactions. On processors without TSX, bit 16 of DR6 is a read-only bit, acting in the same way as bits 31:17. |
| 31:17 | — | Reserved. Read as all-0s on 386/486/6x86 processors, all-1s on later processors. |
| 63:32 | — | (x86-64 only) Reserved. Read as all-0s. Must be written as all-0s. |
(출처: [Wikipedia - x86 debug register](https://en.wikipedia.org/wiki/X86_debug_register))

Dr7은 debug control register로, 각 비트는 각 hardware bp에 대한 중단 조건을 표현하는 데에 사용된다. 각 비트 필드의 의미는 아래와 같다.

| Bits | Abbreviation | Description |
| ----- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 0 | L0 | Local enable for breakpoint #0. |
| 1 | G0 | Global enable for breakpoint #0. |
| 2 | L1 | Local enable for breakpoint #1. |
| 3 | G1 | Global enable for breakpoint #1. |
| 4 | L2 | Local enable for breakpoint #2. |
| 5 | G2 | Global enable for breakpoint #2. |
| 6 | L3 | Local enable for breakpoint #3. |
| 7 | G3 | Global enable for breakpoint #3. |
| 8 | LE | (386 only) Local Exact Breakpoint Enable. |
| 9 | GE | (386 only) Global Exact Breakpoint Enable. |
| 10 | — | Reserved, read-only, read as 1 and should be written as 1. |
| 11 | RTM | (Processors with [Intel TSX](https://en.wikipedia.org/wiki/Intel_TSX "Intel TSX") only) Enable advanced debugging of RTM transactions (only if `DEBUGCTL` bit 15 is also set) On other processors: reserved, read-only, read as 0 and should be written as 0. |
| 12 | IR, SMIE | (386/486 processors only) Action on breakpoint match: 0 = INT 1 (#DB exception, default) 1 = Break to ICE/SMM On other processors: Reserved, read-only, read as 0 and should be written as 0. |
| 13 | GD | General Detect Enable. If set, will cause a debug exception on any attempt at accessing the DR0-DR7 registers. |
| 15:14 | — | Reserved, should be written as all-0s. |
| 17:16 | R/W0 | Breakpoint condition for breakpoint #0. |
| 19:18 | LEN0 | Breakpoint length for breakpoint #0. |
| 21:20 | R/W1 | Breakpoint condition for breakpoint #1. |
| 23:22 | LEN1 | Breakpoint length for breakpoint #1. |
| 25:24 | R/W2 | Breakpoint condition for breakpoint #2. |
| 27:26 | LEN2 | Breakpoint length for breakpoint #2. |
| 29:28 | R/W3 | Breakpoint condition for breakpoint #3. |
| 31:30 | LEN3 | Breakpoint length for breakpoint #3. |
| 32 | DR0_PT_LOG | Enable DR0/1/2/3 breakpoint match as a trigger input for PTTT (Processor Trace Trigger Tracing). Read as 0 and must be written as all-0s on processors that don't support PTTT. |
| 33 | DR1_PT_LOG | " |
| 34 | DR2_PT_LOG | " |
| 35 | DR3_PT_LOG | " |
| 63:36 | — | (x86-64 only) Reserved. Read as all-0s. Must be written as all-0s. |

Breakpoint condition representation in bits:

|Value|Break on|
|---|---|
|`00b`|Instruction execution only|
|`01b`|Data writes only|
|`10b`|I/O reads and writes (only defined if [CR4.DE](https://en.wikipedia.org/wiki/Control_register#CR4 "Control register")=1)|
|`11b`|Data reads and writes|

Breakpoint length representation in bits:

|Value|Breakpoint length|
|---|---|
|`00b`|1 byte|
|`01b`|2 bytes|
|`10b`|8 bytes (only defined in 64-bit mode)|
|`11b`|4 bytes|

Dr4와 Dr5는 실제 레지스터가 아니다. CR4.DE bit을 지원하는 CPU (Intel Pentium 이후)에서 Dr4/5의 행동은 CR4.DE에 의해 다음과 같이 정의된다.
CR4.DE = 0: Dr4와 Dr5는 Dr6, Dr7의 alias다.
CR4.DE = 1: Dr4/5에 접근하는 것은 UD (undefined instruction) exception을 발생시킨다.

Debug register는 한정된 자원이기 때문에 debug register에 값을 쓰는 경우, ring 0 (kernel mode)의 권한이 필요하다. (낮은 권한에서 debug register에 접근 시 general protection fault 발생)
#### (1) GetThreadContext()
##### (a) GetThreadContext() Example
Windows가 제공하는 `GetThreadContext()` API를 사용해서 thread의 context를 얻어올 수 있다. Context에 포함된 debug register를 확인하여 hardware breakpoint가 설정되었는지 파악할 수 있다.

아래는 thread의 context를 받아와 읽는 C 코드이다.

// x86 debug, VS19
#include <stdio.h>
#include <Windows.h>
#include <errhandlingapi.h>

int main() {
CONTEXT ctx;

DWORD threadId = GetCurrentThreadId();
HANDLE hThread = OpenThread(THREAD_GET_CONTEXT, FALSE, threadId);

DWORD e = GetLastError();
if(e) {
printf("error info: 0x%x\n", e);
}

printf("ThreadId: %x\n", threadId);
printf("hThread: %p\n", hThread);

// ContextFlags를 먼저 설정 안 해주면 0x3eb 오류 발생
ctx.ContextFlags = CONTEXT_ALL;

if (GetThreadContext(hThread, &ctx) != 0) {
printf("\n");

printf("[registers]\n");
printf("Eip: 0x%08x\n", ctx.Eip);
printf("Ebp: 0x%08x\n", ctx.Ebp);
printf("Esp: 0x%08x\n", ctx.Esp);
printf("Eax: 0x%08x\n\n", ctx.Eax);

printf("[debug registers]\n");
printf("Dr0: 0x%08x\n", ctx.Dr0);
printf("Dr1: 0x%08x\n", ctx.Dr1);
printf("Dr2: 0x%08x\n", ctx.Dr2);
printf("Dr3: 0x%08x\n", ctx.Dr3);
printf("Dr6: 0x%08x\n", ctx.Dr6);
printf("Dr7: 0x%08x\n", ctx.Dr7);

} else {
printf("failed to get the context\n");
e = GetLastError();
printf("error info: 0x%x\n", e);
}

}

`GetThreadId()`로 현재 thread의 ID를 얻어온 다음, `OpenThread()`로 이 thread에 대해 `THREAD_GET_CONTEXT` 권한을 가진 핸들을 받아온다. `GetThreadContext()`를 호출하기 전에, `CONTEXT` 구조체의 `ContextFlags` 멤버를 수정해야 한다. (`GetThreadContext()`는 `Context.ContextFlags` 멤버를 읽고 context에 저장해야 할 부분을 판단하기 때문.) 이 예제에서는 단순히 context 정보 전체를 받아오기 위해 `CONTEXT_ALL`을 사용하였으나, debug register만 얻어오기 위해서는 `CONTEXT_DEBUG_REGISTERS`를 사용할 수 있다.
###### (a-1) CONTEXT.ContextFlags 값
ContextFlags에는 다음과 같은 상수 값들이 올 수 있다. (winnt.h 참고)

#define CONTEXT_CONTROL         (CONTEXT_i386 | 0x00000001L) // SS:SP, CS:IP, FLAGS, BP
#define CONTEXT_INTEGER         (CONTEXT_i386 | 0x00000002L) // AX, BX, CX, DX, SI, DI
#define CONTEXT_SEGMENTS        (CONTEXT_i386 | 0x00000004L) // DS, ES, FS, GS
#define CONTEXT_FLOATING_POINT  (CONTEXT_i386 | 0x00000008L) // 387 state
#define CONTEXT_DEBUG_REGISTERS (CONTEXT_i386 | 0x00000010L) // DB 0-3,6,7
#define CONTEXT_EXTENDED_REGISTERS  (CONTEXT_i386 | 0x00000020L) // cpu specific extensions

#define CONTEXT_FULL (CONTEXT_CONTROL | CONTEXT_INTEGER | CONTEXT_SEGMENTS)

#define CONTEXT_ALL            (CONTEXT_CONTROL | CONTEXT_INTEGER | CONTEXT_SEGMENTS | CONTEXT_FLOATING_POINT | CONTEXT_DEBUG_REGISTERS | CONTEXT_EXTENDED_REGISTERS)

#define CONTEXT_XSTATE          (CONTEXT_i386 | 0x00000040L)

#define CONTEXT_EXCEPTION_ACTIVE    0x08000000L
#define CONTEXT_SERVICE_ACTIVE      0x10000000L
#define CONTEXT_EXCEPTION_REQUEST   0x40000000L
#define CONTEXT_EXCEPTION_REPORTING 0x80000000L

`Context.ContextFlags`를 설정했으면, `GetThreadContext()`를 호출하여 context를 받아온다. 그 뒤에 context의 각 멤버에 접근하여 어떤 값이 저장되었는지 확인할 수 있다.

debugger를 붙여 hardware bp를 설정하고 프로그램을 실행하여 결과를 확인해보길 바란다.

ThreadId: 54a0
hThread: 00000140

[registers]
Eip: 0x77637b0c
Ebp: 0x0133f71c
Esp: 0x0133f710
Eax: 0x00000000

[debug registers]
Dr0: 0x00191994
Dr1: 0x00195607
Dr2: 0x00000000
Dr3: 0x00000000
Dr6: 0xffff0ff0
Dr7: 0x00000005

디버거를 붙여 실행하면 위와 같이 설정된 hardware bp를 확인할 수 있다.
이제 이 정보를 읽어서 anti-debugging에 적용해보자.
##### (b) Anti-debugging with GetThreadContext()
간단히 Dr0 ~ Dr3에 0이 아닌 값이 들어있는지를 확인하여 프로그램을 종료시키는 등의 작업을 할 수 있다. 아래의 코드는 hardware breakpoint check를 수행하고 그 결과를 출력한다.

// x86 debug, VS19
#include <stdio.h>
#include <Windows.h>
#include <errhandlingapi.h>

int main() {
CONTEXT ctx;

DWORD threadId = GetCurrentThreadId();
HANDLE hThread = OpenThread(THREAD_GET_CONTEXT, FALSE, threadId);

ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS;

if (GetThreadContext(hThread, &ctx) != 0) {
if ((ctx.Dr0 | ctx.Dr1 | ctx.Dr2 | ctx.Dr3) != 0) {
printf("Hardware breakpoint detected.\n");
} else {
printf("Hardware breakpoint not detected.\n");
}

}
else {
printf("failed to get the context\n");
DWORD e = GetLastError();
printf("error info: 0x%x\n", e);
}

}

직접 디버깅해보며 판단하길 바란다.

#### (2) Set SEH to check debug registers

## 4. Single Step Check
### 1) Trap Flag (TF)
### 2) PUSHFD/POPFD
### 3) INT 2D

## 5. Timing Check
### 1) RDTSC
### 2) QueryPerformanceCount()
### 3) GetTickCount()
### 4) timeGetTime()
#### (1) \_ftime()

## 6. Patching Detection
### 1) Scanning 0xCC
### 2) Checksum

## 7. Anti-Disassembly
### 1) Jump Over Invalid Bytes
### 2) Instruction Nesting
## 8. PE Image Switching

## 9. Self-Execution

## 10. Self-Debugging

## 11. Nanomite

## 12. Code Obfuscation

## 13. Encryption/Decryption

## 14. Stolen Bytes

## 15. Multi-Threaded Packers

## 16. Code Virtualization

## 17. API Redirection

## 18. API Wrapping

## 19. ptrace (linux)

## 20. Platform-Independent Program (PIP)

## 21. Execution-based Steganography
# Static Anti-Reversing Techniques
## 1. PEB
### 1) PEB.BeingDebugged (PEB + 0x02)
### 2) PEB.Ldr (PEB + 0x0C)

### 3) PEB.ProcessHeap (PEB + 0x18)
#### (1) SegmentFlags (\_Heap + 0x0C)
#### (2) SegmentListEntry (\_Heap + 0x10)

#### (3) Flags (\_Heap + 0x40)

#### (4) ForceFlags (\_Heap + 0x44)

### 4) NtGlobalFlag (PEB + 0x68)

## 2. TEB

## 3. Native APIs
### 1) ntdll!NtQueryInformationProcess(), ntdll!ZwQueryInformationProcess()

### 2) ntdll!NtQuerySystemInformation()

### 3) ntdll!NtQueryObject()

### 4) SeDebugPrivilege()

## 4. TLS callback function

## 5. Using Normal APIs
### 1) FindWindow(), FindWindowEx() (Window Name)

### 2) Process32First(), Process32Next() (Parent Process)

# Attacking Debugger
## 1. ntdll!NtSetInformationThread(), ntdll!ZwSetInformationThread()

## 2. user32!BlockInput()

## 3. Disable breakpoints

## 4. kernel32!UnhandledExceptionFilter()

## 5. Exploit Format String Vulns in debugger

## 6. Set

귀찮아서 아직 업데이트 안 한 글들이 산더미입니다. 안티 리버싱 기법 중에는 재미있는 것이 아주 많으니 한 번씩 실험해보세요.

개인 옵시디언에 마크다운 형식으로 정리했던 것들이라 html 환경에서는 가독성이 좀 떨어집니다.

아마 2025년이 끝날 즈음에는 완성되어 있지 않을까... 라고 생각됩니다.

현재글안티 리버싱 핵심원리

가끔 해킹합니다. 곧 이전 예정이니 https://cyalu.me 로 오세요 (비정상영업중)

BB84, 웹해킹, 문제풀이, 써니나타스, 드림핵, 리버싱, HackThisSite, rev-basic, Delphi, wargame, CodeEngn, Dreamhack, Reverse Engineering, reversing, wargame.kr, 양자키분배, suninatas, webhacking.kr, 양자암호, 안티리버싱,

Github
Twitter

Today :
Yesterday :

👾