Šajā rakstā mēs aplūkosim vienkārša sniffer izveidi operētājsistēmai Windows OS.
Ikviens interesents, laipni lūdzam kaķī.

Ievads

Mērķis: uzrakstiet programmu, kas uztvers tīkla trafiku (Ethernet, WiFi), kas tiek pārraidīts pa IP protokolu.
Ērtības: Visual Studio 2005 vai jaunāka versija.
Šeit aprakstītā pieeja nepieder personīgi autoram un tiek veiksmīgi izmantota daudzos komerciālos, kā arī kategoriski bezmaksas programmas(labdien, GPL).
Šis darbs ir paredzēts galvenokārt tīkla programmēšanas iesācējiem, kuriem tomēr ir vismaz pamatzināšanas ligzdu jomā kopumā un Windows ligzdu jomā. Šeit es bieži rakstīšu labi zināmas lietas, jo priekšmeta joma konkrēts, ja kaut ko palaidīsi garām, galva būs juka.

Ceru, ka jums tas liksies interesanti.

Teorija (lasīt nav obligāti, bet ieteicams)

IN Šis brīdis lielākā daļa mūsdienu informācijas tīkli ir balstīti uz TCP/IP protokolu steku pamatu. TCP/IP protokolu steks (Transmission Control Protocol/Internet Protocol) ir tīklos izmantoto dažāda līmeņa tīkla protokolu kolektīvs nosaukums. Šajā rakstā mūs galvenokārt interesēs IP protokols - maršrutēts tīkla protokols, ko izmanto tā sauktajās paketēs (pareizāks termins ir datagramma) sadalītu datu negarantētai piegādei no viena tīkla mezgla uz otru.
Īpaši mūs interesē IP paketes, kas paredzētas informācijas pārsūtīšanai. Tas ir pietiekami augsts līmenis tīkla OSI datu modelis, kad var norobežoties no ierīces un datu pārraides vides, darbojoties tikai ar loģisko attēlojumu.
Ir pilnīgi loģiski, ka agrāk vai vēlāk bija jāparādās pārtveršanas, kontroles, uzskaites un analīzes instrumentiem tīkla trafiku. Šādus rīkus parasti sauc par trafika analizatoriem, pakešu analizatoriem vai sniffers (no angļu valodas uz sniff - sniff). Šis - tīkla analizators trafika, programma vai aparatūras-programmatūras ierīce, kas paredzēta, lai pārtvertu un pēc tam analizētu vai tikai analizētu tīkla trafiku, kas paredzēta citiem mezgliem.

Prakse (saruna pēc būtības)

Šobrīd ir izveidots diezgan daudz programmatūra lai klausītos satiksmi. Slavenākais no tiem: Wireshark. Protams, mērķis nav plūkt laurus - mūs interesē uzdevums pārtvert trafiku, vienkārši “klausoties” tīkla saskarnē. Ir svarīgi saprast, ka mēs negrasāmies uzlauzt un pārtvert svešinieks satiksme. Mums vienkārši jāskata un jāanalizē datplūsma, kas iet caur mūsu saimniekdatoru.

Kāpēc tas var būt nepieciešams:

1. Skatiet pašreizējo trafika plūsmu caur tīkla savienojumu (ienākošais/izejošais/kopējais).
2. Novirziet trafiku turpmākai analīzei uz citu saimniekdatoru.
3. Teorētiski jūs varat mēģināt to izmantot, lai uzlauztu WiFi tīklu (mēs to nedarīsim, vai ne?).

Atšķirībā no Wireshark, kura pamatā ir libpcap/WinPcap bibliotēka, mūsu analizators neizmantos šo draiveri. Turklāt mums vispār nebūs draivera, un mēs nerakstīsim paši savu NDIS (ak, šausmas!). Par to varat lasīt šajā tēmā. Viņš vienkārši būs pasīvs novērotājs, izmantojot tikai WinSock bibliotēka. Šajā gadījumā draivera izmantošana ir lieka.

Kā tā? Ļoti vienkārši.
Galvenais solis, lai vienkāršu tīkla lietojumprogrammu pārvērstu par tīkla analizatoru, ir pārslēgt tīkla interfeisu uz izlaiduma režīmu, kas ļaus tai saņemt paketes, kas adresētas citām tīkla saskarnēm. Šis režīms ir piespiedu kārtā tīkla karte pieņemt visus kadrus neatkarīgi no tā, kam tie ir adresēti tīklā.

Sākot ar operētājsistēmu Windows 2000 (NT 5.0), kļuva ļoti viegli izveidot programmu tīkla segmenta klausīšanai, jo viņa tīkla draiverisļauj pārslēgt ligzdu visu pakešu saņemšanas režīmā.

Promiscuous režīma iespējošana

Mūsu programma darbojas ar IP paketēm un izmanto Windows Sockets bibliotēkas versiju 2.2 un neapstrādātas ligzdas. Lai iegūtu tiešu piekļuvi IP paketei, ligzda ir jāizveido šādi:

Neapstrādātas ligzdas izveide

Šeit konstantes vietā SOCK_STREAM(TCP protokols) vai SOCK_DGRAM(UDP protokols), mēs izmantojam vērtību SOCK_RAW. Vispārīgi runājot, darbs ar neapstrādātām ligzdām ir interesants ne tikai no satiksmes uztveršanas viedokļa. Faktiski mēs iegūstam pilnīgu kontroli pār iepakojuma veidošanu. Pareizāk sakot, veidojam manuāli, kas ļauj, piemēram, nosūtīt konkrētu ICMP paketi...

Uz priekšu. Ir zināms, ka IP pakete sastāv no galvenes, pakalpojuma informācijas un faktiski datiem. Iesaku ielūkoties šeit, lai atsvaidzinātu savas zināšanas. Aprakstīsim IP galveni struktūras veidā (pateicoties lieliskajam rakstam par RSDN):

IP pakešu struktūras apraksts

Klausīšanās algoritma galvenā funkcija izskatīsies šādi:

Vienas paketes uztveršanas funkcija

Šeit viss ir vienkārši: mēs saņemam datu daļu, izmantojot standarta ligzdas funkciju recv, un pēc tam kopējiet tos tādā struktūrā kā IP Header.
Un beidzot mēs sākam bezgalīgs cikls pakešu uztveršana:

Uztversim visas paketes, kas sasniedz mūsu tīkla saskarni

Mazliet offtopic

Šeit un tālāk autors izveidoja RS_ (no Raw Sockets) prefiksu dažām svarīgām funkcijām un mainīgajiem. Projektu veicu pirms 3-4 gadiem, un man radās traka ideja uzrakstīt pilnvērtīgu bibliotēku darbam ar neapstrādātām ligzdām. Kā jau nereti gadās, pēc dažu nozīmīgu (autorei) rezultātu iegūšanas entuziasms pagaisa, un tālāk par mācību piemēru lieta netika.

Principā varat iet tālāk un aprakstīt visu turpmāko protokolu galvenes, kas atrodas iepriekš. Lai to izdarītu, jums ir jāanalizē lauks protokols struktūrā IP Header. Apskatiet piemēru kodu (jā, tur jābūt slēdzim, sasodīts!), kur galvene ir iekrāsota atkarībā no tā, kādu protokolu pakete ir iekapsulējusi IP:

/* * Pakotnes izcelšana ar krāsu */ void ColorPacket(const IPHeader *h, const u_long haddr, const u_long whost = 0) ( if (h->xsum) SetConsoleTextColor(0x17); // ja pakotne nav tukša cits SetConsoleTextColor(0x07) ; // tukša pakotne if (haddr == h->src) ( SetConsoleTextColor(BACKGROUND_BLUE | /*BACKGROUND_INTENSITY |*/ FOREGROUND_RED | FOREGROUND_INTENSITY); // pakotnei "native" = "native" h->dest ) ( SetConsoleTextColor(BACKGROUND_BLUE | /*BACKGROUND_INTENSITY |*/ FOREGROUND_GREEN | FOREGROUND_INTENSITY); // "vietējā" saņemšanas pakete ) if (h->protocol == PROT_ICMP ||) h->protocol ==ex. (0x70) ; // ICMP pakete ) else if(h->protocol == PROT_IP || h->protocol == 115) ( SetConsoleTextColor(0x4F); // IP-in-IP pakete, L2TP ) else if(h) - >protocol == 53 ||. h->protocol == 56) ( SetConsoleTextColor(0x4C); // TLS, IP ar šifrēšanu ) if(whost == h->dest || whost == h->src) ( SetConsoleTextColor (0x0A);

Tomēr tas ievērojami pārsniedz šī raksta darbības jomu. Mūsu apmācības piemēram pietiks apskatīt to resursdatoru IP adreses, no kuriem un uz kuriem nāk trafika, un aprēķināt tā apjomu laika vienībā (gatavā programma atrodas arhīvā raksta beigās) .

Lai parādītu IP galvenes datus, ir jāievieš funkcija, kas konvertē datagrammas galveni (bet ne datus) par virkni. Kā ieviešanas piemēru mēs varam piedāvāt šādu iespēju:

IP galvenes pārveidošana par virkni

Pamatojoties uz iepriekš sniegto pamatinformāciju, mēs iegūstam šo mazo programmu (rāpojošs nosaukums ss, saīsinājums no vienkāršas sniffer), kas ievieš lokālu IP trafika klausīšanos. Tās saskarne ir parādīta zemāk attēlā.

Avots un binārais kods Es sniedzu to tādu, kāds tas ir, kā tas bija pirms vairākiem gadiem. Tagad man ir bail uz to skatīties, un tomēr, tas ir diezgan lasāms (protams, nevar būt tik pašpārliecināts). Kompilācijai pietiks pat ar Visual Studio Express 2005.

Ar ko mēs nonācām:

• Sniffer darbojas lietotāja režīmā, taču tam ir nepieciešamas administratora tiesības.
• Paketes netiek filtrētas un tiek rādītas tādas, kādas tās ir (varat pievienot pielāgotus filtrus - ja jūs interesē, es iesaku detalizēti apskatīt šo tēmu nākamajā rakstā).
• Tiek tverts arī WiFi trafiks (tas viss ir atkarīgs no konkrēts modelis mikroshēma, tas var nedarboties jums, tāpat kā man pirms vairākiem gadiem), lai gan ir AirPcap, kas to var izdarīt lieliski, bet maksā naudu.
• Visa datagrammas straume tiek reģistrēta failā (skatiet raksta beigās pievienoto arhīvu).
• Programma darbojas kā serveris portā 2000. Varat izveidot savienojumu ar resursdatoru, izmantojot telnet utilītu, un pārraudzīt satiksmes plūsmas. Savienojumu skaits ir ierobežots līdz divdesmit (kods nav mans, es to atradu internetā un izmantoju eksperimentiem; es to neizdzēsu - žēl)

Paldies par uzmanību, novēlu jums un visiem priecīgus Ziemassvētkus!

Šajā rakstā mēs aplūkosim vienkārša sniffer izveidi operētājsistēmai Windows OS.
Ikviens interesents, laipni lūdzam kaķī.

Ievads

Ceru, ka jums tas liksies interesanti.

Teorija (lasīt nav obligāti, bet ieteicams)

Prakse (saruna pēc būtības)

Kāpēc tas var būt nepieciešams:

1. Skatiet pašreizējo trafika plūsmu caur tīkla savienojumu (ienākošais/izejošais/kopējais).
2. Novirziet trafiku turpmākai analīzei uz citu saimniekdatoru.
3. Teorētiski jūs varat mēģināt to izmantot, lai uzlauztu WiFi tīklu (mēs to nedarīsim, vai ne?).

Kā tā? Ļoti vienkārši.
Galvenais solis, lai vienkāršu tīkla lietojumprogrammu pārvērstu par tīkla analizatoru, ir pārslēgt tīkla interfeisu uz izlaiduma režīmu, kas ļaus tai saņemt paketes, kas adresētas citām tīkla saskarnēm. Šis režīms liek tīkla kartei pieņemt visus kadrus neatkarīgi no tā, kam tie ir adresēti tīklā.

Sākot ar operētājsistēmu Windows 2000 (NT 5.0), kļuva ļoti viegli izveidot programmu tīkla segmenta klausīšanai, jo tā tīkla draiveris ļauj iestatīt ligzdu visu pakešu saņemšanai.

Promiscuous režīma iespējošana

Neapstrādātas ligzdas izveide

Uz priekšu. Ir zināms, ka IP pakete sastāv no galvenes, pakalpojuma informācijas un faktiski datiem. Iesaku ielūkoties šeit, lai atsvaidzinātu savas zināšanas. Aprakstīsim IP galveni struktūras veidā (pateicoties lieliskajam rakstam par RSDN):

IP pakešu struktūras apraksts

Vienas paketes uztveršanas funkcija

Uztversim visas paketes, kas sasniedz mūsu tīkla saskarni

Mazliet offtopic

Principā varat iet tālāk un aprakstīt visu turpmāko protokolu galvenes, kas atrodas iepriekš. Lai to izdarītu, jums ir jāanalizē lauks protokols struktūrā IP Header. Apskatiet piemēru kodu (jā, tur jābūt slēdzim, sasodīts!), kur galvene ir iekrāsota atkarībā no tā, kādu protokolu pakete ir iekapsulējusi IP:

/* * Pakotnes izcelšana ar krāsu */ void ColorPacket(const IPHeader *h, const u_long haddr, const u_long whost = 0) ( if (h->xsum) SetConsoleTextColor(0x17); // ja pakotne nav tukša cits SetConsoleTextColor(0x07) ; // tukša pakotne if (haddr == h->src) ( SetConsoleTextColor(BACKGROUND_BLUE | /*BACKGROUND_INTENSITY |*/ FOREGROUND_RED | FOREGROUND_INTENSITY); // pakotnei "native" = "native" h->dest ) ( SetConsoleTextColor(BACKGROUND_BLUE | /*BACKGROUND_INTENSITY |*/ FOREGROUND_GREEN | FOREGROUND_INTENSITY); // "vietējā" saņemšanas pakete ) if (h->protocol == PROT_ICMP ||) h->protocol ==ex. (0x70) ; // ICMP pakete ) else if(h->protocol == PROT_IP || h->protocol == 115) ( SetConsoleTextColor(0x4F); // IP-in-IP pakete, L2TP ) else if(h) - >protocol == 53 ||. h->protocol == 56) ( SetConsoleTextColor(0x4C); // TLS, IP ar šifrēšanu ) if(whost == h->dest || whost == h->src) ( SetConsoleTextColor (0x0A);

Tomēr tas ievērojami pārsniedz šī raksta darbības jomu. Mūsu apmācības piemēram pietiks apskatīt to resursdatoru IP adreses, no kuriem un uz kuriem nāk trafika, un aprēķināt tā apjomu laika vienībā (gatavā programma atrodas arhīvā raksta beigās) .

Lai parādītu IP galvenes datus, ir jāievieš funkcija, kas konvertē datagrammas galveni (bet ne datus) par virkni. Kā ieviešanas piemēru mēs varam piedāvāt šādu iespēju:

IP galvenes pārveidošana par virkni

Es sniedzu avota un bināro kodu tādu, kāds tas ir, kā tas bija pirms vairākiem gadiem. Tagad man ir bail uz to skatīties, un tomēr, tas ir diezgan lasāms (protams, nevar būt tik pašpārliecināts). Kompilācijai pietiks pat ar Visual Studio Express 2005.

Ar ko mēs nonācām:

• Sniffer darbojas lietotāja režīmā, taču tam ir nepieciešamas administratora tiesības.
• Paketes netiek filtrētas un tiek rādītas tādas, kādas tās ir (varat pievienot pielāgotus filtrus - ja jūs interesē, es iesaku detalizēti apskatīt šo tēmu nākamajā rakstā).
• Tiek tverts arī WiFi trafiks (viss atkarīgs no konkrētā mikroshēmas modeļa, iespējams, ka tev tas nedarbosies, kā man pirms vairākiem gadiem), lai gan ir AirPcap, kas to spēj brīnišķīgi, bet maksā naudu.
• Visa datagrammas straume tiek reģistrēta failā (skatiet raksta beigās pievienoto arhīvu).
• Programma darbojas kā serveris portā 2000. Varat izveidot savienojumu ar resursdatoru, izmantojot telnet utilītu, un pārraudzīt satiksmes plūsmas. Savienojumu skaits ir ierobežots līdz divdesmit (kods nav mans, es to atradu internetā un izmantoju eksperimentiem; es to neizdzēsu - žēl)

Labdien Kaut kā darbā radās problēma - bija ierīce, kas strādāja caur I2C un kuras protokols bija jāsaprot. Tāpēc mums ir nepieciešams sniffer I2C interfeisam, kas izvadītu visu, kas nāk un iet caur I2C uz UART portu un pēc tam caur pārveidotāju uz datora COM portu.

Sākt

Bija 2 iespējas - ieslēgt sniffer paralēli, vai atvērtā ķēdē. Acīmredzot pirmais variants izskatās daudz vienkāršāks, kas patiesībā izrādījās pilnīgi nepareizs. Bet vispirms vispirms.

Īsumā par pašu saskarni. I2C (TWI in Atmel) izmanto divus vadus - SCL un SDA. Pirmais ir atbildīgs par signāla pulksteni, otrais ir atbildīgs par informācijas tiešu pārraidi. Interfeisam ir arī START un STOP stāvokļi.

Tātad, mana pirmā doma bija paņemt zondi un savienot to ar manu kāju vienā pusē ārējs pārtraukums uz atmega8 no otras uz SDA līniju un noķert priekšējo malu un noteikt 0 vai 1 no pagājušā laika Acīmredzot tam vajadzēja darboties ļoti slikti, jo STOP signāls netika apstrādāts pareizi.

Otra doma bija darīt to pašu, bet uztvert pārtraukumu SCL līnijā un nolasīt SDA līniju, kas savienota ar parasto digitālo posmu, izmantojot pārtraukumu. Šeit viss izskatījās dzīvotspējīgāks, izņemot to pašu STOP stāvokli, bet es nolēmu mēģināt to salikt uz maizes dēļa un redzēt, kas notiks.

Jau iepriekš atvainojos, ja zemāk esošajā kodā atrodat acīmredzamas kļūdas, jo es uz ceļiem rekonstruēju noraidītās koda versijas no atmiņas.

Pārtraukumu apstrādātāja kods izskatījās šādi:

ISR(INT0_vect) (cli(); if (bitIsHigh(PINB, 0)) uart_send_char("1"); else uart_send_char("0"); sei(); )
Ostā ieplūda nulles un vieninieki, taču uzreiz kļuva skaidrs, ka dati ir nepareizi - to bija daudz mazāk nekā gaidīts un tas mainījās, atkārtojot vienu un to pašu pieprasījumu. Cēloņu noskaidrošanas procesā viss nonāca pie tā, ka dati tika zaudēti, jo tika piekļūts uart interfeisam, kas, starp citu, darbojās ar maksimālo stabilu ātrumu 38 kbit/s, savukārt I2C pati strādāja ar ātrumu 100 kbit/s. Nebija iespējams palielināt UART ātrumu, jo trūka vajadzīgās frekvences kristāla, lai UART sasniegtu pieņemamu ātrumu. Tāpēc bija nepieciešams noņemt darbu ar uart no pārtraukuma. Sanāca kaut kas līdzīgs šim:

Statiskie uint8_t dati = 0; statisks uint8_t idx = 7; ISR(INT0_vect) ( cli(); dati |= bitIsHigh(PINB, 0)<< (idx--); if (!idx) { uart_send_char(data); data = 0; idx = 7; } sei(); }
Viss kļuva stabilāks, taču datiem joprojām nebija nekādas jēgas. Pēc vairāku stundu darba ar algoritmu, ieslēdzot STOP apstrādi utt., tika nolemts iet citu ceļu.

Uz pareizā ceļa

Tā kā atmega8 ir tikai viena aparatūra I2C, ir skaidrs, ka, lai tas darbotos, jums ir jāraksta programmatūras atbalsts protokolam.

Rezultāts bija šāds kods:

ISR (TWI_VECT) (CLI (); UINT8_T Statuss = TWSR; UINT8_T B; Char S; S = 0; _DLAY_MS (1); STATUSS & I2C_STATUS_MASK) (CASE I2C_STATUS_SR_RX_ADR_AC:/* CASE I2C_ST ARS:* AW :"); uart_send_int(TWDR); i2csoft_start(); i2csoft_open_write(I2C_ADDRESS); pārtraukums; case I2C_STATUS_SR_RX_DATA_ACK:/* case I2C_STATUS_SR_RX_DATA_NACK:*/ b = TWDR(b.sstr); i2csoft_write_byte(b) case I2C_STATUS_SR_RX_START: uart_send_str("E\n"); _lasīšanas_baits (); uart_send_str(s); uart_send_str("L\n"); pārtraukums; noklusējuma: uart_send_char("U"); uart_send_int(statuss); uart_send_char(" "); pārtraukums; ) TWCR |= (1<Galvenā ierīce ir savienota ar atmega aparatūru I2C, izpildierīce ir savienota ar jebkurām 2 digitālajām kājām, no kurām viena darbojas SCL režīmā, otra SDA. Viss iepriekš minētais kods saņem pārtraukumu, izmantojot I2C, un rada līdzīgu stāvokli programmatūras saskarnē, savukārt pakalpojuma informācija tiek rakstīta uart, lai palīdzētu saprast, kas notiek. Iestatītās aizkaves tika atlasītas konkrētai ierīcei un var nedaudz atšķirties citām ierīcēm. Rezultātā mēs iegūstam ļoti labu sniffer.

Ja kādam interesē, avotus var ņemt no