Вопрос об NDIS Intermediate Driver

[Kife]

Здравствуйте ув. Гром и другие уважаемые люди!  как-то неделю назад попала через поисковик ко мне ваша статья о драйвере NDIS c рассылки Subscribe.ru выпуск №3, целую неделю искал продолжение и начало, наконец то нашел!! Огромное вам спасибо за подробное описание всего этого дела, было очень интересно. Не ожидал (я искал целый месяц материалы) что у нас кто-то будет освещать эту тему. Но как всегда )) у меня есть пару вопросиков, может подскажите, если знаете ответы... :oops:

1. Как извлечь содержимое пакетов более высокого уровня из NDIS_PACKET??? Желательно пример, а то в теории я понимаю, что там цепь буферов и т.д.

2. возможна ли динамическая загрузка такого драйвера (без inf-файлов и "ручной" привязки к TCP/IP ), и если да, то как в него передать адаптеры, к которым надо "заБиндиться"(конкретно надо и NIC и Dial-up модемный )

3. Если я правильно понимаю, пример такого драйвера в DDK (passthru) корректно работает с модемным соединением, это так???

4. И последний, самый навороченный: как изменять содержимое пакета, изменяя и его длину тоже?

Прошу всем откликнуться, ведь тема очень интересная!

С уважением Алексей.

[Гром]

Kife (Алексей)
1. Показываю на примере MPSend()

Сначала вызывается NdisAllocatePacket
NdisAllocatePacket(&Status,
                  &MyPacket,
                  pAdapt->SendPacketPoolHandle);
Где &MyPaket - это буфер свой для пакета

PNDIS_PACKET     MyPacket;


Не забыть потом его освободить...NdisFreePacket(MyPacket);

Это как бы временный захват пакеты из NDIS стека.
По поводу изменения пакета - смотри структуру NDIS_PACKET в DDK.

2. Не скажу - не делал такого - мы ставились с помощью inf файла.

Насчет bind на адаптер думаю лучше всего расскажет SlavaI

3. Нет НЕ ТАК Наоборот, он работает ТОЛЬКО с LAN и мне не удалось создать фильтр драйвер для моджемного соединения.

Причина выяснилась позже, фирме Моторола удалось добится ответа от Майкрософт , что такой драйвер не будет поддерживать DialUp - но у тебя сть возможность использовать TDI драйвер.
Я про него пока не писал, если будет нужно - то могу подсказать.

4. Я наизусть не помню, тебе придется смотреть структуру пакета, где описана вся его последовательность и там же персчитывать не только длину , но и контрольную сумму.

[SlavaI]

По этой теме также почитай на www.ntndis.com.

[Kife]

Kife (Алексей)

3. Нет НЕ ТАК Наоборот, он работает ТОЛЬКО с LAN и мне не удалось создать фильтр драйвер для моджемного соединения.

Причина выяснилась позже, фирме Моторола удалось добится ответа от Майкрософт , что такой драйвер не будет поддерживать DialUp - но у тебя сть возможность использовать TDI драйвер.
Я про него пока не писал, если будет нужно - то могу подсказать.

:? :? :?
Тогда еще 2 вопроса:
1. Нет ли оффициальной ссылки на инфу по поводу ответа Майкрософта Мотороле (или хоть скажи, где ты это слышал)

2. Подскажи пожалуйста про TDI драйвер. Нужно перехватывать и модифицировать и LAN и Dial-Up. Кстати, а в Filter-Hook драйвере модифицировать и/или изменять длину ведь нельзя?

[Гром]

1. Я это слышал в самой Мотороле , где имел честь трудится одно время Естественно ссылки на частные переписки двух фирм у меня нет

2. Не то что бы совсем нельзя, но видимо сопряжено с огромными трудностями...

Вопрос по TDI драйверам не простой...
Азы сказать - так все драйверы похожи.
Обрати внимание на то , что TDI драйвер находится над NDIS между ним и socket.dll то бишь между уровнем драйверов NDIS и сокетной прослойкой.

Почитай в MSDN по типам этих драйверов, а я подберу тебе код драйверных функций, и самое главное, примеры перехвата.

Опиши тут задачу поподробнее, возможно мы вместе найдем решение, ибо то , которое использовали мы на фирме, подразумевало клиент+сервер структуру....

[Kife]

Опиши тут задачу поподробнее, возможно мы вместе найдем решение, ибо то , которое использовали мы на фирме, подразумевало клиент+сервер структуру....

Огр. спасибо за ответ. В общем то надо перехватывать и модифицировать/фильтровать весь IP трафик (что-то вроде IPSec). Соответственно меняется и длина пакета (добавл-ся свой IP и не только IP заголовок). Может еще какой - нить тип драйверов можно использовать, попроще в реализации? Но есь условие -- ВЕСЬ IP трафик (LAN, DialUp, etc.) А если вариант только TDI, то оч. прошу, если не трудно, материала подкинуть...  :oops:

[Гром]

1. Самое главное не жди панацеи, даже при совпадении некоторой части задач, все равно полного совпадения не будет. Ищи сам - копай, ответить на форумах и даже в больших книгах можно только на конкретные вопросы или наоборот - только в теории.

ИМХО
1. Тебе нужен будет TDI драйвер.
2. Еще раз вопрос - есть ли у тебя серверная часть....
Зачем и какая задача полностью и подробно IPsec  - IPSecurity???

Материалы по TDI драйверу обещаю накидать.

[Kife]

2. Еще раз вопрос - есть ли у тебя серверная часть....
Зачем и какая задача полностью и подробно IPsec  - IPSecurity???
.

Что значит серверная часть? Просто  есть идея разработать аналог IPSec -a со своими стандартами криптования:
1. Перехват IP траффика
2. Шифрование траффика
3. Шифрование IP заголовков и "приклеивания" своего заголовка... в общем все то, что IPSEC делает.

Может еще какие нить идеи о виде драйвера будут???

С ув. Алексей

[Гром]

Kife, еще раз - Я НЕ ЗНАЮ что делает IPSec - то что ты говоришь - кому оно нужно на принимающей стороне???
Если с той стороны нет дешифратора и нет принимающей СЕРВЕРНОЙ части.

Другое - для того что бы сделать аналог. надо понять как оно работает или придумать свой алгоритм...

Так что для начала опиши что делает IPSec и зачем...
Я правда не понимаю что делать с такой системой без серверной (принимающей) части.

[Kife]

Kife, еще раз - Я НЕ ЗНАЮ что делает IPSec
Так что для начала опиши что делает IPSec и зачем...
Я правда не понимаю что делать с такой системой без серверной (принимающей) части.

На каждой стороне стоит шифратор / дешифратор . Шифратор соответственно шифрует исходящий IP траффик а дешифратор соответственно дешифрирует (кажется это слово так пишется )
Стороны с такими системами договариваются между собой об  алгоритмах шифрации,  ключах и т.д.

Шифрация бывает:
1. Только содержимое пакетов более высокого уровня нежели IP (TCP, etc.)
2. Шифрация содержимого пакетов более высокого уровня + шифрация IP заголовков  (тут  можно скрывать реальные IP адреса ) но в этом случае надо прикрепить к зашифрованному пакету нормальный нешифрованый заголовок (исходный мы зашифровали)

Достоинства:
1. Позволяет убедиться стороне "A" что пакет пришел именно со стороны "B" а не от кого-нить другого

2. позволяет убедиться в целостности (неподменности данных) пакета с момента отправления.

3. Криптостойкие алгоритмы позволяют добиться невозможности дешифрации информации 3-й стороной.

Как конкретно реализовывается шифрация - нюансы.

[Артем]

Kife, на Ozone.ru продается книга что-то вроде "Системы безопасности и написание драйверов" (название очень не точное, но через поисковик найти можно ) стоит в районе 70-80 руб.+пересылка.

[Гром]

Ну что тебе сказать - идей может быть много - ИМХО - тебе надо как-то решать вопрос о шифрации 2 - х уровней - 1 шифратор аппликация, которая поучает пакет из драйвера, шифрует его и отправляет далее - в драйвере стоит анализатор - если пакет уходит от шифратора, то перехватывать его не надо и наоборот.
Однако учитывать надо , что при повторном заходе автором будет стоять шифратор, соответственно ему пришлют ответ, поэтому адрес в IP пакете обратный и сам сокет придется менять на реальный.

Если не менять - то тогда надо хранить по ID кому и кто посылал реально...
Но это уже конкретика.

Второй путь - честно говоря - не скажу, однако нормальный заголовок IP небольшой и шифровать его можно отдельно вполне в самом драйвере бинарными операциями с ключами.

Само собой пакет уже должен быть заширован.

Если все шифровать в драйвере или передавать данные, задерживая их отдачу в сеть то возникнут проблемы, при больших пакетах данных.

Теперь о технологии перехвата, которая работала, я уже писал - мы подменяли реальный IP на 127.0.0.1 и номер порта на котором ждала наша шифрующая аппликация. Но дальше проблема, внутри самой аппликации у нас стоял достаточно серьезный движок по хранению и определению реального адреса...
Более того наши данные уходили на наш собственный сервер, а не в такой же драйвер на той стороне , сервер дешифровыва\л пакет и получал данные куда посылать реальный пакет - работал как файрвол и как гейтвей.

В общем такая вот идея - о тонкостях такой работы я сказать не смогу, да и тонкости у вас другие будут.