Ребят, как отлаживать инжект в исходниках?

Мало ли что может мешать, навскидку, выравнивания секций. В вопросе оговорено - загрузка руками. Если же можно подменить условия задачи и пользоваться LoadLibrary, тогда какой смысл в этих int3, когда то же делается Event Filters или bp? Если модуль есть в списках, то любой вменяемый отладчик должен загрузить для него символы.

 

J0E
+1
На время отложил эту проблему, теперь опять к ней вернулся. Почитал посты. То что советовали - это не то.
Задача стоит именно так, как вы ее поняли. Отлалить шел-код.
Обычную дллку я сам отлажу без труда. В той же студии.

Ребят, задача такая.
Нужно отладить именно инжект. ДЛЛ в списке модулей нет.
Предположим, что вообще никакой ДЛЛ нет.

Есть шел-код, написанный на сях. В наш процесс он инжектится вот так:
VirtualAllocEx -> WriteProcessMemory -> CreateRemoteThread

Вначале шел-кода стоит int 3.

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

 

пути к сорцам находятся в pdb файле, путь к pdb файлу в исполняемом файле в debug directory, так что никак

 

В подобных случаях использовал такой дубовый способ: сборка с ключами /FAs даёт листинг где есть асм команды + строки исходников, потом в этом листинге искал уже ассемблерные команды и соответственно проблемную строку, обычно этого хватало что бы сориентироваться и понять в чем проблема. Если сразу тяжело найти где (например) падает, то можно расставлять точки останова сверяясь с листингом, я называю это "половинным делением", когда трасса делится на участки и бряки постепенно сужается вокруг проблемного места (это когда нет сорцов). Когда есть сорцы, можно подобным образом натыкать int3, но не одиноких, а парами, тройками, совместно с нопами - в общем насоздавать паттернов которые помогут узнавать места в исходниках. Пока хватало так что над автоматизацией не думал, правильнее наверное написать плагин)