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

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)
12254정성태7/2/202024오류 유형: 626. git - REMOTE HOST IDENTIFICATION HAS CHANGED!
12253정성태7/2/202055.NET Framework: 922. C# - .NET ThreadPool의 Local/Global Queue파일 다운로드1
12252정성태7/2/202053.NET Framework: 921. C# - I/O 스레드를 사용한 비동기 소켓 서버/클라이언트파일 다운로드2
12251정성태7/1/202081.NET Framework: 920. C# - 파일의 비동기 처리 유무에 따른 스레드 상황파일 다운로드2
12250정성태7/1/2020256.NET Framework: 919. C# - 닷넷에서의 진정한 비동기 호출을 가능케 하는 I/O 스레드 사용법 [1]파일 다운로드1
12249정성태6/29/202027오류 유형: 625. Microsoft SQL Server 2019 RC1 Setup - 설치 제거 시 Warning 26003 오류 발생
12248정성태6/29/202024오류 유형: 624. SQL 서버 오류 - service-specific error code 17051
12247정성태6/29/202097.NET Framework: 918. C# - 불린 형 상수를 반환값으로 포함하는 3항 연산자 사용 시 단축 표현 권장(IDE0075) [2]파일 다운로드1
12246정성태6/29/202054.NET Framework: 917. C# - USB 관련 ETW(Event Tracing for Windows)를 이용한 키보드 입력을 감지하는 방법
12245정성태6/25/2020174.NET Framework: 916. C# - Task.Yield 사용법 (2) [2]파일 다운로드1
12244정성태6/29/202073.NET Framework: 915. ETW(Event Tracing for Windows)를 이용한 닷넷 프로그램의 내부 이벤트 활용파일 다운로드1
12243정성태6/23/202054VS.NET IDE: 147. Visual C++ 프로젝트 - .NET Core EXE를 "Debugger Type"으로 지원하는 기능 추가
12242정성태6/24/202031오류 유형: 623. AADSTS90072 - User account '...' from identity provider 'live.com' does not exist in tenant 'Microsoft Services'
12241정성태6/26/2020104.NET Framework: 914. C# - Task.Yield 사용법파일 다운로드1
12240정성태6/23/202073오류 유형: 622. 소켓 바인딩 시 "System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions" 오류 발생
12239정성태6/21/202055Linux: 30. (윈도우라면 DLL에 속하는) .so 파일이 텍스트로 구성된 사례
12238정성태6/21/202084.NET Framework: 913. C# - SharpDX + DXGI를 이용한 윈도우 화면 캡처 라이브러리
12237정성태6/20/202096.NET Framework: 912. 리눅스 환경의 .NET Core에서 "test".IndexOf("\0")가 0을 반환
12236정성태6/19/202053오류 유형: 621. .NET Standard 대상으로 빌드 시 dynamic 예약어에서 컴파일 오류 - error CS0656: Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create'
12235정성태6/19/202039오류 유형: 620. Windows 10 - Inaccessible boot device 블루 스크린
12234정성태6/19/202035개발 환경 구성: 494. NuGet - nuspec의 패키지 스키마 버전(네임스페이스) 업데이트 방법
12233정성태6/19/202033오류 유형: 619. SQL 서버 - The transaction log for database '...' is full due to 'LOG_BACKUP'. - 두 번째 이야기
12232정성태6/19/202025오류 유형: 618. SharePoint - StoreBusyRetryLater 오류
12231정성태6/15/2020105.NET Framework: 911. Console/Service Application을 위한 SynchronizationContext - AsyncContext
12230정성태6/15/202044오류 유형: 617. IMetaDataImport::GetMethodProps가 반환하는 IL 코드 주소(RVA) 문제
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...