Здравствуйте, DeGandr, Вы писали:
DG>Всем привет. Можете подсказать как проверить на равенство 2 объекта FILE_OBJECT ? DG>P.s. код в нулевом кольце
куча способов, в зависимости от того, что тебе нужно. можно:
1) сравнить указатели на объекты (pFile1 == pFile2)
2) сравнить их стримы (pFile1->FsContext == pFile2->FsContext)
3) сравнить полные имена
4) сравнить NTFS IDs
а что нужно то?
может нужно на самом деле FsRtlInsertPerStreamContext/FsRtlLookupPerStreamContext?
DG>Можете подсказать как проверить на равенство 2 объекта FILE_OBJECT ?
В случае объектов файловых систем обычно сравнивают значения полей FsContext, таким образом можно убедиться, что оба объекта указывают на один и тот же файл. Правда, это допустимо только для локальных файловых сисьем и только не в Pre-Create. В случае TDI-фильтра все файловые объекты уникальны, т.е. достаточно сравнить их адреса (значения указателей). Зачем тебе это нужно? Ключ для карты ищешь или что?
O>А разве бывают копии FILE_OBJECT ? O>По-моему, если у нас есть два различающихся по значению указателя на FILE_OBJECT, O>то мы имеем два разных объекта.
Ну, ежели вы, сударь, желаете углубиться в терминологию, то именно объекты, несомненно, разные, а вот одинаковые тут файлы. Да и кто сказал, что речь о файловой системе? ;)
x64>Ну, ежели вы, сударь, желаете углубиться в терминологию, то именно объекты, несомненно, разные, а вот одинаковые тут файлы. Да и кто сказал, что речь о файловой системе?
Ну ежели сударю хочется копать, то одинаковыми ли будут файлы созданные при помощи хардлинок? FsContext'ы вроде одинаковы — но одинаковы ли они будут с ТЗ ТС
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Ligen, Вы писали:
L>Здравствуйте, DeGandr, Вы писали:
DG>>Всем привет. Можете подсказать как проверить на равенство 2 объекта FILE_OBJECT ? DG>>P.s. код в нулевом кольце
L>куча способов, в зависимости от того, что тебе нужно. можно: L>1) сравнить указатели на объекты (pFile1 == pFile2) L>2) сравнить их стримы (pFile1->FsContext == pFile2->FsContext) L>3) сравнить полные имена L>4) сравнить NTFS IDs L>а что нужно то? L>может нужно на самом деле FsRtlInsertPerStreamContext/FsRtlLookupPerStreamContext?
кстати, совсем забыл, можно еще SectionObjectPointer'ы сравнивать.
ибо у каждого стрима железно должен быть свой уникальный объект SECTION_OBJECT_POINTERS:
The SECTION_OBJECT_POINTERS structure, allocated by a file system or a redirector driver, is used by the memory manager and cache manager to store file-mapping and cache-related information for a file stream.
пруф
BTW сами микрософтовцы используют сие в NtCreatePagingFile(см WRK)
Здравствуйте, x64, Вы писали:
DG>>Можете подсказать как проверить на равенство 2 объекта FILE_OBJECT ?
x64>В случае объектов файловых систем обычно сравнивают значения полей FsContext, таким образом можно убедиться, что оба объекта указывают на один и тот же файл. Правда, это допустимо только для локальных файловых сисьем и только не в Pre-Create. В случае TDI-фильтра все файловые объекты уникальны, т.е. достаточно сравнить их адреса (значения указателей). Зачем тебе это нужно? Ключ для карты ищешь или что?
В общем, нужно пропустить через фильтр соединения моего приложения ничего с ними не предпринимая. Для этого я передаю драйверу хэндл сокета, который устанавливает соединение, потом получаю указатель на FILE_OBJECT этого сокета с помощью ObReferenceObjectByHandle и запоминаю его. Далее при отслеживании TDI_CONNECT'a сравниваю указатель на FILE_OBJECT, полученный из IO_STACK_LOCATION, с сохраненным... Но значения указателей почему-то не совпадают. Что я не так делаю? или чего-то не понимаю?
Здравствуйте, DeGandr, Вы писали:
DG>В общем, нужно пропустить через фильтр соединения моего приложения ничего с ними не предпринимая. Для этого я передаю драйверу хэндл сокета, который устанавливает соединение, потом получаю указатель на FILE_OBJECT этого сокета с помощью ObReferenceObjectByHandle и запоминаю его. Далее при отслеживании TDI_CONNECT'a сравниваю указатель на FILE_OBJECT, полученный из IO_STACK_LOCATION, с сохраненным... Но значения указателей почему-то не совпадают. Что я не так делаю? или чего-то не понимаю?
Извиняюсь за оффтопик, но такая схема будет работать до первого антивируса.
Как, впрочем, и большинство других.
Выше фильтра повиснет какой-нибудь Kaspersky и тоже будет ловить TDI_CONNECT,
перебрасывая все исходящие коннекты на свой локальный прокси. А коннект, который будет
идти с этого прокси, Вы никак не сможете связать с первым коннектом — и сокеты будут
разные, и файловые объекты, и 4-tuple (local address/local port/remote address/remote port).
Такие вот дела.
DG>В общем, нужно пропустить через фильтр соединения моего приложения ничего с ними не предпринимая. Для этого я передаю драйверу хэндл сокета, который устанавливает соединение, потом получаю указатель на FILE_OBJECT этого сокета с помощью ObReferenceObjectByHandle и запоминаю его. Далее при отслеживании TDI_CONNECT'a сравниваю указатель на FILE_OBJECT, полученный из IO_STACK_LOCATION, с сохраненным... Но значения указателей почему-то не совпадают. Что я не так делаю? или чего-то не понимаю?
Да, что-то ты как следует не понимаешь. Ты бы уточнил для начала, речь о TDI или как? Если о TDI, то, во-первых, сокетный хендл не имеет никакого отношения к TDI вообще, это хендлы AFD или другого сокетного провайдера (если таковые установлены в системе). Во-вторых, приложение обычно идентифицируют или по имени его исполняемого файла (что не очень надёжно), либо приложение само сообщает драйверу о себе информацию (например, свой ID процесса) и только после этого начинает сетевое взаимодействие (это более правильный метод). В-третьих, идея твоя в любом случае хреновая, т.к. если в системе установлен какой-нибудь драйвер, заворачивающий соединения на локальный прокси, и если этот драйвер сидит выше твоего фильтра, то ты не сможешь идентифицировать своё приложения, т.к. его запросы твой драйвер получит не в том контексте. Если всё подытожить, то чтобы решить твою задачу в общем случае, тебе придётся переписать твоё приложение и драйвер так, чтобы сетевые запросы оно слало не через сокеты, а напрямую через твой драйвер и дальше через TDI-интерфейсы. Ты напиши, что у тебя за приложение, что за драйвер, что они делают и какую бизнес-задачу решают, — тогда можно было бы как-то более конкретно помочь.
x64>Да, что-то ты как следует не понимаешь. Ты бы уточнил для начала, речь о TDI или как? Если о TDI, то, во-первых, сокетный хендл не имеет никакого отношения к TDI вообще, это хендлы AFD или другого сокетного провайдера (если таковые установлены в системе). Во-вторых, приложение обычно идентифицируют или по имени его исполняемого файла (что не очень надёжно), либо приложение само сообщает драйверу о себе информацию (например, свой ID процесса) и только после этого начинает сетевое взаимодействие (это более правильный метод). В-третьих, идея твоя в любом случае хреновая, т.к. если в системе установлен какой-нибудь драйвер, заворачивающий соединения на локальный прокси, и если этот драйвер сидит выше твоего фильтра, то ты не сможешь идентифицировать своё приложения, т.к. его запросы твой драйвер получит не в том контексте. Если всё подытожить, то чтобы решить твою задачу в общем случае, тебе придётся переписать твоё приложение и драйвер так, чтобы сетевые запросы оно слало не через сокеты, а напрямую через твой драйвер и дальше через TDI-интерфейсы. Ты напиши, что у тебя за приложение, что за драйвер, что они делают и какую бизнес-задачу решают, — тогда можно было бы как-то более конкретно помочь.
Да, речь о TDI. Его задача сводится к перенаправлению соединений на локальный прокси-сервер, который в свою очередь установит с тем, с кем требовалось изначально. Говоря простыми словами, нужно пустить весь сетевой трафик через мой прокси, прозрачно для обеих сторон. Реализовать нужно и фильтр и прокси. К примеру браузер подключается к www.google.ru, фильтр перенаправляет его на мой прокси, который в свою очередь узнает у драйвера куда действительно подключался браузер и сам подключается к этому ресурсу в сети. В данный момент столкнулся с проблемой: как сделать так, что бы фильтр не перенаправлял запросы на соединение моего прокси (с тем же гуглом), а просто пропускал их по назаначению?
DG>В данный момент столкнулся с проблемой: как сделать так, что бы фильтр не перенаправлял запросы на соединение моего прокси (с тем же гуглом), а просто пропускал их по назаначению?
Во-первых, эта проблема обсуждалась на этом форуме много раз, настоятельно советую использовать поиск, там и мои ответы есть, и ответы других не менее квалифицированных людей. Вкратце, если ты пишешь тупо перенаправлялку на локальный прокси, то решение проблемы я уже озвучил: пишешь в TDI-фильтре TCP-клиента (опять же на TDI), который будет отправлять сетевые запросы драйверу, который ниже тебя в TDI-стеке, а приложение общается с сетью только и исключительно через твой драйвер, ну т.е. надо если connect сделать, значит шлём драйверу что-то типа IOCTL_MY_CONNECT, в ответ на который драйвер шлёт TDI_CONNECT нижележащему драйверу, ну и т.д. Такая вот схема, детали несущественны сейчас. Если бы все фильтры локальных проксей так делали, было бы вообще идеально, но некоторые используют другие методы для обнаружения "своих" запросов, а это, к сожалению, снижает производительность или же приводит к более серьёзных проблемам совместимости.
Здравствуйте, DeGandr, Вы писали:
DG>Да, речь о TDI. Его задача сводится к перенаправлению соединений на локальный прокси-сервер, который в свою очередь установит с тем, с кем требовалось изначально. Говоря простыми словами, нужно пустить весь сетевой трафик через мой прокси, прозрачно для обеих сторон. Реализовать нужно и фильтр и прокси. К примеру браузер подключается к www.google.ru, фильтр перенаправляет его на мой прокси, который в свою очередь узнает у драйвера куда действительно подключался браузер и сам подключается к этому ресурсу в сети. В данный момент столкнулся с проблемой: как сделать так, что бы фильтр не перенаправлял запросы на соединение моего прокси (с тем же гуглом), а просто пропускал их по назаначению?
Как верно отметил x64 — в поиск ! Обсуждалось бесчисленное количество раз.
Если конкретно по теме, то здесь есть два решения.
Первое элементарно — при запуске прокси-сервера получить id его процесса и
отправить драйверу. TDI_CONNECT в подавляющем большинстве случаев выполняется в
контексте потока, который инициирует соединение, поэтому драйвер сможет различать,
где "его" процесс, а где другие, просто вызывая PsGetCurrentProcessId и сравнивая
полученное значение с переданным ранее id.
Но это будет работать только на девственно чистых системах.
Связка "TDI-редиректор + прокси" очень широко используется, и чуть ли не каждый
антивирус или фаерволл построен по точно такой же схеме.
В практическом смысле это означает то, что выше или ниже вашего фильтра будет
находиться чужак, который, скорее всего, не захочет играть по вашим правилам.
Последствия могут быть самыми разными. Например, он может задержать TDI_CONNECT
(инициатору вернут STATUS_PENDING), чтобы немного позже возобновить его из своего потока.
В этом случае PsGetCurrentProcessId в фильтре будет возвращать не то, что ожидалось.
Тут можно порекомендовать следующее — получать Id процесса не на TDI_CONNECT, а
значительно раньше, в момент создания сокета, так как эти операции обычно не
откладываются (в этом нет смысла). Когда в устройство \Device\Tcp приходит
IRP_MJ_CREATE, это означает одно из двух — клиент создает либо transport address,
либо connection context (разница узнается из FILE_FULL_EA_INFORMATION).
Что это такое — ищите на просторах интернета (на RSDN тоже), здесь объяснять нет смысла.
Перехватив создание connection context, нужно запомнить Id текущего процесса,
затем позволить драйверу tcpip.sys завершить запрос, и на обратном пути, где-нибудь в
completion routine, сохранить FILE_OBJECT, ассоциировав его с полученным Id.
При выполнении connect на созданном сокете мы в обработчике TDI_CONNECT получим
тот же самый FILE_OBJECT, а по нему сможем вытянуть ранее сохраненный Id процесса.
Упрощенно говоря, получается что-то типа std::map, где ключом будет FILE_OBJECT, а
значением — Id процесса, который создал этот FILE_OBJECT.
Это спасает от задержки TDI_CONNECT верхними фильтрами, но не решает остальных проблем.
Самое веселье начинается, когда нечто в стеке точно также ловит TDI_CONNECT и
редиректит коннекты на свой прокси. В этом случае Id нужного процесса вы никогда не
получите — все исходящие соединения будут приходить в TDI_CONNECT уже в контексте чужого прокси,
безотносительно того, где вы запоминаете Id процесса — на TDI_CONNECT или на IRP_MJ_CREATE.
А двойной редирект приведет к тому, что соединение закрутится в бесконечной петле —
сначала чужак редиректит коннекты на свой прокси, затем вы перехватываете коннекты с этого
прокси, редиректите их на свой прокси, позже их снова перехватывает чужак, шлет на свой прокси,
после чего они опять попадают к вам, и так далее до бесконечности, пока не будет исчерпан пул
локальных динамических адресов для bind-а.
Второе решение учитывает эти проблемы, хотя оно на порядок сложнее.
Суть в том, чтобы найти способ работать с сетью из прокси напрямую, в обход всего стека TCP и
фильтров-чужаков, сидящих в нем. Например, можно повесить дополнительное устройство сразу над
\Device\Tcp и придумать для него некий протокол с аналогами socket/send/recv/closesocket/shutdown,
чтобы эти команды и данные отправлялись драйверу tcpip.sys напрямую. Это будет работать.
По крайней мере, я проверял на десятке популярных антивирусов и самое страшное, что случалось —
это требовалось добавить процесс прокси-сервера в список исключений.
Вот такой расклад. Надеюсь, информация была полезной.
Тут стоит проблему разделить на две части: первое, это детект собственного прокси-процесса, второе, это детект оригинального процесса, который осуществляет сетевое взаимодействие. Так вот, первое решается относительно просто, я уже написал как (т.е. работать с сетью не через сокеты, а через TDI-интерфейсы посредством драйвера), а вот второе, при наличии установленного в системе ещё одной такой вот перенаправлялки на локальный прокси, — решается только и исключительно анализом трафика непосредственно в драйвере. Сложно, да, но зато проблема с зацикливаниями и прочими косяками совместимости больше не побеспокоит.
Здравствуйте, x64, Вы писали:
x64>Тут стоит проблему разделить на две части: первое, это детект собственного прокси-процесса, второе, это детект оригинального процесса, который осуществляет сетевое взаимодействие. Так вот, первое решается относительно просто, я уже написал как (т.е. работать с сетью не через сокеты, а через TDI-интерфейсы посредством драйвера), а вот второе, при наличии установленного в системе ещё одной такой вот перенаправлялки на локальный прокси, — решается только и исключительно анализом трафика непосредственно в драйвере. Сложно, да, но зато проблема с зацикливаниями и прочими косяками совместимости больше не побеспокоит.
У меня есть сильные сомнения, что вторая часть вообще решается. Я имею в виду правильное
определение процесса, в контексте которого было инициировано исходящее соединение.
Ведь тот же KAV/KIS сажает свой фильтр на самый верх TCP-стека, делая редирект на свой прокси, а
потом все исходящие соединения приходят уже в контексте этого прокси, то есть — от имени avp.exe.
Можно, правда, ловить контекст сразу после редиректа KAV/KIS, но смысла в этом нет, ибо
адрес уже изменен на 127.0.0.1. К тому же оригинальный сокет, на котором был выполнен connect, и
его сокет-дубликат внутри прокси avp.exe, от которого этот connect возобновляется, как-то
логически связать между собой не представляется возможным.
Мы пробовали LSP повесить в систему, чтобы снимать показания там, но у LSP оказались
проблемы с последними версиями IE на Windows 7, а под Vista он вообще работал с глюками.
O>У меня есть сильные сомнения, что вторая часть вообще решается.
Ну почему же? Я ж написал, что можно фильтровать контент прям в драйвере и тогда никаких проблем с другими перенаправлялками гарантированно не возникнет. Но это только в случае, если на контекст процесса можно положить. И в самом деле, — какая разница, кто там HTTP-запросы шлёт? Может, у пользователя вообще какой-нибудь Web-броузер самописный или встроенный IE в другое приложение. Не думаю, что это важно. Но если всё таки важно, тогда, наверное, да, задача не решается.
O>Ведь тот же KAV/KIS сажает свой фильтр на самый верх TCP-стека...
Насколько я в курсе, последние версии KIS фильтруют трафик прямо в NDIS-фильтре и ничего никуда не перенаправляют.
Здравствуйте, x64, Вы писали:
x64>Я ж написал, что можно фильтровать контент прям в драйвере и тогда никаких проблем с другими перенаправлялками гарантированно не возникнет.
Если кто-нибудь ухитрится сесть ниже нашего фильтра, проблемы останутся.
Хотя можно вызвать IoGetDeviceAttachmentBaseRef и получить указатель прямо на нижнее устройство,
чтобы работать с ним напрямую, в обход фильтров, находящихся снизу.
Но это лишь при условии, что dispatch table нижнего устройства никто не похукал (на пятых NT
вполне возможно), в противном случае получаются те же грабли, только в профиль.
O>>Ведь тот же KAV/KIS сажает свой фильтр на самый верх TCP-стека...
x64>Насколько я в курсе, последние версии KIS фильтруют трафик прямо в NDIS-фильтре и ничего никуда не перенаправляют.
Моя информация касается продуктов Kaspersky вплоть до версий 2010-2011 годов, но
для успокоения совести надо бы проверить.
O>Если кто-нибудь ухитрится сесть ниже нашего фильтра, проблемы останутся.
Какая именно проблема останется, если мы трафик будем фильтровать прямо в драйвере, ничего не перенаправляя в локальный прокси? Я вижу только один косяк, что одни и те же данные могут обрабатыватся несколько раз подряд, если точнее, то столько раз, сколько перенаправляющих фильтров сидит сверху, при условии, что связанные с ними локальные прокси пользуются обычными сокетами. Но, я думаю, что авторы таких "перенаправлялок" должны понимать эту проблему и, следовательно, должны предупреждать пользователя о возможных проблемах совместимости. А представь, что все авторы контент-фильтров будут обрабатывать трафик прямо в драйвере, без каких-либо перенаправлений и локальных прокси, — вообще никаких проблем не будет, и контекст инициатора всегда будет правильный (ну тот, что в Post-Create поймали) — рай же =)
O>Хотя можно вызвать IoGetDeviceAttachmentBaseRef и получить указатель прямо на нижнее устройство, O>чтобы работать с ним напрямую, в обход фильтров, находящихся снизу.
Всё же не стоит так делать, нехорошо прокидывать нижележащие фильтры.
Здравствуйте, x64, Вы писали: x64>Насколько я в курсе, последние версии KIS фильтруют трафик прямо в NDIS-фильтре и ничего никуда не перенаправляют.
Ради интереса поставил Kaspersky Internet Security 2012.
Та же картина, что и на предыдущих версиях — драйвер kl2.sys, тэг в группе PNP_TDI,
настроенный на загрузку драйвера раньше всех остальных, как и в прошлых версиях.
Вот что у меня теперь в логах LSP-фильтра:
Скрытый текст
[10:49:51] opera.exe.log — WSPConnect — ip 173.194.71.104 port 80
[10:49:51] avp.exe.log — WSPConnect — ip 173.194.71.104 port 80
[10:49:51] opera.exe.log — WSPConnect — ip 173.194.71.94 port 80
[10:49:51] avp.exe.log — WSPConnect — ip 173.194.71.94 port 80
[10:49:52] opera.exe.log — WSPConnect — ip 173.194.71.94 port 80
[10:49:52] avp.exe.log — WSPConnect — ip 173.194.71.94 port 80
[10:49:53] opera.exe.log — WSPConnect — ip 209.85.173.120 port 80
[10:49:53] avp.exe.log — WSPConnect — ip 209.85.173.120 port 80
[10:49:53] avp.exe.log — WSPConnect — ip 130.117.190.234 port 443
[10:50:10] opera.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:10] avp.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:11] opera.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:11] avp.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:11] opera.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:11] avp.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:11] opera.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:11] avp.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:11] opera.exe.log — WSPConnect — ip 173.194.32.35 port 80
[10:50:11] avp.exe.log — WSPConnect — ip 173.194.32.35 port 80
[10:50:11] opera.exe.log — WSPConnect — ip 77.88.21.90 port 80
[10:50:11] avp.exe.log — WSPConnect — ip 77.88.21.90 port 80
[10:50:11] opera.exe.log — WSPConnect — ip 93.158.134.119 port 80
[10:50:11] avp.exe.log — WSPConnect — ip 93.158.134.119 port 80
[10:50:12] opera.exe.log — WSPConnect — ip 93.158.134.119 port 80
[10:50:12] avp.exe.log — WSPConnect — ip 93.158.134.119 port 80
[10:50:40] opera.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:40] avp.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:42] opera.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:42] opera.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:42] avp.exe.log — WSPConnect — ip 95.31.13.136 port 80
[10:50:42] avp.exe.log — WSPConnect — ip 95.31.13.136 port 80
Тут видно, что каждый коннект от opera.exe перехватывается KIS-ом и потом
заново шлется в сеть уже от имени avp.exe.
x64>Какая именно проблема останется, если мы трафик будем фильтровать прямо в драйвере, ничего не перенаправляя в локальный прокси? Я вижу только один косяк, что одни и те же данные могут обрабатыватся несколько раз подряд, если точнее, то столько раз, сколько перенаправляющих фильтров сидит сверху, при условии, что связанные с ними локальные прокси пользуются обычными сокетами. Но, я думаю, что авторы таких "перенаправлялок" должны понимать эту проблему и, следовательно, должны предупреждать пользователя о возможных проблемах совместимости.
Возможно, ты и прав.
Но в любом случае, авторам фильтров нужно будет принимать и другие меры предосторожности.
Например, не рассчитывать, что файловый объект какого-нибудь TDI-запроса, пойманного на
верхнем уровне стека, сохранится в целостности при прохождении вниз. К примеру, при
"накапливании" ответа сервера во внутреннем буфере, драйвер может задержать оригинальный
TDI_RECEIVE, а вниз отправить свой эквивалент. И если нижний драйвер каким-то образом
сопоставляет файловые объекты, полученные на IRP_MJ_CREATE с теми, которые приходят в
TDI-запросах, может случиться все, что угодно. Впрочем, это лишь догадки — сам я до
реализации inplace-фильтрации еще не дошел. Если дойду когда-нибудь — непременно отпишусь,
что из этого вышло. x64>А представь, что все авторы контент-фильтров будут обрабатывать трафик прямо в драйвере, без каких-либо перенаправлений и локальных прокси, — вообще никаких проблем не будет, и контекст инициатора всегда будет правильный (ну тот, что в Post-Create поймали) — рай же =)
Это да. Я надеюсь, что когда-нибудь так и будет.
Еще интересно, как проблема с двумя и более прокси решается в WFP — там ведь
поддержка редиректов имеется, начиная с Windows 7, и включает в себя сохранение данных об
инициаторе соединения (Id процесса), а также оригинальный адрес.
ТС не конкретизировал что значит разные
