XSLT存档  

不及格的程序员-八神

 查看分类:  ASP.NET XML/XSLT JavaScripT   我的MSN空间Blog

在软件调试的角度看,某种类型的数据都有它特别的特征码,就像以前的病毒,看到特征码就知道是什么类型的病毒

我们从16制格式的内存数据中也能猜出某段内存数据是什么相关类型数据,比如位图,文本 Ascii码,被free的内存(0xFEEEFEEE),刚被初始化的内存 ,栈:(0xCCCCCCCC)烫 堆:(0xCDCDCDCD) 都有一定的特征码,不及格的程序员-八神

我在知乎的回答:
0指针不能访问,那那个位置的字节会不会很孤独? - 海格雷尔的回答 - 知乎 https://www.zhihu.com/question/596371908/answer/2996093823

0指针地址是操作系统的后宫外人禁止入内,偶尔有人越过红线,系统会生气,直接杀死来犯者
操作系统规定了许多个内存无人区(NoMansLand),它们不孤独,而且还能一起做游戏,玩过家家。

  • 内存里不能吃不能用的的地方,就会标记为:0xBAADF00D, 食物过期了
  • 内存里刚刚还有人的地方,不过现在没人住了标记为:0xFeeeFeee 这地方空了 (铪铪铪)
  • 内存里还有院墙功能,标记为:0xABABABAB,内存中的变量内容是不能跨过这个栅栏的,因为那是别人家了
  • 内存里刚刚建好的楼盘还没卖出去,标记为:0xCCCCCCCC, 翻译成中文就是烫烫烫烫烫烫人
  • 内存里还有商务区,标记为:0x0ff1ce, 这是专门给微软Office软件用的

微软在内存里成了房地产开发商,Sun看着眼红,之后在周边开起了餐厅。
Java class 标记为:0xCafe babe 第一家咖啡店
Linux看不下去了, 就占了一块地,标记为 0xFee1 Dead, 映射它的函数reboot(),它感觉混身难受时会重新启动,大家一起完蛋。
Apple苹果是个和事姥,拉个横幅标记:0xC00010FF , 代表 Cool Off, 让大家冷静一点。。。

聪明的程序员能从内存地址前面4个字节推断出这里住的是什么人家,大户还是达官贵人。

0019FD62  40 00 C8 91 40 00 1C FE 19 00 20 5F 40 00 00  @.葢@..... _@..
0019FD71  A0 3D 00 CC CC CC CC CC CC CC CC CC CC CC CC  .=.烫烫烫烫烫烫
0019FD80  CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC  烫烫烫烫烫烫烫.
0019FD8F  CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC  烫烫烫烫烫烫烫.
0019FD9E  CC CC CC CC CC CC CC CC CC CC CC CC CC CC CC  烫烫烫烫烫烫烫.
0019FDAD  CC CC CC CC CC CC CC CC CC CC CC 28 FE 19 00  烫烫烫烫烫.(...
0019FDBC  D0 2B 40 00 65 00 00 00 C9 00 00 00 2D 01 00  .+@.e.......-..
0019FDCB  00 7C FE 19 00 20 5F 40 00 00 A0 3D 00 CC CC  .|... _@...=.烫

铪铪 EEFE

char *temp = fileDialog.GetPathName().GetBuffer(0);
GetPathName() 返回的CString 生命周期仅在这个表达式之后,之后就被自动析构了,因为我们没有执有对GetPathName的返回值引用,它的缓冲区自然被free,*temp指向的内容就变成了FEEE  就是这个原因。。。 

 


 

内存保护边界无人区:

  • NoMansLand (0xFD)
    The “NoMansLand” buffers on either side of the memory used by an application are currently filled with 0xFD.

  • Freed blocks (0xDD)
    The freed blocks kept unused in the debug heap’s linked list when the _CRTDBG_DELAY_FREE_MEM_DF flag is set are currently filled with 0xDD.

  • New objects (0xCD)
    New objects are filled with 0xCD when they are allocated.

黑白位图特征:灰度值与透明度 00 代表全黑, 不及格的程序员-八神

00000000`546b0950  b1 b1 b1 b1 ff ff ff ff-ff ff ff ff ff ff ff ff  ................
00000000`546b0960  ff ff ff ff d1 d1 d1 d1-00 00 00 00 00 00 00 00  ................
00000000`546b0970  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000000`546b0980  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000000`546b0990  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000000`546b09a0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000000`546b09b0  00 00 00 00 da da da da-ff ff ff ff ff ff ff ff  ................
00000000`546b09c0  ff ff ff ff ff ff ff ff-a3 a3 a3 a3 00 00 00 00  ................
00000000`546b09d0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000000`546b09e0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000000`546b09f0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000000`546b0a00  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000000`546b0a10  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000000`546b0a20  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000000`546b0a30  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000000`546b0a40  00 00 00 00 00 00 00 00-93 93 93 93 da da da da  ................
00000000`546b0a50  da da da da da da da da-da da da da da da da da  ................
00000000`546b0a60  da da da da da da da da-da da da da da da da da  ................
00000000`546b0a70  b1 b1 b1 b1 82 82 82 82-00 00 00 00 00 00 00 00  ................

 后来我发现国外有一个人做了更详细的介绍:

Win32 Debug CRT Heap Internals

www.nobugs.org

This is Andrew Birkett’s website. I’m a software developer, living in Edinburgh. Contact me at andy@nobugs.org. I write one blog mostly about software engineering, and another about cycling and unicycling.

 

 


 

Inside CRT: Debug Heap Management

 

This paper is copied from below link:

http://www.codeguru.com/cpp/w-p/win32/tutorials/article.php/c9535

When you compile a debug build of your program with Visual Studio and run it in debugger, you can see that the memory allocated or deallocated has funny values, such as 0xCDCDCDCD or 0xDDDDDDDD. This is the result of the work Microsoft has put in to detect memory corruption and leaks in the Win32 platform. In this article, I will explain how memory allocation/deallocation is done via new/delete or malloc/free.

First, I will explain what all these values that you see, like CD, DD, and so forth, mean.

ValueNameDescription
0xCD Clean Memory Allocated memory via malloc or new but never written by the application.
0xDD Dead Memory Memory that has been released with delete or free. It is used to detect writing through dangling pointers.
0xFD Fence Memory Also known as "no mans land." This is used to wrap the allocated memory (like surrounding it with fences) and is used to detect indexing arrays out of bounds.
0xAB (Allocated Block?) Memory allocated by LocalAlloc().
0xBAADF00D Bad Food Memory allocated by LocalAlloc() with LMEM_FIXED, but not yet written to.
0xCC   When the code is compiled with the /GZ option, uninitialized variables are automatically assigned to this value (at byte level).

If you take a look at DBGHEAP.C, you can see how some of these values are defined:

static unsigned char _bNoMansLandFill = 0xFD;   /* fill no-man's land with this */
static unsigned char _bDeadLandFill   = 0xDD;   /* fill free objects with this */
static unsigned char _bCleanLandFill  = 0xCD;   /* fill new objects with this */

Before going any further, take a look at the memory management function that I will refer in this article.

FunctionDescription
malloc C/C++ function that allocates a block of memory from the heap. The implementation of the C++ operator new is based on malloc.
_malloc_dbg Debug version of malloc; only available in the debug versions of the run-time libraries. _malloc_dbg is a debug version of the malloc function. When _DEBUG is not defined, each call to _malloc_dbg is reduced to a call to malloc. Both malloc and _malloc_dbg allocate a block of memory in the base heap, but _malloc_dbg offers several debugging features: buffers on either side of the user portion of the block to test for leaks, a block type parameter to track specific allocation types, and filename/linenumber information to determine the origin of allocation requests.
free C/C++ function that frees an allocated block. The implementation of C++ operator delete is based on free.
_free_dbg Debug version of free; only available in the debug versions of the run-time libraries. The _free_dbg function is a debug version of the free function. When _DEBUG is not defined, each call to _free_dbg is reduced to a call to free. Both free and _free_dbg free a memory block in the base heap, but _free_dbg accommodates two debugging features: the ability to keep freed blocks in the heap's linked list to simulate low memory conditions and a block type parameter to free specific allocation types.
LocalAlloc
GlobalAlloc
Win32 API to allocate the specified number of bytes from the heap. Windows memory management does not provide a separate local heap and global heap.
LocalFree
GlobalFree
Win32 API free the specified local memory object and invalidates its handle.
HeapAlloc Win32 API allocates a block of memory from a heap. The allocated memory is not movable.
HeapFree Win32 API frees a memory block allocated from a heap by the HeapAlloc or HeapReAlloc function.

There are many other functions that deal with memory management. For a complete view please refer to MSDN.

Note: Because this article is about memory management in a debug build, all the references to malloc and free in the following are actually references to their debug versions, _malloc_dbg and _free_dbg.

Compile the following code and run it in the debugger, walking step by step into it to see how memory is allocated and deallocated.

int main(int argc, char* argv[])
{
   char *buffer = new char[12];

   delete [] buffer;

   return 0;
}

Here, 12 bytes are dynamically allocated, but the CRT allocates more than that by wrapping the allocated block with bookkeeping information. For each allocated block, the CRT keeps information in a structure called _CrtMemBlockHeader, which is declared in DBGINT.H:

#define nNoMansLandSize 4

typedef struct _CrtMemBlockHeader
{
        struct _CrtMemBlockHeader * pBlockHeaderNext;
        struct _CrtMemBlockHeader * pBlockHeaderPrev;
        char *                      szFileName;
        int                         nLine;
        size_t                      nDataSize;
        int                         nBlockUse;
        long                        lRequest;
        unsigned char               gap[nNoMansLandSize];
        /* followed by:
         *  unsigned char           data[nDataSize];
         *  unsigned char           anotherGap[nNoMansLandSize];
         */
} _CrtMemBlockHeader;

It stores the following information:

FieldDescription
pBlockHeaderNext A pointer to the next block allocated, but next means the previous allocated block because the list is seen as a stack, with the latest allocated block at the top.
pBlockHeaderPrev A pointer to the previous block allocated; this means the block that was allocated after the current block.
szFileName A pointer to the name of the file in which the call to malloc was made, if known.
nLine The line in the source file indicated by szFileName at which the call to malloc was made, if known.
nDataSize Number of bytes requested
nBlockUse 0 - Freed block, but not released back to the Win32 heap
1 - Normal block (allocated with new/malloc)
2 - CRT blocks, allocated by CRT for its own use
lRequest Counter incremented with each allocation
gap A zone of 4 bytes (in the current implementation) filled with 0xFD, fencing the data block, of nDataSize bytes. Another block filled with 0xFD of the same size follows the data.

Most of the work of heap block allocation and deallocation are made by HeapAlloc() and HeapFree(). When you request 12 bytes to be allocated on the heap, malloc() will call HeapAlloc(), requesting 36 more bytes.

blockSize = sizeof(_CrtMemBlockHeader) + nSize + nNoMansLandSize;

malloc requests space for the 12 bytes we need (nSize), plus 32 bytes for the _CrtMemBlockHeader structure and another nNoMansLandSize bytes (4 bytes) to fence the data zone and close the gap.

But, HeapAlloc() will allocate even more bytes: 8 bytes below the requested block (that is, at a lower address) and 32 above it (that is, at a bigger address). It also initializes the requested block to 0xBAADF00D (bad food).

Then, malloc() fills the _CrtMemBlockHeader block with information and initializes the data block with 0xCD and no mans land with 0xFD.

Here is a table that shows how memory looks after the call to HeapAlloc() and after malloc() returns. For a complete situation, see the last table. (Note: All values are in hex.)

Addressafter HeapAlloc()after malloc()
00320FD8
00320FDC
00320FE0
00320FE4
00320FE8
00320FEC
00320FF0
00320FF4
00320FF8
00320FFC
00321000
00321004
00321008
0032100C
00321010
00321014
00321018
0032101C
00321020
00321024
00321028
0032102C
09 00 09 01
E8 07 18 00
0D F0 AD BA
0D F0 AD BA
0D F0 AD BA
0D F0 AD BA
0D F0 AD BA
0D F0 AD BA
0D F0 AD BA
0D F0 AD BA
0D F0 AD BA
0D F0 AD BA
0D F0 AD BA
0D F0 AD BA
AB AB AB AB
AB AB AB AB
00 00 00 00
00 00 00 00
79 00 09 00
EE 04 EE 00
40 05 32 00
40 05 32 00
09 00 09 01
E8 07 18 00
98 07 32 00
00 00 00 00
00 00 00 00
00 00 00 00
0C 00 00 00
01 00 00 00
2E 00 00 00
FD FD FD FD
CD CD CD CD
CD CD CD CD
CD CD CD CD
FD FD FD FD
AB AB AB AB
AB AB AB AB
00 00 00 00
00 00 00 00
79 00 09 00
EE 04 EE 00
40 05 32 00
40 05 32 00

Colors:

  • Green: win32 bookkeeping info
  • Blue: block size requested by malloc and filled with bad food
  • Magenta: _CrtMemBlockHeader block
  • Red: no mans land
  • Black: requested data block

In this example, after the call to malloc() returns, buffer will point to memory address 0x00321000.

When you call delete/free, the CRT will set the block it requested from HeapAlloc() to 0xDD, indicating this is a free zone. Normally after this, free() will call HeapFree() to give back the block to the Win32 heap, in which case the block will be overwritten with 0xFEEEEEEE, to indicate Win32 heap free memory.

You can avoid this by using the CRTDBG_DELAY_FREE_MEM_DF flag to _CrtSetDbgFlag(). It prevents memory from actually being freed, as for simulating low-memory conditions. When this bit is on, freed blocks are kept in the debug heap's linked list but are marked as _FREE_BLOCK. This is useful if you want to detect dangling pointers errors, which can be done by verifying if the freed block is written with 0xDD pattern or something else. Use _CrtCheckMemory() to verify the heap.s integrity.

The next table shows how the memory looks during the free(), before HeapFree() is called and afterwards.

AddressBefore HeapFree()After HeapFree()
00320FD8
00320FDC
00320FE0
00320FE4
00320FE8
00320FEC
00320FF0
00320FF4
00320FF8
00320FFC
00321000
00321004
00321008
0032100C
00321010
00321014
00321018
0032101C
00321020
00321024
00321028
0032102C
09 00 09 01
5E 07 18 00
DD DD DD DD
DD DD DD DD
DD DD DD DD
DD DD DD DD
DD DD DD DD
DD DD DD DD
DD DD DD DD
DD DD DD DD
DD DD DD DD
DD DD DD DD
DD DD DD DD
DD DD DD DD
AB AB AB AB
AB AB AB AB
00 00 00 00
00 00 00 00
79 00 09 00
EE 04 EE 00
40 05 32 00
40 05 32 00
82 00 09 01
5E 04 18 00
E0 2B 32 00
78 01 32 00
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE
EE FE EE FE

Colors:

  • Green: win32 bookkeeping info
  • Blue: CRT block filled with dead memory
  • Gray: memory given back to win32 heap

The two tables above are put in a single, more detailed, table below:

Address (hex)OffsetHeapAllocmallocFree before HeapFreeFree after HeapFreeDescription
00320FD8 -40 01090009 01090009 01090009 01090082 Win32 Heap info
00320FDC -36 001807E8 001807E8 0018075E 0018045E Win32 Heap info
00320FE0 -32 BAADF00D 00320798 DDDDDDDD 00322BE0 pBlockHeaderNext
00320FE4 -28 BAADF00D 00000000 DDDDDDDD 00320178 pBlockHeaderPrev
00320FE8 -24 BAADF00D 00000000 DDDDDDDD FEEEEEEE szFileName
00320FEC -20 BAADF00D 00000000 DDDDDDDD FEEEEEEE nLine
00320FF0 -16 BAADF00D 0000000C DDDDDDDD FEEEEEEE nDataSize
00320FF4 -12 BAADF00D 00000001 DDDDDDDD FEEEEEEE nBlockUse
00320FF8 -8 BAADF00D 0000002E DDDDDDDD FEEEEEEE lRequest
00320FFC -4 BAADF00D FDFDFDFD DDDDDDDD FEEEEEEE gap (no mans land)
00321000 0 BAADF00D CDCDCDCD DDDDDDDD FEEEEEEE Data requested
00321004 +4 BAADF00D CDCDCDCD DDDDDDDD FEEEEEEE Data requested
00321008 +8 BAADF00D CDCDCDCD DDDDDDDD FEEEEEEE Data requested
0032100C +12 BAADF00D FDFDFDFD DDDDDDDD FEEEEEEE No mans land
00321010 +16 ABABABAB ABABABAB ABABABAB FEEEEEEE Win32 Heap info
00321014 +20 ABABABAB ABABABAB ABABABAB FEEEEEEE Win32 Heap info
00321018 +24 00000000 00000000 00000000 FEEEEEEE Win32 Heap info
0032101C +28 00000000 00000000 00000000 FEEEEEEE Win32 Heap info
00321020 +32 00090079 00090079 00090079 FEEEEEEE Win32 Heap info
00321024 +36 00EE04EE 00EE04EE 00EE04EE FEEEEEEE Win32 Heap info
00321028 +40 00320540 00320540 00320540 FEEEEEEE Win32 Heap info
0032102C +44 00320540 00320540 00320540 FEEEEEEE Win32 Heap info

Most time you may find that there is no filename and line name. If you need, you need to do like below:

#define DEBUG_NEW new(_NORMAL_BLOCK, __FILE__, __LINE__)
#define new DEBUG_NEW

And for the

_crtBreakAlloc,

you'd better take a look at below article.

How to use _crtBreakAlloc to debug a memory allocation

http://support.microsoft.com/kb/151585

扩展阅读:不及格的程序员-八神

baadf00d!

 

Came across this while debugging a program today in Eclipse:

0xBAADF00D : Used by Microsoft‘s LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory

(http://en.wikipedia.org/wiki/Magic_number_(programming)#Magic_debug_values)

…I very obviously forgot to initialize one of my variables.


Magic number (programming)

From Wikipedia, the free encyclopedia

In computer programming, a magic number is any of the following:

  • A unique value with unexplained meaning or multiple occurrences which could (preferably) be replaced with a named constant
  • A constant numerical or text value used to identify a file format or protocol; for files, see List of file signatures
  • A distinctive unique value that is unlikely to be mistaken for other meanings (e.g., Globally Unique Identifiers)

Unnamed numerical constants[edit]

The term magic number or magic constant refers to the anti-pattern of using numbers directly in source code. This has been referred to as breaking one of the oldest rules of programming, dating back to the COBOLFORTRAN and PL/1 manuals of the 1960s.[1] The use of unnamed magic numbers in code obscures the developers' intent in choosing that number,[2] increases opportunities for subtle errors (e.g. is every digit correct in 3.14159265358979323846 and is this equal to 3.14159?) and makes it more difficult for the program to be adapted and extended in the future.[3] Replacing all significant magic numbers with named constants (also called explanatory variables) makes programs easier to read, understand and maintain.[4]

Names chosen to be meaningful in the context of the program can result in code that is more easily understood by a maintainer who is not the original author (or even by the original author after a period of time).[5] An example of an uninformatively named constant is int SIXTEEN = 16, while int NUMBER_OF_BITS = 16 is more descriptive.

The problems associated with magic 'numbers' described above are not limited to numerical types and the term is also applied to other data types where declaring a named constant would be more flexible and communicative.[1] Thus, declaring const string testUserName = "John" is better than several occurrences of the 'magic value' "John" in a test suite.

For example, if it is required to randomly shuffle the values in an array representing a standard pack of playing cards, this pseudocode does the job using the Fisher–Yates shuffle algorithm:

for i from 1 to 52
    j := i + randomInt(53 - i) - 1
    a.swapEntries(i, j)

where a is an array object, the function randomInt(x) chooses a random integer between 1 and x, inclusive, and swapEntries(i, j) swaps the ith and jth entries in the array. In the preceding example, 52 is a magic number. It is considered better programming style to write the following:

constant int deckSize := 52
for i from 1 to deckSize
    j := i + randomInt(deckSize + 1 - i) - 1
    a.swapEntries(i, j)

This is preferable for several reasons:

  • It is easier to read and understand. A programmer reading the first example might wonder, What does the number 52 mean here? Why 52? The programmer might infer the meaning after reading the code carefully, but it is not obvious.[5] Magic numbers become particularly confusing when the same number is used for different purposes in one section of code.
  • It is easier to alter the value of the number, as it is not duplicated. Changing the value of a magic number is error-prone, because the same value is often used several times in different places within a program.[5] Also, when two semantically distinct variables or numbers have the same value they may be accidentally both edited together.[5] To modify the first example to shuffle a Tarot deck, which has 78 cards, a programmer might naively replace every instance of 52 in the program with 78. This would cause two problems. First, it would miss the value 53 on the second line of the example, which would cause the algorithm to fail in a subtle way. Second, it would likely replace the characters "52" everywhere, regardless of whether they refer to the deck size or to something else entirely, such as the number of weeks in a Gregorian calendar year, or more insidiously, are part of a number like "1523", all of which would introduce bugs. By contrast, changing the value of the deckSize variable in the second example would be a simple, one-line change.
  • It encourages and facilitates documentation.[5] The single place where the named variable is declared makes a good place to document what the value means and why it has the value it does. Having the same value in a plethora of places either leads to duplicate comments (and attendant problems when updating some but missing some) or leaves no one place where it's both natural for the author to explain the value and likely the reader shall look for an explanation.
  • The declarations of "magic number" variables are placed together, usually at the top of a function or file, facilitating their review and change.[5]
  • It helps detect typos. Using a variable (instead of a literal) takes advantage of a compiler's checking. Accidentally typing "62" instead of "52" would go undetected, whereas typing "dekSize" instead of "deckSize" would result in the compiler's warning that dekSize is undeclared.
  • It can reduce typing in some IDEs. If an IDE supports code completion, it will fill in most of the variable's name from the first few letters.
  • It facilitates parameterization. For example, to generalize the above example into a procedure that shuffles a deck of any number of cards, it would be sufficient to turn deckSize into a parameter of that procedure, whereas the first example would require several changes.
function shuffle (int deckSize)
   for i from 1 to deckSize
       j := i + randomInt(deckSize + 1 - i) - 1
       a.swapEntries(i, j)

Disadvantages are:

  • When the named constant is not defined near its use, it hurts the locality, and thus comprehensibility, of the code. Putting the 52 in a possibly distant place means that, to understand the workings of the "for" loop completely (for example to estimate the run-time of the loop), one must track down the definition and verify that it is the expected number. This is easy to avoid (by relocating the declaration) when the constant is only used in one portion of the code. When the named constant is used in disparate portions, on the other hand, the remote location is a clue to the reader that the same value appears in other places in the code, which may also be worth looking into.
  • It may make the code more verbose. The declaration of the constant adds a line. When the constant's name is longer than the value's, particularly if several such constants appear in one line, it may make it necessary to split one logical statement of the code across several lines. An increase in verbosity may be justified when there is some likelihood of confusion about the constant, or when there is a likelihood the constant may need to be changed, such as reuse of a shuffling routine for other card games. It may equally be justified as an increase in expressiveness.
  • It may be slower to process the expression deckSize + 1 at run-time than the value "53", although most modern compilers and interpreters will notice that deckSize has been declared as a constant and pre-calculate the value 53 in the compiled code. Even when that's not an option, loop optimization will move the addition so that it is performed before the loop. There is therefore usually no (or negligible) speed penalty compared to using magic numbers in code. Especially the cost of debugging and the time needed trying to understand non-explanatory code must be held against the tiny calculation cost.

Accepted uses [edit]

In some contexts, the use of unnamed numerical constants is generally accepted (and arguably "not magic"). While such acceptance is subjective, and often depends on individual coding habits, the following are common examples:

  • the use of 0 and 1 as initial or incremental values in a for loop, such as for (int i = 0; i < max; i += 1)
  • the use of 2 to check whether a number is even or odd, as in isEven = (x % 2 == 0), where % is the modulo operator
  • the use of simple arithmetic constants, e.g., in expressions such as circumference = 2 * Math.PI * radius,[1] or for calculating the discriminant of a quadratic equation as d = b^2 − 4*a*c
  • the use of powers of 10 to convert metric values (e.g. between grams and kilograms) or to calculate percentage and per mille values
  • exponents in expressions such as (f(x) ** 2 + f(y) ** 2) ** 0.5 for �(�)2+�(�)2{\displaystyle {\sqrt {f(x)^{2}+f(y)^{2}}}}

The constants 1 and 0 are sometimes used to represent the boolean values True and False in programming languages without a boolean type, such as older versions of C. Most modern programming languages provide a boolean or bool primitive type and so the use of 0 and 1 is ill-advised. This can be more confusing since 0 sometimes means programmatic success (when -1 means failure) and failure in other cases (when 1 means success).

In C and C++, 0 represents the null pointer. As with boolean values, the C standard library includes a macro definition NULL whose use is encouraged. Other languages provide a specific null or nil value and when this is the case no alternative should be used. The typed pointer constant nullptr has been introduced with C++11.

Format indicators [edit]

Origin [edit]

Format indicators were first used in early Version 7 Unix source code.[citation needed]

Unix was ported to one of the first DEC PDP-11/20s, which did not have memory protection. So early versions of Unix used the relocatable memory reference model.[6] Pre-Sixth Edition Unix versions read an executable file into memory and jumped to the first low memory address of the program, relative address zero. With the development of paged versions of Unix, a header was created to describe the executable image components. Also, a branch instruction was inserted as the first word of the header to skip the header and start the program. In this way a program could be run in the older relocatable memory reference (regular) mode or in paged mode. As more executable formats were developed, new constants were added by incrementing the branch offset.[7]

In the Sixth Edition source code of the Unix program loader, the exec() function read the executable (binary) image from the file system. The first 8 bytes of the file was a header containing the sizes of the program (text) and initialized (global) data areas. Also, the first 16-bit word of the header was compared to two constants to determine if the executable image contained relocatable memory references (normal), the newly implemented paged read-only executable image, or the separated instruction and data paged image.[8] There was no mention of the dual role of the header constant, but the high order byte of the constant was, in fact, the operation code for the PDP-11 branch instruction (octal 000407 or hex 0107). Adding seven to the program counter showed that if this constant was executed, it would branch the Unix exec() service over the executable image eight byte header and start the program.

Since the Sixth and Seventh Editions of Unix employed paging code, the dual role of the header constant was hidden. That is, the exec() service read the executable file header (meta) data into a kernel space buffer, but read the executable image into user space, thereby not using the constant's branching feature. Magic number creation was implemented in the Unix linker and loader and magic number branching was probably still used in the suite of stand-alone diagnostic programs that came with the Sixth and Seventh Editions. Thus, the header constant did provide an illusion and met the criteria for magic.

In Version Seven Unix, the header constant was not tested directly, but assigned to a variable labeled ux_mag[9] and subsequently referred to as the magic number. Probably because of its uniqueness, the term magic number came to mean executable format type, then expanded to mean file system type, and expanded again to mean any type of file.

In files [edit]

Magic numbers are common in programs across many operating systems. Magic numbers implement strongly typed data and are a form of in-band signaling to the controlling program that reads the data type(s) at program run-time. Many files have such constants that identify the contained data. Detecting such constants in files is a simple and effective way of distinguishing between many file formats and can yield further run-time information.

Examples
  • Compiled Java class files (bytecode) and Mach-O binaries start with hex CAFEBABE. When compressed with Pack200 the bytes are changed to CAFED00D.
  • GIF image files have the ASCII code for "GIF89a" (47 49 46 38 39 61) or "GIF87a" (47 49 46 38 37 61)
  • JPEG image files begin with FF D8 and end with FF D9. JPEG/JFIF files contain the ASCII code for "JFIF" (4A 46 49 46) as a null terminated string. JPEG/Exif files contain the ASCII code for "Exif" (45 78 69 66) also as a null terminated string, followed by more metadata about the file.
  • PNG image files begin with an 8-byte signature which identifies the file as a PNG file and allows detection of common file transfer problems: \211 P N G \r \n \032 \n (89 50 4E 47 0D 0A 1A 0A). That signature contains various newline characters to permit detecting unwarranted automated newline conversions, such as transferring the file using FTP with the ASCII transfer mode instead of the binary mode.[10]
  • Standard MIDI audio files have the ASCII code for "MThd" (MIDI Track header, 4D 54 68 64) followed by more metadata.
  • Unix or Linux scripts may start with a "shebang" (#!23 21) followed by the path to an interpreter, if the interpreter is likely to be different from the one from which the script was invoked.
  • ELF executables start with 7F E L F
  • PostScript files and programs start with "%!" (25 21).
  • PDF files start with "%PDF" (hex 25 50 44 46).
  • DOS MZ executable files and the EXE stub of the Microsoft Windows PE (Portable Executable) files start with the characters "MZ" (4D 5A), the initials of the designer of the file format, Mark Zbikowski. The definition allows the uncommon "ZM" (5A 4D) as well for dosZMXP, a non-PE EXE.[11]
  • The Berkeley Fast File System superblock format is identified as either 19 54 01 19 or 01 19 54 depending on version; both represent the birthday of the author, Marshall Kirk McKusick.
  • The Master Boot Record of bootable storage devices on almost all IA-32 IBM PC compatibles has a code of 55 AA as its last two bytes.
  • Executables for the Game Boy and Game Boy Advance handheld video game systems have a 48-byte or 156-byte magic number, respectively, at a fixed spot in the header. This magic number encodes a bitmap of the Nintendo logo.
  • Amiga software executable Hunk files running on Amiga classic 68000 machines all started with the hexadecimal number $000003f3, nicknamed the "Magic Cookie."
  • In the Amiga, the only absolute address in the system is hex $0000 0004 (memory location 4), which contains the start location called SysBase, a pointer to exec.library, the so-called kernel of Amiga.
  • PEF files, used by the classic Mac OS and BeOS for PowerPC executables, contain the ASCII code for "Joy!" (4A 6F 79 21) as a prefix.
  • TIFF files begin with either II or MM followed by 42 as a two-byte integer in little or big endian byte ordering. II is for Intel, which uses little endian byte ordering, so the magic number is 49 49 2A 00MM is for Motorola, which uses big endian byte ordering, so the magic number is 4D 4D 00 2A.
  • Unicode text files encoded in UTF-16 often start with the Byte Order Mark to detect endianness (FE FF for big endian and FF FE for little endian). And on Microsoft WindowsUTF-8 text files often start with the UTF-8 encoding of the same character, EF BB BF.
  • LLVM Bitcode files start with BC (0x42, 0x43)
  • WAD files start with IWAD or PWAD (for Doom), WAD2 (for Quake) and WAD3 (for Half-Life).
  • Microsoft Compound File Binary Format (mostly known as one of the older formats of Microsoft Office documents) files start with D0 CF 11 E0, which is visually suggestive of the word "DOCFILE0".
  • Headers in ZIP files often show up in text editors as "PK♥♦" (50 4B 03 04), where "PK" are the initials of Phil Katz, author of DOS compression utility PKZIP.
  • Headers in 7z files begin with "7z" (full magic number: 37 7A BC AF 27 1C).
Detection

The Unix utility program file can read and interpret magic numbers from files, and the file which is used to parse the information is called magic. The Windows utility TrID has a similar purpose.

In protocols [edit]

Examples
  • The OSCAR protocol, used in AIM/ICQ, prefixes requests with 2A.
  • In the RFB protocol used by VNC, a client starts its conversation with a server by sending "RFB" (52 46 42, for "Remote Frame Buffer") followed by the client's protocol version number.
  • In the SMB protocol used by Microsoft Windows, each SMB request or server reply begins with 'FF 53 4D 42', or "\xFFSMB" at the start of the SMB request.
  • In the MSRPC protocol used by Microsoft Windows, each TCP-based request begins with 05 at the start of the request (representing Microsoft DCE/RPC Version 5), followed immediately by a 00 or 01 for the minor version. In UDP-based MSRPC requests the first byte is always 04.
  • In COM and DCOM marshalled interfaces, called OBJREFs, always start with the byte sequence "MEOW" (4D 45 4F 57). Debugging extensions (used for DCOM channel hooking) are prefaced with the byte sequence "MARB" (4D 41 52 42).
  • Unencrypted BitTorrent tracker requests begin with a single byte containing the value 19 representing the header length, followed immediately by the phrase "BitTorrent protocol" at byte position 1.
  • eDonkey2000/eMule traffic begins with a single byte representing the client version. Currently E3 represents an eDonkey client, C5 represents eMule, and D4 represents compressed eMule.
  • The first 04 bytes of a block in the Bitcoin Blockchain contains a magic number which serves as the network identifier. The value is a constant 0xD9B4BEF9, which indicates the main network, while the constant 0xDAB5BFFA indicates the testnet.
  • SSL transactions always begin with a "client hello" message. The record encapsulation scheme used to prefix all SSL packets consists of two- and three- byte header forms. Typically an SSL version 2 client hello message is prefixed with a 80 and an SSLv3 server response to a client hello begins with 16 (though this may vary).
  • DHCP packets use a "magic cookie" value of '0x63 0x82 0x53 0x63' at the start of the options section of the packet. This value is included in all DHCP packet types.
  • HTTP/2 connections are opened with the preface '0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a', or "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n". The preface is designed to avoid the processing of frames by servers and intermediaries which support earlier versions of HTTP but not 2.0.

In interfaces [edit]

Magic numbers are common in API functions and interfaces across many operating systems, including DOSWindows and NetWare:

Examples
  • IBM PC-compatible BIOSes use magic values 0000 and 1234 to decide if the system should count up memory or not on reboot, thereby performing a cold or a warm boot. Theses values are also used by EMM386 memory managers intercepting boot requests.[12] BIOSes also use magic values 55 AA to determine if a disk is bootable.[13]
  • The MS-DOS disk cache SMARTDRV (codenamed "Bambi") uses magic values BABE and EBAB in API functions.[12]
  • Many DR DOSNovell DOS and OpenDOS drivers developed in the former European Development Centre in the UK use the value 0EDC as magic token when invoking or providing additional functionality sitting on top of the (emulated) standard DOS functions, NWCACHE being one example.[12]

Other uses [edit]

Examples

Data type limits[edit]

This is a list of limits of data storage types:[15]

DecimalHexDescription
18,446,744,073,709,551,615 FFFF FFFF FFFF FFFF The maximum unsigned 64 bit value (264 − 1)
9,223,372,036,854,775,807 7FFF FFFF FFFF FFFF The maximum signed 64 bit value (263 − 1)
4,294,967,295 FFFF FFFF The maximum unsigned 32 bit value (232 − 1)
2,147,483,647 7FFF FFFF The maximum signed 32 bit value (231 − 1)
65,535 FFFF The maximum unsigned 16 bit value (216 − 1)
32,767 7FFF The maximum signed 16 bit value (215 − 1)
255 FF The maximum unsigned 8 bit value (28 − 1)
127 7F The maximum signed 8 bit value (27 − 1)
−128 80 Minimum signed 8 bit value
−32,768 8000 Minimum signed 16 bit value
−2,147,483,648 8000 0000 Minimum signed 32 bit value
−9,223,372,036,854,775,808 8000 0000 0000 0000 Minimum signed 64 bit value

GUIDs [edit]

It is possible to create or alter globally unique identifiers (GUIDs) so that they are memorable, but this is highly discouraged as it compromises their strength as near-unique identifiers.[16][17] The specifications for generating GUIDs and UUIDs are quite complex, which is what leads to them being virtually unique, if properly implemented. .[citation needed]

Microsoft Windows product ID numbers for Microsoft Office products sometimes end with 0000-0000-0000000FF1CE ("OFFICE"), such as {90160000-008C-0000-0000-0000000FF1CE}, the product ID for the "Office 16 Click-to-Run Extensibility Component".

Java uses several GUIDs starting with CAFEEFAC.[18]

In the GUID Partition Table of the GPT partitioning scheme, BIOS Boot partitions use the special GUID {21686148-6449-6E6F-744E-656564454649}[19] which does not follow the GUID definition; instead, it is formed by using the ASCII codes for the string "Hah!IdontNeedEFI" partially in little endian order.[20]

Debug values [edit]

Magic debug values are specific values written to memory during allocation or deallocation, so that it will later be possible to tell whether or not they have become corrupted, and to make it obvious when values taken from uninitialized memory are being used. Memory is usually viewed in hexadecimal, so memorable repeating or hexspeak values are common. Numerically odd values may be preferred so that processors without byte addressing will fault when attempting to use them as pointers (which must fall at even addresses). Values should be chosen that are away from likely addresses (the program code, static data, heap data, or the stack). Similarly, they may be chosen so that they are not valid codes in the instruction set for the given architecture.

Since it is very unlikely, although possible, that a 32-bit integer would take this specific value, the appearance of such a number in a debugger or memory dump most likely indicates an error such as a buffer overflow or an uninitialized variable.

Famous and common examples include:

CodeDescription
00008123 Used in MS Visual C++. Deleted pointers are set to this value, so they throw an exception, when they are used after; it is a more recognizable alias for the zero address. It is activated with the Security Development Lifecycle (/sdl) option.[21]
..FACADE "Facade", Used by a number of RTOSes
1BADB002 "1 bad boot"Multiboot header magic number[22]
8BADF00D "Ate bad food", Indicates that an Apple iOS application has been terminated because a watchdog timeout occurred.[23]
A5A5A5A5 Used in embedded development because the alternating bit pattern (1010 0101) creates an easily recognized pattern on oscilloscopes and logic analyzers.
A5 Used in FreeBSD's PHK malloc(3) for debugging when /etc/malloc.conf is symlinked to "-J" to initialize all newly allocated memory as this value is not a NULL pointer or ASCII NUL character.
ABABABAB Used by Microsoft's debug HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory.[24]
ABADBABE "A bad babe", Used by Apple as the "Boot Zero Block" magic number
ABBABABE "ABBA babe", used by Driver Parallel Lines memory heap.
ABADCAFE "A bad cafe", Used to initialize all unallocated memory (Mungwall, AmigaOS)
B16B00B5 "Big Boobs", Formerly required by Microsoft's Hyper-V hypervisor to be used by Linux guests as the upper half of their "guest id"[25]
BAADF00D "Bad food", Used by Microsoft's debug HeapAlloc() to mark uninitialized allocated heap memory[24]
BAAAAAAD "Baaaaaad", Indicates that the Apple iOS log is a stackshot of the entire system, not a crash report[23]
BAD22222 "Bad too repeatedly", Indicates that an Apple iOS VoIP application has been terminated because it resumed too frequently[23]
BADBADBADBAD "Bad bad bad bad"Burroughs large systems "uninitialized" memory (48-bit words)
BADC0FFEE0DDF00D "Bad coffee odd food", Used on IBM RS/6000 64-bit systems to indicate uninitialized CPU registers
BADDCAFE "Bad cafe", On Sun MicrosystemsSolaris, marks uninitialized kernel memory (KMEM_UNINITIALIZED_PATTERN)
BBADBEEF "Bad beef", Used in WebKit, for particularly unrecoverable errors[26]
BEBEBEBE Used by AddressSanitizer to fill allocated but not initialized memory[27]
BEEFCACE "Beef cake", Used by Microsoft .NET as a magic number in resource files
C00010FF "Cool off", Indicates Apple iOS app was killed by the operating system in response to a thermal event[23]
CAFEBABE "Cafe babe", Used by Java for class files
CAFED00D "Cafe dude", Used by Java for their pack200 compression
CAFEFEED "Cafe feed", Used by Sun MicrosystemsSolaris debugging kernel to mark kmemfree() memory
CCCCCCCC Used by Microsoft's C++ debugging runtime library and many DOS environments to mark uninitialized stack memory. CC resembles the opcode of the INT 3 debug breakpoint interrupt on x86 processors.[28]
CDCDCDCD Used by Microsoft's C/C++ debug malloc() function to mark uninitialized heap memory, usually returned from HeapAlloc()[24]
0D15EA5E "Zero Disease", Used as a flag to indicate regular boot on the GameCube and Wii consoles
DDDDDDDD Used by MicroQuill's SmartHeap and Microsoft's C/C++ debug free() function to mark freed heap memory[24]
DEAD10CC "Dead lock", Indicates that an Apple iOS application has been terminated because it held on to a system resource while running in the background[23]
DEADBABE "Dead babe", Used at the start of Silicon GraphicsIRIX arena files
DEADBEEF "Dead beef", Famously used on IBM systems such as the RS/6000, also used in the classic Mac OS operating systemsOPENSTEP Enterprise, and the Commodore Amiga. On Sun MicrosystemsSolaris, marks freed kernel memory (KMEM_FREE_PATTERN)
DEADCAFE "Dead cafe", Used by Microsoft .NET as an error number in DLLs
DEADC0DE "Dead code", Used as a marker in OpenWRT firmware to signify the beginning of the to-be created jffs2 file system at the end of the static firmware
DEADFA11 "Dead fail", Indicates that an Apple iOS application has been force quit by the user[23]
DEADF00D "Dead food", Used by Mungwall on the Commodore Amiga to mark allocated but uninitialized memory[29]
DEFEC8ED "Defecated", Used for OpenSolaris core dumps
DEADDEAD "Dead Dead" indicates that the user deliberately initiated a crash dump from either the kernel debugger or the keyboard under Microsoft Windows.[30]
D00D2BAD "Dude, Too Bad", Used by Safari crashes on macOS Big Sur.[31]
EBEBEBEB From MicroQuill's SmartHeap
FADEDEAD "Fade dead", Comes at the end to identify every AppleScript script
FDFDFDFD Used by Microsoft's C/C++ debug malloc() function to mark "no man's land" guard bytes before and after allocated heap memory,[24] and some debug Secure C-Runtime functions implemented by Microsoft (e.g. strncat_s) [32]
FEE1DEAD "Feel dead", Used by Linux reboot() syscall
FEEDFACE "Feed face", Seen in PowerPC Mach-O binaries on Apple Inc.'s Mac OSX platform. On Sun MicrosystemsSolaris, marks the red zone (KMEM_REDZONE_PATTERN)

Used by VLC player and some IP cameras in RTP/RTCP protocol, VLC player sends four bytes in the order of the endianness of the system. Some IP cameras expect the player to send this magic number and do not start the stream if it is not received.

FEEEFEEE "Fee fee", Used by Microsoft's debug HeapFree() to mark freed heap memory. Some nearby internal bookkeeping values may have the high word set to FEEE as well.[24]

Most of these are each 32 bits long – the word size of most 32-bit architecture computers.

The prevalence of these values in Microsoft technology is no coincidence; they are discussed in detail in Steve Maguire's book Writing Solid Code from Microsoft Press. He gives a variety of criteria for these values, such as:

  • They should not be useful; that is, most algorithms that operate on them should be expected to do something unusual. Numbers like zero don't fit this criterion.
  • They should be easily recognized by the programmer as invalid values in the debugger.
  • On machines that don't have byte alignment, they should be odd numbers, so that dereferencing them as addresses causes an exception.
  • They should cause an exception, or perhaps even a debugger break, if executed as code.

Since they were often used to mark areas of memory that were essentially empty, some of these terms came to be used in phrases meaning "gone, aborted, flushed from memory"; e.g. "Your program is DEADBEEF".[citation needed]

See also[edit]


 

Hexspeak

 
From Wikipedia, the free encyclopedia
 

Hexspeak, like leetspeak, is a novelty form of variant English spelling using the hexadecimal digits. Created by programmers as memorable magic numbers, hexspeak words can serve as a clear and unique identifier with which to mark memory or data.

Hexadecimal notation represents numbers using the 16 digits 0123456789ABCDEF. Using only the letters ABCDEF it is possible to spell several words. Further words can be made by treating some of the decimal numbers as letters - the digit "0" can represent the letter "O", and "1" can represent the letters "I" or "L". Less commonly, "5" can represent "S", "7" represent "T", "12" represent "R" and "6" or "9" can represent "G" or "g", respectively. Numbers such as 24 or 8 can be used in a manner similar to leet or rebuses; e.g. the word "defecate" can be expressed either as DEFECA7E or DEFEC8.

Notable magic numbers

Many computer processorsoperating systems, and debuggers make use of magic numbers, especially as a magic debug value.

CodeDecimalDescription
0x0000000FF1CE 1044942 ("office") is used as the last part of product codes (GUID) for Microsoft Office components (visible in registry under the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall registry key).
0x00BAB10C 12235020 ("über (ooba) block") is used as the magic number for the ZFS uberblock.
0x1BADB002 464367618 ("1 bad boot"[1]) Multiboot header magic number.[2]
0x4B1D 19229 ("forbid") was a password in some calibration consoles for developers to peer deeper into control registers outside the normal calibration memory range.[citation needed]
0x8BADF00D 2343432205 ("ate bad food") is used by Apple in iOS crash reports, when an application takes too long to launch, terminate, or respond to system events.[3]
0xABADBABE 2880289470 ("a bad babe") was/is used by Microsoft's Windows 7 to trigger a debugger break-point, probably when a USB device is attached[4]
0xB105F00D 2969956365 ("BIOS food") is the value of the low bytes of last four registers on ARM PrimeCell compatible components (the component_id registers), used to identify correct behaviour of a memory-mapped component.
0xB16B00B5 2976579765 ("big boobs") was required by Microsoft's Hyper-V hypervisor to be used by Linux guests as their "guest signature".[5] One proposal suggested changing it to 0x0DEFACED ("defaced"),[6] but it was instead initially changed to decimal and then replaced entirely.[7]
0x0B00B135 184594741 ("boobies") was likewise required by Microsoft's Hyper-V hypervisor to be used by a user of XEN as their user id.[8] It was removed on January 22, 2010.[9]
0xBAAAAAAD 3131746989 ("baaaaaad") is used by Apple's iOS exception report to indicate that the log is a stackshot of the entire system, not a crash report.[10]
0xBAADF00D 3131961357 ("bad food") is used by Microsoft's LocalAlloc(LMEM_FIXED) to indicate uninitialised allocated heap memory when the debug heap is used.[11]
0xBAD22222 3134333474 ("bad too repeatedly") is used by Apple's iOS exception log to indicate that a VoIP application has been terminated by iOS because it resumed too frequently.[10]
0xBADDCAFE 3135097598 ("bad cafe") is used by Libumem to indicate uninitialized memory area.
0xCAFEB0BA 3405689018 ("cafe boba") is used by datp as canned return value for QKit MFCC keyword detection for Host GUI development since his colleague likes coffee (and maybe boba, too).
0xB0BABABE 2965027518 ("boba babe") is used by pton as Host GUI Ack to QKit MFCC keyword detection response.
0xBEEFBABE 3203381950 ("beef babe") is used by the 1997 video game Frogger to detect a stack buffer overflow.
0xB000 0xDEAD 2952847021 ("boo dead") was displayed by PA-RISC based HP 3000 and HP 9000 computers upon encountering a "system halt" (aka "low level halt").[12]
0xC00010FF 3221229823 ("cool off") is used by Apple in iOS crash reports, when application was killed in response to a thermal event.[3]
C15C:0D06:F00D 212601099710477 ("cisco dog food") used in the IPv6 address of www.cisco.com on World IPv6 Day. "Dog food" refers to Cisco eating its own dog food with IPv6.
0xCAFEBABE 3405691582 ("cafe babe") is used by Plan 9's libc as a poison value for memory pools.[13] It is also used by Mach-O to identify Universal object files, and by the Java programming language to identify Java bytecode class files. It was originally created by NeXTSTEP developers as a reference to the baristas at Peet's Coffee & Tea.[14]
0xCAFED00D 3405697037 ("cafe dude") is used by Java as a magic number for their pack200 compression.[15]
0xCEFAEDFE 3472551422 ("face feed") is used by Mach-O to identify flat (single architecture) object files. In little endian this reads FEEDFACE, "Feed Face".
0x0D15EA5E 219540062 ("zero disease") is a flag that indicates regular boot on the GameCube and Wii consoles.[16][17]
0xDABBAD00 3669732608 ("dabba doo") is the name of a blog on computer security.[18]
0xDEAD2BAD 3735890861 ("dead too bad") was used to mark allocated areas of memory that had not yet been initialised on Sequent Dynix/ptx systems.
0xDEADBAAD 3735927469 ("dead bad") is used by the Android libc abort() function when native heap corruption is detected.
0xDEADBABE 3735927486 ("dead babe") is used by IBM Jikes RVM as a sanity check of the stack of the primary thread.[19]
0xDEADBEAF 3735928495 ("dead beaf") is part of the signature code of Jazz Jackrabbit 2 tileset files.[20] Level files have less room for their signatures and use 0xBABE ("babe") instead.[21] It is also the header of campaign gamesaves used in the Halo game series.
deadbeef-dead-beef-dead-beef00000075 295990755083049101712519384016336453749 ("dead beef") is the GUID assigned to hung/dead virtual machines in Citrix XenServer.
0xDEADBEEF 3735928559 ("dead beef") is frequently used to indicate a software crash or deadlock in embedded systems. 0xDEADBEEF was originally used to mark newly allocated areas of memory that had not yet been initialized—when scanning a memory dump, it is easy to see the 0xDEADBEEF. It is used by IBM RS/6000 systems, Mac OS on 32-bit PowerPC processors, and the Commodore Amiga as a magic debug value. On Sun MicrosystemsSolaris, it marks freed kernel memory. The DEC Alpha SRM console has a background process that traps memory errors, identified by PS as "BeefEater waiting on 0xdeadbeef".[22]
0xDEADC0DE 3735929054 ("dead code") is used as a marker in OpenWrt firmware to signify the beginning of the to-be created jffs2 filesystem at the end of the static firmware.
0xDEADDEAD 3735936685 ("dead dead") is the bug check (STOP) code displayed when invoking a Blue Screen of Death either by telling the kernel via the attached debugger, or by using a special keystroke combination.[23] This is usually seen by driver developers, as it is used to get a memory dump on Windows NT based systems. An alternative to 0xDEADDEAD is the bug check code 0x000000E2,[24] as they are both called MANUALLY_INITIATED_CRASH as seen on the Microsoft Developer Network.
0xDEADD00D 3735932941 ("dead dude") is used by Android in the Dalvik virtual machine to indicate a VM abort.
0xDEADFA11 3735943697 ("dead fall" or "dead fail") is used by Apple in iOS crash reports, when the user force quits an application.[3]
0xDEAD10CC 3735883980 ("dead lock") is used by Apple in iOS crash reports, when an application holds on to a system resource while running in the background.[3]
0xDEADFEED 3735944941 ("dead feed") is used by Apple in iOS crash reports, when a timeout occurs spawning a service.
0xDECAFBAD 3737844653 ("decaf bad") is often found in coding as an easily recognized magic number when hex dumping memory.
0xDEFEC8ED 3741239533 ("defecated") is the magic number for OpenSolaris core dumps.[25]
0xD0D0CACA 3503344330 ("doo-doo caca") is the uninitialized value of GPIO values on the Nvidia Tegra X1.[citation needed]
0xE011CFD0 3759263696 ("docfile0") is used as a magic number for Microsoft Office files. In little endian this reads D0CF11E0, "docfile0".[26]
0xF1AC 61868 ("FLAC") is used as the Free Lossless Audio Codec's audio format tag.[27]
face:b00c 4207849484 ("facebook") used in the IPv6 addresses of www.facebook.com.[28]
0xFACEFEED 4207869677 ("face feed") is used by Alpha servers running Windows NT. The Alpha Hardware Abstraction Layer (HAL) generates this error when it encounters a hardware failure.[29]
0xFBADBEEF 4222467823 ("bad beef") is used in the WebKit and Blink layout engines to indicate a known, unrecoverable error such as out of memory.[30]
0xFEE1DEAD 4276215469 ("feel dead") is used as a magic number in the Linux reboot system call.[31] Other magic numbers to reboot the machine are 672274793, 85072278, 369367448 and 537993216 which in hex translate respectively to 0x28121969, 0x5121996, 0x16041998 and 0x20112000, the birth date of Linus Torvalds and his three sons.[32]
0xFEEDBABE 4276992702 ("feed babe") is the magic number used to indicate the beginning of an OpenRG flash partition descriptor.[33]
0xFEEDC0DE 4276994270 ("feed code") is used as filling pattern by the OS-9 operating system when initializing its RAM.[34]
0xFEEDFACECAFEBEEF 18369614221190020847 ("feed face cafe beef") is the magic number used to send as a password via serial wire to rescue some NXP created controller devices from boot failures.[35][36][37]
0xFFBADD11 4290436369 ("bad DLL"): Used by Windows internally.[citation needed]
0xF00DBABE 4027431614 ("food babe"): The Ledger Nano hardware cryptocurrency wallet used this magic number in the process of signing that was exploited.[38]

Alternative letters[edit]

Many computer languages require that a hexadecimal number be marked with a prefix or suffix (or both) to identify it as a number. Sometimes the prefix or suffix is used as part of the word.

  • The C programming language uses the "0x" prefix to indicate a hexadecimal number, but the "0x" is usually ignored when people read such values as words. C also allows the suffix L to declare an integer as long, or LL to declare it as long long, making it possible to write "0xDEADCELL" (dead cell). In either case a U may also appear in the suffix to declare the integer as unsigned, making it possible to write "0xFEEDBULL" (feed bull).
  • In the (non-Unix) Intel assembly language, hexadecimal numbers are denoted by a "h" suffix, making it possible to write "0beach" (beach). Note that numbers in this notation that begin with a letter must be prefixed with a zero to distinguish them from variable names. A Unix-style assembler uses C language convention instead (but non-Unix-style assemblers are also available on x86 Unix-type OSes).
  • Visual Basic and all previous Microsoft BASICs such as QuickBasic, GWBasic, BASICA and ColorBASIC, use a &H prefix, for example, "&HEADED" (headed) and "&HADC0FFEE" (had coffee).
  • In Pascal and several assembly languages (6502,6809,...), hexadecimal numbers are denoted by a "$" prefix. This allows for words starting with the letter "S", for example "$EED" (seed).
  • In Б3-34 programmable calculators, an alternative hexadecimal alphabet was used, where the symbols "−", "L", "C", "Г", "E", and " " (space) were used instead of Latin letters. Using these, it was possible to display messages like "EГГ0Г" (error).

PlayStation 3 RSX

In reverse engineering aspects of the Sony PlayStation 3, a number of hexspeak codes were found to either trigger, affect or were present in aspects of communicating to and through the PlayStation 3 Hypervisor in communication to its GPU, the RSX Reality Synthesizer.[39]

These projects were largely born out of PS3 homebrew operating on the PS3's OtherOS which allowed Linux to be installed, initially with extremely limited GPU access.

CodeDescription
0x1337BEEF0x1337F0010x1337BEEF Found as part of the RSX Descriptor.
0xF00DBEEF The RSX Semaphore Value
0x1337C0D3 and 0x1337BABE Begin semaphore value and pad, from the system.[40]

See also

posted on 2023-04-03 14:37  不及格的程序员-八神  阅读(184)  评论(0编辑  收藏  举报