Microsoft MVP성태의 닷넷 이야기
디버깅 기술: 200. DLL Export/Import의 Hint 의미 [링크 복사], [링크+제목 복사],
조회: 8076
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 

(시리즈 글이 4개 있습니다.)
.NET Framework: 872. C# - 로딩된 Native DLL의 export 함수 목록 출력
; https://www.sysnet.pe.kr/2/0/12093

디버깅 기술: 197. Windbg - PE 포맷의 Export Directory 탐색
; https://www.sysnet.pe.kr/2/0/13689

디버깅 기술: 199. Windbg - 리눅스에서 뜬 닷넷 응용 프로그램 덤프 파일에 포함된 DLL의 Export Directory 탐색
; https://www.sysnet.pe.kr/2/0/13692

디버깅 기술: 200. DLL Export/Import의 Hint 의미
; https://www.sysnet.pe.kr/2/0/13700




DLL Export/Import의 Hint 의미

지난 글에 만든 C++ 예제를,

Windbg - PE 포맷의 Export Directory 탐색
; https://www.sysnet.pe.kr/2/0/13689

dumpbin으로 /exports 옵션을 사용해 보면 이런 출력이 나옵니다.

c:\temp> dumpbin Dll1.dll /exports
...[생략]...

    ordinal hint RVA      name

        100    0 00011122 fnDll1 = @ILT+285(?fnDll1@@YAHXZ)
        103    1 00011050 fnDll2 = @ILT+75(?fnDll2@@YAHXZ)
...[생략]...

재미있게도, Hint라는 칼럼이 나오는데요, Export DataDirecotry를 분석해 본 적이 있다면 그 영역의 어떠한 데이터도 Hint라는 값이 존재하지 않다는 것을 아실 것입니다.

그렇다면 저게 도대체 뭘까요?

지난 글에서 설명했듯이, DLL의 export 함수를 사용하는 측에서는 해당 함수를 식별하는 용도로 "Ordinal"과 "Name"을 사용할 수 있습니다. 그리고 성능은 Ordinal이 Name보다 빠른 이유를 설명했는데요, 그렇긴 해도 다들 일반적으로는 "Name"을 사용하는 것이 관례가 되었습니다.

여기서 문제는, Name인 경우 그 함수의 실제 주소를 얻기 위해서는 AddressOfNames가 가리키는 위치의 테이블에서 문자열 비교를 통해 일치하는 이름을 찾아낸 다음, AddressOfNameOrdinals로부터 다시 Ordinal을 구해 AddressOfFunctions로 구해야 하는 번거로움이 있다는 점입니다.

그리고, 저 과정에서 (물론, 근래의 PC에서는 미미하지만) 가장 성능에 영향을 미치는 지점이 AddressOfNames로부터 일일이 문자열 검색을 거쳐야 하는 부분임을 짐작할 수 있습니다.

바로 저 문자열 검색 단계를 줄이기 위해 Hint가 사용됩니다. 가령, 위의 예제에서는 fnDll2 함수를 사용하려는 측에서 "fnDll2" 이름과 함께 Hint로 1을 함께 보관해 Import DataDirectory 영역에 보관해 두는 것입니다. 그럼, 이후 실행 시 Hint 1을 보고 곧바로 (이름을 검색할 필요 없이) AddressOfNameOrdinals[1]에 해당하는 이름을 가져와 "fnDll2" 함수 이름과 비교해 일치하면 AddressOfNameOrdinals 단계로 곧바로 넘어갈 수 있습니다.

즉, 단 한 번의 문자열 비교로 함수를 찾아낸 것입니다. 이것이 Hint의 역할입니다.

당연히, 저 Hint는 Export DataDirecotry 영역에는 없습니다. 그냥 단지 이름순에 따라 나오는 +1 증가의 번호일 뿐입니다. 그러다 보니, DLL이 바뀌는 경우 저 Hint는 바뀔 수 있습니다.

예를 들어, 위의 예제에서 다음과 같은 함수를 새롭게 export 하면,

// 헤더
DLL1_API int fnDll0(void);

// 구현 파일
DLL1_API int fnDll0(void)
{
    printf("Hello from Dll0\n");
    return 0;
}

// Source.def
LIBRARY
EXPORTS
    fnDll1 @100
    fnDll2 @103
    fnDll0 @104

이제 dumpbin /exports의 실행 결과는 이렇게 바뀝니다.

ordinal hint RVA      name

    104    0 00011087 fnDll0 = @ILT+130(?fnDll0@@YAHXZ)
    100    1 00011127 fnDll1 = @ILT+290(?fnDll1@@YAHXZ)
    103    2 00011050 fnDll2 = @ILT+75(?fnDll2@@YAHXZ)

"fnDll0" 함수가 가장 앞단에 나오고 Hint는 0이 되었습니다. 왜냐하면, AddressOfNames가 담고 있는 테이블의 함수 이름은 검색 속도를 향상시키기 위해 정렬돼 있기 때문입니다.

// fnDll0 추가 전 AddressOfNames
[0] == fnDll1 문자열을 담고 있는 RVA
[1] == fnDll2 문자열을 담고 있는 RVA

// fnDll0 추가 후 AddressOfNames
[0] == fnDll0 문자열을 담고 있는 RVA
[1] == fnDll1 문자열을 담고 있는 RVA
[2] == fnDll2 문자열을 담고 있는 RVA

이렇게 되면 어떤 문제가 발생할까요? fnDll0이 추가되기 전 해당 DLL과 링크한 EXE는 fnDll2에 대한 Hint를 1로 보관하고 있을 것입니다. 그런데, DLL 업데이트 후 이것이 2로 바뀌었으니 예전 버전으로 링크한 EXE는 자칫 fnDll1 함수를 호출하는 상황이 벌어졌습니다.

바로 이런 문제를 해결하기 위해, Hint로 AddressOfNames[1]에 해당하는 이름을 구해 그것과 현재의 "fnDll2" 함수 이름을 비교해 일치하는지를 검사하는 단계를 DLL Loader는 가지고 있습니다. 따라서, 위와 같은 경우 그 이름이 일치하지 않으므로 Loader는 어쩔 수 없이 Hint는 무시하고 다시 "fnDll2" 이름에 해당하는 함수를 AddressOfNames에서 찾아내는 과정을 거칩니다.

그리고, 그 검색 과정을 배열에 의한 순차 검색이 아니라, 이것조차 속도를 높이기 위해 AddressOfNames의 테이블은 정렬돼 있으므로 2진 검색을 사용하게 됩니다. 그러니까, 2진 검색을 위해 정렬된 AddressOfNames가 아이러니하게도 Hint를 사용하지 못하게 되는 원인이 된 것입니다.




Visual C++의 경우, DLL 측에서 Ordinal을 함수에 지정했다면 사용하는 측에서는 Import DataDirectory에 Hint를 보관하지 않습니다. 하지만, Ordinal이 없는 경우라면 Name과 함께 Hint를 보관합니다. 물론, DLL의 변화로 Hint가 맞지 않은 경우에도 재검색을 수행하므로 잘 동작합니다.

그나저나, Hint에 대해 웹상에서도 헷갈리는 글들이 있습니다. 가령 아래의 Q&A에서도,

hint in the _IMAGE_IMPORT_BY_NAME structure
; https://masm32.com/board/index.php?topic=6145.0

다음과 같은 답변이 있습니다.

The hint is an index value used to quickly find the import name. It is just an incrementing number. If the hint is correct and the index points to the named function then the import is found quickly. If the hint is incorrect and doesn't point to the named function then a slower search by string is used to find the import.
Ordinal = hint + 1502


전체적인 답변은 맞지만, 하필 마지막 줄의 공식이 상황에 따라서는 틀리게 됩니다. 가령, DLL이 Ordinal을 def 파일을 통해 명시하지 않는다면 제가 만든 DLL의 경우 다음과 같은 /exports 결과가 나옵니다.

    00000000 characteristics
    FFFFFFFF time date stamp
        0.00 version
           1 ordinal base
           3 number of functions
           3 number of names

    ordinal hint RVA      name

          1    0 0001122B fnDll0 = @ILT+550(fnDll0)
          2    1 00011096 fnDll1 = @ILT+145(fnDll1)
          3    2 00011069 fnDll2 = @ILT+100(fnDll2)

따라서, 이런 경우는 "Ordinal = hint + (ordinal base) 1" 공식이 맞습니다. 하지만, 만약 def 파일을 통해 Ordinal을 (이번 글의 Source.def처럼) 설정했다면,

    00000000 characteristics
    FFFFFFFF time date stamp
        0.00 version
         100 ordinal base
           5 number of functions
           3 number of names

ordinal hint RVA      name

    104    0 00011087 fnDll0 = @ILT+130(?fnDll0@@YAHXZ)
    100    1 00011127 fnDll1 = @ILT+290(?fnDll1@@YAHXZ)
    103    2 00011050 fnDll2 = @ILT+75(?fnDll2@@YAHXZ)

이제 저 공식(104 != 0 + 100)은 더 이상 유효하지 않습니다.




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







[최초 등록일: ]
[최종 수정일: 7/31/2024]

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

비밀번호

댓글 작성자
 




... [76]  77  78  79  80  81  82  83  84  85  86  87  88  89  90  ...
NoWriterDateCnt.TitleFile(s)
12036정성태10/14/201925525.NET Framework: 866. C# - 고성능이 필요한 환경에서 GC가 발생하지 않는 네이티브 힙 사용파일 다운로드1
12035정성태10/13/201919624개발 환경 구성: 461. C# 8.0의 #nulable 관련 특성을 .NET Framework 프로젝트에서 사용하는 방법 [2]파일 다운로드1
12034정성태10/12/201918964개발 환경 구성: 460. .NET Core 환경에서 (프로젝트가 아닌) C# 코드 파일을 입력으로 컴파일하는 방법 [1]
12033정성태10/11/201923175개발 환경 구성: 459. .NET Framework 프로젝트에서 C# 8.0/9.0 컴파일러를 사용하는 방법
12032정성태10/8/201919287.NET Framework: 865. .NET Core 2.2/3.0 웹 프로젝트를 IIS에서 호스팅(Inproc, out-of-proc)하는 방법 - AspNetCoreModuleV2 소개
12031정성태10/7/201916574오류 유형: 569. Azure Site Extension 업그레이드 시 "System.IO.IOException: There is not enough space on the disk" 예외 발생
12030정성태10/5/201923380.NET Framework: 864. .NET Conf 2019 Korea - "닷넷 17년의 변화 정리 및 닷넷 코어 3.0" 발표 자료 [1]파일 다운로드1
12029정성태9/27/201924216제니퍼 .NET: 29. Jennifersoft provides a trial promotion on its APM solution such as JENNIFER, PHP, and .NET in 2019 and shares the examples of their application.
12028정성태9/26/201919174.NET Framework: 863. C# - Thread.Suspend 호출 시 응용 프로그램 hang 현상을 해결하기 위한 시도파일 다운로드1
12027정성태9/26/201914852오류 유형: 568. Consider app.config remapping of assembly "..." from Version "..." [...] to Version "..." [...] to solve conflict and get rid of warning.
12026정성태9/26/201920254.NET Framework: 862. C# - Active Directory의 LDAP 경로 및 정보 조회
12025정성태9/25/201918583제니퍼 .NET: 28. APM 솔루션 제니퍼, PHP, .NET 무료 사용 프로모션 2019 및 적용 사례 (8) [1]
12024정성태9/20/201920514.NET Framework: 861. HttpClient와 HttpClientHandler의 관계 [2]
12023정성태9/18/201920967.NET Framework: 860. ServicePointManager.DefaultConnectionLimit와 HttpClient의 관계파일 다운로드1
12022정성태9/12/201924910개발 환경 구성: 458. C# 8.0 (Preview) 신규 문법을 위한 개발 환경 구성 [3]
12021정성태9/12/201940718도서: 시작하세요! C# 8.0 프로그래밍 [4]
12020정성태9/11/201923895VC++: 134. SYSTEMTIME 값 기준으로 특정 시간이 지났는지를 판단하는 함수
12019정성태9/11/201917444Linux: 23. .NET Core + 리눅스 환경에서 Environment.CurrentDirectory 접근 시 주의 사항
12018정성태9/11/201916248오류 유형: 567. IIS - Unrecognized attribute 'targetFramework'. Note that attribute names are case-sensitive. (D:\lowSite4\web.config line 11)
12017정성태9/11/201920052오류 유형: 566. 비주얼 스튜디오 - Failed to register URL "http://localhost:6879/" for site "..." application "/". Error description: Access is denied. (0x80070005)
12016정성태9/5/201920058오류 유형: 565. git fetch - warning: 'C:\ProgramData/Git/config' has a dubious owner: '(unknown)'.
12015정성태9/3/201925481개발 환경 구성: 457. 윈도우 응용 프로그램의 Socket 연결 시 time-out 시간 제어
12014정성태9/3/201919243개발 환경 구성: 456. 명령행에서 AWS, Azure 등의 원격 저장소에 파일 관리하는 방법 - cyberduck/duck 소개
12013정성태8/28/201922132개발 환경 구성: 455. 윈도우에서 (테스트) 인증서 파일 만드는 방법 [3]
12012정성태8/28/201926713.NET Framework: 859. C# - HttpListener를 이용한 HTTPS 통신 방법
12011정성태8/27/201926268사물인터넷: 57. C# - Rapsberry Pi Zero W와 PC 간 Bluetooth 통신 예제 코드파일 다운로드1
... [76]  77  78  79  80  81  82  83  84  85  86  87  88  89  90  ...