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.
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
Ho bisogno di una soluzione/esempio del WFP, sfortunatamente. – ChopperCharles