Raw WINSUCKS... preciso de uma opinião.

[void_brain_void]

Realmente WINSUCKS para quem está acostumado com UNIX sockets... Enfim, segue o problema:

Escrevendo um TCP/SYN scanner minimalista para Win32, tenho conseguido uns erros meio malucos, onde eu consigo enviar o pacote com a flag de sincronização ativada, mas a a resposta não volta. Sniffei a comunicação com o Ethereal e realmente o pacote flui pela rede, mas tudo indica que se perde.

Procurei me informar sobre as limitações de raw sockets sobre win32 e vi que apenas pode-se colocar o socket (não a interface) em modo promíscuo e além disso, testando, notei que só há recepção de pacotes vindos para o socket, não os enviados por ele, até aqui tudo ok, pois só preciso do retorno SYN/ACK ou SYN/RST. Mas estou com este problema da resposta não voltar. O Ethereal validou ambos checksum's (TCP e IP). E sim, envio a SYN flag para uma porta que sei estar aberta.

Já tentei de tudo e acho que conceitualmente cheguei na causa do problema:

Um pacote TCP/IP com porta origem N foi enviado pela rotina, ao chegar uma resposta, a pilha TCP nota que não há nenhuma conexão "em trânsito" com a porta origem idêntica à porta destino indicada no datagrama, com isso, o S.O. descarta silenciosamente o pacote. Será mesmo isso? O mais hilário é que o Ethereal usa a Winpcap que até onde eu sei utiliza ndi para acessar o pacote num nível mais baixo, ou seja, mesmo um pacote descartado deveria ser listado pelo sniffer.

Já comparei o que escrevi com dezenas de outras rotinas parecidas que usam winsock, até encontrei um exemplo de syn scanner com winsock (mas também não funciona, e possui coisas ridículas do tipo "htons(0)" (...) definitivamente não é um bom parâmetro...)... Mas no geral não parece existir nada de errado com minha rotina.

Alguém já teve algum problema parecido usando WINSOCKS? Mesmo no XP SEM SP2 raw sockets possuem restrições?

[void_brain_void]

Resolvi em termos, por meio de um truque sujo, dei um jeito de "registrar" a porta origem indicada no pacote SYN e o pacote SYN/ACK ou SYN/RST já sobe para o user mode, realmente era o que pensava. O único problema é que tem o efeito colateral de um RST retornar para o host scaneado por conta da porta registrada não estar esperando nenhum SYN/ACK oficialmente. Não sei se esse RST caracterizaria um handshake TCP falho, a ponto de ficar registrado num log o que acabaria deixando de ser TCP SYN scan. Claro que um IDS bem configurado pegaria fácil um pacote desses (mesmo só o SYN), mas vamos abstrair esse fato. Alguém que esteja habituado a analisar esse tipo de log sabe me informar se a maioria dos processos servidores tendem a logar somente conexões estabelecidas ou também conexões abruptamente interrompidas?

Outra coisa me intriga, são esses exemplos de syn scan em winsock que dizem funcionar, sei lá, a teoria é linda, mas realmente seguindo a lógica do TCP/IP é bem impossível na prática, em user mode.