Почему стек заполняется 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). Это было сделано так, чтобы стек можно было отсканировать (начиная со дна), чтобы определить, сколько не было использовано. В встроенных системах, где объем памяти может быть довольно ограниченным, это весьма полезно во время разработки, так что использование памяти может быть оптимизировано.
Надеюсь, что это поможет.