Как то решил сравнить содержимое PEB под ОllyDbg и без нее в XP (sp1).
Получилась интересная вещь, что кроме байта BeingDebugged и разного "мусора" четко различаются значения указателя PEB.Ldr (смещение 0Ch). Пример:
0С: 00241E90 - без отладчика
0С: 00241EA0 - под OllyDbg => +10h - какие-то 16 байт
Кто что думает по этому поводу ?
Может ось все таки вставляет какие-то ссылочки на дебаггер в контекст процесса ? Или это опять частный случай ?

special for volodya: что говорят на этот счет твои "упаковщики" ?

PS: я по прежнему под мастдаем парюсь, так что подробнее покопаться не получается

Вот тебе ещё результаты из других осей

00071E90h - w2ksp4
00071EA0h - w2ksp4 + olly
00131DC8h - nt4.0
00131DD0h - nt4.0 + olly

bogrus
Спасибо за результаты из других осей.
В теории я не силен, но вроде бы значения не зависят от запуска других приложений. Как твое впечатление ?

PS: Ой.. Насчет "других приложений" - это пивной глюк. Пить меньше надо.., но не получается..

„но вроде бы значения не зависят от запуска других приложений“

Что значит других , у других своё пространство . Тебя же интересует запуск под отладчиком . Я проверял не только с олли , действительно это значение разное . А почему разное , так это надо курить PEB , для чего оно там используеться .

bogrus
Да, насчет других приоложений я чушь спорол, прошу прощения (хотел поправить да не успел, ты меня опередил).

А теоретики, сегодня отдыхают ?

Пока вопросы плодятся быстрее чем ответы..

1) Пытался "выйти на след" отладчика через OutputDebugString, но погряз в дебрях. В отличие от 9х, никакой предварительной проверки наличия отладки не делается. "Тупо" устанавливается SEH с каким-то запутанным обработчиком и вызывается kernel32.RaiseException. Что дальше ? Где будет обработано это исключение, в этом SEH или в глубинных "потрохах" ситемы ?

2) Промотр ntdll.ConnectToDbg показывает, что еще какой-то признак отладки пишется в TEB.DbgSsReserved (dword TEB+F24h). Если он не 0, то на выход с песнями. Если 0, то ссылочка на это поле передается в ntdll.ZwCreateDebugObject. Дальше - дебри.

Промотр ntdll.ConnectToDbg показывает, что еще какой-то признак отладки пишется в TEB.DbgSsReserved (dword TEB+F24h). Если он не 0, то на выход с песнями. Если 0, то ссылочка на это поле передается в ntdll.ZwCreateDebugObject. Дальше - дебри.


Слушай, я дико занят. У меня сейчас курсы по MySQL. Эти дебри - это LPC. А DbgSsReserved - это два DWORD'a. В третьих упаковщиках эта тема ДЕТАЛЬНО прорабатывается. Все там будет. Не морочь пока себе этим голову.

volodya
Как говориться, и на том спасибо.

"А DbgSsReserved - это два DWORD'a"
Знаю, знаю. Я хотел сказать, что ConnectToDbg проверяет на 0 только первый dword.

А как скоро ожидаются твои "третьи" ?

Я хотел сказать, что ConnectToDbg проверяет на 0 только первый dword.


NtCurrentTeb()->DbgSsReserved[0] - это объект синхронизации
NtCurrentTeb()->DbgSsReserved[1] - хендл LPC-порта на стороне клиента.

А как скоро ожидаются твои "третьи" ?

Третьи состоят из двух частей. Т.к. вводится очень большой объем криптографии, то пишется математическое введение. На данный момент введение доросло до 20 страниц. Полагаю, еще столько же - и можно класть на сайт :) Третья часть тоже пока только 20 страниц. Сначала закончу мат. введение. Положу на сайт. Потом крепко возьмусь за собственно статью. Очень много интересных наработок и много людей подключено.

2 volodya
До выпуска долгожданной статьи обратите ,пожалуйста ,внимание на Titanium 4.0 от BitArts . В нем используется на мой взгляд интересный метод защиты и упаковки.

manOwar
А не дашь ли линк, нато что тебе понравилось?

У меня есть только программа , защищенная Titanium 4.0 ,
а самого протектора нет.