Microsoft MVP성태의 닷넷 이야기
.NET Framework: 955. .NET 메서드의 Signature 바이트 코드 분석 [링크 복사], [링크+제목 복사],
조회: 10999
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 9개 있습니다.)
.NET Framework: 491. 닷넷 Generic 타입의 메타 데이터 토큰 값 알아내는 방법
; https://www.sysnet.pe.kr/2/0/1848

.NET Framework: 494. 값(struct) 형식의 제네릭(Generic) 타입이 박싱되는 경우의 메타데이터 토큰 값
; https://www.sysnet.pe.kr/2/0/1857

.NET Framework: 495. CorElementType의 요소 값 설명
; https://www.sysnet.pe.kr/2/0/1860

.NET Framework: 509. ELEMENT_TYPE_MODIFIER의 조합
; https://www.sysnet.pe.kr/2/0/2894

.NET Framework: 510. 제네릭(Generic) 인자에 대한 메타데이터 등록 확인
; https://www.sysnet.pe.kr/2/0/2907

.NET Framework: 844. C# - 박싱과 언박싱
; https://www.sysnet.pe.kr/2/0/11943

.NET Framework: 955.  .NET 메서드의 Signature 바이트 코드 분석
; https://www.sysnet.pe.kr/2/0/12379

.NET Framework: 1130. C# - ELEMENT_TYPE_INTERNAL 유형의 사용 예
; https://www.sysnet.pe.kr/2/0/12903

.NET Framework: 1174. C# - ELEMENT_TYPE_FNPTR 유형의 사용 예
; https://www.sysnet.pe.kr/2/0/12998




.NET 메서드의 Signature 바이트 코드 분석

.NET Profiler를 만들 때, 메서드의 signature 분석이 요구될 때가 있습니다. 일례로 예전 글에서,

CLR Profiler - 별도 정의한 .NET 코드를 호출하도록 IL 코드 변경
; https://www.sysnet.pe.kr/2/0/10959

C++ 측에서 IL 코드를 재정의해 .NET 메서드로,

public static void Enter() { ... }

호출을 넘기기 위해 저 Enter 메서드의 signature를 다음과 같이 구성해 등록해야만 했습니다.

COR_SIGNATURE sigFunctionProbe[] = {
            IMAGE_CEE_CS_CALLCONV_DEFAULT,      // default calling convention (쉽게 말해, static 멤버)
            0x0,                                // # of arguments == 0
            ELEMENT_TYPE_VOID,                  // return type == void
        };

기왕 해보는 김에, 좀 더 복잡한 것을 통해 signature 분석 방법을 알아보겠습니다. ^^ 이를 위해 예제를 다음과 같이 작성하고,

using System;
using System.Threading.Tasks;

namespace ConsoleApp1
{
    public readonly struct TestItem
    {
        internal static Task InvokeAsync<T>(MulticastDelegate @delegate, T arg)
        {
            NextCall(@delegate, arg);
            return null;
        }

        internal Task InvokeAsync2<T>(MulticastDelegate @delegate, T arg)
        {
            NextCall(@delegate, arg);
            return null;
        }

        private static void NextCall(MulticastDelegate @delegate, object arg)
        {
            Console.WriteLine(arg);
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
        }
    }
}

ildasm을 이용해 역어셈블한 내용을 토대로,

C:\temp\ConsoleApp1\bin\Debug> ildasm /metadata=hex /bytes ConsoleApp1.exe /out=sample_il.txt

풀어보면, 예를 들어 "internal static Task InvokeAsync<T>(MulticastDelegate @delegate, T arg)" 메서드의 signature 출력에서 다음과 같은 바이트 출력을 볼 수 있습니다.

// SIG: 10 01 02 12 4D 12 51 1E 00

우선 가장 첫 번째 바이트는, corhdr.h에 있는 "CorCallingConvention"이 담당합니다.

typedef enum CorCallingConvention
{
    IMAGE_CEE_CS_CALLCONV_DEFAULT       = 0x0,

    IMAGE_CEE_CS_CALLCONV_VARARG        = 0x5,
    IMAGE_CEE_CS_CALLCONV_FIELD         = 0x6,
    IMAGE_CEE_CS_CALLCONV_LOCAL_SIG     = 0x7,
    IMAGE_CEE_CS_CALLCONV_PROPERTY      = 0x8,
    IMAGE_CEE_CS_CALLCONV_UNMGD         = 0x9,
    IMAGE_CEE_CS_CALLCONV_GENERICINST   = 0xa,  // generic method instantiation
    IMAGE_CEE_CS_CALLCONV_NATIVEVARARG  = 0xb,  // used ONLY for 64bit vararg PInvoke calls
    IMAGE_CEE_CS_CALLCONV_MAX           = 0xc,  // first invalid calling convention


        // The high bits of the calling convention convey additional info
    IMAGE_CEE_CS_CALLCONV_MASK      = 0x0f,  // Calling convention is bottom 4 bits
    IMAGE_CEE_CS_CALLCONV_HASTHIS   = 0x20,  // Top bit indicates a 'this' parameter
    IMAGE_CEE_CS_CALLCONV_EXPLICITTHIS = 0x40,  // This parameter is explicitly in the signature
    IMAGE_CEE_CS_CALLCONV_GENERIC   = 0x10,  // Generic method sig with explicit number of type arguments (precedes ordinary parameter count)
    // 0x80 is reserved for internal use
} CorCallingConvention;

그래서, 0x10 == IMAGE_CEE_CS_CALLCONV_GENERIC이 되는데 이와 함께 static 메서드의 경우 "IMAGE_CEE_CS_CALLCONV_DEFAULT"도 함께 지정된 것과 같습니다.

0x10 == IMAGE_CEE_CS_CALLCONV_GENERIC | IMAGE_CEE_CS_CALLCONV_DEFAULT

만약 저 메서드가 instance 멤버였다면 첫 번째 바이트는 다음과 같이 바뀝니다.

0x30 == IMAGE_CEE_CS_CALLCONV_GENERIC | IMAGE_CEE_CS_CALLCONV_HASTHIS

이후 차례로 다음의 의미를 갖는데,

// ========== 1. Generic 인자 및 매개 변수 수
01 == # of generic args (만약 IMAGE_CEE_CS_CALLCONV_GENERIC 유형이 아니라면 생략)
02 == # of arg

// ========== 2. 반환 타입
12 == 반환 타입의 CorElementType, 0x12 == ELEMENT_TYPE_CLASS
4D == 반환 타입(System.Threading.Tasks.Task)의 토큰에 대한 compressed 인코딩 값

// ========== 3. 인자 타입 ('# of arg' 값이 0 이라면 생략)
12 == 첫 번째 인자의 CorElementType, 0x12 == ELEMENT_TYPE_CLASS
51 == System.MulticastDelegate 토큰의 compressed 인코딩 값

1E == 두 번째 인자의 CorElementType, 0x1e == ELEMENT_TYPE_MVAR
00 == generic method의 타입 인덱스, 즉 T

이 중에서, CorElementType의 경우 ELEMENT_TYPE_CLASS나 ELEMENT_TYPE_VALUETYPE이라면 뒤이어 "메타데이터 토큰의 compressed 인코딩 값"이 나오는데요, 이 값의 구성을 알아보려면 Metadata에 (반환 타입의 System.Threading.Tasks.Task에 해당하는) 토큰을 먼저 확인해야 합니다.

// TypeRef #19 (01000013)
// -------------------------------------------------------
// Token:             0x01000013
// ResolutionScope:   0x23000001
// TypeRefName:       System.Threading.Tasks.Task

여기서 상위 1바이트가 RID라는 구분자라서 보통 IL disassembler에서는 (01)000013으로 표현하는데, "compressed" 시에는 인코딩 영향으로 rid를 잘라내는 식으로 구현합니다.

#define RidFromToken(tk) ((RID) ((tk) & 0x00ffffff))

그래서, 순수 토큰 id 값으로 2바이트 우측 shift 연산을 한 다음,

0x13 << 2 (결과 값: 4C)

해당 토큰이 "TypeRef"인지 "TypeSpec"인지에 따라 1 또는 2를 더합니다.

if (typeRef) 4C | 1;
else if (typeSpec) 4C | 2;

즉, 하위 2바이트를 shift 해 확보한 자리를 통해 0 == TypeDef, 1 == TypeRef, 2 == TypeSpec 유형의 토큰임을 알 수 있습니다. 이렇게 구한 값을 이제 범위에 따라 1, 2, 또는 4 바이트 인코딩을 합니다.

int ridIndex = ...id...;

if (ridIndex <= 0x7F)
{
    // 작으면 1byte로 끝남.
    // (BYTE)ridIndex;
}
else if (ridIndex >= 0x80 && ridIndex <= 0x3FFF)
{
    // (short)(ridIndex |= 0x8000);
}
else
{
    // (int)(ridIndex |= 0xC0000000);
}

그렇기 때문에, (01)000013이었던 System.Threading.Tasks.Task 타입의 토큰이 1바이트인 "4D"로 인코딩 된 것입니다. 이런 식으로 첫 번째 인자인 "12 51"도 해석할 수 있습니다.

// TypeRef #20 (01000014)
// -------------------------------------------------------
// Token:             0x01000014
// ResolutionScope:   0x23000001
// TypeRefName:       System.MulticastDelegate

12 == ELEMENT_TYPE_CLASS
51 == System.MulticastDelegate 토큰(01000014)의 compressed 인코딩 값

마지막으로, 두 번째 인자는 generic이라 특별히 1E == ELEMENT_TYPE_MVAR 바이트가 선행이 된 다음 generic 인자의 "인덱스"가 지정이 되었습니다. 약간 혼란의 여지를 줄 수 있는데, 여기서 인덱스는 해당 메서드에서의 generic 인자의 순서가 아니라, 메타데이터에 등록된 generic 인자의 인덱스를 의미합니다.




사실, 지난 글에 소개한 라이브러리를 사용하면 위와 같은 내용을 코딩으로 작업할 필요는 없습니다. 가령, 다음의 메서드가 이미 그 작업을 아주 잘 수행하고 있기 때문입니다.

bool SigParser::ParseMethod(sig_elem_type elem_type)
; https://github.com/microsoftarchive/clrprofiler/blob/master/ILRewrite/ILRewriteProfiler/sigparse.inl#L340

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




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 10/26/2020]

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

비밀번호

댓글 작성자
 



2022-01-06 03시05분
Decyphering methods signature with .NET profiling APIs
; https://chnasarre.medium.com/decyphering-method-signature-with-clr-profiling-api-8328a72a216e

-------------------------

Generic 관련 signature 예제

public class Var2Class1<T, V>
{
    public void Method(T t, V v) // 20 02 01 13 00 13 01
    {
        /* 8C0400001B : box!T */
        /* 8C0700001B : box!V */
        Console.Write($"{t}{v}");
    }
}

public class Var2Class2<T2, V2>
{
    public void Method(T2 t, V2 v) // 20 02 01 13 00 13 01
    {
        /* 8C0400001B : box!T2 */
        /* 8C0700001B : box!V2 */
        Console.Write($"{t}{v}");
    }
}

public class Var2M2Class1<T3, V3>
{
    public void Method<X, Y>(T3 t, V3 v, X x, Y y) // 30 02 04 01 13 00 13 01 1e 00 1e 01
    {
        /* 8C0400001B : box!T3 */
        /* 8C0700001B : box!V3 */
        /* 8C0800001B : box!!X */
        /* 8C0900001B : box!!Y */
        Console.Write($"{t}{v}{x}{y}");
    }
}

public class Var2M2Class2<T4, V4>
{
    public void Method<X2, Y2>(T4 t, V4 v, X2 x, Y2 y) // 30 02 04 01 13 00 13 01 1e 00 1e 01
    {
        /* 8C0400001B : box!T4 */
        /* 8C0700001B : box!V4 */
        /* 8C0800001B : box!!X2 */
        /* 8C0900001B : box!!Y2 */
        Console.Write($"{t}{v}{x}{y}");
    }
}


--------------------------------

07 04 12 80 9d 02 1c 13 00

07: IMAGE_CEE_CS_CALLCONV_LOCAL_SIG
04: # of local variables
12: ELEMENT_TYPE_CLASS
80 9d: class token
02: ELEMENT_TYPE_BOOLEAN
1c: ELEMENT_TYPE_OBJECT
13 00: ELEMENT_TYPE_VAR !T0
정성태

... 61  62  [63]  64  65  66  67  68  69  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12072정성태12/9/201910927오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
12071정성태12/9/201913238오류 유형: 582. 리눅스 디스크 공간 부족 및 safemode 부팅 방법
12070정성태12/9/201915406오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/2/201911761디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/201915113디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [3]파일 다운로드2
12067정성태11/27/201911765디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201911628디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201910498디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201912693오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201911721디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201911801디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201911964Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/20/201912338디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
12059정성태11/20/201911936디버깅 기술: 131. windbg/Visual Studio - HeapFree x86의 동작 분석
12058정성태11/19/201912731디버깅 기술: 130. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례
12057정성태11/18/20199866오류 유형: 579. Visual Studio - Memory 창에서 유효한 주소 영역임에도 "Unable to evaluate the expression." 오류 출력
12056정성태11/18/201913693개발 환경 구성: 464. "Microsoft Visual Studio Installer Projects" 프로젝트로 EXE 서명 및 MSI 파일 서명 방법파일 다운로드1
12055정성태11/17/20199427개발 환경 구성: 463. Visual Studio의 Ctrl + Alt + M, 1 (Memory 1) 등의 단축키가 동작하지 않는 경우
12054정성태11/15/201910760.NET Framework: 869. C# - 일부러 GC Heap을 깨뜨려 GC 수행 시 비정상 종료시키는 예제
12053정성태11/15/201912446Windows: 166. 윈도우 10 - 명령행 창(cmd.exe) 속성에 (DotumChe, GulimChe, GungsuhChe 등의) 한글 폰트가 없는 경우
12052정성태11/15/201911554오류 유형: 578. Azure - 일정(schedule)에 등록한 runbook이 1년 후 실행이 안 되는 문제(Reason - The key used is expired.)
12051정성태11/14/201914020개발 환경 구성: 462. 시작하자마자 비정상 종료하는 프로세스의 메모리 덤프 - procdump [1]
12050정성태11/14/201911697Windows: 165. AcLayers의 API 후킹과 FaultTolerantHeap
12049정성태11/13/201911793.NET Framework: 868. (닷넷 프로세스를 대상으로) 디버거 방식이 아닌 CLR Profiler를 이용해 procdump.exe 기능 구현
12048정성태11/12/201912561Windows: 164. GUID 이름의 볼륨에 해당하는 파티션을 찾는 방법
12047정성태11/12/201914407Windows: 163. 안전하게 eject시킨 USB 장치를 물리적인 재연결 없이 다시 인식시키는 방법
... 61  62  [63]  64  65  66  67  68  69  70  71  72  73  74  75  ...