GetModulehandle? из других процессов? EnumProcessModule вообще то и локально применяется, для определенных задач(на пример поиск загруженных библиотек для патчинга, так как одной и тойже либы может быть две в процессе.)
shchetinin А какой именно дебаг ивент? Breakpoint Exception CreateThread ExitThread CreateProcess ExitProcess LoadModule UnloadModule SystemError SessionStatus ChangeDebuggeeState ChangeEngineState ChangeSymbolState Ну да, я отчасти вас понял. Но тогда был бы более простой способ, на этот самый дебаг ивент просто загрузить мою dll. К сожалению с дебаг ивентами в windbg плоховато. Это вторая возможность, которую я рассматриваю, но, честно говоря, я на васме особых спецов по windbg не видел, поэтому решил её здесь не обсуждать -)
sergegers Это не дебаг евенты, это методы колбек интерфейса из мс дебаг инженерии. В данном случае, вам нужен будет Breakpoint . Только провалидировать rEip. Вы что юзаете дебаг инженерию(которая в windbg) для остановки всех потоков? просто так или по событию ? П.С. Вам и в правду нужно матчасть учить ... Не знаю как на васме, но каждый дажет системный программист(или реверсер) хорошо знает виндбг(внутриности, плагины, и технику как с ним работать, в особенности dbgeng. ) и знает что токое дебаг апи.Но к стати да, прото dbgeng мало литературы ...
shchetinin А какая разница, это просто обертка над дебаг евентами. Зачем мне их напрямую использовать, если я в плагине. Breakpoint мне не подойдёт, использование плагина выглядит так: - в отлаживаемом процессе выполняется команда расширения - чтобы её выполнить в отлаживаемом процессе должна присутствовать моя dll Можно пойти двумя путями - загружать её до подсоединении дебаггера к процессу - загружать её в замороженный процесс Второй путь чуть предпочтительней, потому что отлаживаемый процесс никак не будет взаимодействовать с моей dll. Осознавая мою недостаточность знаний работы лоадера я задал вопрос на васм, рассчитывая получить дельный совет. Ни дельного совета, ни аргументированных возражений я не услышал. Первый способ труден тем, что нет такого ивента, где у дебаггера уже установлен целевой процесс, но его потоки гарантированно не засапенжены. Но с этим я не обращаюсь на васм, потому что не так много народу писало расширения для windbg, а в моём случае имеет место нестандартный доступ к памяти отлаживаемого процесса из расширения отладчика. И я позволю высказать себе своё мнение, не стоит посылать меня учить матчасть. Я сознаю недостаточность своих знаний в некоторых областях, но называть бы вас гуру я бы тоже не стал. Но как бы то ни было, сама дисскурсия, пусть неплодотворная, позволила мне взглянуть на проблему свежим взглядом. Спасибо всем, кто принял участие и прошу извинить, если я кого-то задел.
sergegers Интересно, почему ты считаешь, что задача LoaderLock сводится только к манипулированию списками модулей? Разве сам процесс\порядок загрузки и инициализации модулей не использует кучу ресурсов и не требует синхронизации? По крайней мере, очевидно, что твоя dll не должна явно или неявно тащить за собой подгрузку других еще не загруженных или не инициализированных dll (см.грозные предупреждения в DllMain). Плюс, как уже отмечалось, помимо списка модулей и порядка их загрузки\инициализации может юзаться еще множество различных ресурсов, которые могут быть защищены как LoaderLock, так и своими собственными КС. Простой пример - те же списки модулей хранятся в отдельной куче Ldr, и соотв-но поток может быть остановлен на операции выделения памяти в этой куче со своим собственным локом. Соотв-но, если тебе удасться обойти LoaderLock, то можешь застрять на другом локе. А если и его обойдешь, то скорее всего получишь "краш-тест" - или пойдешь дальше копать и пытаться восстанавливать, например, структуру кучи или чего то еще?!
leo Я не считаю, я собственно спросил, что я ещё могу испортить, чтобы оценить список изменений, которые надо было бы внести, если я пойду этим путём. А может, на форуме нашёлся бы человек, который сказал, я делал таким способом, всё работает - это была бы ценная информация. Это не продакшн код, здесь допустимы некоторые вольности. В конце концов сейчас я пользуюсь этим расширением и оно тупо грузит модуль в засаспенженый процесс, просто временами это становится неудобно. А по поводу кучи я вот что скажу как же можно не любить родную природу спасибо, вот ещё один момент, на который стоило бы обратить внимание.
