2009-03-29 26 views
10

Mi piacerebbe scrivere uno sniffer di pacchetti e un editor per Windows. Voglio poter vedere il contenuto di tutti i pacchetti che entrano e escono dal mio sistema e possibilmente modificarli. Qualsiasi linguaggio va bene, ma mi piacerebbe che funzionasse abbastanza veloce da non sovraccaricare il sistema.Come faccio ad agganciare lo stack TCP in Windows per sniffare e modificare i pacchetti?

Ho letto un po 'di WinPcap ma la documentazione afferma che non è possibile utilizzare WinPcap per creare un firewall perché non può eliminare pacchetti. Quali strumenti mi aiuteranno a scrivere questo software?

risposta

1

Sono sicuro che avresti bisogno di scrivere un driver di filtro. http://en.wikipedia.org/wiki/Filter_driver Non ne so molto di più :). Sarebbe sicuramente un'app Win32 C/C++ ed è probabile che stiate facendo del kernel. Inizia scaricando il DDK e trovando alcuni dei driver di filtro di esempio.

Se si desidera monitorare ciò che entra e esce da IIS, prendere in considerazione un filtro ISAPI. Ancora C/C++ in Win32, ma relativamente più facile rispetto alla scrittura di un driver di dispositivo.

1

codice C# per fare questo è here

+0

Dal momento che è basata raw socket , non sarà in grado di annusare i pacchetti TCP in arrivo su Windows 7. (Microsoft ha storpiato socket non elaborati su versioni non server di Windows) – CodesInChaos

+0

Ho bisogno di una soluzione/esempio del WFP, sfortunatamente. – ChopperCharles

0

realtà ho fatto questo, diversi anni fa. Sono alquanto confuso nei dettagli a questo punto, ma ho dovuto sviluppare un filtro/pass-through/driver intermedio utilizzando Windows DDK. Ho ricevuto molte buone informazioni da pcausa. Ecco un url che indica il loro prodotto che fa questo: http://www.pcausa.com/pcasim/Default.htm

0

Se lo stai facendo per motivi pratici, e non solo per divertimento, dovresti dare un'occhiata allo Microsoft Network Monitor. La home page parla della versione 3.3 beta, ma è possibile scaricare la versione 3.2 dalla pagina Download. C'è anche un SDK per NM e la possibilità di scrivere parser per i propri protocolli di rete.

8

Ci sono stato, fatto così :-) Nel 2000 il mio primo programma per Windows era sempre un filter hook driver.

Quello che ho fatto è stato implementare il driver hook del filtro e scrivere un'applicazione per gli utenti che ha preparato una tabella dei filtri su cosa consentire e cosa non consentire. Quando si ottiene il set iniziale di schermate blu (vedere sotto per il mio suggerimento di debug in modalità kernel) il driver in modalità filtro è abbastanza facile da usare ... assegna ad ogni pacchetto una funzione scritta e, a seconda del codice di ritorno, lo rilascia o lascia passare.

I pacchetti sfortunati a quel livello sono QUITE non elaborati, i frammenti non vengono riassemblati e assomigliano più alla fine della "carta di rete" (ma non alle intestazioni Ethernet più). Quindi ti divertirai parecchio a decodificare i pacchetti da filtrare con quella soluzione.

C'è anche il driver del firewall hook, come discusso in questo codeproject article.

Se si utilizza Vista o Server 2008, è preferibile dare un'occhiata al WFP (Windows Filtering Platform), che sembra essere l'API obbligatoria del giorno per la scrittura di firewall. Non ne sono a conoscenza tranne che su google per aggiornarlo alcuni minuti fa quando ho cercato su Google il driver del filtro hook.

Aggiornamento: Hai dimenticato la punta di debug:

Sysinternals DbgView mostra l'output DbgPrint in modalità kernel, e più importante - si può anche loro leggere dal file di dump tua ultima schermata blu prodotta. Quindi cospargere il codice con dbgprint e se è bluescreens basta caricare il dump in dbgview per vedere cosa è successo prima che morisse ... MOLTO utile. Usando questo ho gestito senza avere un debugger del kernel.

+0

I driver di hook del filtro non sono una buona scelta, perché è possibile averne solo uno installato in qualsiasi momento. Se provi a installare su un sistema che ha già qualcuno che si aggancio, sei pieno. –

+0

concordato. Penso che il driver hook del firewall sia la strada da percorrere, anche se è deprecato in WinXP e oltre per funzionare troppo in alto nello stack di rete. NDIS è raccomandato per WinXP. NDIS sembra più un lavoro, però. – Eyal

0

C'è una domanda che devi chiedere a chi non sai di dover chiedere; vuoi sapere a quali socket appartiene? o sei felice di essere limitato all'IP: port quad per una connessione?

Se si desidera conoscere le applicazioni, è necessario scrivere un driver di filtro TDI, ma ciò rende la gestione della ricezione quasi impossibile, poiché non è possibile bloccare il percorso di ricezione.

Se sei soddisfatto di IP: port, accedi al livello NDIS e credo che puoi bloccare il ricevere i contenuti del tuo cuore.

Una parola di avvertimento; se non si ha esperienza del kernel precedente, la scrittura di uno di questi driver (sebbene TDI sia molto più difficile) richiederà circa due anni, a tempo pieno.

0

questo:

TdiFw è un semplice TDI-Based Open Source Personal Firewall per Windows NT4/2000/XP/2003

http://tdifw.sourceforge.net/

possono aiutare

+0

Se è quello che penso sia, fa schifo! il codice sorgente NON è ben scritto o comprensibile. L'ho guardato mentre stavo scrivendo il mio filtro TDI e non mi ha aiutato affatto. –