Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 5개 있습니다.)
(시리즈 글이 3개 있습니다.)
.NET Framework: 299. 해당 어셈블리가 Debug 빌드인지, Release 빌드인지 알아내는 방법
; https://www.sysnet.pe.kr/2/0/1227

.NET Framework: 315. 해당 DLL이 Managed인지 / Unmanaged인지 확인하는 방법
; https://www.sysnet.pe.kr/2/0/1279

.NET Framework: 328. 해당 DLL이 Managed인지 / Unmanaged인지 확인하는 방법 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/1296




해당 DLL이 Managed인지 / Unmanaged인지 확인하는 방법 - 두 번째 이야기


예전에 다음과 같은 글을 쓴 적이 있었는데요. ^^

해당 DLL이 Managed인지 / Unmanaged인지 확인하는 방법
; https://www.sysnet.pe.kr/2/0/1279

그때 당시에, 좀 더 개선될 수 있는 것으로 PE 파일 포맷 분석하는 방법을 남겨놓았었는데요. 혹시나, ^^ 어떤 분이 그에 관해서 글을 쓰시지 않을까 하는... 기대를 갖고 있었는데, 오늘 기준으로 아무도 안 쓰시네요. ^^; 별로 관심 사항은 아닌가 봅니다.

어쨌든, 이번에는 PE 파일을 직접 살펴보고 Managed/Unmanaged 판별을 해낼 텐데요.

사실, 그다지 어려운 문제는 아닙니다. 게다가 PE 파일 포맷에 대해 잘 설명된 책도 있고요.

Windows 시스템 실행파일의 구조와 원리
; http://www.yes24.com/24/goods/1493278?scode=029

그럼, 우선 IMAGE_DOS_HEADER 먼저 구조체를 채워보는 것부터 시작하겠습니다.

책에 설명된 데로, 해당 구조체는 WinNT.h에 정의되어 있지만 여기서는 C# 에서 구현할 것이기 때문에 적절한 Interop 구조체가 필요합니다. 역시 ^^ pinvoke.net이 그 해답이겠지요.

IMAGE_DOS_HEADER
; http://www.pinvoke.net/default.aspx/Structures/IMAGE_DOS_HEADER.html

위의 정의를 이용하면 간단하게 다음과 같이 IMAGE_DOS_HEADER의 내용을 채울 수 있습니다.

using (FileStream fs = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{
    // IMAGE_DOS_HEADER를 읽어들이고,
    IMAGE_DOS_HEADER dosHeader = new IMAGE_DOS_HEADER();
    {
        int dosHeaderSize = Marshal.SizeOf(dosHeader);
        byte[] dosHeaderBytes = new byte[dosHeaderSize];
        fs.Read(dosHeaderBytes, 0, dosHeaderSize);

        fixed (byte* p = dosHeaderBytes)
        {
            IntPtr ptr = new IntPtr(p);
            object objDosHeader = Marshal.PtrToStructure(ptr, typeof(IMAGE_DOS_HEADER));
            dosHeader = (IMAGE_DOS_HEADER)objDosHeader;
        }

        if (dosHeader.isValid == false) // _e_magic == "MZ"
        {
            return false;
        }
    }
}

(이후의 PE 포맷에 관련된 헤더들도 모두 기본적으로는 위와 같은 구조를 따릅니다.)

IMAGE_DOS_HEADER 이후에는 IMAGE_NT_HEADERS 구조체를 읽어들여야 하는데, 아쉽게도 IMAGE_NT_HEADERS 내부에 포함하고 있는 IMAGE_OPTIONAL_HEADER가 32비트/64비트 모듈에 따라 달라지므로 이 2가지를 한꺼번에 지원하기 위해 이에 대한 판단을 먼저 해야 합니다.

그러려면, 우선 'PE Signature' 바이트를 읽어서 넘어가고,

// IMAGE_NT_HEADERS - signature 를 읽어들이고,
{
    fs.Position = dosHeader.e_lfanew;
    byte [] ntSignature = new byte[4];
    fs.Read(ntSignature, 0, 4);

    // PE 헤더임을 확인 (IMAGE_NT_SIGNATURE == 0x00004550)
    if (ntSignature[0] != 80 || ntSignature[1] != 69 || ntSignature[2] != 0 || ntSignature[3] != 0)
    {
        return false;
    }
}

다행히 IMAGE_NT_HEADERS 내에 IMAGE_FILE_HEADER 구조체까지 이어서 읽어들이면 32비트/64비트 구별을 할 수 있게 됩니다.

// IMAGE_NT_HEADERS - IMAGE_FILE_HEADER를 읽어들임
IMAGE_FILE_HEADER ntFileHeader = new IMAGE_FILE_HEADER();
bool is64BitHeader = false;
{
    int ntFileHeaderSize = Marshal.SizeOf(ntFileHeader);
    byte[] ntFileHeaderBytes = new byte[ntFileHeaderSize];
    fs.Read(ntFileHeaderBytes, 0, ntFileHeaderSize);

    fixed (byte* p = ntFileHeaderBytes)
    {
        IntPtr ptr = new IntPtr(p);
        object objNtFileHeader = Marshal.PtrToStructure(ptr, typeof(IMAGE_FILE_HEADER));
        ntFileHeader = (IMAGE_FILE_HEADER)objNtFileHeader;
    }

    if (ntFileHeader.Machine == IMAGE_FILE_MACHINE_I386)
    {
        is64BitHeader = false;
    }
    else if (ntFileHeader.Machine == IMAGE_FILE_MACHINE_AMD64 ||
        ntFileHeader.Machine == IMAGE_FILE_MACHINE_IA64)
    {
        is64BitHeader = true;
    }
    else
    {
        return false;
    }
}

이걸로 모든 준비는 끝났습니다. .NET DLL/EXE의 경우, IMAGE_OPTIONAL_HEADER 내부의 DataDirectory 구조체 중의 하나인 CLRRuntimeHeader 값을 포함하고 있기 때문에 그 값이 유효한지를 판단해 내면 됩니다. 다음은 32비트인 경우에 사용될 수 있는 코드입니다.

ushort optionalHeaderSize = ntFileHeader.SizeOfOptionalHeader;
if (is64BitHeader == false)
{
    IMAGE_OPTIONAL_HEADER32 optionalHeader32 = new IMAGE_OPTIONAL_HEADER32();

    byte[] optionalHeaderBytes = new byte[optionalHeaderSize];
    fs.Read(optionalHeaderBytes, 0, optionalHeaderSize);

    fixed (byte* p = optionalHeaderBytes)
    {
        IntPtr ptr = new IntPtr(p);
        object objOptionalHeader = Marshal.PtrToStructure(ptr, typeof(IMAGE_OPTIONAL_HEADER32));
        optionalHeader32 = (IMAGE_OPTIONAL_HEADER32)objOptionalHeader;

        if (optionalHeader32.Magic != MagicType.IMAGE_NT_OPTIONAL_HDR32_MAGIC
            || optionalHeader32.NumberOfRvaAndSizes != 16)
        {
            return false;
        }
    }

    return optionalHeader32.CLRRuntimeHeader.VirtualAddress != 0;
}
else
{
    ...[생략: 32비트와 유사]...
}

원래 DataDirectory는 16개의 배열로 정의되는 것이 보통인데, 위의 코드에서는 C# Interop 코드에서 명시적으로 15번째 COM descriptor 요소를 CLRRuntimeHeader 속성으로 제공하고 있어 쉽게 접근하고 있습니다. 따라서, 그 값이 0이면 Native DLL이고, 그렇지 않으면 .NET DLL이 됩니다.

첨부된 파일은 지난번 글에 포함된 소스 코드에다 이번 글의 IsManagedFromPE 메서드를 추가 구현한 것을 포함하고 있습니다.




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/10/2021]

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

비밀번호

댓글 작성자
 



2012-06-08 07시01분
[윤성민] 저 같은 경우는 닷넷의 Version클래스로.. dll의 버전을 읽었을때 가져오면.. 그냥 managed판별하고 0으로 돌려주면 Unmanaged로 판별했던것으로 기억합니다만
[guest]
2012-06-08 02시48분
윤성민 님의 경우 AssemblyName.GetAssemblyName(assemblyPath).Version으로 알아낸다는 건가요? 그렇게 되면 결국 지난번 글에서의 문제점과 같은 현상이 발생합니다.

해당 DLL이 Managed인지 / Unmanaged인지 확인하는 방법
; http://www.sysnet.pe.kr/2/0/1279

위의 글 중간에 설명을 했지만, 경우에 따라서 System.BadImageFormatException이 발생할 수 있습니다. ^^
정성태
2015-01-05 04시04분
정성태
2021-03-03 01시23분
정성태

... 151  152  153  154  155  [156]  157  158  159  160  161  162  163  164  165  ...
NoWriterDateCnt.TitleFile(s)
1183정성태11/26/201122748오류 유형: 140. Visual Studio 2010 - Floating된 에디트 윈도우가 사라지지 않는 경우 [2]
1182정성태11/25/201158746.NET Framework: 276. 중복 없는 숫자를 랜덤으로 배열하는 방법 [5]파일 다운로드1
1181정성태11/24/201129056디버깅 기술: 44. windbg의 mscordacwks DLL 로드 문제
1180정성태11/23/201138937.NET Framework: 275. 레지스트리 등록 및 Interop DLL 없이 COM 개체 사용하는 방법 [2]파일 다운로드1
1179정성태11/22/201129453.NET Framework: 274. ReaderWriterLockSlim은 언제 쓰는 걸까요? [4]파일 다운로드1
1178정성태11/19/201126012.NET Framework: 273. 설치된 .NET 버전에 민감한 코드를 포함하는 경우, 다중으로 어셈블리를 만들어야 할까요?파일 다운로드1
1177정성태11/18/201131315.NET Framework: 272. 소켓 연결 시간 제한 - 두 번째 이야기 [1]파일 다운로드1
1176정성태11/17/201130728.NET Framework: 271. C#에서 확인해 보는 관리 힙의 인스턴스 구조 [3]파일 다운로드1
1175정성태11/16/201128676.NET Framework: 270. .NET 참조 개체 인스턴스의 Object Header를 확인하는 방법 [1]파일 다운로드1
1174정성태11/15/201127989.NET Framework: 269. 일반 참조형의 기본 메모리 소비는 얼마나 될까요? [4]
1173정성태11/14/201124116.NET Framework: 268. .NET Array는 왜 12bytes의 기본 메모리를 점유할까? [1]
1172정성태11/13/201121083.NET Framework: 267. windbg - GC Heap에서 .NET 타입에 대한 배열을 찾는 방법
1171정성태11/12/201137822.NET Framework: 266. StringBuilder에서의 OutOfMemoryException 오류 원인 분석 [4]파일 다운로드1
1170정성태11/10/201127190.NET Framework: 265. Named 동기화 개체 생성 시 System.UnauthorizedAccessException 예외 발생하는 경우
1169정성태11/10/201130711.NET Framework: 264. 다중 LAN 카드 환경에서 Dns.GetHostAddresses(local)가 반환해 주는 IP의 우선순위는 어떻게 될까요? [4]
1168정성태11/6/201126614오류 유형: 139. TlbImp : error TI0000 : A single valid machine type compatible with the input type library must be specified
1167정성태11/5/201138414개발 환경 구성: 133. Registry 등록 과정 없이 COM 개체 사용 - 두 번째 이야기 [5]파일 다운로드4
1166정성태11/5/201124453.NET Framework: 263. byte[] pData = new byte[100000]로 인한 성능 차이? [1]파일 다운로드1
1165정성태11/3/201129521개발 환경 구성: 132. "Visual Studio Command Prompt (2010)" 명령행에서 2.0 버전의 MSBuild를 구동하는 방법 [2]파일 다운로드1
1164정성태11/1/201127588.NET Framework: 262. .NET 스레드 콜 스택 덤프 (4) - .NET 4.0을 지원하지 않는 MSE 응용 프로그램 원인 분석
1163정성태10/31/201127183.NET Framework: 261. .NET 스레드 콜 스택 덤프 (3) - MSE 소스 코드 개선파일 다운로드1
1162정성태10/30/201127252.NET Framework: 260. .NET 스레드 콜 스택 덤프 (2) - Managed Stack Explorer 소스 코드를 이용한 스택 덤프 구하는 방법파일 다운로드1
1161정성태10/29/201124008.NET Framework: 259. Type.GetMethod - System.Reflection.AmbiguousMatchException파일 다운로드1
1159정성태10/28/201127542.NET Framework: 258. Roslyn 맛보기 - SyntaxTree 조작 [2]
1158정성태10/24/201126694.NET Framework: 257. Roslyn 맛보기 - Roslyn Symbol / Binding API파일 다운로드1
1157정성태10/23/201131273.NET Framework: 256. Roslyn 맛보기 - Syntax Analysis (Roslyn Syntax API) [2]
... 151  152  153  154  155  [156]  157  158  159  160  161  162  163  164  165  ...