Как-то просмотрел это сообщение, только заметил.
maXmoкстати, посмотри зависимости, не грузится ли при её запуске лишних дллей.
Попытался смотреть остановив отладчиком сразу после отработки внедренного трэда (процесс в состоянии SUSPENDED), загружены уже все dll, которые нужны дочернему процессу.

depends показывает:
KERNEL32.DLL (куча функций)
USER32.DLL (wsprintfA())
ADVAPI32.DLL (InitializeSecurityDescriptor(), SetSecurityDescriptorDacl())

Функции InitializeSecurityDescriptor(), SetSecurityDescriptorDacl() убрал, теперь ADVAPI32.DLL не грузится. Они случайно перетащились из другого проекта, там общий блок памяти использовался для всех пользователей терминал-сервера.

KERNEL32.DLL грузит только NTDLL.DLL
USER32.DLL грузит GDI32.DLL, KERNEL32.DLL, NTDLL.DLL
GDI32.DLL грузит USER32.DLL, KERNEL32.DLL, NTDLL.DLL

От wsprintf() избавиться сложнее, но реально. Уберу, попробую.

Спасибо за совет.

Вот_он_я_какойВнедрить длл можно и через обычные хуки, так даже правильнее будет.
Могу дать исходники внедрения, но на асме:). На асме пока не надо :) Внедрение через хуки у Рихтера с примерами описано. Только очереди сообщений может не быть. Тот процесс, который сегодня гадит на экран не показывается, помолотит немного и закрывается, если не зависнет.
Вот_он_я_какойТо что не успевают инициализироваться длл - очень спорно, но проверить просто - перехватить ZwResumeThread, и процес создавать без флага CREATE_SUSPENDED, а в обработчике ZwResumeThread уже внедрять свою длл.
От этой теории я уже отказался, когда Sleep(500) сделал, а оно снова вылетело и продолжало глючить на всех подряд последующих запусках до закрытия родительского процесса. Сейчас вся надежда что это из-за advapi32.dll и user32.dll которые к моей dll прилинкованы.
Вот_он_я_какойЕщё вариант - создавайте процес с флагом DEBUG_PROCESS - и мониторь все исключения, что происходят.
А это действительно вариант, если не избежать вылета, то хоть от пользователя спрятать. Поизучаю эту тему поподробнее. Я правильно понимаю: я создаю дочерний процесс, в случае исключения об этом информируется родительский, где я могу прибить дочерний и запустить его заново без внедрения?

от wsprintf`а избавился, пришлось правда свой конвертер с юникода делать. Сейчас только функции из kernel32.dll. Есть еще один еще один нехороший момент с другими dll, но его я пока убрал, т.к. еще один серьезный косяк вылез:

Появилась новая дочерняя прога, если в нее внедряться сразу после создания процесса, то у нее кнопки исчезают т.е. если запустить просто - кнопки есть, а если с внедрением моей dll, то вместо кнопок пустые прямоугольники. Причем оставил только внедрение, без перехватов, т.е. в дочернем процессе ничего не делается, кроме загрузки dll. Если дать дочернему процессу до конца загрузиться, а потом внедряться, то все нормально, кнопки есть.
Прога написана на дельфях, кнопки класса TbitBtn (если кто с дельфями знаком)
Заметил что некоторые модули в дочерней проге при внедрении грузятся по другим адресам. Пробовал разные базовые адреса для загрузки моей dll - не помогло.

Как это обойти?

Вот_он_я_какой>>Только очереди сообщений может не быть.
А она и не нужна. Делайте все перехваты в длл майн при загрузке, а потом пусть хоть что происходит.Я наверно что-то недопонимаю. Везде пишут про 2 способа внедрения:
1. Который я использую сейчас, записать в адресное пространство дочернего процесса какой-нибудь код и запустить его через CreateRemoteThread()
2. Через хуки, устанавливается хук SetWindowsHookEx(), а затем шлется сообщение, при приеме которого в дочерний процесс загружается моя dll. Т.е. если очереди сообщений нет, то и дочерний процесс его не примет и мою dll не загрузит
Пишут еще, правда, про третий вариант - копирование всего кода dll из родительского процесса в дочерний и запуск dllmain(), но тут я очень смутно представляю как памятью управлять и как новый базовый адрес задать.
maXmoв дельфе дллки вроде как динамически подгружаются, как ком-модули.
Похоже надо менять способ внедрения. Чувствую не победить мне внедрение до начала работы процесса. Попробую все-таки через хуки, хотя тут можно внедриться после того как все интересное произошло.

White OwlВот исходя из этого, я бы пошел по пути виртуальных файлов. Перемещаешь реальные файлы куда-нибудь подальше, а в стартапе запускаешь свой процесс который создает виртуальный каталог с dbf'ками и все обращения к виртуальным файлам пропускает через себя а потом отправляет к реальным.
Реальные все-равно будут присутствовать и никто не мешает к ним зацепиться. Или кто мешает внедриться в мой процесс и получать правильную расшифрованную инфу. Какое-то серьезное шифрование я использовать не хочу, т.к. прога и так тяжелая, а компы у некоторых клиентов очень слабые, и частенько глючные. Планирую шифровать только полностью восстановимые данные (это несколько файлов), и то для зашиты от копирования на другой комп.
Я вообще не сторонник защиты своего софта, т.к. был печальный опыт расхлебывания гемороя из-за самодельной защиты.
На сегодня я пошел путем кормления шпиенов инфой похожей на правду, но попытки воспользоваться экономическим анализом собранной инфы приведут к неприятным последствиям. Сейчас надо отследить момент когда они поймут что их г...ом кормят, разберутся где правильную инфу взять, и в этот момент переделать базу так, чтобы они снова обломались. Для всего этого есть каналы связи и механизмы автообновления.
Почему и хочется создать в первую очередь механизм контроля, а не защиты. И просто полностью подорвать доверие к собранной инфе, тогда и желание ее собирать исчезнет.