Microsoft MVP성태의 닷넷 이야기
디버깅 기술: 89. Win32 Debug CRT Heap Internals의 0xBAADF00D 표시 재현 [링크 복사], [링크+제목 복사]
조회: 5981
글쓴 사람
홈페이지
첨부 파일

Win32 Debug CRT Heap Internals의 0xBAADF00D 표시 재현

다음의 tweet이 있길래,

MS에서는 디버깅용으로 메모리 할당 기본값을 0xBAADF00D(BadFood)를 쓰고, 리눅스에서는 0xFEE1DEAD(Feel Dead)를 reboot() syscall 용으로 쓴다고 ㅋㅋㅋ https://en.wikipedia.org/wiki/Magic_number_(programming) ...


실제로 그런가 한번 해봤습니다. ^^

Wiki에 기록된 내용을 잘 소개하고 있는 글로 다음의 내용이 있습니다.

Win32 Debug CRT Heap Internals
; http://www.nobugs.org/developer/win32/debug_crt_heap.html

내용을 간략하게 정리해 보면.

debug CRT의 malloc을 이용해 8바이트를 할당받으려고 하는 경우 HeapAlloc에게 총 48바이트를 요구하지만, 다음의 그림에서와 같이 HeapAlloc 자체의 정보 및 예약 공간으로 인해 malloc에게 돌려줄 메모리의 앞으로 8바이트, 뒤로 32바이트까지 해서 총 88바이트의 공간이 소요됩니다.

debug_crt_heap_1.png

위의 내용에 따르면 malloc 호출 시 HeapAlloc으로부터 할당받은 메모리는 malloc의 처리를 거치기 전 0xBAADF00D로 채워져 있다고 되어 있습니다. 이것이 정말 사실인지, Visual Studio의 디버거 기능을 이용해 확인해봐야겠습니다. ^^

방법은 간단합니다. malloc 함수 호출에서 "Disassembly" 창을 띄워 따라가다 보면, 다음의 call stack에 따라 결국 HeapAlloc으로부터 메모리를 할당받게 됩니다. (테스트는 Visual Studio 2017 + Windows 10에서 v120_xp Platform toolset 설정으로 한 것입니다.)

__imp__HeapAlloc@12
_heap_alloc_base(unsigned int size)
_heap_alloc_dbg_impl(unsigned int nSize, int nBlockUse, const char * szFileName, int nLine, int * errno_tmp)
_nh_malloc_dbg_impl(unsigned int nSize, int nhFlag, int nBlockUse, const char * szFileName, int nLine, int * errno_tmp)
_nh_malloc_dbg(unsigned int nSize, int nhFlag, int nBlockUse, const char * szFileName, int nLine)
malloc(unsigned int nSize)

우선, debug 버전의 malloc은 8바이트 할당 요구에 대해 HeapAlloc에게 48바이트가 아닌 44바이트의 공간을 요구합니다. 또한, HeapAlloc 호출 후 @eax 레지스터의 내용(0x01756EC8)에 따라 다음과 같이 메모리 창으로 확인해 봤지만 0xBAADF00D 패턴은 찾을 수 없었습니다.

0x01756EC8  c0 00 75 01  ?.u.
0x01756ECC  e0 71 75 01  ?qu.
0x01756ED0  05 00 00 05  ....
0x01756ED4  46 d6 00 00  F?..
0x01756ED8  d0 70 75 01  ?pu.
0x01756EDC  c0 00 75 01  ?.u.
0x01756EE0  2d 00 6c 00  -.l.
0x01756EE4  30 00 2d 00  0.-.
0x01756EE8  02 00 00 02  ....
0x01756EEC  47 d6 00 00  G?..
0x01756EF0  d0 70 75 01  ?pu.

하지만, CRT에 의해 채워지는 내용은 "Win32 Debug CRT Heap Internals" 문서에 따라 그대로 수행되었습니다. 이 작업은 _heap_alloc_dbg_impl에 의해 이뤄지고 다음과 같이 crt Debug 정보로 채워지게 됩니다.

0x01756EC8  68 c0 75 01     [Ptr to next CRT heap block (allocated earlier in time)]
0x01756ECC  00 00 00 00     [Ptr to prev CRT heap block (allocated later in time)]
0x01756ED0  00 00 00 00     [Filename of malloc() call]
0x01756ED4  00 00 00 00     [Line number of malloc() call]
0x01756ED8  08 00 00 00     [Number of bytes to malloc()]
0x01756EDC  01 00 00 00     [Type (0=Freed, 1=Normal, 2=CRT use, etc)]  
0x01756EE0  55 00 00 00     [Request #, increases from 0]
0x01756EE4  fd fd fd fd     [_bNoMansLandFill == 0xfd]  
0x01756EE8  cd cd cd cd     [_bCleanLandFill == 0xcd] // 사용자가 요구한 8바이트
0x01756EEC  cd cd cd cd     [_bCleanLandFill == 0xcd] // 사용자가 요구한 8바이트
0x01756EF0  fd fd fd fd     [_bNoMansLandFill == 0xfd]  

또한, 사용자가 요구한 메모리는 0xCD로 초기화되었고 그전/후 4바이트는 역시 0xfd로 채워져 있었습니다.




테스트를 위해, "Win32 Debug CRT Heap Internals" 문서의 내용에서 보여주는 offset 값에 따라 debug malloc 호출에 따른 메모리 덤프를 해보았습니다. (소스 코드는 이 글의 첨부 파일에 있습니다.)

다음은 이 프로그램을 Windows 2003 x86 버전에서 실행한 결과입니다.

offset: -40(at 0x00154cf0) == 0x00440007 [Win32 heap info]
offset: -36(at 0x00154cf4) == 0x000c01a4 [Win32 heap info]
offset: -32(at 0x00154cf8) == 0x00156008 [Ptr to next CRT heap block (allocated earlier in time)]
offset: -28(at 0x00154cfc) == 0x00000000 [Ptr to prev CRT heap block (allocated later in time)]
offset: -24(at 0x00154d00) == 0x00000000 [Filename of malloc() call]
offset: -20(at 0x00154d04) == 0x00000000 [Line number of malloc() call]
offset: -16(at 0x00154d08) == 0x00000008 [Number of bytes to malloc()]
offset: -12(at 0x00154d0c) == 0x00000001 [Type (0=Freed, 1=Normal, 2=CRT use, etc)]
offset: -08(at 0x00154d10) == 0x00000040 [Request #, increases from 0]
offset: -04(at 0x00154d14) == 0xfdfdfdfd [No mans land]

offset: 000(at 0x00154d18) == 0xcdcdcdcd [The 8 bytes you wanted]
offset: 004(at 0x00154d1c) == 0xcdcdcdcd [The 8 bytes you wanted]

offset: 008(at 0x00154d20) == 0xfdfdfdfd [No mans land]

offset: 012(at 0x00154d24) == 0xdddddddd [Win32 heap allocations are rounded up to 16 bytes]

offset: 016(at 0x00154d28) == 0x000700bf [Win32 heap bookkepping]
offset: 020(at 0x00154d2c) == 0x00dd00dd [Win32 heap bookkepping]
offset: 024(at 0x00154d30) == 0x00157038 [Win32 heap bookkepping]
offset: 028(at 0x00154d34) == 0x00150178 [Win32 heap bookkepping]
offset: 032(at 0x00154d38) == 0xdddddddd [Win32 heap bookkepping]
offset: 036(at 0x00154d3c) == 0xdddddddd [Win32 heap bookkepping]
offset: 040(at 0x00154d40) == 0xdddddddd [Win32 heap bookkepping]
offset: 044(at 0x00154d44) == 0xdddddddd [Win32 heap bookkepping]

일단, 파란색 굵은 선 내의 내용은 _heap_alloc_dbg_impl에 의해 채워지는 것을 확인한 것으로 MSDN 문서에서도 이에 대해 잘 설명하고 있습니다.

CRT Debug Heap Details
; https://msdn.microsoft.com/en-us/library/974tc9t1.aspx

typedef struct _CrtMemBlockHeader  
{  
// Pointer to the block allocated just before this one:  
    struct _CrtMemBlockHeader *pBlockHeaderNext;  
// Pointer to the block allocated just after this one:  
    struct _CrtMemBlockHeader *pBlockHeaderPrev;  
    char *szFileName;    // File name  
    int nLine;           // Line number  
    size_t nDataSize;    // Size of user block  
    int nBlockUse;       // Type of block  
    long lRequest;       // Allocation number  
// Buffer just before (lower than) the user's memory:  
    unsigned char gap[nNoMansLandSize];  
} _CrtMemBlockHeader;  

/* In an actual memory block in the debug heap,  
 * this structure is followed by:  
 *   unsigned char data[nDataSize];  
 *   unsigned char anotherGap[nNoMansLandSize];  
 */  

하지만 그 외의 내용은 "Win32 Debug CRT Heap Internals" 문서에 따르면 HeapAlloc에 의해 부가적으로 할당되는 영역이라고 하는데 (물론 있긴 하겠지만) 딱히 문서의 내용에 따라 보이는 것 같지는 않습니다. (즉, heap 관련 메모리 분석은 현재로서는 불확실합니다.)

여기서 재미있는 것이 있는데요. _CrtMemBlockHeader->pBlockHeaderNext 포인터가 바로 전의 CRT 메모리 블록을 가리킨다는 점입니다. 실제로 위의 출력 결과에서 -32 오프셋 위치에 있는 0x00156008 메모리가 가리키는 내용은 이전에 할당되었던 _CrtMemBlockHeader의 pBlockHeaderNext 위치를 가리킵니다. 따라서 이 정보를 기반으로 다시 덤프를 해보면 대략 이런 정보를 얻게 됩니다.

========== ptrToNext 0x156008 =========
offset: -40(at 0x00156000) == 0x00090206 [Win32 heap info]
offset: -36(at 0x00156004) == 0x000c013a [Win32 heap info]
offset: -32(at 0x00156008) == 0x00154a28 [Ptr to next CRT heap block (allocated earlier in time)]
offset: -28(at 0x0015600c) == 0x00154cf8 [Ptr to prev CRT heap block (allocated later in time)]
offset: -24(at 0x00156010) == 0x00491844 [Filename of malloc() call]
offset: -20(at 0x00156014) == 0x0000005b [Line number of malloc() call]
offset: -16(at 0x00156018) == 0x00001000 [Number of bytes to malloc()]
offset: -12(at 0x0015601c) == 0x00000002 [Type (0=Freed, 1=Normal, 2=CRT use, etc)]
offset: -08(at 0x00156020) == 0x0000003f [Request #, increases from 0]
offset: -04(at 0x00156024) == 0xfdfdfdfd [No mans land]
... 이하 0x1000 바이트는 이전에 malloc(0x1000)으로 할당받은 메모리 ...

그리고, -08 위치의 "Request #"도 1이 줄어 있습니다. 즉, 우리가 malloc한 메모리는 0x40(64) 번째 할당했던 메모리였던 것입니다. 이런 식이라면, debug 빌드에서의 malloc 메모리를 모두 덤프할 수 있을 것입니다. ^^




테스트를 마치고, "Win32 Debug CRT Heap Internals" 문서의 작성일이 궁금했습니다. 문서에 보면 그 내용을 담고 있다는 책 "Debugging Windows Programs"의 발행 연도가 2000년 8월 28일로 된 것으로 봐서 아마도 Windows 2000 이전의 운영체제에서는 0xBAADF00D 표시가 있었을 것입니다. 하지만 적어도 Windows Server 2003부터는 더 이상 0xBAADF00D 표시는 쓰지 않는 듯싶으니 결국 역사적인 내용으로만 알면 되겠습니다.

트친인 @taehwalee 님이 0xBAADF00D 상태를 재현할 수 있는 힌트를 주었습니다. ^^

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\gflags.exe

gflags를 이용해 "Enable heap free checking" 또는 "Enable heap parameter checking" 또는 "Enable heap validation on call" 중의 하나를 활성화 시키면,

debug_crt_heap_2.png

다음과 같이 간단히 테스트해 볼 수 있습니다.

HANDLE hHeap = HeapCreate(0, 1024, 1024);
LPVOID pVoid = HeapAlloc(hHeap, 0, 8);

DWORD *pData = (DWORD *)pVoid;

for (int i = 0; i < 2; i++)
{
    DWORD value = *(pData + i);
    printf("offset: %03d(at 0x%08x) == 0x%08x\n", i * 4, (pData + i), value);
}

/*
출력 결과:

offset: 000(at 0x019a04a0) == 0xbaadf00d
offset: 004(at 0x019a04a4) == 0xbaadf00d
*/

검색하니 다음의 글에 이에 대한 옵션 소개가 있습니다. ^^

Heap Magic: Process Heap Internals, Part 2
; http://devproconnections.com/development/heap-magic-process-heap-internals-part-2

참고로, 각각의 옵션에 대한 단축 이름은 다음과 같습니다.

hfc - Enable heap free checking
hpc - Enable heap parameter checking
hvc - Enable heap validation on call

예)
gflags /i TestApp.exe +hpc




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

[연관 글]





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

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

비밀번호

댓글 쓴 사람
 



2017-07-31 01시44분
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12163정성태2/27/202047.NET Framework: 899. 익명 함수를 가리키는 delegate 필드에 대한 직렬화 문제
12162정성태2/28/202043디버깅 기술: 166. C#에서 만든 COM 객체를 C/C++로 P/Invoke Interop 시 메모리 누수(Memory Leak) 발생파일 다운로드2
12161정성태2/26/202010오류 유형: 597. manifest - The value "x64" of attribute "processorArchitecture" in element "assemblyIdentity" is invalid.
12160정성태2/26/202030개발 환경 구성: 469. Reg-free COM 개체 사용을 위한 manifest 파일 생성 도구 - COMRegFreeManifest
12159정성태2/26/202012오류 유형: 596. Visual Studio - The project needs to include ATL support
12158정성태2/26/202044디버깅 기술: 165. C# - Marshal.GetIUnknownForObject/GetIDispatchForObject 사용 시 메모리 누수(Memory Leak) 발생파일 다운로드1
12157정성태2/27/202058디버깅 기술: 164. C# - Marshal.GetNativeVariantForObject 사용 시 메모리 누수(Memory Leak) 발생 및 해결 방법파일 다운로드1
12156정성태2/25/202027오류 유형: 595. LINK : warning LNK4098: defaultlib 'nafxcw.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
12155정성태2/25/202028오류 유형: 594. Warning NU1701 - This package may not be fully compatible with your project
12154정성태2/25/202033오류 유형: 593. warning LNK4070: /OUT:... directive in .EXP differs from output filename
12153정성태2/23/202074.NET Framework: 898. Trampoline을 이용한 후킹의 한계파일 다운로드1
12152정성태2/23/202065.NET Framework: 897. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 세 번째 이야기(Trampoline 후킹)파일 다운로드1
12151정성태2/23/202070.NET Framework: 896. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 - 두 번째 이야기 (원본 함수 호출)파일 다운로드1
12150정성태2/23/202077.NET Framework: 895. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법파일 다운로드1
12149정성태2/20/202059.NET Framework: 894. eBEST C# XingAPI 래퍼 - 연속 조회 처리 방법
12148정성태2/23/2020127디버깅 기술: 163. x64 환경에서 구현하는 다양한 Trampoline 기법
12147정성태2/27/2020119디버깅 기술: 162. x86/x64의 기계어 코드 최대 길이
12146정성태2/18/202094.NET Framework: 893. eBEST C# XingAPI 래퍼 - 로그인 처리파일 다운로드1
12145정성태2/18/202078.NET Framework: 892. eBEST C# XingAPI 래퍼 - Sqlite 지원 추가파일 다운로드1
12144정성태2/23/2020145.NET Framework: 891. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 두 번째 이야기파일 다운로드1
12143정성태2/13/202092.NET Framework: 890. 상황별 GetFunctionPointer 반환값 정리 - x64파일 다운로드1
12142정성태2/27/2020127.NET Framework: 889. C# 코드로 접근하는 MethodDesc, MethodTable파일 다운로드1
12141정성태2/10/2020181.NET Framework: 888. C# - ASP.NET Core 웹 응용 프로그램의 출력 가로채기 [1]파일 다운로드1
12140정성태2/10/2020128.NET Framework: 887. C# - ASP.NET 웹 응용 프로그램의 출력 가로채기파일 다운로드1
12139정성태2/9/2020188.NET Framework: 886. C# - Console 응용 프로그램에서 UI 스레드 구현 방법
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...