Почему стек заполняется 0xCCCCCCCC

В настоящее время я разбираю некоторые небольшие C-программы, созданные в Visual Studio 2012 Express, и я заметил тенденцию среди двоичных файлов.

Первый набор команд, выполняемых в основной функции, всегда:

SUB ESP,154                       ; Doesn't have to be 0x154.
.....
.....
.....
LEA EDI,DWORD PTR SS:[EBP-154]
MOV ECX,55                        ; Also doesn't have to be 0x55.
MOV EAX,CCCCCCCC
REP STOS DWORD PTR ES:[EDI]

Итак, почему машина заполняет стек этим 0xCCCCCCCC? Я читал, что он используется VС++ или что-то в качестве метки для неинициализированного пространства?

Тогда скажем, что я собираюсь что-то положить в свой буфер... Компилятор или процессор решает поставить его в какую-то случайную точку внутри этого пространства, но я не вижу , почему это поставьте его там...

EBP-90   > CCCCCCCC  ÌÌÌÌ
EBP-8C   > CCCCCCCC  ÌÌÌÌ
EBP-88   > CCCCCCCC  ÌÌÌÌ
EBP-84   > 00000001  ...  ; Why this place?
EBP-80   > CCCCCCCC  ÌÌÌÌ
EBP-7C   > CCCCCCCC  ÌÌÌÌ
EBP-78   > 41414141  AAAA ; Why this far from both the top and bottom of the stack?
EBP-74   > CCCCCC00  .ÌÌÌ
EBP-70   > CCCCCCCC  ÌÌÌÌ
EBP-6C   > CCCCCCCC  ÌÌÌÌ

А...

EBP-14   > CCCCCCCC  ÌÌÌÌ
EBP-10   > CCCCCCCC  ÌÌÌÌ
EBP-C    > 00000000  ....  ; Why here?
EBP-8    > CCCCCCCC  ÌÌÌÌ
EBP-4    > 7EA7D069  iЧ~  ; I think this is some stack cookie stuff.
EBP ==>  >/0017FEA8  ¨þ.   ; Saved EBP.

Предоставлено, что 1 и 0 слова хранятся здесь из-за некоторых операторов if, но мне просто интересно, почему они размещены там, где они есть. Если за этим стоит какая-то логика.

Спасибо.

Ответы

Ответ 1

Вы просто видите код, сгенерированный компилятором MSVC, когда вы используете параметр /RTC. Это позволяет проверять время выполнения, включенное по умолчанию в сборке отладки. Значение 0xcccccccc волшебное, это очень хорошо при сбое вашей программы, когда вы используете неинициализированный указатель. Или создайте странное значение int. Или сбой вашего кода, когда он идет бананы, и начать выполнять данные, как если бы это был код. 0xcc - это инструкция x86 для INT 3, она вызывает разрыв отладчика.

"Почему это место" является частью диагностики, которую вы получаете из /RTC. Это заставляет компилятор выделять локальные переменные с дополнительным пространством между ними. Заполнено этим магическим значением. Это очень просто диагностировать повреждение стека, вызванное переполнениями буфера, просто нужно проверить, все ли волшебные значения остаются, когда функция возвращается.

Ответ 2

Я не могу говорить для Visual Studio, но некоторые среды, в которых я закодирован, намеренно заполняли стек с заданным значением (например, 0xcccccccccc). Это было сделано так, чтобы стек можно было отсканировать (начиная со дна), чтобы определить, сколько не было использовано. В встроенных системах, где объем памяти может быть довольно ограниченным, это весьма полезно во время разработки, так что использование памяти может быть оптимизировано.

Надеюсь, что это поможет.