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

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)
12198정성태3/17/2020524오류 유형: 609. SQL 서버 접속 시 "Cannot open user default database. Login failed."
12197정성태3/17/2020637VS.NET IDE: 144. .NET Core 콘솔 응용 프로그램을 배포(publish) 시 docker image 자동 생성 - 두 번째 이야기
12196정성태3/17/2020556오류 유형: 608. The ServicedComponent being invoked is not correctly configured (Use regsvcs to re-register).
12195정성태3/17/2020696.NET Framework: 902. C# - 프로세스의 모든 핸들을 열람 - 세 번째 이야기
12194정성태3/16/2020613오류 유형: 607. PostgreSQL - Npgsql.NpgsqlException: sorry, too many clients already
12193정성태3/16/2020582개발 환경 구성: 485. docker - SAP Adaptive Server Enterprise 컨테이너 실행
12192정성태3/14/2020723개발 환경 구성: 484. docker - Sybase Anywhere 16 컨테이너 실행
12191정성태3/14/20201101개발 환경 구성: 483. docker - OracleXE 컨테이너 실행 [1]
12190정성태3/14/2020414오류 유형: 606. Docker Desktop 업그레이드 시 "The process cannot access the file 'C:\Program Files\Docker\Docker\resources\dockerd.exe' because it is being used by another process."
12189정성태3/13/20201040개발 환경 구성: 482. Facebook OAuth 처리 시 상태 정보 전달 방법과 "유효한 OAuth 리디렉션 URI" 설정 규칙
12188정성태9/24/2020572Windows: 169. 부팅 시점에 실행되는 chkdsk 결과를 확인하는 방법
12187정성태3/12/2020463오류 유형: 605. NtpClient was unable to set a manual peer to use as a time source because of duplicate error on '...'.
12186정성태3/12/2020551오류 유형: 604. The SysVol Permissions for one or more GPOs on this domain controller and not in sync with the permissions for the GPOs on the Baseline domain controller.
12185정성태3/11/2020462오류 유형: 603. The browser service was unable to retrieve a list of servers from the browser master...
12184정성태3/11/2020692오류 유형: 602. Automatic certificate enrollment for local system failed (0x800706ba) The RPC server is unavailable. [3]
12183정성태3/12/2020521오류 유형: 601. Warning: DsGetDcName returned information for \\[...], when we were trying to reach [...].
12182정성태3/11/2020671.NET Framework: 901. C# Windows Forms - Vista/7 이후의 Progress Bar 업데이트가 느린 문제파일 다운로드1
12181정성태3/11/2020817기타: 76. 재현 가능한 최소한의 예제 프로젝트란? - 두 번째 예제파일 다운로드1
12180정성태3/10/2020421오류 유형: 600. "Docker Desktop for Windows" - EXPOSE 포트가 LISTENING 되지 않는 문제
12179정성태3/10/2020602개발 환경 구성: 481. docker - PostgreSQL 컨테이너 실행
12178정성태3/10/2020494개발 환경 구성: 480. Linux 운영체제의 docker를 위한 tcp 바인딩 추가
12177정성태3/9/2020563개발 환경 구성: 479. docker - MySQL 컨테이너 실행
12176정성태3/9/2020411개발 환경 구성: 478. 파일의 (sha256 등의) 해시 값(checksum) 확인하는 방법
12175정성태3/8/2020619개발 환경 구성: 477. "Docker Desktop for Windows"의 "Linux Container" 모드를 위한 tcp 바인딩 추가
12174정성태3/8/2020771개발 환경 구성: 476. DockerDesktopVM의 파일 시스템 접근 [2]
12173정성태3/8/2020712개발 환경 구성: 475. docker - SQL Server 2019 컨테이너 실행 [1]
1  2  3  4  5  6  [7]  8  9  10  11  12  13  14  15  ...