Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

C# - 디버깅 중인 프로세스를 강제로 다른 디버거에서 연결하는 방법

윈도우 운영체제의 경우 특정 프로세스에 디버거는 하나만 연결이 됩니다. (또는, 배타적으로 다른 디버거가 연결할 수는 있습니다.) 그래서 다음 글에서 설명하는 것과 같은,

Debug Blocker
; https://kblab.tistory.com/311

디버깅 방해가 가능한 것입니다. 그런데, 이때 디버거와의 통신을 위해 debuggee 측에서는 특별하게 "DebugPort"를 열게 되는데요, 바로 이 값이 "EPROCESS" 구조체에 DebugPort라는 필드에 저장되어 있습니다.

0:006> dt _EPROCESS
ntdll!_EPROCESS
   +0x000 Pcb              : _KPROCESS
   +0x2e0 ProcessLock      : _EX_PUSH_LOCK
   +0x2e8 UniqueProcessId  : Ptr64 Void
   +0x2f0 ActiveProcessLinks : _LIST_ENTRY
   +0x300 RundownProtect   : _EX_RUNDOWN_REF
...[생략]...
   +0x418 ObjectTable      : Ptr64 _HANDLE_TABLE
   +0x420 DebugPort        : Ptr64 Void
   +0x428 WoW64Process     : Ptr64 _EWOW64PROCESS
...[생략]...
   +0x868 ParentSecurityDomain : Uint8B
   +0x870 CoverageSamplerContext : Ptr64 Void
   +0x878 MmHotPatchContext : Ptr64 Void

그런데 아래의 문서를 보면,

Anti Revering Techniques [zer0day].pdf
; http://cfile7.uf.tistory.com/attach/21611F5057EC7DCD2FC7C8

이 기법은 간단하게 말하면 자기 자신은 디버깅 하는 기법으로, 자식 프로세스를 만들고 그 프로세스가 부모 프로세스를 디버깅 하는 방식으로 이뤄진다. 한번에 한 프로세스를 디버깅 할 수 있는 사실을 이용해 외부 디버거가 디버깅을 하지 못하게 할 수 있는 좋은 기법 중 하나다. 하지만 이 기법의 단점은 EPROCESS 구조체의 DebugPort 값을 0 으로 설정을 하면 우회가 가능하다.


그냥 DebugPort를 덮어쓰면 된다고 나옵니다. 어디 직접 한 번 해볼까요? ^^




아쉽게도 EPROCESS 영역은 커널 메모리라서 KernelMemoryIO 드라이버의 힘을 빌려야 합니다.

C# - KernelMemoryIO 드라이버를 이용해 실행 프로그램을 숨기는 방법(DKOM: Direct Kernel Object Modification)
; https://www.sysnet.pe.kr/2/0/12111

이것을 이용하면 다음과 같이 간단하게 DebugPort 필드의 값을 읽을 수 있습니다.

// Install-Package KernelStructOffset

using (KernelMemoryIO memoryIO = new KernelMemoryIO())
{
    if (memoryIO.IsInitialized == false)
    {
        Console.WriteLine("Failed to open device");
        return;
    }

    Console.WriteLine($"Cid offset: {ethreadOffset["Cid"]:x}");

    // Check that access is valid
    {
        IntPtr clientIdPtr = ethreadOffset.GetPointer(ethreadPtr, "Cid"); // windows 10 1909 == 0x648;
        _CLIENT_ID cid = memoryIO.ReadMemory<_CLIENT_ID>(clientIdPtr);

        if (cid.Pid != processId)
        {
            Console.WriteLine($"PID: {cid.Pid} ({cid.Pid:x})");
            Console.WriteLine("Invalid access");
        }
    }

    IntPtr processPtr = kthreadOffset.GetPointer(ethreadPtr, "Process");
    IntPtr eprocessPtr = memoryIO.ReadMemory<IntPtr>(processPtr);

    IntPtr debugPortPtr = eprocessOffset.GetPointer(eprocessPtr, "DebugPort");
    IntPtr debugPortValue = memoryIO.ReadMemory<IntPtr>(debugPortPtr);

    Console.WriteLine($"DebugPort: {debugPortValue.ToInt64():x}");

    Console.ReadLine();
}

실제로 위의 프로그램을 (단독으로) 실행시켜 보면 "DebugPort" 값이 0으로 나옵니다. 반면, Visual Studio 환경에서 F5 키를 눌러 디버깅을 시작하면 "DebugPort: ffffd60dc0d1ff40"와 같은 식으로 출력이 됩니다.

DebugPort에 값이 있는 상황에서 또 다른 디버거, 예를 들어 windbg로 연결하려고 하면 0xC0000048 오류가 출력됩니다.

Could not attach to process 70856, NTSTATUS 0xC0000048

The process that you are attempting to attach to is already being debugged. Only one debugger can be invasively attached to a process at a time. A non-invasive attach is still possible when another debugger is attached.


(물론 non-invasive attach 방식으로 연결할 수 있지만) 그래도 다음과 같이 DebugPort의 값을 0으로 만들어 버리면,

memoryIO.WriteMemory<IntPtr>(debugPortPtr, IntPtr.Zero);

이후, windbg에서 아무런 오류 없이 attach가 됩니다. 대신 기존 연결된 디버거는 아무런 동작도 하지 않으며 windbg가 "qd" 명령어로 detach시켜도 DebugPort 값이 해제되었기 때문에 기존 디버거는 영원히 제어권을 잃어버리게 됩니다.

이런 의미에서 봤을 때 "하지만 이 기법의 단점은 EPROCESS 구조체의 DebugPort 값을 0으로 설정을 하면 우회가 가능하다."라는 것은 별로 의미가 없을 수 있습니다. 왜냐하면, 기존 디버거 입장에서는 더 이상 debuggee와 통신이 안 되는 것을 금방 알 수 있으므로 또 다른 조치를 취할 수 있는 여지가 다분하기 때문입니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




재미 삼아서 ^^ DebugPort 값을 0이 아닌 임의의 숫자를 넣으면 어떻게 될까요?

memoryIO.WriteMemory<IntPtr>(debugPortPtr, new IntPtr(1));

그럼 "쓰자마자" "Stop code: SYSTEM SERVICE EXCEPTION"의 BSOD 화면이 뜨는 것을 볼 수 있습니다. 부팅 후 남겨진 이벤트 로그는 다음과 같고,

Log Name:      System
Source:        Microsoft-Windows-WER-SystemErrorReporting
Date:          2020-01-15 오전 01:24:27
Event ID:      1001
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      TESTPC
Description:
The computer has rebooted from a bugcheck.  The bugcheck was: 0x0000003b (0x00000000c0000005, 0xfffff80042639320, 0xfffff4052db698e0, 0x0000000000000000). A dump was saved in: C:\WINDOWS\MEMORY.DMP. Report Id: e7c3b934-9a67-4e72-bd66-ce935a0c3492.

Log Name:      System
Source:        Microsoft-Windows-WER-SystemErrorReporting
Date:          2020-01-15 오전 01:24:56
Event ID:      1018
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      TESTPC
Description:
The dump file at location: C:\WINDOWS\MEMORY.DMP was deleted because the disk volume had less than 25 GB free space.

"C:\WINDOWS\MEMORY.DMP"라고 알려주는 덤프 파일은 아쉽게도 디스크 용량 부족으로 삭제되었고 대신 미니 덤프 파일을 "C:\Windows\Minidump" 경로에서 "011520-534078-01.dmp" 파일로 남겨진 것을 볼 수 있습니다.

이를 windbg에서 로드해 "!analyze -v"로 분석하면,

3: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff80042639320, Address of the instruction which caused the bugcheck
Arg3: fffff4052db698e0, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:
------------------

...[생략]...

DUMP_TYPE:  2

BUGCHECK_P1: c0000005

BUGCHECK_P2: fffff80042639320

BUGCHECK_P3: fffff4052db698e0

BUGCHECK_P4: 0

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

FAULTING_IP: 
nt!ExAcquireFastMutex+100
fffff800`42639320 f00fba3700      lock btr dword ptr [rdi],0

CONTEXT:  fffff4052db698e0 -- (.cxr 0xfffff4052db698e0)
rax=0000000000000000 rbx=0000000000000001 rcx=ffffb48fa3673080
rdx=0000000000000019 rsi=ffffb48fa3673400 rdi=0000000000000019
rip=fffff80042639320 rsp=fffff4052db6a2d0 rbp=0000000000000001
 r8=fffff4052db6a328  r9=0000000000000000 r10=fffff80042ccd110
r11=ffffb48fa390a308 r12=0000000000000019 r13=ffffb48fa1692080
r14=fffff4052db6a360 r15=ffffb48fa3673080
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00050246
nt!ExAcquireFastMutex+0x100:
fffff800`42639320 f00fba3700      lock btr dword ptr [rdi],0 ds:002b:00000000`00000019=????????
Resetting default scope

BUGCHECK_STR:  0x3B_c0000005

...[생략]...

CPU_MICROCODE: 6,5e,3,0 (F,M,S,R)  SIG: FFFFFFFF'00000000 (cache) FFFFFFFF'00000000 (init)

BLACKBOXBSD: 1 (!blackboxbsd)

BLACKBOXNTFS: 1 (!blackboxntfs)

BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

PROCESS_NAME:  ConsoleApp2.exe

CURRENT_IRQL:  1

ANALYSIS_SESSION_HOST:  TESTPC

ANALYSIS_SESSION_TIME:  01-15-2020 10:36:35.0843

ANALYSIS_VERSION: 10.0.18362.1 amd64fre

LAST_CONTROL_TRANSFER:  from fffff80042e4a231 to fffff80042639320

STACK_TEXT:  
fffff405`2db6a2d0 fffff800`42e4a231 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000000 : nt!ExAcquireFastMutex+0x100
fffff405`2db6a320 fffff800`42e4ba00 : ffffe301`ccfb9180 00000000`00000000 ffffb48f`a3673180 00000000`00000000 : nt!DbgkpQueueMessage+0x1b9
fffff405`2db6a520 fffff800`42e4c33d : 00000000`00000000 fffff405`2db6a869 00000000`00000000 fffff800`3ebb55a0 : nt!DbgkpSendApiMessage+0xa4
fffff405`2db6a570 fffff800`42dcae11 : ffffb48f`00000000 00000000`00000000 00000000`00000000 ffffb48f`a1692360 : nt!DbgkExitThread+0x8d
fffff405`2db6a6c0 fffff800`42ccd143 : ffffb48f`00000000 00000119`a455d200 00000000`00000000 fffff405`2db6a8b4 : nt!PspExitThread+0x16cd49
fffff405`2db6a7d0 fffff800`4263e551 : 00000000`00000000 fffff800`42bf0fde ffff43cc`cce36257 fffff800`00000002 : nt!KiSchedulerApcTerminate+0x33
fffff405`2db6a810 fffff800`427c5a60 : ffffb48f`a3683c01 fffff405`2db6a8d0 ffffb48f`a41fd090 00000000`00000000 : nt!KiDeliverApc+0x481
fffff405`2db6a8d0 fffff800`427d2dbf : 00000000`0000017c ffffe301`ccfb9180 fffff405`2db6aa00 00000000`00000000 : nt!KiInitiateUserApc+0x70
fffff405`2db6aa10 00007ff8`43c7fa54 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0x9f
0000000c`1b7ff448 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff8`43c7fa54

THREAD_SHA1_HASH_MOD_FUNC:  b5f1f2dcacd920241e342a8fe3877e894c43e7e5

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  dddc76a8a315a318b1c64e11f185ac97b3e96ad4

THREAD_SHA1_HASH_MOD:  9f457f347057f10e1df248e166a3e95e6570ecfe

FOLLOWUP_IP: 
nt!ExAcquireFastMutex+100
fffff800`42639320 f00fba3700      lock btr dword ptr [rdi],0

FAULT_INSTR_CODE:  37ba0ff0

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!ExAcquireFastMutex+100

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  12dcb470

IMAGE_VERSION:  10.0.18362.535

STACK_COMMAND:  .cxr 0xfffff4052db698e0 ; kb

BUCKET_ID_FUNC_OFFSET:  100

FAILURE_BUCKET_ID:  0x3B_c0000005_nt!ExAcquireFastMutex

BUCKET_ID:  0x3B_c0000005_nt!ExAcquireFastMutex

PRIMARY_PROBLEM_CLASS:  0x3B_c0000005_nt!ExAcquireFastMutex

...[생략]...

딱히 DebugPort를 건드려서 발생했을 것 같은 단서는 찾을 수 없지만... 혹시나 싶어 다시 시도해 보면 여지없이 DebugPort에 0이 아닌 값을 쓰는 순간 BSOD를 보게 됩니다. ^^




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]





[최초 등록일: ]
[최종 수정일: 1/15/2020 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer@outlook.com

비밀번호

댓글 쓴 사람
 




1  2  3  4  5  6  [7]  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12138정성태2/9/2020719.NET Framework: 885. C# - 닷넷 응용 프로그램에서 Sqlite 사용 [3]파일 다운로드1
12137정성태2/9/2020377오류 유형: 592. [AhnLab] 경고 - 디버거 실행을 탐지했습니다.
12136정성태2/6/2020313Windows: 166. Windows + S(또는 Q)로 뜨는 작업 표시줄의 검색 바가 동작하지 않는 경우
12135정성태7/9/2020411개발 환경 구성: 468. Nuget 패키지의 로컬 보관 폴더를 옮기는 방법 [1]
12134정성태2/5/20201102.NET Framework: 884. eBEST XingAPI의 C# 래퍼 버전 - XingAPINet Nuget 패키지 [2]파일 다운로드1
12133정성태2/7/2020490디버깅 기술: 161. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기
12132정성태2/20/2020705.NET Framework: 883. C#으로 구현하는 Win32 API 후킹(예: Sleep 호출 가로채기)파일 다운로드1
12131정성태1/27/2020743개발 환경 구성: 467. LocaleEmulator를 이용해 유니코드를 지원하지 않는(한글이 깨지는) 프로그램을 실행하는 방법
12130정성태1/26/2020412VS.NET IDE: 142. Visual Studio에서 windbg의 "Open Executable..."처럼 EXE를 직접 열어 디버깅을 시작하는 방법
12129정성태1/26/20201467.NET Framework: 882. C# - 키움 Open API+ 사용 시 Registry 등록 없이 KHOpenAPI.ocx 사용하는 방법 [1]
12128정성태1/26/2020505오류 유형: 591. The code execution cannot proceed because mfc100.dll was not found. Reinstalling the program may fix this problem.
12127정성태1/28/2020514.NET Framework: 881. C# DLL에서 제공하는 Win32 export 함수의 내부 동작 방식(VT Fix up Table)파일 다운로드1
12126정성태1/25/2020454.NET Framework: 880. C# - PE 파일로부터 IMAGE_COR20_HEADER 및 VTableFixups 테이블 분석파일 다운로드1
12125정성태1/24/2020359VS.NET IDE: 141. IDE0019 - Use pattern matching
12124정성태1/24/2020848VS.NET IDE: 140. IDE1006 - Naming rule violation: These words must begin with upper case characters: ...
12123정성태1/23/2020646웹: 39. Google Analytics - gtag 함수를 이용해 페이지 URL 수정 및 별도의 이벤트 생성 방법
12122정성태1/22/2020603.NET Framework: 879. C/C++의 UNREFERENCED_PARAMETER 매크로를 C#에서 우회하는 방법(IDE0060 - Remove unused parameter '...')파일 다운로드1
12121정성태1/24/2020351VS.NET IDE: 139. Visual Studio - Error List: "Could not find schema information for the ..."파일 다운로드1
12120정성태1/20/2020564.NET Framework: 878. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 네 번째 이야기(IL 코드로 직접 구현)파일 다운로드1
12119정성태1/17/2020668디버깅 기술: 160. Windbg 확장 DLL 만들기 (3) - C#으로 만드는 방법
12118정성태1/17/2020651개발 환경 구성: 466. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 세 번째 이야기 [1]
12117정성태1/15/2020645디버깅 기술: 159. C# - 디버깅 중인 프로세스를 강제로 다른 디버거에서 연결하는 방법파일 다운로드1
12116정성태1/15/2020533디버깅 기술: 158. Visual Studio로 디버깅 시 sos.dll 확장 명령어를 (비롯한 windbg의 다양한 기능을) 수행하는 방법
12115정성태1/14/2020538디버깅 기술: 157. C# - PEB.ProcessHeap을 이용해 디버깅 중인지 확인하는 방법파일 다운로드1
12114정성태1/13/2020745디버깅 기술: 156. C# - PDB 파일로부터 심벌(Symbol) 및 타입(Type) 정보 열거 [1]파일 다운로드3
12113정성태1/12/20201044오류 유형: 590. Visual C++ 빌드 오류 - fatal error LNK1104: cannot open file 'atls.lib' [1]
1  2  3  4  5  6  [7]  8  9  10  11  12  13  14  15  ...