Привет всем
Ищу информацию по разработке NDIS Intermediate драйвера. Специфика задачи - пакеты нужно передавать в пользовательский режим и задерживать в драйвере на длительное время (я даже не представляю, где и как это можно сделать)

| Сообщение посчитали полезным:

ntndis.com/

| Сообщение посчитали полезным:

В DDK есть пример - называется passthru. Это и есть документированный NDIS intermediate driver. На http://ntndis.com http://ntndis.com низкоуровневый перехвадчик (kernel hooks).

В user mode пакеты передаются через DeviceIOControl() или Read(). В любом случае обрабытывать будешь IRPs.

Эта, если ты не работал с драйверами и NDIS, будешь разбираться много недель. Так что, IMHO, если тебе для комерческого проекта, то просто купи кусок кода - это всё продаётся.

| Сообщение посчитали полезным:

Спасибо
К сожалению, не для коммерческого. С passthru разбираюсь уже, наверное, больше месяца - с тем что написано в общем разобрался, но вот как дописывать пока не знаю. Была мысль не делать индикацию получения пакета в протоколе - но тогда надо
1. Как-то полностью сохранять пакет (представление о его структуре довольно смутное.
2. Достучаться до него из обработчиков Read и IoCtl - похоже, контекст там уже другой будет. Можно ли оттуда делать индикацию? Плюс вопрос, как ориентироваться, где какие заголовки и данные - в общем, как потрошить это дело?

| Сообщение посчитали полезным:

Dian пишет:
Как-то полностью сохранять пакет (представление о его структуре довольно смутное.
Эта.... тебе надо скопировать пакет и данные. Для этого:
- allocate a block of memory
- allocate an NDIS_BUFFER (MDL) from your pool
- attach one to the other
- allocate an NDIS_PACKET from your pool
- attach the buffer to the packet
- copy the data, the OOB data and flags

То есть, NDIS_BUFFER это descriptor куска памяти. Сама структура будет из pool, а блок пямяти отдельно. NDIS_PACKET это штука к которой цепляутся NDIS_BUFFERS. Напримет Eth прицепит 14-ти байтовый блок в начало IP пакета.

После этого, можешь этот новый пакет запердолить в очередь, список и т.д.

Dian пишет:
Достучаться до него из обработчиков Read и IoCtl - похоже, контекст там уже другой будет.
Будет, но это не важно. Кста, разницы между Read() и DeviceIOControl() нету... те же IRP в ядре.

Dian пишет:
Можно ли оттуда делать индикацию?
Да.

Dian пишет:
Плюс вопрос, как ориентироваться, где какие заголовки и данные - в общем, как потрошить это дело?
То есть? По RFC - сначала там Ethernet header (14 bytes), then IP header.... и понеслась... Только это всё данные внутри блоков пямяти, и NDISу на них плевать.

Если всё копипрование у тебя работает, то одному слою говоришь ОК, больше мне пакет не нужен, и потом скармливаешь саою копию другому. Ну а тот слой может вернуть его синхронно или асинхронно - внимательно читай доки фунций - там много заморочек с ProtocolReceive(), TransferData(), TransferDataComplete()....

Так вот, когда traffic начнёт ходить, будешь пробовать изменять содержимое и попаришься с IP/TCP/UDP checksums.

Кста, совет - поставь VmWare и отлаживай драйвер WinDBG из пот главной операционки - типа удалённая отладка через порт.

| Сообщение посчитали полезным:

Here is the break down of the IP packet: [url=http://www.networksorcery.com/enp/protocol/ip.htm
]http://www.networksorcery.com/enp/protocol/ip.htm
[/url]

Don't forget about network byte order. And, you will also need struct definitions of this kind:

struct EthHeader
{
byte m_dest[ETH_MAC_SIZE],
m_source[ETH_MAC_SIZE];

uint16 m_proto; // See ETH_PROTO_*
};


| Сообщение посчитали полезным:

Приветствую

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

616b_21.08.2006_CRACKLAB.rU.tgz - code.txt

| Сообщение посчитали полезным:

Кстати, может где-нибудь есть пример на эту тему?

| Сообщение посчитали полезным:

год назад получил задание на работе на подобную темку, вот сейчас через 10 000 Bsodов все почти готово,
очередь делал свою с указателями на пакеты(пакет, контекст, указатель на следующий пакет),
в ринг 3 все идет через IOCTL + синхронизация сообщениями
некоторым пакетам принудительно присваивал статус NDIS_STATUS_RESOURCES
+ в функции обработки очереди должно быть ожидание асинхронных операций, если у тебя в 3 ринге обрабатывается только 1 пакет

| Сообщение посчитали полезным:

Vermouth Colt
А где ты ставил пакеты в очередь? (ProtocolReceive?)
И как их правильно копировать к себе?

| Сообщение посчитали полезным:

Ставил в очередь в ProtocolReceive для входящих, и в MiniportSendPackets для исходящих правильнее будет ставить в очередь для всех точек входа минипорта и протокола,
для правильного копирования нужно сделать то же самое что и в драйвере Passthru, который идет вместе с DDK, плюс если ты хочешь изменять буферы пакета, нужно приделать свой буфер с данными (их НДИС не контролирует и можно извращаться как хочешь, только нужно помнить, что например драйвер ARP или другго вышележащего протокола при вызове будет рассматривать часть буфера как свой и может зависнуть при обработке), к новому пакету причем старый пакет обратно нужно вернуть все так же как и взял.

| Сообщение посчитали полезным:

прошу простить за лексику, прочитал - стало стыдно

| Сообщение посчитали полезным:

Vermouth Colt
Раньше я как раз и делал как в passthru, но это не работало.

Зато теперь всё хорошо
Всем спасибо

| Сообщение посчитали полезным: