Отзывы о ней не очень хорошие — н-р, крешит Вин 7. Попробовал собрать тот проект под VC 2012 — не собирается — куча конфликтов. Да это и понятно, проект писался 10 лет назад.
Есть есть недокументированные функции в ntdll: RTLCreateUserProcess, zwCreateUserProcess, ntCreateUSerProcess.
RTLCreateUserProcess, описание нашел http://hex.pp.ua/nt-native-create-process.php , но как я понял , ее использовать можно только для запуска native приложений,
на других апп ложит ОС. По другим ф-циям та же противоречивая инфа в гуле.
Может, кто подскажет решение, ну хотя бы под Вин7 32 ?
V>Может, кто подскажет решение, ну хотя бы под Вин7 32 ?
есть еще способ, с установкой драйвера запускать свой собственный сервис,который потом по команде драйвера будет запускать мой процесс в user mode. Но мне не хотелось держать для этой цели работающий сервис на машине пользователя. Что посоветуете?
V>>Может, кто подскажет решение, ну хотя бы под Вин7 32 ?
V>есть еще способ, с установкой драйвера запускать свой собственный сервис,который потом по команде драйвера будет запускать мой процесс в user mode. Но мне не хотелось держать для этой цели работающий сервис на машине пользователя. Что посоветуете?
единственно правильное решение — именно юзермодный хелпер в виде сервиса, даже не думайте о другом.
Здравствуйте, Vicul, Вы писали:
V>есть еще способ, с установкой драйвера запускать свой собственный сервис,который потом по команде драйвера будет запускать мой процесс в user mode. Но мне не хотелось держать для этой цели работающий сервис на машине пользователя. Что посоветуете?
Например, добавить задание в планировщик Windows, которое бы срабатывало на появление в
системном журнале события с определенным кодом и запускало бы нужное приложение.
Будет работать только на Vista и выше.
O>Например, добавить задание в планировщик Windows, которое бы срабатывало на появление в
Хотелось все это сделать в драйвере и не тащить лишнее к пользователю. Да и должно все работать с хр до 8
Скорее все буду делать через сервис.
Всем спасибо
Здравствуйте, Vicul, Вы писали:
V>Хотелось все это сделать в драйвере и не тащить лишнее к пользователю. Да и должно все работать с хр до 8 V>Скорее все буду делать через сервис.
Делать через сервис или обычное юзермодное приложение, конечно, более идейно.
А вариант с планировщиком это я так предложил, как информацию к размышлению.
V>>Может, кто подскажет решение, ну хотя бы под Вин7 32 ?
V>есть еще способ, с установкой драйвера запускать свой собственный сервис,который потом по команде драйвера будет запускать мой процесс в user mode. Но мне не хотелось держать для этой цели работающий сервис на машине пользователя. Что посоветуете?
в принципе написать загрузку длл(дальше эта длл уже может запустить новый процесс или всё сделать в текущем) из ядра в процесс, которая бы 100% корректно работала на всех windows(от xp x86 до win8 x64) — вполне возможно. но для данной задачи это, я думаю, далеко не лучшее решение. лучше написать сервис в виде длл, работающий в одном из сущетсвующих svchost-ов.(но не в виде отдельного exe cо своим процессом). в таком виде — дополнительные ресурсы минимальны — всего лишь +1 одна длл в памяти(а всего их > 100 ), а не дополнительный процесс.
Здравствуйте, anonymous185, Вы писали:
A>в принципе написать загрузку длл(дальше эта длл уже может запустить новый процесс или всё сделать в текущем) из ядра в процесс, которая бы 100% корректно работала на всех windows(от xp x86 до win8 x64) — вполне возможно. но для данной задачи это, я думаю, далеко не лучшее решение. лучше написать сервис в виде длл, работающий в одном из сущетсвующих svchost-ов.(но не в виде отдельного exe cо своим процессом). в таком виде — дополнительные ресурсы минимальны — всего лишь +1 одна длл в памяти(а всего их > 100 ), а не дополнительный процесс.
а разве можно из x64 приложения/dll вызвать 32 битную dll ?
а разве можно из x64 приложения/dll вызвать 32 битную dll ?
нет, нельзя. но в чём проблема написать 64 битную dll ?(если есть исходный код). если нет ассемблерный вставок — то правильно написанный код без проблем компилируется/линкуется/работает для x64. вообще моё личное мнение, что для x64 систем нужно использовать именно x64 код. x86 код(в 64 бит системе) не на 100% функционален. некоторые тонкие вещи не работают.
S>а разве можно из x64 приложения/dll вызвать 32 битную dll ?
Я сам не делал, но если исходить из того, что 32-битные приложения в 64-битных системах запускаются в эмуляторе и хост-процесс один хрен 64-битный, то нет ничего невозможного.
Здравствуйте, x64, Вы писали:
S>>а разве можно из x64 приложения/dll вызвать 32 битную dll ?
x64>Я сам не делал, но если исходить из того, что 32-битные приложения в 64-битных системах запускаются в эмуляторе и хост-процесс один хрен 64-битный, то нет ничего невозможного.
вопрос возник тк мне надо в x64 приложении использовать 32 битную dll,
ее исходников у меня нет и уже не будет
поэтому я пока думал использовать эту dll через service
буду очень блогадарен если вы покажите куда копать что бы вызывать непосредственно из x64 приложения
S>поэтому я пока думал использовать эту dll через service
Можно службу сделать всегда 32-битной, тогда она везде сможет загружать 32-битные .dlls, но если ей необходимо взаимодействовать с драйвером, то ты должен быть уверен, что драйвер умеет работать с процессами "нестандартной" разрядности (т.к. драйвера всегда "правильной" разрядности), там есть нюансы в обработке буферов и т.п., в документации ищи по ключевому слову "IoIs32bitProcess".
S>буду очень блогадарен если вы покажите куда копать что бы вызывать непосредственно из x64 приложения
Не подскажу, т.к. это недокументировано и делать так не советую, но есть вариант "для бедных" — RunDll32, при этом для 32-битных .dlls на 64-битных системах вызывать её необходимо из папки SysWow64, а не как обычно.
S>>буду очень блогадарен если вы покажите куда копать что бы вызывать непосредственно из x64 приложения
x64>Не подскажу, т.к. это недокументировано и делать так не советую, но есть вариант "для бедных" — RunDll32, при этом для 32-битных .dlls на 64-битных системах вызывать её необходимо из папки SysWow64, а не как обычно.
я думаю что самостоятельно инициализировать wow64 в x64 процессе абсолютно нереально. и не потому что это недокументировано. в wow процессе 64-бит ntdll зазружат wow64.dll и вызывает из неё Wow64LdrpInitialize. но если проделать это из 64-бит процесса — сразу исключение в начале Wow64LdrpInitialize — оказывается wow потоки имеют расширенный 64-бит TEB по сравнению с native потоками, а Wow64LdrpInitialize обращается к этим экстра-полям. а TEB создаётся в ядре... так что загрузить 32-бит длл в 64-бит процесс не получится. с другой стороны, из wow64 процесса можно выполнить 64-бит шеллкод или даже загрузить 64-бит длл, но при условии, что эта длл импортирует только из Ntdll
Здравствуйте, x64, Вы писали:
S>>а разве можно из x64 приложения/dll вызвать 32 битную dll ?
x64>Я сам не делал, но если исходить из того, что 32-битные приложения в 64-битных системах запускаются в эмуляторе и хост-процесс один хрен 64-битный, то нет ничего невозможного.
невозможно это, бинарные соглашения по параметрам функций не позволят.
Re[3]: запуск 32-р приложение из kernel mode
От:
Аноним
Дата:
22.04.13 12:46
Оценка:
I>единственно правильное решение — именно юзермодный хелпер в виде сервиса, даже не думайте о другом.
Сделал все через сервис, день работает — полет нормальный!