16 svar · 792 visningar · startad av renholm
Satt och funderade på om det var möjligt att skriva ett program i .NET som loggar vad som skickas och tas emot från en dator.
Syftet är inte att på något sätts spionera på någon utan att jag vill se ur olika program fungerar med protokol osv...
Det går säkert, men hur vet jag inte....
Lycka till ;)
Njae, det blir svårt. För att kunna läsa det som går över ett nätverkskort är det bästa hooka in i kernelmode, och det går inte med .Net. Ett alternativ är väl kanske att hooka in i varje process och byta ut winsock-funktionerna mot en som loggar trafiken innan den skickar respektive loggar efter att ha tagit emot data.
Men om du vill studera traffik är det enklaste att installera netmon (Network Monitor) som finns till W2k server (add/remove programs, windows components från kontrollpanelen). Jag tror inte det finns för professional eller Windows XP. Till XP verkar det finnas något som heter netcap som jag inte provat, se http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q310875
http://support.microsoft.com/default.aspx?scid=kb;[LN];Q148942
Eller sök efter netmon på: http://www.microsoft.com/technet/
EDIT: lagade en trasig länk.
Då hade jag fel...
ok, vet om de färdiga programmen, men var lite intresserad av att göra ett eget, det finns även fler orsaker till att logga trafiken än bara för att se hur program fungerar, tänkte också att gör en form av egen brandvägg som igentligen inte ska stoppa så mycket utan logga de aktiva kopplingarna och portar. Att byta ut winsock är lite väl mycket, men skulle man kunna skriva en form av proxy som man låter trafiken gå igenom?
Vilka transporter behöver du logga? Om det bara är http är det ju relativt lätt att skriva en proxy som du konfigurerar din webläsare till att använda. Annars blir det mer jobb. Jag hittade förresten en ganska bra artikel: http://www.ntndis.com/articles/firewalleng.htm
oh, ett sånt program skulle jag vilja ha, som för statistik över all trafik till o från.
ja, i baktanken har jag tänkt mig ett program som man skulle installera på den datorn man vill ha statistik av och sedan kanske via webservices loggas det på lämplig plats, om man bara vill ha statistik för hur mycket data som skickas kan man använda SNMP och logga med MRTG ( http://people.ee.ethz.ch/~oetiker/webtools/mrtg/ )
får bli att läsa url imorn, börjar kännas lite segt just nu =)
Du kan ju skriva en egen TCP/IP stack. Då har du alla möjligheter i väröden att övervaka. Annars tror jag det blir rätt å svårt.
Ok, TCP/IP stack, något man skriver på 5 minuter? Och det går nog inte att göra i .NET språken?
Tråden är kanske inte så aktuell.. Men om någon är intresserad så finns en fungerande sniffer skriven i C# och med källkod här.
När jag provar så funkar den alldeles utmärkt och klarar tom att sätta nätverkskortet i "promiscuous mode" (vilket innebär att man även kan sniffa andra maskiner). Hur detta går till fattar jag inte riktigt eftersom man normalt måste göra sånt på driver-nivå (det finns dessutom ingen unsafe kod!!).
Så om någon har tid över och lyckas reda ut hur i.. det är gjort så är i alla fall jag intresserad av att veta.
Tackar, ska se om jag ska ta upp mitt projekt igen :)
Ingen orsak. Ska nog själv ta mig en titt på koden när jag har bättre koll på C#. Om man kan göra såna här lågnivågrejer i managed kod så borde man nästan kunna skriva en brandvägg i VB. :)
vilket innebär att man även kan sniffa andra maskiner
Förutsatt att du inte har ett switchat nät ......
cya,
PatrikB
PatrikB skrev:
Förutsatt att du inte har ett switchat nät ......
Ja, självklart måste paketen på något sätt passera på den fysiska kabeln för att man ska kunna inspektera dom. Men, det gäller ju alla sniffers. Det intressanta här är ju att det faktiskt går att skriva en (promiscuous) sniffer i managed C#.
Jepp, mycket intressant och har man ett switchat nät så speglar man en port ;) så man kan vara "nicke-nyfiken" :e
cya,
PatrikB
Visst, och man kan lura switchen med fejkade ARP/RARP-paket. Men då är vi ju way off topic. Och det vill vi ju inte ..? ;)
Som sagt, det jag tyckte var intressant (och imponerande) var att .NET-Frameworken i detta fall verkar ge mer (och enklare) access till lågnivågrejer än det gamla Windows-API:et. Där hade man nog fått vända ut och in på sig för att göra nåt liknande utan att använda VXD:er eller drivers.
