Интересная тема для оффтопа.

С разрешения автора привожу текст (все ники, какие возможно, убраны):

<здесь был ник> пишет:

Нет смысла делать отладчик без хвостов в нулевом уровне. DEBUG API винды это архитектурный понос. Поделок на базе него сделано уже овер 1000 и <здесь был ник> при все моем уважении к нему делает очередную поделку. О вкусах не спорят, но какие могут быть вкусы, если я за 5 минут могу наваять программу, которая выбросит OllyDbg или в вылет или в синий экран (при наличии фантома). Никто просто качественный софт в мире реверс-инженерии не видел, а все кто хотел не справились с задачей морально, отсюда и все холивары. А идея в том (не только у меня, а вообще у всех кто имеет представление об отладке и о внутреннем устройстве DEBUG API) чтобы обойти DEBUG API и делать все на прямую - где перехватом IDT (например, захват pagefault'ов в обход механизма свопа, чтобы тот не испоганил наши хак-методы бряков на память и абсолютно невидимых точек останова), где через KiDispatchException (куда летят все исключения всех программ, дабы обработать их через SEH/VEH или вызовом AeDebug). Еще отладка ускоряется тем, что API выглядят НЕ так:

BOOL WINAPI WaitForDebugEvent(
_Out_ LPDEBUG_EVENT lpDebugEvent,
_In_ DWORD dwMilliseconds
);
BOOL WINAPI ContinueDebugEvent(
_In_ DWORD dwProcessId,
_In_ DWORD dwThreadId,
_In_ DWORD dwContinueStatus
);

А вот так:

DBGAPI_API
int CALLING_CONVENTION dbg_continue_event(
PVOID remote_id,
HANDLE proc_id,
u32 status,
PEXCEPTION_RECORD new_record
);

На хуя две API??? Каким наркотиком надо было колоться, чтобы это придумать??? Индуссо-китайский код мелкософта, работникам которого важней получить премию в конце года против написать хороший код и концепт. В итоге имеем два системных вызова, которая идут следом друг за другом. В NIX'ах вообще всю отладку делает одна функция - ptrace(). Там у них на это хватило ума.

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

Вы почему-то путаете ядерный отладчик и концепцию <здесь было название отладчика>. Все говорят, на кой хрен GUI к ядерному отладчику (типа намек на удаленную отладку). Ну так вот. <здесь было название отладчика> никогда не планировался быть ядерным отладчиком, а драйвер нужен чтобы сделать его невидимым. Абсолютно невидимым, если у защиты нет драйвера. А от драйверов большинство "защитников" отказались. Вот и все. И поэтому немного смешно наблюдать за поделиями вроде умершего уже EDB, умирающей OllyDbg (а она умрет) и "рожденного мертвым" отладчика <здесь был ник>. GUI там вроде годный намечается, но я боюсь, они его сильно испортят жестким натягиванием на x86_64/x86 архитектуру и Windows DEBUG API.

Давайте обсудим:

1) Концепцию идеального отладчика.
2) DebugAPI vs Ring0.
3) Умрет ли OllyDbg.
4) Нужно ли, если задача только скрытие отладки, писать новый отладчик. (Возможно для этого достаточно написания плагинов к уже существующим?)

-----
http://ntinfo.biz

| Сообщение посчитали полезным:

5) Пусть <здесь был ник> сам возьмет и напишет идеальный отладчик. После и поговорим.

| Сообщение посчитали полезным:

Я потихоньку пытаюсь отвязать Ollydbg от debugapi, заменив его двумя dll:
1)frontend. Внутри Olly, которая перехватывает CreateProcessW, WaitForDebugEvent, ContinueDebugEvent, Get/SetThreadContext и вместо них синхронизируется с backend
2)backend. Инжектится при старте дочернего процесс, вешает свой VEH обработчик + пару хуков. При всяких событиях собирает структуру DEBUG_EVENT и отправляет ее в frontend.

Теоретически большую часть этого можно вынести в ring0.

| Сообщение посчитали полезным:

Сайд очень гибкий, большинство антидебаг метод обходит. Если сделать нотифи на потоки и проецирование модулей(что весьма просто), то получится полный аналог дебагапи.

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

Про TF можно сразу забыть.

| Сообщение посчитали полезным:

1) есть интересный концепт) но нереализуемый, при котором все бросается в емуляцию вирутального CPU в ring3, этот концепт еще можно было бы натянуть если отладчик сам запускает приложение,

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

2) ни тот ни другой, потому что дебуг апи хоть это и стандартный интерфейс - это ограничения,
а ринг0 ... да с таким же успехом тогда через bochs в иде отлаживать можно хоть всю ось, ограничений не припомню

3) с++ уже который год закапывают)))

4) проще плагин для скрытия

| Сообщение посчитали полезным:

Эту тему поднимали уже лет шесть назад. Имхо нужно писать полностью виртуальную машину, в который будет встроен отладчик, структуры, дефайны, аналитика и т.д. Но это довольно трудоемко, и разработка будет стоить где то 80к$.

-----
have a nice day

| Сообщение посчитали полезным:

Nimnul пишет:
Имхо нужно писать полностью виртуальную машину, в который будет встроен отладчик

для нее насколько я помню все же драйвера уровня ring0, нужны,
а мой 1) концепт предполагал все в ring3

Nimnul пишет:
разработка будет стоить где то 80к$.
если заказывать у мелкософта?)) а если это пишут те кому это надо, то это не стоит ничего

поэтому здесь вариант аля ида+bochs проще
тоже самое, и уже все готово
тогда останутся всякие плюшки в виде плагинов для скриптов, если кому то надо

| Сообщение посчитали полезным:

bochs работает слишком медленно. Кстати если кто начнет делать такой проект я могу дать пару практических советов, как сделать "быстрый" виртуальный процессор.

-----
have a nice day

| Сообщение посчитали полезным:

Nimnul пишет:
bochs работает слишком медленно
код боша открыт, изменяй не хочу)

а что конкретно там медленное? полагаю что то типа отладки всяких игрушек? ну так этот дебаггер не для игрушек если я правильно понимаю

| Сообщение посчитали полезным:

>> для нее насколько я помню все же драйвера уровня ring0, нужны,

В том то и дело, что для полностью виртуальной машины никаких дров, все стандартное. Отладчик будет надсистемным. Представь что ты мог бы физически тормознуть проц, и посмотреть что в регистрах, что в памяти.

>> код боша открыт, изменяй не хочу)

== Переписывать все с нуля

>> а что конкретно там медленное?

Да все прогрузи там винду, я не знаю как сейчас, но раньше это занимало добрый час. Отладчик должен быть быстрым, должен делать аналитику, давать подсказки по структурам системы, PE, встроенный просмотр памяти, управление планировщиком потоков. Ну вобщем нужно целый доклад писать, что должен уметь нормальный полноэмулирующий отладчик ))

-----
have a nice day

| Сообщение посчитали полезным:

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

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

| Сообщение посчитали полезным:

Да он не будет атачиться )), он и будет моделировать виртуальный проц и память, а так же исполнять код. В любой момент этот процесс можно тормознуть. Кстати забыл добавить, что в таком случае можно ставить интеллектуальные бряки на которые только фантазии хватит.

-----
have a nice day

| Сообщение посчитали полезным:

reversecode Ты просто путаешь полностью виртуальную машину, с псевдо виртуальными машинами, которые сейчас существуют. Псолькольку мне известно нет еще ни одной полностью виртуальной машины.

-----
have a nice day

| Сообщение посчитали полезным:

Nimnul пишет:
Да он не будет атачиться )), он и будет моделировать виртуальный проц и память,
медленно медитирую...
написали мы отладчик который ты хотел за 80к,
запустили его, хотим аттачнутся к уже готовому процессу что бы поотлаживать его
контекст cpu мы можем свичнут, а что с памятью делать? а всю страничную адрессацию?
ну вообщем тяжеловато именно этот момент во мне переваривается

и да, что это за отладчик, в котором ты только cpu емулируешь?
остальные данные как ты по процессу вытянешь?
или это будет псевдо отладчик только с состоянием cpu и бряками?

у того же ida+bochs, есть два режима, один из которых именно емуляция CPU

| Сообщение посчитали полезным:

Память будет просто кусок реальной памяти, с которой работает ЦПУ. Другие устройства можно мапить в виртуальную машину, а можно их тоже эмулировать. Процессор этот не должен эмулировать всю архитектуру например Core i7, с его кешами, выборками и т.д. Процессор будет эмулировать только логическую модель команд x64\x86\arm.

>> запустили его, хотим аттачнутся к уже готовому процессу что бы поотлаживать его

Хорошо тут подробнее. Захотел ты отлаживать процесс. Нажимаешь паузу в ВМ, и теперь ты отлаживаешь ВСЕ вместе с ядром и IO железяк. В этот отладчик можно будет встроить механизм Step Out для переходов в Ring0, если ты отлаживаешь просто процесс.

Как работает обычный процессор? По сути он парсит команды, потом что то делает. Так же и виртуальный проц, будет парсить команды потом что то делать. ВМ которые есть сегодня практически ничего не парсят, код исполняет реальный проц. Если ты сделал программу которая эмулирует железо, память, hdd, то что мешает организовать в этой программе надсистемный отладчик?

-----
have a nice day

| Сообщение посчитали полезным:

Итак. Пришли к выводу, что идеальный отладчик это виртуальная машина, эмулирующая всё и быстро работающая. Тогда разработка обойдется не в 80k, а раз в 5 больше(минимум).

-----
http://ntinfo.biz

| Сообщение посчитали полезным:

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

но весь концепт всю архитектура у меня например нет времени продумать, а поверхностно все равно не складывается

| Сообщение посчитали полезным:

reversecode, одного виртуального CPU не хватит, так как нужно будет эмулировать еще к примеру и windowsAPI(сам же об этом писал).

-----
http://ntinfo.biz

| Сообщение посчитали полезным:

reversecode пишет: потому что готовых и приватных дохрена и больше.

Не только в привате ( там и с jit есть ), вполне себе концепты и на паблике лежат, но не видно что бы народ особо пилил.
Например pokasdbg кто не видел осторожнее перед запуском, автор нуб и выложил зараженный сектором бинарь, на основе поковского эмуля есть библиотека
winSRDF и еще больше десятка подобных прожектов.
Оперативная память несложно эмулится, как и апишки, тем более готовая малварная база уже есть, а в малварке юзается тоже самое, что и в протах.
Вообще все сводится ко времени, точнее к отсутствию оного, многие начинали, но погрязли в работе и положили болт на эмуль.

| Сообщение посчитали полезным:

Думаю трудоемкость эмулирования Windows API выше, чем трудоемкость написания полноценной виртуальной машины с отладчиком, на которую будет установленна обычная винда\линукс\андроид\осх. И конечно все проекты загнутся без финансирования, жрать же что то надо... Есть выход собрать бапки на кикстартере, а потом продавать буржуям лицензии. Полноэмулирующая ВМ со встроенным отладчиком, имеющая к тому же несколько виртуальных процессоров, x64,x86,arm etc позволит создать офигенный инструмент для разработчиков софта под всякое железо.

-----
have a nice day

| Сообщение посчитали полезным:

Nimnul пишет:
Думаю трудоемкость эмулирования Windows API выше, чем трудоемкость написания полноценной виртуальной машины с отладчиком

Зачем все эмулить?
Особой сложности нет, рутина и один человек мягко говоря устанет сидеть и пилить эмуль апишек, сродни конвейеру от которого едет крыша.
Эмулить нужно только то, от чего может настать звиздец, остальное можно запилить, как прокси, ну например _GetProcess() { return GetProcess(); }
Запилил от фонаря, лишь бы донести суть.

| Сообщение посчитали полезным:

То о чем я говорю позволит сделать универсальный отладчик любого кода любой платформы. То о чем вы говорите, мне представляется как отладка процесса с весьма ограниченными возможностями. Кроме того процесс сможет опознать такую отладку вызвав то что вы не эмулируете. Все дырки всеравно не заткнешь. Достаточно сравнить время исполнения. Представляю себе прога дергает АПИ из контекста отладчика. Первая проблема это прятать дллки отладчика. Вторая проблема это полностью эмулить работу с памятью. Полностью эмулить работу с хендлерами, потоками, кэллбеками. Дядя жо будет вашим лучшим другом.

>> Эмулить нужно только то, от чего может настать звиздец

А звидец настанет от чего угодно, помните что в программе нет ни единого лишнего байта.

-----
have a nice day

| Сообщение посчитали полезным:

hors я про эмуляцию винапи ничего не писал, и даже не подразумевал

| Сообщение посчитали полезным:

reversecode, значит я неправильно понял твою фразу про "данные о процессе уйдут глубоко в систему". Тогда выходит твоя идея вообще не в тему.

-----
http://ntinfo.biz

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

reversecode пишет:
цена 80к поделеная на 100к, потому что готовых и приватных дохрена и больше.

Стоимость разработки это не сколько денег нужно заплатить, чтобы написали программу.
Стоимость разработки расчитывается как количество затраченных часов умноженных на стоимость часа работы разработчика.
Есть ли уже наработки или программисты согласны работать бесплатно, не влияет на стоимость разработки.

-----
http://ntinfo.biz

| Сообщение посчитали полезным:

hors пишет:
Есть ли уже наработки или программисты согласны работать бесплатно, не влияет на стоимость разработки.

именно

поэтому убранные ники и названия программ из начала топика, очень подозрительны и не одному мне хотелось бы их узнать на публике)

| Сообщение посчитали полезным:

reversecode пишет:
поэтому убранные ники и названия программ из начала топика, очень подозрительны и не одному мне хотелось бы их узнать на публике)

<здесь был ник> читает этот топик, так что можно написать ему здесь пожелания по будущему отладчику.

-----
http://ntinfo.biz

| Сообщение посчитали полезным:

hors Это тот чье имя можно произносить только шопотом? ))) Тьма, тьма глубоко сидит внутри ваших мозгов друзья )

-----
have a nice day

| Сообщение посчитали полезным:

Nimnul пишет:
hors Это тот чье имя можно произносить только шопотом? ))) Тьма, тьма глубоко сидит внутри ваших мозгов друзья )

У него может быть с сотню причин не называться. Это его личное дело.
Главное, что он решительно настроен написать (почти) идеальный отладчик.
Лично я не разделяю его скепсиса по отношению к OllyDBG и к другому отладчику для которого я сейчас кое-что пишу.

-----
http://ntinfo.biz

| Сообщение посчитали полезным: