… где                    iAddressCount        –             количество сетевых интерфейсов;

                               Address[1]             -              IP последнего.

Далее следуют мероприятия по вычленению этого IP из структуры - SOCKET_ADDRESS_LIST и перенесение его в структуру - sockaddr_in.
Наверное, Вы спросите: “ Что за ерунда! У меня воткнута одна сетевая карта. Откуда возьмутся иные IP – адреса кроме как тот, который присвоен мною (или специальным сервисом DHCP, PPP …)?” Но не спешите с выводами! Вы вероятно забываете об интерфейсе так называемой “обратной петли”, ей то и присвоен IP = 127.0.0.1. Вот Вам и еще один адресованный сетевой интерфейс.

2)

invoke bind,s,addr if0,SIZE sockaddr_in

Tут можно задать вопрос:
- “Я в инет хожу через диалап и мой внешний IP постоянно меняется провайдером. Если мне нужен снифер могу ли я провязать созданный сокет к IP = 127.0.0.1?”

Ответ может звучать примерно так:
- “если вы "привязали" (bind) сокет на интерфейс -127.0.0.1
то параметр SIO_RCVALL не отработает. RAW- сокет “привязать” (bind) можно будет, но WSAIoctl() с параметром SIO_RCVALL будет выдавать ошибку №10022”

3)

invoke recv, s, addr buf, sizeof buf, 0
;############################################################################
;############################################################################
lea EDX,buf
assume EDX : PTR IP_HEADER
invoke inet_ntoa, dword ptr [EDX].DstAddr
invoke lstrcpy,ADDR buf_in,eax
invoke ParseBuffer,addr buf,sizeof buf,ADDR _char_str

 Тут у прославленного GriYo использовалась функция WSARecv(). Посмотрим в справочник [1.2]:

int WSARecv(
SOCKET s,
LPWSABUF lpBuffers,
DWORD dwBufferCount,
LPDWORD lpNumberOfBytesRecvd,
LPDWORD lpFlags,
LPWSAOVERLAPPED lpOverlapped,
LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine);

typedef struct __WSABUF
{
u_long len;
char FAR *buf;
} WSABUF, FAR * LPWSABUF;

Буферы, в которые нужно поместить данные, передаются функции WSARecv через параметр lpBuffers. Он содержит указатель на начало массива структур TWSABuf, а параметр dwBufferCount - количество элементов в этом массиве. Выше мы знакомились со структурой TWSABuf: она содержит указатель на начало буфера и его размер. Соответственно, массив таких структур определяет набор буферов. При чтении данных заполнение буферов начинается с первого буфера в массиве lpBuffers, затем, если в нём не хватает места, используется второй буфер и т.д. Функция не переходит к следующему буферу, пока не заполнит предыдущий до последнего байта. Таким образом, данные, получаемые с помощью функции WSARecv, могут быть помещены в несколько несвязных областей памяти, что иногда бывает удобно, если принимаемые сообщения имеют строго определённый формат с фиксированными размерами компонентов пакета: в этом случае можно каждый компонент поместить в свой независимый буфер.

Однако нам ради наших, более чем скромных, целей не нужно строить связный список этих посылок, полученных от принимающей функции. Чем проще – тем надежнее! Вот почему мы используем старую добрую Recv(). Далее применим стандартный прием - наложение структуры на область данных в памяти. Мне лично этот прием очень нравится. Вот и все, теперь мы можем обращаться в куску данных как к структурированной совокупности, и это удобно.
Далее мы вызываем функцию ParseBuffer() – функцию, которая в принятом объеме пакета находит строку с именем отправителя – MAIL FROM: …

4)

push esi

xor ecx,ecx 
mov cx,100
cld 
___search3E:
mov al,byte ptr [esi] 
cmp al,3eh ; '>'
jz ___formatESI
inc esi
loop ___search3E

___formatESI:
inc esi
mov byte ptr [esi],0dh
mov byte ptr [esi+1],0ah
mov byte ptr [esi+2],00h

 Для того чтобы адрес отправителя получился чистым мы проводим поиск символа – ‘>’ и отсекаем часть стоки после него. Отсекающим “мечем” служит последовательность 0Ah,0Dh,00.

Вот ты какой – сниффер! :) Просто, не правда ли? Теперь как только пользователь отправить письмо мы сразу узнаем и IP – SMTP – сервера, и имя зарегистрированного на этом сервере пользователя. Но! Если бы не эти - Но! А что если пользователь долго не отсылает никаких писем? Во всех, известных мне, червях IP – сервера SMTP получают из реестра. Имя зарегистрированного пользователя из файлов на локальных ресурсах. Да это быстро и не накладно. Но что если применить несколько способов получения “жизненно – необходимой” информации, может на выходе будет результат?

Но хватит уже возиться с этими локальными сетями. Пора, встряхнувшись, выйти в мир! Итак, в следующей главе мы с Вами посмотрим, что творится на необъятных просторах всемирной паутины :)

А пока - до свиданья!