Аналог recv() / Обход recv() / Прямое чтение всего буфера сокета

← →
bwwebm (2010-04-23 14:54) [0]

Предположим что я имею сокет инициализированный следующим образом:

const MAX_PACKET_SIZE = $10000; // 2^16 // 65536 SIO_RCVALL = $98000001; WSA_VER = $202; //procedure Close; //закрывает сокет function Init: Integer; var hSocket: TSocket; WSA: WSAData; Addr_in: sockaddr_in; Switch: Integer; begin Result:=WSAStartup(WSA_VER, WSA); if Result <> NOERROR then Exit; hSocket:=socket(AF_INET, SOCK_RAW, IPPROTO_IP); if hSocket = INVALID_SOCKET then begin Close; Exit; end; FillChar(Addr_in, SizeOf(sockaddr_in), 0); Addr_in.sin_family:= AF_INET; Addr_in.sin_addr.s_addr := inet_addr("IP интерфейса сети"); if bind(hSocket, Addr_in, SizeOf(sockaddr_in)) <> 0 then begin Close; Exit; end; Switch:=1; if ioctlsocket(hSocket, SIO_RCVALL, Switch) <> 0 then begin Close; Exit; end; Result:=hSocket; end;

тоесть сокет который получает все пакеты уровня IP.
Дальше, несложно читать recv() пакеты и их обрабатывать. Но вот какая незадача, использовать recv() - недопустимо.
Хорошей идей показалось сохранение буфера, из которого четает recv() в файл, для последующей обработки, но как это сделать непонятно.
Если я правильно понимаю, то вызов:
IOCTLSocket(hSocket, FIONREAD, buf);
запишет в buf текущий размер этого самого буфера, это я к тому, что зная его размер остается только найти его расположение в памяти, для считывания, ну например используя CopyMemory() что ли.

Зачем это нужно? Да хотя бы для ускорения процесса считывания данных, при реализации задач с отложенной отработкой данных. Да например в Java, подобное свободно практикуется:
httx://www.salesat.ru/158-ehffektivnyjj_perenos_dannykh_s_pomoshhbju_zero_co.html

← →
bwwebm (2010-04-23 15:17) [1]

Может быть нижесказанное, уточнит вопрос: при успешной инициализации сокета в hSocket записывается указатель на инициированный сокет. А следовательно будет выделена память, для последующей работы. Скорее всего это будет некая структурированная запись, в которой на ряду с другими параметрами, будет находиться буфер (буфер устанавливается опцией SO_RCVBUF и по умолчанию равен 2^16), а следовательно используя указатель hSocket, как то можно найти в памяти ту область, в которой расположен буфер приема, а далее его сохранить в бинарный файл.

← →
Сергей М. © (2010-04-23 15:56) [2]

Лобля блох.

← →
bwwebm (2010-04-23 15:58) [3]

А что нибудь по существу?

← →
Сергей М. © (2010-04-23 17:08) [4]

Так оно по существу и есть)

← →
Сергей М. © (2010-04-23 17:09) [5]

Ты лучше скажи где ты столкнулся с реальными (а не высосанными из пальца) "тормозами" - тогда и будет "по существу"..

← →
bwwebm (2010-04-25 00:47) [6]

На самом деле на данный момент проблемы с тормозами нет. Есть система защиты nProtect, при запуске она инжектит recv() на предмет анализа порта источника и приемника, и если в заголовке пакета IP защищаемый порт, то recv() не возвращает данных.

← →
Сергей М. © (2010-04-25 20:31) [7]

А, так ты, оказывается, решил похулиганить в Тырнете, и тебе мешает какая-то там "защита", так ?)

← →
bwwebm (2010-04-27 12:57) [8]

Я решил анализировать трафик, входящий на мой компутер, а какая то там защита делает свой хук, на функцию recv() в библиотеку ws2_32.dll моей винды. Меня это расстраивает, и я ищу решение данной задачи. Но кто то на этом форуме, больше любит разводить демагогию, нежели помочь с решением проблемы.

← →
Сергей М. © (2010-04-27 14:44) [9]

> помочь с решением проблемы

Кто-то на этом форуме высасывает проблему из пальца.
Более того, кто-то на этом форуме лепит горбатого, пытаясь выдать трафик, ассоциированый с неким отдельно взятым процессом, за сетевой трафик хоста в целом.

← →
Rouse_ © (2010-04-27 14:57) [10]

> bwwebm (27.04.10 12:57) [8]
>
> Я решил анализировать трафик, входящий на мой компутер,
> а какая то там защита делает свой хук, на функцию recv()
> в библиотеку ws2_32.dll моей винды

Удали процесс ставящий хук - будет тебе счастье. Анализируй сколько влезет.

← →
bwwebm (2010-04-27 15:00) [11]

Так как же получить указатель на буфер чтения, ассоциированный с сокетом?

← →
bwwebm (2010-04-27 15:02) [12]

> Удали процесс ставящий хук - будет тебе счастье. Анализируй
> сколько влезет.

Приложение контролирует наличие процесса защиты при работе. Да и просто из диспетчера задач, завершения процесса приходит с ошибкой доступа

> bwwebm (27.04.10 15:02) [12]
>
>
> > Удали процесс ставящий хук - будет тебе счастье. Анализируй
> > сколько влезет.
>
>
> Приложение контролирует наличие процесса защиты при работе

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

← →
bwwebm (2010-04-28 09:51) [14]

Замечательно. А как это сделать мне?

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

← →
bwwebm (2010-04-28 17:10) [16]

Уже проще проверить всю доступную память, или даже дампить.

А чем отличатся дамп от проверки всей доступной памяти? :) И кстати, что это тебе даст? :)

← →
bwwebm (2010-06-01 10:26) [18]

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

Возможно использования сетевого драйвера, по аналогии с KIS, в фильтре которого пакеты бегают без перебоев, поможет? Есть вараны?

Аналог recv() / Обход recv() / Прямое чтение всего буфера сокета Найти похожие ветки