在Visual Studio中,我们所有人都有“ baadf00d”,在运行时在C ++中的调试器中检查变量时看到“ CC”和“ CD”。

据我所知,“ “ CC”处于DEBUG模式,仅表示何时对内存进行new()或alloc()并统一化。而“ CD”代表已删除或已释放的内存。我只在RELEASE版本中看到过“ baadf00d”(但我可能错了)。

有一段时间,我们陷入了解决内存泄漏,缓冲区溢出等问题的局面。信息会派上用场。

请问有人可以指出何时以及在哪种模式下将内存设置为可识别的字节模式以进行调试?

评论

操作系统何时以及为何将在malloc / free / new / delete上将内存初始化为0xCD,0xDD等?

@LưuVĩnhPhúc:它不是操作系统,而是调试器。 “ D”(如0xCD和0xDD上的)用于调试(即,如msdn.microsoft.com/en-us/library/aa270812(v=vs.60).aspx中所述,malloc_dbg是通过malloc调用的)。我相信它还会在堆周围添加围栏/柱子以跟踪缓冲区溢出。当您遇到两次删除或多次释放(甚至可能调用delete而不是delete []的错误)和悬空的指针(已处置)并且检查数据时,它是“ 0xDD”,这对于捕获问题非常有用。 (或未初始化的堆显示0xCD时)

我没有说是操作系统。是其他提问者错误地写了标题

何时以及为什么操作系统会在malloc / free / new / delete上将内存初始化为0xCD,0xDD等的可能重复项?

#1 楼

该链接具有更多信息:
https://en.wikipedia.org/wiki/Magic_number_(programming)#Debug_values
* 0xABABABAB : Used by Microsoft's HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory
* 0xABADCAFE : A startup to this value to initialize all free memory to catch errant pointers
* 0xBAADF00D : Used by Microsoft's LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory
* 0xBADCAB1E : Error Code returned to the Microsoft eVC debugger when connection is severed to the debugger
* 0xBEEFCACE : Used by Microsoft .NET as a magic number in resource files
* 0xCCCCCCCC : Used by Microsoft's C++ debugging runtime library to mark uninitialised stack memory
* 0xCDCDCDCD : Used by Microsoft's C++ debugging runtime library to mark uninitialised heap memory
* 0xDDDDDDDD : Used by Microsoft's C++ debugging heap to mark freed heap memory
* 0xDEADDEAD : A Microsoft Windows STOP Error code used when the user manually initiates the crash.
* 0xFDFDFDFD : Used by Microsoft's C++ debugging heap to mark "no man's land" guard bytes before and after allocated heap memory
* 0xFEEEFEEE : Used by Microsoft's HeapFree() to mark freed heap memory


评论


在这里,我看到了BAADF00D(坏食物),BEEFCACE(牛肉蛋糕),BAADCAB1E(坏电缆),BADCAFE(坏咖啡馆)和DEADDEAD(死者)。这是故意的吗?

–安德森·格林(Anderson Green)
13年2月16日在4:23



@AndersonGreen当然是故意的。叫做hexspeak。

–user142019
2013年5月9日14:20



过去,当我们进行一些低级(操作系统内核)编程时,我们曾经使用C0CAC01A ...;)

– Per Lundberg
2013年9月4日在12:36

即使0xDEADBEEF,0xC0EDBABE也没有成为MS的母语,它们也很经典

– J. Paulding
15年4月8日在18:52

作为Paul McCartney的粉丝,我喜欢BEA71E5

– BlueRaja-Danny Pflughoeft
2015年6月6日18:22



#2 楼

实际上,有很多有用的信息添加到调试分配中。该表更加完整:

http://www.nobugs.org/developer/win32/debug_crt_heap.html#table

Address  Offset After HeapAlloc() After malloc() During free() After HeapFree() Comments
0x00320FD8  -40    0x01090009    0x01090009     0x01090009    0x0109005A     Win32 heap info
0x00320FDC  -36    0x01090009    0x00180700     0x01090009    0x00180400     Win32 heap info
0x00320FE0  -32    0xBAADF00D    0x00320798     0xDDDDDDDD    0x00320448     Ptr to next CRT heap block (allocated earlier in time)
0x00320FE4  -28    0xBAADF00D    0x00000000     0xDDDDDDDD    0x00320448     Ptr to prev CRT heap block (allocated later in time)
0x00320FE8  -24    0xBAADF00D    0x00000000     0xDDDDDDDD    0xFEEEFEEE     Filename of malloc() call
0x00320FEC  -20    0xBAADF00D    0x00000000     0xDDDDDDDD    0xFEEEFEEE     Line number of malloc() call
0x00320FF0  -16    0xBAADF00D    0x00000008     0xDDDDDDDD    0xFEEEFEEE     Number of bytes to malloc()
0x00320FF4  -12    0xBAADF00D    0x00000001     0xDDDDDDDD    0xFEEEFEEE     Type (0=Freed, 1=Normal, 2=CRT use, etc)
0x00320FF8  -8     0xBAADF00D    0x00000031     0xDDDDDDDD    0xFEEEFEEE     Request #, increases from 0
0x00320FFC  -4     0xBAADF00D    0xFDFDFDFD     0xDDDDDDDD    0xFEEEFEEE     No mans land
0x00321000  +0     0xBAADF00D    0xCDCDCDCD     0xDDDDDDDD    0xFEEEFEEE     The 8 bytes you wanted
0x00321004  +4     0xBAADF00D    0xCDCDCDCD     0xDDDDDDDD    0xFEEEFEEE     The 8 bytes you wanted
0x00321008  +8     0xBAADF00D    0xFDFDFDFD     0xDDDDDDDD    0xFEEEFEEE     No mans land
0x0032100C  +12    0xBAADF00D    0xBAADF00D     0xDDDDDDDD    0xFEEEFEEE     Win32 heap allocations are rounded up to 16 bytes
0x00321010  +16    0xABABABAB    0xABABABAB     0xABABABAB    0xFEEEFEEE     Win32 heap bookkeeping
0x00321014  +20    0xABABABAB    0xABABABAB     0xABABABAB    0xFEEEFEEE     Win32 heap bookkeeping
0x00321018  +24    0x00000010    0x00000010     0x00000010    0xFEEEFEEE     Win32 heap bookkeeping
0x0032101C  +28    0x00000000    0x00000000     0x00000000    0xFEEEFEEE     Win32 heap bookkeeping
0x00321020  +32    0x00090051    0x00090051     0x00090051    0xFEEEFEEE     Win32 heap bookkeeping
0x00321024  +36    0xFEEE0400    0xFEEE0400     0xFEEE0400    0xFEEEFEEE     Win32 heap bookkeeping
0x00321028  +40    0x00320400    0x00320400     0x00320400    0xFEEEFEEE     Win32 heap bookkeeping
0x0032102C  +44    0x00320400    0x00320400     0x00320400    0xFEEEFEEE     Win32 heap bookkeeping


#3 楼

特别是关于0xCC0xCD,它们是1980年代的Intel 8088/8086处理器指令集的遗物。 0xCC是软件中断操作码INT 0xCD的特例。特殊的单字节版本0xCC允许程序生成中断3。虽然原则上软件中断号是任意的,但传统上将INT 3用于调试器的break或breakpoint函数,该约定仍然存在。到今天。每当启动调试器时,它都会为INT 3安装一个中断处理程序,以便在执行该操作码时将触发调试器。通常,它将暂停当前正在运行的程序并显示交互式提示。

通常,x86 INT操作码为两个字节:0xCD,后跟所需的中断号(0-255)。现在,尽管您可以为0xCD 0x03发行INT 3,但是Intel决定添加一个特殊版本-0xCC,不带附加字节-因为操作码必须仅为一个字节,才能用作未使用内存的可靠“填充字节”。 />
这里的意思是,如果处理器错误地跳入了不包含任何预期指令的内存,则可以进行正常恢复。多字节指令不适合此目的,因为错误的跳转可能会落在任何可能的字节偏移处,在这种情况下它必须继续以正确格式的指令流继续执行。

显然,一字节操作码可以正常工作为此,但也可能有一些古怪的例外:例如,考虑填充序列0xCDCDCDCD(也在本页上提到),我们可以看到它是相当可靠的,因为无论指令指针到达何处(最后一个填充字节除外) ,CPU可以继续执行有效的两字节x86指令CD CD,在这种情况下,会产生软件中断205(0xCD)。

尽管CD CC CD CC是100%可解释的(给出INT 3INT 204),但是序列CC CD CC CD的可靠性较差,如图所示仅为75%,但作为整数大小的内存填充物重复使用时通常为99.99%。

宏汇编程序参考,1987年

评论


哇,我没有意识到(连接两个)0xCC是INT3。这是有道理的(即不是巧合)。我曾经在有JMP检查寄存器的地方注入“ NOP + INT3”,然后才有几次出现跳跃(回溯到何时)。感谢您的见解,神秘感得到了解决!

– HidekiAI
18年1月20日在14:54

NOP的用途是什么?使用eb(输入字节)命令输入单个0xCC字节是否足够?

– Glenn Slayden
18年1月20日在23:34

只是一种习惯,那时,某些代码会读取两个字节并尝试将其用作跳转表,或者在某些情况下,当我列出汇编代码时,通过添加NOP,它不会显示为“ ???”。或拆卸时的东西(更清晰);总而言之,出于多种原因,在BRK之前或之后注入NOP成为一种习惯。哦,在某些情况下,某些应用程序会尝试对地址块进行校验和,因此我会用INT3 + [some-hex]笑容平衡JMP $ XYZW

– HidekiAI
18-2-5在13:45