Microsoft MVP성태의 닷넷 이야기
VC++: 112. C++의 가상 함수 테이블 (vtable)은 언제 생성될까요? [링크 복사], [링크+제목 복사]
조회: 6527
글쓴 사람
홈페이지
첨부 파일
 

C++의 가상 함수 테이블 (vtable)은 언제 생성될까요?

실습을 위해 다음과 같이 간단한 상속 코드를 만들어 보겠습니다.

#include "stdafx.h"

class A
{
public:
    int n1 = 1;

    void func1() { n1++; }

    virtual void vfunc1() { }
};

class BonA : A
{
public:
    int n2 = 2;

    void func2() { n2++; }

    virtual void vfunc2() { }
};

class ConBonA : BonA
{
public:
    int n3 = 2;

    void func3() { n3++; }

    virtual void vfunc3() { }
};

int main()
{
    ConBonA *table1 = new ConBonA();
    ConBonA *table2 = new ConBonA();

    return 0;
}

이제 디버그 모드로 실행하면서 생성자 호출로 인한 코드를 한번 살펴보겠습니다.

우선, new ConBonA 코드로 메모리가 할당되고 그 위치를 ecx 포인터에 this 값으로 전달하면서 생성자를 호출합니다.

    38:     ConBonA *table1 = new ConBonA();
00CE1A29 8B 8D 20 FF FF FF    mov         ecx,dword ptr [table1]  
00CE1A40 E8 CE F6 FF FF       call        ConBonA::ConBonA (0CE1113h)  

ConBonA의 생성자를 가보면,

ConBonA::ConBonA:
00CE18E6 E8 12 FA FF FF       call        BonA::BonA (0CE12FDh)  
...[생략]...
00CE1914 C3                   ret  

자신의 클래스에서 해야 하는 일보다 먼저 기반 클래스의 생성자를 호출합니다. 다시 BonA 생성자로 가면,

BonA::BonA:
00CE1876 E8 28 FA FF FF       call        A::A (0CE12A3h)  
...[생략]...
00CE18A4 C3                   ret  

마찬가지로 자신의 클래스를 위한 초기 코드보다는 기반 클래스의 생성자를 호출합니다. 이제 가장 상단에 위치하는 기반 클래스 A의 생성자는,

A::A:
00CE1823 8B 45 F8             mov         eax,dword ptr [this]  
00CE1826 C7 00 34 7B CE 00    mov         dword ptr [eax],offset A::`vftable' (0CE7B34h)  
...[생략: n1 = 1과 같은 생성자 함수의 초기화 코드]...
00CE183F C3                   ret  

"ConBonA *table1 = new ConBonA();" 코드로 메모리가 할당된 table1 주소에 "class A"를 컴파일하면서 구성해놓았던 "vtable"의 주소를 첫 번째 4바이트에 씁니다. 그래서 위의 코드까지만 실행된 상태에서는 this 포인터 주소의 내용이 다음과 같이 구성됩니다.

[오프셋12: 필드 ConBonA::n3]         - 4바이트
[오프셋 8: 필드 BonA::n2]            - 4바이트
[오프셋 4: 필드 A::n1]               - 4바이트
[오프셋 0: A 클래스의 vtable 포인터]  - 4바이트

그리고 "A 클래스의 vtable 포인터"가 가리키는 주소를 가보면 다음과 같이 구성되어 있습니다.

오프셋 0: [A:vfunc1 함수 주소]

그러니까... 적어도 main 함수 실행 중에는 vtable의 내용이 이미 구성된 상태인 것입니다. 게다가 vtable의 값은 instance 별로 생성되는 것이 아닌, 클래스 별로 생성된다는 것을 알 수 있습니다.




조금 더 깊게 파헤쳐 볼까요? ^^

결론부터 말하면, vtable은 컴파일러가 해당 소스 코드 파일을 컴파일하면서 알아낸 정보를 바탕으로 PE 파일의 Section에 미리 기록해 둡니다. 재미 삼아서 계산까지 한번 해보겠습니다. ^^

Visual Studio에서 디버깅 모드로 예제 EXE 프로그램을 실행시킨 후, "Ctrl + Alt + U" 키를 눌러 "Modules" 창을 띄우면 EXE 파일의 이미지 로딩 주소를 알아낼 수 있습니다. (코드로는 GetModuleHandle Win32 API로 반환받은 HMODULE 값이 됩니다.) EXE 파일의 경우 IMAGE_OPTIONAL_HEADER에 지정된 "Image Base (보통 0x400000)"로 로딩이 되지만 Vista 운영체제부터는 ASLR 덕분에 주소가 가변으로 바뀝니다. 제 경우에 테스트 용 ConsoleApplication1.exe의 이미지 매핑이 "00CD0000-00CEF000"로 되어 있었습니다.

그다음, "mov dword ptr [eax],offset A::`vftable' (0CE7B34h)"로 나왔던 0x00ce7b34 주소에서 0x00cd0000 기반 주소를 빼면,

0CE7B34h - 0x00cd0000 = 0x17b34

0x17b34 변위가 나오고 이를 ConsoleApplication1.exe 파일에 기록된 IMAGE_SECTION_HEADER들의 정보를 통해 어느 Section에 있는지 찾아낼 수 있습니다. 대개의 경우, Visual C++라면 다음과 같이 ".rdata" 섹션에서 찾을 수 있습니다.

about_vtable_1.png

.rdata 섹션의 RVA 값이 0x00017000이고 크기가 0x2564이기 때문에,

0x17000 <= 0x17b34 <= 0x19564

0x17b34 변위가 정확히 .rdata 섹션의 범위안에 드는 것을 볼 수 있습니다. 그럼, Visual C++가 .rdata 섹션에 기록한 vtable 내용을 찾아볼까요?

.rdata 섹션의 시작이 0x17000 위치이니, vtable이 위치한 주소의 섹션 내 변위는 "0x17b34 - 0x17000 = 0xb34"가 됩니다. ConsoleApplication1.exe의 PE 정보에서 .rdata 섹션의 파일 위치 정보를 가리키는 "Pointer to Raw Data" 값이 0x5c00라고 했으니 "0x5c00 + 0xb34 = 0x6734"가 됩니다. 이 위치를 찾아 보면,

about_vtable_2.png

오프셋 0: 0x00411361 (A::vfunc1 가상 함수를 가리키는 주소)

위와 같이 값이 담겨 있습니다. 메모리에서와 마찬가지로 A 클래스의 가상 함수가 1개이기 때문에 PE 파일의 Section 내에도 1개가 보입니다. 물론, 이 값들이 그대로 가상 함수의 주소로 사용되지는 않습니다. 왜냐하면 ASLR로 인해 컴파일러가 가정한 Image Base 주소가 0x400000에서 0x00CD0000으로 변경되었기 때문에 이미지 로딩 시에 Relocation 계산이 이뤄져서 그 값이 반영된 주소로 메모리에서는 덮어써집니다. 역시 직접 계산을 해볼까요? ^^

우선 조정된 Image Base 주소의 차이를 계산하고,

0x00CD0000 - 0x400000 = 0x8d0000

그 값에 PE 파일에서 찾아낸 vtable의 함수 주소인 0x00411361을 더하면,

0x8d0000 + 0x411361 = 0xce1361

정확히 0x00ce1361이 나옵니다. 이 값을 디버깅 중인 A 클래스의 생성자에 있던,

mov         dword ptr [eax],offset A::`vftable' (0CE7B34h)

0CE7B34h 주소를 메모리 창으로 확인하면 동일한 값이 나오는 것을 볼 수 있습니다.

about_vtable_3.png




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 3/29/2017 ]

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

비밀번호

댓글 쓴 사람
 



2019-10-31 04시25분
[test] 저 혹시 우선, new ConBonA 코드로 메모리가 할당되고 그 위치를 ecx 포인터에 this 값으로 전달하면서 생성자를 호출합니다. 이부분까지는
비쥬얼 스튜디오 디어셈으로 찾았는데

ConBonA의 생성자를 가보면, 생성자는 디폴트 생성자라서 디어셈에 안뜨는건지 제가 못찾겠는데 어떻게 찾아야 할까요?? ㅠㅠ
디어셈상태에서는 주소 검색도 못하고 이동도 안되네여
[손님]
2019-11-01 12시27분
"Disassembly (Alt+G)" 창을 이용하면 어셈블리 코드 단위로 F11 키를 눌러 디버깅 트레이스를 할 수 있습니다. 따라서 다음의 라인까지 디버깅을 진행한 다음,

00CE1A40 E8 CE F6 FF FF call ConBonA::ConBonA (0CE1113h)

F11 키를 눌러 생성자 안으로 진입하면 됩니다.
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12076정성태12/12/201952디버깅 기술: 142. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅 - 배포 방법에 따른 차이
12075정성태12/12/201964디버깅 기술: 141. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅
12074정성태12/11/201949디버깅 기술: 140. windbg/Visual Studio - 값이 변경된 경우를 위한 정지점(BP) 설정(Data Breakpoint)
12073정성태12/10/201966Linux: 24. Linux/C# - 실행 파일이 아닌 스크립트 형식의 명령어를 Process.Start로 실행하는 방법
12072정성태12/9/201938오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
12071정성태12/9/201941오류 유형: 582. 리눅스 디스크 공간 부족 및 safemode 부팅 방법
12070정성태12/9/201936오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/2/2019155디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/2019165디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [1]파일 다운로드2
12067정성태11/27/2019146디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201987디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/2019107디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201973오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/2019108디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/2019103디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201998Windows: 165. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/21/2019124디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
12059정성태11/20/2019124디버깅 기술: 131. windbg/Visual Studio - HeapFree x86의 동작 분석
12058정성태11/19/2019126디버깅 기술: 130. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례
12057정성태11/18/201979오류 유형: 579. Visual Studio - Memory 창에서 유효한 주소 영역임에도 "Unable to evaluate the expression." 오류 출력
12056정성태11/18/2019140개발 환경 구성: 464. "Microsoft Visual Studio Installer Projects" 프로젝트로 EXE 서명 및 MSI 파일 서명 방법파일 다운로드1
12055정성태11/17/201987개발 환경 구성: 463. Visual Studio의 Ctrl + Alt + M, 1 (Memory 1) 등의 단축키가 동작하지 않는 경우
12054정성태11/15/2019296.NET Framework: 869. C# - 일부러 GC Heap을 깨뜨려 GC 수행 시 비정상 종료시키는 예제
12053정성태11/15/201990Windows: 164. 윈도우 10 - 명령행 창(cmd.exe) 속성에 (DotumChe, GulimChe, GungsuhChe 등의) 한글 폰트가 없는 경우
12052정성태11/15/201984오류 유형: 578. Azure - 일정(schedule)에 등록한 runbook이 1년 후 실행이 안 되는 문제(Reason - The key used is expired.)
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...