Microsoft MVP성태의 닷넷 이야기
글쓴 사람
홈페이지
첨부 파일

C# DLL에서 제공하는 Win32 export 함수의 내부 동작 방식(VT Fix up Table)

지난 글에서 IL 코드 수준의 DLL Export 함수를 구현하는 방법을 살펴봤습니다.

C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 네 번째 이야기(IL 코드로 직접 구현)
; https://www.sysnet.pe.kr/2/0/12120

그러면서 "Inside IL Assembler" 책에 실린 다이어그램으로 동작 방식을 어렴풋이 알게 되었는데요.

["Figure 18-3. Indirect referencing of v-table entries from the EAT" - 출처: https://books.google.co.kr/books?id=Xv_0AwAAQBAJ&pg=P9A353]
il_export_1.png

이렇게 제공된 DLL export C# 함수가 정확히 어떻게 동작할 수 있었는지 파헤쳐 보는 것이 이번 글의 목적입니다.




예제를 간단하게 하기 위해, 다음과 같이 3개의 함수를,

using System;

public static class Class1
{
    public static void Func1() // export할 함수 1
    {
        Console.WriteLine("Func1");
        return;
    }

    public static int Func2() // export할 함수 2
    {
        return 5;
    }

    public static void Func3(int n)  // export할 함수 3
    {
        Console.WriteLine(n);
    }
}

ildasm.exe로 IL 코드로 번역 후 ".export ..."만 끼워 넣어,

.method public hidebysig static void  Func1() cil managed
  {
    // Code size       15 (0xf)
    .export [1] // 1 == ordinal number
    .maxstack  8
    IL_0000:  nop
    ...[생략]...

    IL_000e:  ret
  } // end of method Class1::Func1

  .method public hidebysig static int32  Func2() cil managed
  {
    // Code size       7 (0x7)
    .export [2] // 2 == ordinal number
    .maxstack  1
    .locals init ([0] int32 V_0)
    IL_0000:  nop
    ...[생략]...
    IL_0006:  ret
  } // end of method Class1::Func2

  .method public hidebysig static void  Func3(int32 n) cil managed
  {
    // Code size       9 (0x9)
    .export [3] // 3 == ordinal number
    .maxstack  8
    IL_0000:  nop
    ...[생략]...
    IL_0008:  ret
  } // end of method Class1::Func3

ilasm.exe로 어셈블한 DLL을 대상으로 테스트를 진행하겠습니다. 이렇게 한 경우, vtfixup 테이블은 1개만 구성되고,

.vtfixup [3] int64 fromunmanaged at VT_01
.data VT_01 = int64(0)[3]

지난번에 구현해 둔 PEImage 라이브러리를 이용하면 DLL 파일 상의 Fix up 테이블 내용을 확인할 수 있습니다.

// Install-Package WindowsPE -Version 1.1.5

using System;
using WindowsPE;

class Program
{
    static void Main(string[] _)
    {
        PEImage img = PEImage.ReadFromFile(@"ClassLibrary1.dll");
        WriteInfo(img);
    }

    public static void WriteInfo(PEImage img)
    {
        if (img == null)
        {
            Console.WriteLine("img == null");
            return;
        }

        foreach (var vtf in img.EnumerateVTableFixups())
        {
            Console.WriteLine(vtf + ", " + vtf.Type.ToString());

            for (int i = 0; i < vtf.Count; i++)
            {
                int itemSize = vtf.GetItemSize();
                uint itemPos = (uint)(vtf.rva + (i * itemSize));

                long vtableItem = (itemSize == 8) ? img.Read<long>(itemPos) : img.Read<int>(itemPos);
                Console.WriteLine($"\tVTable[{i}] {vtableItem:x} at 0x{itemPos:x}");
            }
        }
    }
}

/*
RVA: 0x4000, # of entries: 3, Type: 0x0006, COR_VTABLE_64BIT, COR_VTABLE_FROM_UNMANAGED
        VTable[0] 6000001 at 0x4000
        VTable[1] 6000002 at 0x4008
        VTable[2] 6000003 at 0x4010
*/

일단 여기까지가 "Figure 18-3. Indirect referencing of v-table entries from the EAT" 그림에서의 다이어그램 중 "VT Fix up Table"과 "V-Table"의 값을 확인한 것입니다. 그리고, 파일 상에서의 "EAT" 테이블에 출력된 export 함수의 기계어 주소 코드를 다음의 코드로 확인할 수 있고,

foreach (ExportFunctionInfo efi in img.EnumerateExportFunctions())
{
    Console.WriteLine($"{efi.Name} at 0x{efi.RvaAddress:x8}");
    byte[] code = img.ReadBytes(efi.RvaAddress, 1024);
}

이 글에서 사용하는 ClassLibrary1.dll 예제라면 다음과 같이 출력됩니다.

Func1 at 0x00002622
Func2 at 0x0000262e
Func3 at 0x0000263a

해당 EAT에 기록된 함수의 주소 0x00002622, 0x0000262e, 0x0000263a의 코드는 어떻게 되어 있을까요? 이를 확인하려면 disassembler가 있어야 하는데 마침 "Udis86 Assembler"의 C# 포팅이 NuGet에 있으니 이를 추가하고,

Install-Package SharpDisasm

각각의 함수에 대한 기계어 코드를 덤프할 수 있습니다.

foreach (ExportFunctionInfo efi in img.EnumerateExportFunctions())
{
    Console.WriteLine($"{efi.Name} at 0x{efi.RvaAddress:x8}");
    byte[] code = img.ReadBytes(efi.RvaAddress, 1024);

    var disasm = new SharpDisasm.Disassembler(code, mode, 0, true);
    foreach (var insn in disasm.Disassemble().Take(2))
    {
        Console.Write("\t" + insn.ToString());

        if (insn.Operands.Length == 2)
        {
            long value = insn.Operands[1].Value;
            long rvaValue = value - img.BaseAddress.ToInt64();
            ulong vTableValue = img.Read<ulong>((uint)rvaValue);

            if (ILDecoder.IsMethodDef((long)vTableValue) == true)
            {
                Console.Write($" // methodDef Token: {vTableValue:x8}");
            }
            else
            {
                Console.Write($" // Code Address: {vTableValue:x8}");
            }
        }

        Console.WriteLine();
    }
}

출력 결과를 보면,

Func1 at 0x00002622
        0000000000000000 48 a1 00 40 00 10 00 00 00 00  mov rax, [0x10004000] // methodDef Token: 06000001
        000000000000000a ff e0                          jmp rax
Func2 at 0x0000262e
        0000000000000000 48 a1 08 40 00 10 00 00 00 00  mov rax, [0x10004008] // methodDef Token: 06000002
        000000000000000a ff e0                          jmp rax
Func3 at 0x0000263a
        0000000000000000 48 a1 10 40 00 10 00 00 00 00  mov rax, [0x10004010] // methodDef Token: 06000003
        000000000000000a ff e0                          jmp rax

엉뚱하게 methodDef 토큰 값을 "rax"에 가져와 jmp하는 코드로 이뤄져 있습니다. 당연히, DLL 파일 상으로만 저렇게 되어 있을 뿐 실행 중에, 즉 해당 DLL이 메모리에 올라왔을 때는 [0x10004000], [0x10004008], [0x10004008] 주소에 있는 값은 "Marshaling Thunks" 역할을 하는 함수의 주소로 바뀔 것입니다.




런타임 시에 "Jump Stubs"의 rax 값들이 실제로 어떻게 변하는지에 대해서는 해당 DLL을 로드한 상태의 PE 이미지를 조사해 보면 됩니다. 이를 위해 DLL의 메서드를 호출한 다음 그것의 BaseAddress로부터 PE Image를 분석하면,

[DllImport("ClassLibrary1.dll")]
public static extern void Func1();

static void Main(string[] _)
{
    // ClassLibrary1.dll 자체의 PE Image 덤프
    {
        PEImage img = PEImage.ReadFromFile(@"ClassLibrary1.dll");
        WriteInfo(img);
    }

    // Func1을 호출해 ClassLibrary1.dll이 로딩된 후의 BaseAddress로부터 PE Image 덤프
    {
        Func1();
        PEImage img = PEImage.FromLoadedModule("ClassLibrary1.dll");
        WriteInfo(img);
    }
}

그 변화를 확연히 파악할 수 있습니다.

// Func1을 호출해 ClassLibrary1.dll이 로딩된 후의 BaseAddress로부터 PE Image 덤프

RVA: 0x4000, # of entries: 3, Type: 0x0006, COR_VTABLE_64BIT, COR_VTABLE_FROM_UNMANAGED
        VTable[0] 7ff9d6cc004c at 0x4000
        VTable[1] 7ff9d6cc009c at 0x4008
        VTable[2] 7ff9d6cc00ec at 0x4010
Func1 at 0x00002622
        0000000000000000 48 a1 00 40 09 5d 00 00 00 00  mov rax, [0x5d094000] // Code Address: 7ff9d6cc004c
        000000000000000a ff e0                          jmp rax
Func2 at 0x0000262e
        0000000000000000 48 a1 08 40 09 5d 00 00 00 00  mov rax, [0x5d094008] // Code Address: 7ff9d6cc009c
        000000000000000a ff e0                          jmp rax
Func3 at 0x0000263a
        0000000000000000 48 a1 10 40 09 5d 00 00 00 00  mov rax, [0x5d094010] // Code Address: 7ff9d6cc00ec
        000000000000000a ff e0                          jmp rax




재미있는 것은, 저렇게 "Marshaling Thunks" 코드가 생성되고 V-Table의 methodDef 토큰 값이 그 주소로 바뀌는 시점이 export 함수의 호출 시점이 아니라는 것입니다. 물론, 처음 로딩을 위해서는 함수 호출이 있어야 하겠지만 일단 어떤 것이라도 1개의 함수가 불린다면 EAT에 등록된 모든 함수의 "Marshaling Thunks" 코드 생성이 이뤄집니다.

그렇다면 그 시점이 어떻게 될까요? 이를 위해 windbg의 힘을 빌려 살펴보겠습니다. 우선, 함수가 실행되는 시점에 Thunks 코드가 생성되는지는 windbg에서 해당 함수의 진입 시점으로 BP를 걸어보면 됩니다.

bp ClassLibrary1!Func1

하지만, 실제로 해보면 이미 Thunks 코드가 생성된 후임을 알게 됩니다. 그래서 이번에는 아예 ClassLibrary1 DLL이 로드되는 시점으로 BP를 걸고,

0:000> sxe ld:ClassLibrary1.dll

0:000> g

로딩이 되자마자 BreakPoint가 잡히면 BaseAddress를 통해,

ModLoad: 00007ffa`fb150000 00007ffa`fb1ee000   C:\WINDOWS\System32\msvcrt.dll
ModLoad: 00007ffa`fbb20000 00007ffa`fbbb7000   C:\WINDOWS\System32\sechost.dll
...[생략]...
ModLoad: 00007ffa`fb260000 00007ffa`fb3b6000   C:\WINDOWS\System32\ole32.dll
ModLoad: 00007ffa`e60e0000 00007ffa`e622f000   C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clrjit.dll
ModLoad: 00000000`6a1a0000 00000000`6a1aa000   C:\ClassLibrary1\bin\Debug\ClassLibrary1.dll

Func1의 EAT에 등록된 주소를 덤프하고,

0:000> !u 00000000`6a1a0000+2622
Unmanaged code
00000000`6a1a2622 48a100401a6a00000000 mov rax,qword ptr [ClassLibrary1!Func3+0x19c6 (00000000`6a1a4000)]
00000000`6a1a262c ffe0            jmp     rax
00000000`6a1a262e 48a108401a6a00000000 mov rax,qword ptr [ClassLibrary1!Func3+0x19ce (00000000`6a1a4008)]
00000000`6a1a2638 ffe0            jmp     rax
00000000`6a1a263a 48a110401a6a00000000 mov rax,qword ptr [ClassLibrary1!Func3+0x19d6 (00000000`6a1a4010)]
00000000`6a1a2644 ffe0            jmp     rax

출력된 00000000`6a1a4000, 00000000`6a1a4008, 00000000`6a1a4010 주소의 값을 methodDef 토큰에서 Thunks 코드의 주소로 쓰는 동작(write)에서 멈출 수 있도록 BP를 걸면 됩니다.

0:000> ba w8 00000000`6a1a4000
0:000> ba w8 00000000`6a1a4008
0:000> ba w8 00000000`6a1a4010

이후 'g'키를 눌러 프로그램 진행을 계속하면 다음과 같이 mscoreei!PatchVTableEntriesForDLLAttach 함수에서 멈추는 것을 볼 수 있습니다.

0:000> g
Breakpoint 0 hit
mscoreei!PatchVTableEntriesForDLLAttach+0x29d:
00007ffa`ed209838 4403dd          add     r11d,ebp

그리고 이때의 callstack을 보면,

0:000> k
 # Child-SP          RetAddr           : Call Site
00 00000000`003bd5a0 00007ffa`ed1fadc3 : mscoreei!PatchVTableEntriesForDLLAttach+0x29d
01 00000000`003bd620 00007ffa`ed8f1b3d : mscoreei!CorDllMain+0x145
02 00000000`003bd6a0 00007ffa`ed8f1b97 : MSCOREE!ShellShim__CorDllMain+0xe9
03 00000000`003bd6e0 00007ffa`fbca50a1 : MSCOREE!CorDllMain_Exported+0x37
04 00000000`003bd710 00007ffa`fbce9405 : ntdll!LdrpCallInitRoutine+0x65
05 00000000`003bd780 00007ffa`fbce91f8 : ntdll!LdrpInitializeNode+0x1b1
06 00000000`003bd8c0 00007ffa`fbcaaa97 : ntdll!LdrpInitializeGraphRecurse+0x80
07 00000000`003bd900 00007ffa`fbca2591 : ntdll!LdrpPrepareModuleForExecution+0xbf
08 00000000`003bd940 00007ffa`fbca22a8 : ntdll!LdrpLoadDllInternal+0x199
09 00000000`003bd9c0 00007ffa`fbca1764 : ntdll!LdrpLoadDll+0xa8
0a 00000000`003bdb70 00007ffa`f8f556d0 : ntdll!LdrLoadDll+0xe4
0b 00000000`003bdc60 00007ffa`eb26a417 : KERNELBASE!LoadLibraryExW+0x170
0c 00000000`003bdcd0 00007ffa`eb26a4a4 : clr!CLRLoadLibraryExWorker+0x54
0d 00000000`003bdd20 00007ffa`eb26a705 : clr!CLRLoadLibraryEx+0x51
0e 00000000`003bdd70 00007ffa`eb1931d8 : clr!LocalLoadLibraryHelper+0x31
0f 00000000`003bdda0 00007ffa`eb24bd68 : clr!NDirect::LoadLibraryModule+0x402
10 00000000`003be600 00007ffa`eb24bcd5 : clr!NDirect::NDirectLink+0x80
11 00000000`003be930 00007ffa`eb24b8e1 : clr!NDirect::GetStubForILStub+0x4e
12 00000000`003be980 00007ffa`eb24bc05 : clr!GetStubForInteropMethod+0x65
13 00000000`003be9c0 00007ffa`eb10118c : clr!MethodDesc::DoPrestub+0xef2
14 00000000`003bebe0 00007ffa`eb0f4855 : clr!PreStubWorker+0x3cc
15 00000000`003bef20 00007ffa`8bba08b2 : clr!ThePreStub+0x55
16 00000000`003befd0 00007ffa`eb0f6bd3 : 0x00007ffa`8bba08b2
17 00000000`003bf010 00007ffa`eb0f6aa0 : clr!CallDescrWorkerInternal+0x83
18 00000000`003bf050 00007ffa`eb0f7130 : clr!CallDescrWorkerWithHandler+0x4e
19 00000000`003bf090 00007ffa`eb1cf622 : clr!MethodDescCallSite::CallTargetWorker+0x102
1a 00000000`003bf190 00007ffa`eb1cffe7 : clr!RunMain+0x25f
1b 00000000`003bf370 00007ffa`eb1cfe9a : clr!Assembly::ExecuteMainMethod+0xb7
1c 00000000`003bf660 00007ffa`eb1cf7e3 : clr!SystemDomain::ExecuteMainMethod+0x643
1d 00000000`003bfc60 00007ffa`eb1cf761 : clr!ExecuteEXE+0x3f
1e 00000000`003bfcd0 00007ffa`eb1d0ca4 : clr!_CorExeMainInternal+0xb2
1f 00000000`003bfd60 00007ffa`ed1d8c01 : clr!CorExeMain+0x14
20 00000000`003bfda0 00007ffa`ed8fa56c : mscoreei!CorExeMain+0x112
21 00000000`003bfe00 00007ffa`fb0a7bd4 : MSCOREE!CorExeMain_Exported+0x6c
22 00000000`003bfe30 00007ffa`fbceced1 : KERNEL32!BaseThreadInitThunk+0x14
23 00000000`003bfe60 00000000`00000000 : ntdll!RtlUserThreadStart+0x21

사실상 DLL 로딩 시점에 Thunks 코드 구성이 완료되는 것을 확인할 수 있습니다. 이 단계에서 "Figure 18-3. Indirect referencing of v-table entries from the EAT" 그림에서의 다이어그램 중 EAT, Jump Stubs, V-Table, VT Fix up Table, Marshaling Thunks까지 완료된 것입니다. 하지만 여전히 Func1, Func2, Func3의 IL 코드는 JIT되지 않은 상태인데 이것은 Thunks 코드가 실행되는 시점에 "Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후"의 방식과 유사하게 JIT 컴파일이 될 것이기 때문입니다.

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




예전에, Windows의 DLL Loader를 직접 구현하는 방법에 대해 글을 본 적이 있습니다. 핵심은 IAT, EAT의 주소와 함께 ".reloc" 섹션 내용을 반영하는 것이었는데요, 위와 같은 .NET DLL의 동작까지 반영하려면 문제가 더욱 어려워지게 되었습니다. ^^




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 1/28/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)
12260정성태7/8/202039.NET Framework: 926. C# - ETW를 이용한 ThreadPool 스레드 감시파일 다운로드1
12259정성태7/8/202013오류 유형: 627. nvlddmkm.sys의 BAD_POOL_HEADER BSOD 문제
12258정성태7/8/202064기타: 77. DataDog APM 간략 소개
12257정성태7/7/202047.NET Framework: 925. C# - ETW를 이용한 Monitor Enter/Exit 감시파일 다운로드1
12256정성태7/7/202064.NET Framework: 924. C# - Reflection으로 변경할 수 없는 readonly 정적 필드 [4]
12255정성태7/6/202056.NET Framework: 923. C# - ETW(Event Tracing for Windows)를 이용한 Finalizer 실행 감시파일 다운로드1
12254정성태7/2/202033오류 유형: 626. git - REMOTE HOST IDENTIFICATION HAS CHANGED!
12253정성태7/2/202099.NET Framework: 922. C# - .NET ThreadPool의 Local/Global Queue파일 다운로드1
12252정성태7/2/202072.NET Framework: 921. C# - I/O 스레드를 사용한 비동기 소켓 서버/클라이언트파일 다운로드2
12251정성태7/1/202099.NET Framework: 920. C# - 파일의 비동기 처리 유무에 따른 스레드 상황파일 다운로드2
12250정성태7/1/2020306.NET Framework: 919. C# - 닷넷에서의 진정한 비동기 호출을 가능케 하는 I/O 스레드 사용법 [1]파일 다운로드1
12249정성태6/29/202032오류 유형: 625. Microsoft SQL Server 2019 RC1 Setup - 설치 제거 시 Warning 26003 오류 발생
12248정성태6/29/202029오류 유형: 624. SQL 서버 오류 - service-specific error code 17051
12247정성태6/29/2020120.NET Framework: 918. C# - 불린 형 상수를 반환값으로 포함하는 3항 연산자 사용 시 단축 표현 권장(IDE0075) [2]파일 다운로드1
12246정성태6/29/202062.NET Framework: 917. C# - USB 관련 ETW(Event Tracing for Windows)를 이용한 키보드 입력을 감지하는 방법
12245정성태6/25/2020212.NET Framework: 916. C# - Task.Yield 사용법 (2) [2]파일 다운로드1
12244정성태6/29/202094.NET Framework: 915. ETW(Event Tracing for Windows)를 이용한 닷넷 프로그램의 내부 이벤트 활용파일 다운로드1
12243정성태6/23/202060VS.NET IDE: 147. Visual C++ 프로젝트 - .NET Core EXE를 "Debugger Type"으로 지원하는 기능 추가
12242정성태6/24/202036오류 유형: 623. AADSTS90072 - User account '...' from identity provider 'live.com' does not exist in tenant 'Microsoft Services'
12241정성태6/26/2020119.NET Framework: 914. C# - Task.Yield 사용법파일 다운로드1
12240정성태6/23/202078오류 유형: 622. 소켓 바인딩 시 "System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions" 오류 발생
12239정성태6/21/202064Linux: 30. (윈도우라면 DLL에 속하는) .so 파일이 텍스트로 구성된 사례
12238정성태6/21/202099.NET Framework: 913. C# - SharpDX + DXGI를 이용한 윈도우 화면 캡처 라이브러리
12237정성태7/8/2020106.NET Framework: 912. 리눅스 환경의 .NET Core에서 "test".IndexOf("\0")가 0을 반환
12236정성태6/19/202070오류 유형: 621. .NET Standard 대상으로 빌드 시 dynamic 예약어에서 컴파일 오류 - error CS0656: Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create'
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...