00: 00: 03,700720 192.168.1.100.11955 > 192.168.1.200.80: S [tcp sum ok] 365712315: 365712315 (0) vinner 32768 < mss 536 > (Ttl 63, id 59169, len 44)
0x0000 4500 002c e721 0000 3f06 4253 c0a8 0164 E ..,.! ..?. BS ....
0x0010 c0a8 01c8 2eb3 0050 15cc 53bb 0000 0000. ..1 ... P..S .....
0x0020 6002 8000 30e0 0000 0204 0218 0000 `... 0 .........

00:00: 03.715864 192.168.1.200.80 > 192.168.1.100.11955: S [tcp sum ok] 2093803204: 2093803204 (0) ack 365712316 vinne 5840 < MSS 1460 > (DF) (ttl 52, id 0, len 44)
0x0000 4500 002c 0000 4000 3406 f474 c0a8 01c8 E .., .. @. 4..t ... en
0x0010 c0a8 0164 0050 2eb3 7ccc e6c4 15cc 53bc ..... P .. |. ..... S
0x0020 6012 16d0 32d2 0000 0204 05b4 0000 `... 2 .........

vel sett ovenfor er de samme to pakker som vi har jobbet oss gjennom. I del to vi slapp på seier størrelse beregning. På dette notatet kan plukke det opp igjen, og fortsette vår analyse

<. Mss 536 >

Hva de ovennevnte betegner i virkeligheten er "maksimal segmentstørrelse" eller MSS som det er ofte referert til. Etter det er verdien av 536, som refererer til verdien av mss. Alle sagt og gjort dette betyr at kildedatamaskinen dvs: 192.168.1.100

ikke ønsker å motta mer enn 536 byte data på ett gitt pakke. Dette er en ganske lav verdi for en hss sett på som MTU (Maximum Transmission Unit) for Ethernet er 1540. Selv om vær oppmerksom på at ofte Internet Explorer vil annonsere en standard mss av 536 som vist over. Også husk at MSS verdien er bare noen gang har sett i en SYN segment. Hvis en eller annen grunn kilden ikke sende en MSS verdi da standardverdien på 536 byte er antatt.

(ttl 63, id 59169, len 44)

Den første verdien av ttl 63 faktisk betegner "tid til å leve" at pakken har. Hva det betyr er at hvis denne pakken hadde gått gjennom en annen 63 ruter humle så ville det ha vært droppet. Det i sin tur ville resultert i en ICMP feilmelding blir generert av den siste ruteren for å minske denne verdien. Dette er en av de beregninger som ikke er målt i byte. Det er ganske enkelt en numerisk verdi som blir dekrementert hver gang den går gjennom en ruter. Var det ikke for å være TTL-verdier da internett vil trolig ende opp sliping stoppet opp på et tidspunkt. Det skjer til tider som pakker seg vill i mangel av et bedre ord. Denne verdien gjør at på et tidspunkt pakken er enten levert eller at den er droppet.

id 59169

Neste på vår hit parade er den metriske sett ovenfor. Hva dette betyr er at IP-ID-nummer er 59169. Og det betyr hva !? Vel betyr det at dette bør pakken være fragmenterte eller annen grunn, så hver fragmentet vil ha den samme IP-ID-nummer. I dette tilfellet alle fragmentene vil ha en ip id 59169.

Dette er fordi at når målmaskinen mottar en fragmentert pakke, at den vet hva fragmenter hører til hverandre. Det er en annen verdi selv om det ville være inkludert, og det er den fragmentering utlignet. Denne forskyvningen ville la datamaskinen vite i hvilken rekkefølge pakkene skal være. Tross alt ikke bra å ha alle fragmentene hvis du ikke vet i hvilken rekkefølge de går.

len 44

Nå den endelige verdien i overskriften er len 44. Dette refererer til den totale lengden på selve pakken. Denne tellingen, som måles i byte tar hensyn ikke bare TCP og IP header. Det vil også inkludere data som ble sendt om noen. Dette er et viktig skille å gjøre, og en god en å huske.

Vel det nå brytes opp alle de header beregninger som kan vises i ASCII. Vi er nå på det stadiet hvor vi vil begynne å se på heller kryptiske hex verdier. Vær oppmerksom på at TCP /IP og tcpdump flyer jeg nevnte i del en er nødvendig her. Endelig å finne dette dokumentet finner du nederst på siden under ressurser for PDF-dokumentet har samme tittel som hyperkoblingen. Hva skal vi nå gjøre er å gå gjennom hex en linje av gangen. Så på dette notatet vil jeg lime inn en linje, og kommentere det, under den.

0x0000 4500 002c e721 0000 3f06 4253 c0a8 0164 E ..,.! ..?. BS ....

Vår første verdi som vist ovenfor er 0x0000, og hva det betyr er at verdien følgende 0x vil være i heksadesimalt format nummerering. Det morsomme her er at vi trenger å telle fra null, vice normalt starter med en. En annen ting som er ganske viktig å huske! Så med det sagt, vil vår byte null faktisk bli representert av tegnene 45, som vist over. Vi kan nå se at hvis du ønsker å se på en enkelt bite så det ville da være ett tegn, enten det er et tall eller en bokstav. Ikke glem at det heksadesimale tallsystemet bruker både bokstaver og tall dvs. 0-9, A-F

Så hva gjør vår første byte, eller byte null faktisk bryte ut da? Vel, hvis du ser på TCP /IP-ark vil du legge merke til at IP versjon er tildelt fire biter, eller en småspise. At nibble i dette tilfellet er representert ved verdien av 4. Så det forteller oss at denne pakken er å bruke IPv4.

Etter det er det IHL, eller internett header lengde. Denne verdien representerer antall 32 bits ord at IP header har. Hvis vi deler 32 med 8 da ville vi innse at en 32 bit ord er faktisk fire byte. Verdien vi har her er fem, og hvis vi multipliserer det med fire da har vi 20 byte i IP header. Det i virkeligheten er en standard IP header, og standard i så mye som det er ingen IP valg satt i den. Var det IP alternativer som løs kilde rekord rute da verdien av fem vil endres tilsvarende.

Vel, vi kan se at dette er ganske enkelt å bryte ut gitt vår TCP /IP cheatsheet. Med dette i tankene vil jeg hoppe til TCP spissen. Grunnen til at jeg gjør dette er at det er TCP alternativene som finnes i pakken en. Husk på dette tidspunktet at pakke en refererer til SYN pakke nevnt ovenfor, og ikke SYN /ACK-pakke sett under den.

0x0020 6002 8000 30e0 0000 0204 0218 0000
`... 0 .........

Spesielt fra de ovennevnte siste linje av hex i pakken en, er verdiene for 0204 på til 0000 at vi vil se på. For som jeg nevnte ovenfor dette er der TCP alternativene er detaljert. På denne tiden kan du ta en titt på bunnen av TCP header jukse ark og se alternativ segmentet.

Med det sagt våre TCP opsjoner begynner med de to bytes 0204 nevnt ovenfor i pakken biten. Hva det betyr er at den første TCP alternativet i denne TCP header er MSS eller maksimal segmentstørrelse. At verdien av to tilsvarer mss sett på bunnen av TCP header jukselapp som du lastet ned under alternativer. Neste vi har størrelsen i byte av at TCP alternativet, som er lengden av opsjonen. I dette tilfellet er det fire bytes. Etter det er 0218, og at det i hex tilsvarer 536 i desimal. Det skjer for å være verdien av mss alternativet. Hvis en TCP alternativet har en tallverdi så vil det følge det, som det gjør i dette tilfellet. Endelig er det 0000. Det rare her er at vår totale pakkelengde er ment å 44 som betegnes med "len 44". I dette tilfellet alt som har skjedd er at nic kortet trolig polstret de to ekstra bytes.

Vel som du kan se fra disse artiklene forståelse både TCP og IP er egentlig ikke så vanskelig. Alt som trengs er litt trening, og på kort tid vil du bli ripping gjennom disse som om du var en innfødt. Jeg håper at dette var til nytte for deg, og velkommen som alltid alle eventuelle kommentarer.
Hvis du ønsker å lese resten av artiklene i denne serien kan du gå til: