# новый способ ловли fs

Same Old Song супер! однозначно

 

Hellspawn

чавойто ты там изобразил на картинке?

 

kaspersky

не, плагины палить не кошерно, т.е. хуки им поставленные, можно нарваться
на хуки какого-нибудь аутпоста вместа плагина

 

ничё не изображал всё как есть
EXCEPTION_ACCESS_VIOLATION на [00030FFCh]

 

а вот меня интересует почему в след. коде адрес ESP не 30FFCh, а 31000h

Код (Text):

1. CreateProcess(0,argv[1],0,0,0, DEBUG_PROCESS,0,0,&sis, &x));
2. dev.dwProcessId=x.dwProcessId; dev.dwThreadId=x.dwThreadId;
3. for(;;)
4. {
5. WaitForDebugEvent(&dev,INFINITE);
6. switch(dev.dwDebugEventCode)
7. {
8. case EXCEPTION_DEBUG_EVENT:
9. printf("Exception (%X) @0%Xh\n",
10. dev.u.Exception.ExceptionRecord.ExceptionCode,
11. dev.u.Exception.ExceptionRecord.ExceptionAddress);
12.  
13. context.ContextFlags = CONTEXT_INTEGER|CONTEXT_CONTROL;
14. GetThreadContext(x.hThread, &context);
15. printf("EIP = %08Xh ESP = %08Xh\n", context.Eip, context.Esp);

кстати, наконец осилил механизм желтых и красных страниц стека.
я-то осел думал, что EXCEPTION_STACK_OVERFLOW выскакивает
при обращении к предпоследней странице стека, после чего
система выделяет нам еще одну страницу, чтобы мы могли как-то
обработать возникшее исключение...

и куча статей (http://bbs.vbstreets.ru/viewtopic.php?t=28535)
подтверждала мои мысли. оказалось НИ ХРЕНА!
EXCEPTION_STACK_OVERFLOW выскивает при первом обращении
к _последней_ странице стека. но только один раз. после чего
ее можно использовать по своему усмотрению... с учетом того,
что стек растет вверх, мы имеем почти страницу стека, но...
может и не страницу. это смотря что за код будет. скажем, если
PUSH EBP/SUB ESP, 1FF0h/PUSH ESI и если PUSH EBP попадет
на предпоследнюю страницу стека, то после уменьшения ESP
оставшегося стекового пространства не хватает для обработки
исключения, сгенерированного PUSH ESI и процесс тихо умирает.

а вот при доступе за границы стеке генериться EXCEPTION_ACCESS_VIOLATION,
на 30FFCh, но поскольку управление в юзер спейс не передается,
то в регистр ESP остается равен 31000h... именно так!!!

так что это хороший путь обнаружить отладчик
ольга грит, что ESP == 30FFCh, но это не так.

я вот только думаю... и хочу спросить у народа. что лучше сделать:
породить отладочный процесс и ловить исключения оттуда?
или написать драйвер, ловящий исключения из ядра?
кстати, никто не в курсе на XP и Висте отладка уже отлаживаемых
процессов возможна или нет? на w2k - нет и это смерть Ольги
но порождать отладочный процесс - как-то не хочется.
драйвер красившее будет просто ловить исключение и смотреть:
если ESP == 30FFCh, то мы под Ольгой

 

жестокая антиотладка, по-моему она вообще практически не применима и
опасаться нам нечего

 

Hellspawn
надо будет крякмис заточить

 

Идея конечно интересная, но на практике выяснилось, что засунуть в fs лабуду и отслеживать(на екзепшенах) все обращения к fs можно до первого перехода в ring0, так как после sysenter в fs записывается правильное значение и мы теряем контроль, а жаль...

 

Дык так и есть. Недавно сам тестил эту фигню, вылетел под конец stack overflow, свободно было около 12 или 16 байт на последней странице. Успело выполнить несколько push'ей в обработчике исключения и ушло кудато в астрал )

 

Great
подозрительно. трудно представить себе ситуацию при которое такое может быть... если мы выходим за красную сторожевую страницу (термин DEC) командой SUB ESP, XXL и попадаем в в след. страницу, то там уже EXCEPTION_STACK_OVERFLOW не выскакивает, а когда эта страница кончается мы имеем EXCEPTION_ACCESS_VIOLATION.
таким образом. в худшем случае когда генериться EXCEPTION_STACK_OVERFLOW мы имеем 1001h байт стековой памяти. и еще целую страницу, которую можно выделить в обработчике исключения но никак не несколько байт... ну я просто не представляю как такое вообще может быть, чтобы при EXCEPTION_STACK_OVERFLOW у тебя до конца стека осталось несколько байт. а при дальнейшем переполнении стека ядро просто термирует процесс вот и все, хотя это можно перехватить либо через Dbg API на прикладном уровне, либо через Kd* на уровне ядра и корректно обработать ситуацию.

кстати, я тут новый баг нарыл в винде. неточный подсчет времени - сколько процесс занял процессорного времени. очень легко можно сделать так, чтобы мы отожрали несколько часов ЦП , а диспетчер задач показал всего несколько секунд и нулевую загрузку ЦП. причем из всех API функций вызывается только Sleep(1), а так - pure c вот сейчас думаю - акутальный это баг или неакутальный

мне приходилось покупать процессорное время на суперкомпах, правда, там не винда стояла, но... насколько я в курсе есть вычислительные центры, которые торгруют ЦПшным временем и квотируют это самое время. я даже для Server 2003 видел кучу приблуд, квотирующих время ЦП пользовательских приложений, исполняющихся на сервере...