1) если положить данные ниже esp mov [esp-4],111 то сохранится ли это значение или оно потрется например каким-нибудь прерыванием? 2) какой должен быть минимальный размер свободной области стека, если например делать так bottom dd 111 dd 222 dd 333 top dd bottom ... xchg [top],esp pop [mem1] pop [mem2] pop [mem3] pop esp
1) Прерыванием? Речь о дос? В любом случае потрётся первым вызовом прерывания, первым call, первым push. Хотя может я вопроса не понял, потому как это и так очевидно. 2) Вообще-то top он на то и top, что сверху должен быть, т.е. должен иметь меньший адрес. Но это придираюсь. А вообще код должен нормально отработать. Какая еще "свободная область стека"?
речь о винде. 2) если "чтото" использует стек процесса кроме самого процесса, то это "чтото" будет писать в область стека ниже текущего esp, тогда код somedata dd 000 new_esp dd 111 ... mov esp,new_esp ... потрет somedata ?
GoldFinch Во-первых, стэк закрепляется за каждым потоком отдельно, а не за процессом в целом. Во-вторых, что это за такое загадочное "что-то", что будет использовать стек потоков процесса и находиться при этом за пределами этих потоков?
GoldFinch Даже если бы так и было, то без возврата стека потока в начальное состояние перед выделением процессорного времени этому потоку любой поток бы обрушился. И вообще стэк любого потока - это часть юзермодного адресного пространства процесса. Не может система просто так взять и напачкать там. P.S. Когда поток переходит в нулевое кольцо, то там, конечно, другой стэк, который не является частью юзермодного адресного пространства. Т.е. в момент перехода (SYSENTER'а под XP на intel) ESP подменяется.
GoldFinch кладет при иксепшыне ядро затирает юзер-модный стек нулями вниз для проверки чтобы юзер-модные обработчики ексепшынов которые будут там работать не йопнулись если твоя гениальная прога не имеет с иксепшынами (втч юзер-модными дебаггерами) ниче общего - вперед
нормальные дебаггеры в стеке подопытной проги стараются "не мусорить", в противном сл. их было бы легко обнаружить
leo пример нормального дебаггера в студию еще раз: любой ексепшин в вин32 обнуляет стек ниже указателя на 200+ слов это делает nt!KiUserExceptionDispatcher пример дебаггера у которого этот код не выплняется, плиз
z0mailbox Вы хотите сказать, что при каждом шаге во время трассировки в юзермодном отладчике обнуляется стэк? INT3 ведь тоже вызывает исключение, которое только в юзермоде обрабатывается отладчиком. Что-то никогда в Olly, например, не наблюдал изменений стэка выше ESP. P.S. Говорю именно выше ESP, т.к. стэк растет к младшим адресам. А рост по определению направлен вверх. Хотя это и не суть важно. Просто уточняю для исключения недопонимания.
Речь идет только о варианте оптимизации кода по размеру, чтобы вместо mov [a1],d1 / mov [a2],d2 /... / mov [an],dn - 10*n байт кода написать _data dd $+4,d1,d2,d3,..,dn ;4*(n+1) байт данных xchg [_data],esp / popd [a1] /.../ popd [an] /xchg [_data],esp ;6*(n+2) байт кода Ну и разумеется, мне как всякому нормальному программисту не хочется чтобы ктото реверсил мой код.
z0mailbox KiUserExceptionDispatcher засоряет стек, когда исключение не обработано отладчиком и передано проге. Свои сингл-степы и брикпойнты отлатчик ес-но обрабатывает сам и проге не передает, поэтому не трегоает стек ни "выше" ни "ниже" esp. PS: "Наследить" в памяти процесса могут только "недоделанные" плагины, внедряющие куски своего кода в процесс
l_inc leo Да, признаю что насчет отладчика это я немного погорячился GoldFinch "Бармену не повезло больше всего..." - как раз дебажить твою прогу ЭТО не помешает Все ексепшины обнуляют стек кроме отладочных
