Конференция VBStreets

**ProgSoldier** » 25.12.2005 (Вс) 23:38

Я прописал в реестре в AppInitDLLs, InprocServer32 свою ДЛЛку, например, Invoke.dll. В результате - она грузится вместе с виндой и с ВСЕМИ ДРУГИМИ прогами, которые лоадятся под форточками... Но прикол, вернее, проблемка в том, что в этой ДЛЛке событие Class_initialize не происходит. В чём я не прав или как нужно сделать, чтобы моя ДЛЛка выполняла комманды?

**xenomorph** » 26.12.2005 (Пн) 0:30

Dll_Attach тоже не срабатывает ... 8-(.

Эти длл - Native dll ...
даже длл писаные мной на азм-е не пахают там ...
ЕМНИП они запускаються до win32 ///
хорошо если кто обьяснит как это их бы инициализировать ...
(я красивее решение нашёл)

**ANDLL** » 26.12.2005 (Пн) 10:43

ЕМНИП они запускаються до win32 ///

В BIOS'е что ли? :lol:

Эти длл - Native dll ...

Других и не бывает...

**xenomorph** » 26.12.2005 (Пн) 14:33

2 ANDLL:

В этом мире _всё_ бывает ...

"Слежение за вызовом функций Native API"
http://www.wasm.ru/article.php?article=tracknapi

API бывают разные - серые голубые и красные ...

Подсистема Win32 запускаеться _после_ указаных длл.

Я думаю - в статьях про создание длл на www.vbstreets.ru
авторы допустили неточночть - под native DLL они понимают -
обычную длл - т.е. писаную с возможностью экспорта функций,
т.е. не КОМ библиотека - т.к. именно КОМ-ы ВБ и создаёт.

ИМХО это немножко не правильно ...
Native DLL - это dll содержащие вызовы Native API -
т.е. - zw*, nt* ...

MASM32 Code:
;=================================================
.386
.model flat, stdcall
option casemap :none ; case sensitive
include \MASM32\INCLUDE\windows.inc
include \MASM32\INCLUDE\kernel32.inc
include \MASM32\INCLUDE\shell32.inc
include \MASM32\INCLUDE\masm32.inc
includelib \MASM32\LIB\kernel32.lib
includelib \MASM32\LIB\shell32.lib
includelib \MASM32\LIB\masm32.lib
include \masm32\include\user32.inc
includelib \masm32\lib\user32.lib
.data
PayLoad db "cmd.exe",0 ;128 dup (0)
.code
LibMain proc hInstDLL:DWORD, reason:DWORD, unused:DWORD
.if reason == DLL_PROCESS_ATTACH
;invoke WinExec, Addr PayLoad, 0 ; Не Видимо

invoke WinExec, Addr PayLoad, 1 ; Видимо
.elseif reason == DLL_PROCESS_DETACH
.elseif reason == DLL_THREAD_ATTACH
.elseif reason == DLL_THREAD_DETACH
.endif
ret
LibMain Endp
End LibMain
;=================================================

Как только спроэцировать эту длл в а.п.процесса -
LoadLibrary etc ///
то в подсистеме Win32 происходит DLL_PROCESS_ATTACH событие ...

Проблема в том, что при загрузке этой длл через:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs

Этого НЕ происходит.
Библиотека грузиться в АПП, но процедура
.if reason == DLL_PROCESS_ATTACH
НЕ происходит 8-(((.
Или я не понимаю когда она происходит (???)
я уже и рассматривал вариант что в другом DesktopStation ...
Писал тестовій файл в ФС,
а его тама нету - по идее DLL_PROCESS_ATTACH не происзодит и точка ... 8-(...

Я копал, копал и бросил.

Насколько мене не изменяет догадка -
эти длл инициализируются по-другому - т.е.
это подсистема 1 уровня - NativeAPI ///
--
Эта технология может использоваться для автзапуска приложений
если её довести до ума ...
+ для перехвата АПИ на глобальном уровне.
--
Я не утверждаю ... но надеюсь, что в большинстве вышеописаного я прав! 8-)

.

**ProgSoldier** » 26.12.2005 (Пн) 17:40

Ещё интересно то, что кода запускается любая другая прога, винда читает раздел реестра AppInitDLLs, т. е. моя ДЛЛ. Но как всё-таки сделать, чтобы какая-нить ф-ция энтой ДЛЛ активизировалась? И кста, даже в безопаске эту ДЛЛку нельзя удалить + если ещё поставить слежение за реестром, где прописана данная ДЛЛ, то получается вААше не избавишься от неё...

**ANDLL** » 26.12.2005 (Пн) 17:40

По порядку
1) Нету никакой подсистемы win32. В природе. win32 - просто названия семейства оперционных систем.

Native DLL - это dll содержащие вызовы Native API

А если EXE вызывает только эти "native api", то это native EXE? А если он вызывает напопалам, часть "native api", а часть "не native api", то это полу-native EXE?
2)

происходит DLL_PROCESS_ATTACH событие

ладно это комментировать не буду...
3)

DLL_PROCESS_ATTACH не происзодит и точка ... 8-(...

Блин, нежели не понятно, что твоя dll'а просто не присоединяется и все... Зачем придумывать какие-то сложности с тем, что они как-то "нитак" инициализируются?
4)

это подсистема 1 уровня - NativeAPI

А вот тут я пожалуй кое-что поясню. Дело в том, что в windows действительно есть часть операционной системы, которая расположена в верхней(кажеться) части АП. Код отсюда выполняется только в режиме kernel mode, в user mode эта память просто недоступна. Видимо это ты и имел ввиду, называя "это подсистема 1 уровня - NativeAPI". В эту "подсистему" действительно грузятся библиотеки, отличающиеся по своей структуре от обычных dll(хотя они то же являются PE-файлами). Библиотеки эти инициализируются процедурой DriverEnrty(в отличие от DllMain для обычных библиотек). Только называется эти dll не native dll, как ты видимо думаеш, а драйверами.

**ANDLL** » 27.12.2005 (Вт) 9:02

Вот вам dll'а, прописывайте в App.......
Издает beep при запуске каждой программы. До определенного момента...
К сожалению, работает даже в безопасном режиме...

**xenomorph** » 27.12.2005 (Вт) 12:02

1) Нету никакой подсистемы win32. В природе. win32 - просто названия семейства оперционных систем.

Вот:

NATIVE API
Как известно, Windows 2000 , была спроектирована таким образом, что бы дать возможность исполняться не только Win32 приложениям, но так же древним Win16, MsDos, Os/2v 1.x и POSIX. Короче говоря, ось имеет три встроенных по умолчанию подсистемы, каждая из которых исполняет свои образы. Реально, никто нам не мешает добавить в систему поддержку приложений иных операционных систем, всего лишь нужно написать и прикрутить модуль требуемой подсистемы. И все-таки как же это работает? Для ответа на данный вопрос посмотрим на рисунок ниже.

Вопрос подхода к терминологии Win32 - это досистема выполнения кода именно формата РЕ. ИМХО справедливее было бы сказать что ОС имеет 4 подсистемы:
Win32
Win16,
MsDos,
Os/2v 1.x
POSIX
--
А исполнение кода уже происходит в зависимости от необходимости 8-)

т.е. - формата образа.

И далее:

Если запускаемая программа не является Win32 приложением, а программой другой ос, тогда Win2k будет искать для нее соответствующий образ поддержки, который поймёт и запустит данное приложение. Если не найдёт, то вернёт ошибку соответственно. Поясним данную схему. Любой вызов, к примеру, приложения OS/2 будет конвертирован модулем поддержки данного приложения в вызов соответствующей функции родной библиотеки Win32-подсистемы KERNEL32.DLL. KERNEL32.DLL в свою очередь направит вызов одной из функции модуля NTDLL.DLL

Наиболее низким уровнем есть Native API, функции локализированые в модулях NTDLL.DLL через KERNEL32.DLL, ядро системы (KERNEL32.DLL) - это только ядро Win32 подсистемы - отвечающую за диспечиризацию вызовов WinAPI, но НЕ более. Наиболее низким уровнем являеться ядро NTDLL.DLL - оно работает с Native API вызовами.

И ещё:

Исчерпывающую информацию почти обо всех функциях Native Api Вы можете найти в книге Гари Нэббета “Справочник по базовым функциям API Windows NT/2000”, издательский дом “Вильямс”,2002. Но, я подчеркиваю почти , поскольку книга писалась во времена Win2K, то, соответственно, в ней описаны только те функции, которые существовали лишь в данной версии Windows, с выходом новых версий ядер 5.1(WinXP) и 5.2(Win.Net) было добавлено ещё некоторое количество функций, описания которых я, к сожалению не нашёл.

Тут стоит сказать ещё об одном важном моменте –именах функций, точнее их назначении. Как Вы заметили, вроде бы с виду одинаковые функции имеют префиксы Ntxxx и Zwxxx. Если заглянуть дизассемблером в модуль NTDLL.DLL, то особой разницы в этих функциях нет, кроме этих самых префиксов – Nt и сопоставленные им Zw указывают на один и тот же код. Что касается модуля NTOSKRNL.EXE, то в нем дела обстоят несколько иным образом. Функции, имена которых начинаются с префикса Zw, реально экспортируются данным модулем и вызываются напрямую. Функции, содержащие в своем имени префикс Nt – должны пройти ряд проверок на безопасность, прежде чем управление получат соответствующие функции Zw. Впрочем, советую не слишком ломать голову по данному вопросу, если честно, там сам чёрт ногу сломит.

Итого - Zwxxx функции - єкспортируються напрямую - и их поюзать можно. А вот Ntxxx - гемморой ещё тот.

А если EXE вызывает только эти "native api", то это native EXE? А если он вызывает напопалам, часть "native api", а часть "не native api", то это полу-native EXE?

Угу.
Примеры:
NTDLL.DLL - чистые NativeAPI.
Kernel32.Dll - смешанные АПИ.
Список длл-ок в AppInitDLLs - чистые NativeAPI (подозреваю что ТАКИ ДА [они-то экспортируют обічніе АПИ, а вот процедура их инициализации какого-то Х отличаеться!!! ПОЧЕМУ ТОГДА НЕ РАБОТАЕТ ТВОЯ ДЛЛ??? ИМОЯ ТОЖЕ 8-)

))]).
Все нормальные длл писаные на MVC++ // и т.п. - это как правило чистые Вин32 АПИ. NativeAPI в них как правило не вызываються.

Проблема в том, что они НЕ документированы, и 80% не экспортируемы напрямую.

Вот так они выглядят:
zwCreateProcess.
NtDll!ZwWriteFile
NtCreateProcess
NtOpenFile
NtCreateFile
...

DLL_PROCESS_ATTACH не происзодит и точка ... 8-(...
Блин, нежели не понятно, что твоя dll'а просто не присоединяется и все... Зачем придумывать какие-то сложности с тем, что они как-то "нитак" инициализируются?

эээ ... нда? блин - я то могу объяснить - веришь? ... дя чепятать лень.
(признаю что я не прав - если запустишь ЛЮБУЮ длл через AppInitDLLs Ж-)).

А вот тут я пожалуй кое-что поясню. Дело в том, что в windows действительно есть часть операционной системы, которая расположена в верхней(кажеться) части АП. Код отсюда выполняется только в режиме kernel mode, в user mode эта память просто недоступна. Видимо это ты и имел ввиду, называя "это подсистема 1 уровня - NativeAPI". В эту "подсистему" действительно грузятся библиотеки, отличающиеся по своей структуре от обычных dll(хотя они то же являются PE-файлами). Библиотеки эти инициализируются процедурой DriverEnrty(в отличие от DllMain для обычных библиотек). Только называется эти dll не native dll, как ты видимо думаеш, а драйверами.

Извините, но если Вы поёмёте верхнюю часть поста то я, уверен, что Вы поймёте почему ^ЭТО^ я коментировать не буду. Оно мягко говоря НЕ ТО что я имел ввиду. А вопрос kernel mode/user mode это немного офтоп.

И последнне - код драйвера ядра приложить? (МОЕГО драйвера 8-)

)

**ANDLL** » 27.12.2005 (Вт) 12:52

Пожалуй, тему можно закрывать.
Г-н xenomorph своими умозакличениями уморил бы даже Аристотеля.

**ANDLL** » 27.12.2005 (Вт) 13:26

Кстати, эта dll то же скажите не работает?

**ProgSoldier** » 27.12.2005 (Вт) 15:30

А ДЛЛка на СЯх написана :lol:

А нужно-то на ВБ :lol:

**keks-n** » 27.12.2005 (Вт) 16:28

ProgSoldier
На VB DLL, экспортирующую пользовательские функции можно, но подгрузишь ты её тока из VB'шной проги. Сий феномен я объяснить не в состоянии, обращайся к авторам методики.

**ProgSoldier** » 27.12.2005 (Вт) 16:42

Так ты тады не понял вопроса (или всё-таки я не понял ответа :shock:

) : Мне нужно, чтобы ActiveX DLL, ктороя написана на Visual Basic 6.0 стартовала при загрузке Windows XP или любой другой проги. Где мне надо в реестре её прописать и в каких событиях я должен вставить свой код?

ЗЫ. Неуж-то на ВБ6 энто невозможно?

**keks-n** » 27.12.2005 (Вт) 16:54

Это низя сделать для ActiveX DLL.

**ProgSoldier** » 27.12.2005 (Вт) 17:00

keks-n писал(а):Это низя сделать для ActiveX DLL.

А на Сях или Асме? Если можно, то дайте исходничек (простенький, т. к. и в том и в другом плохо разбираюсь) ДЛЛки, которая может воспользоваться автозапуском и ещё запустить ЕХЕшник. :oops:

Заранее благодарен.

**keks-n** » 27.12.2005 (Вт) 17:13

Таак, значит всё упирается в EXE. Ну тады кто мешает написать сервис и зарегить его под системный аккаунт?
Это пишется на VB, не надо никакой спец. DLL, и работает с аккаунтом NT_AUTORITY_SYSTEM

**ProgSoldier** » 27.12.2005 (Вт) 17:19

keks-n писал(а):Таак, значит всё упирается в EXE. Ну тады кто мешает написать сервис и зарегить его под системный аккаунт?
Это пишется на VB, не надо никакой спец. DLL, и работает с аккаунтом NT_AUTORITY_SYSTEM

Тады будет всё упираться в "Диспетчер задач" :lol:

**keks-n** » 27.12.2005 (Вт) 17:36

1) "Диспетчер задач" его не убьёт (оригинальный), т. к. процесс системный.
2) Не хочешь так, тогда ищи пример ANDLL, по "вшиванию в другой процесс", и из сервайсом вшивай свой код в winlogon (без него система всё равно рестартанёт

)

**ProgSoldier** » 27.12.2005 (Вт) 18:00

Ок. Чё-нить попробую. Спасибо :wink:

**xenomorph** » 27.12.2005 (Вт) 18:20

Многоуважаемый Ари ... тьфу, ANDLL!
Даваёте по-существу - или никак ... ОК?
--
Эффекта и от этой я не вижу. Ни писка ни крика ни файла.
(может я чёт-то не так делаю -
у кого пашет? откликнитесь пжжжалуйста!)
--
Огромная просьба - если уже что-то выкладываете -
то протестьте хоть разок ОК?
--
Спасибо за понимание.

**Yurio** » 27.12.2005 (Вт) 20:29

но подгрузишь ты её тока из VB'шной проги

Заблуждение...

**ANDLL** » 27.12.2005 (Вт) 22:09

xenomorph писал(а):Многоуважаемый Ари ... тьфу, ANDLL!
Даваёте по-существу - или никак ... ОК?
--
Эффекта и от этой я не вижу. Ни писка ни крика ни файла.
(может я чёт-то не так делаю -
у кого пашет? откликнитесь пжжжалуйста!)
--
Огромная просьба - если уже что-то выкладываете -
то протестьте хоть разок ОК?
--
Спасибо за понимание.

Дорогой ксенофоб, ой простите ксеноморф!
Протестировали, работает даже без перезагрузки. Может Вы динаимики не включили? Али у вас системный звук "beep" отключен? А может вы запамятовали прописать ее в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs? Хотелось бы знать, что вы туда написали...

2keks-n: Родной диспетчер зада прекрасно убивает программы, запущенные под аккаунтом system. smss, winlogon и т.п. он не убивает по несколько другой причине.

ProgSoldier писал(а):А на Сях или Асме? Если можно, то дайте исходничек (простенький, т. к. и в том и в другом плохо разбираюсь) ДЛЛки, которая может воспользоваться автозапуском и ещё запустить ЕХЕшник.
Заранее благодарен.

Замечу, что вопрос который мы рассматриваем совсем не "простенький". Поэтому никто не будет давать тебе пример "для дурака".

На VB это написать не реально по той причине, что сия достопочтенная dll'а грузится по статическому адресу, VB такой возможности, кажеться, не поддерживает.
Именно по этой причине может не срабатывать код dll в некоторых программах. Но в некоторых срабатыывает, это точно.

**xenomorph** » 27.12.2005 (Вт) 22:50

2 ANDLL -
... ага траФка сегодня попалась ник чёрту 8-)

)).
след. раз обязуюсь курить ТОТ РФСи что надо Ж-))).
--
Спасибо за некоторые разъяснения :-)

Усё на местах ..

**ANDLL** » 27.12.2005 (Вт) 22:55

2Кислотный Ожог: нет ну а мы то тут причем? Зачем портить топик?

**ProgSoldier** » 28.12.2005 (Ср) 6:40

ANDLL писал(а):Замечу, что вопрос который мы рассматриваем совсем не "простенький". Поэтому никто не будет давать тебе пример "для дурака".

Надо для меня, а не для дурака

**keks-n** » 28.12.2005 (Ср) 12:40

ANDLL писал(а):2keks-n: Родной диспетчер зада прекрасно убивает программы, запущенные под аккаунтом system. smss, winlogon и т.п. он не убивает по несколько другой причине.

Странно... На меня вопит, что дескать в доступе отказано :scratch:

**ANDLL** » 28.12.2005 (Ср) 12:42

А какой процесс пытаемся заверишть? А может ты не администратор?

**xenomorph** » 28.12.2005 (Ср) 16:52

2 keks-n - w2k - не убиваемы все system-порождённые.
ЕМНИП ХР (чекать лень) - убиваемы все.
--
Диагноз - неличие SE_DEBUG privellage.

Конференция VBStreets

Autorun DLL

Autorun DLL

re

Autorun DLL

ку

Кто сейчас на конференции