Packet Sniffing / Exe filer gjennom Hex

[Dark Fire]

Vet ikke hvordan det fungerer, altså hva slags språk dette er jeg..

Funderte litt på om det var TCP/IP-språket eller noe? ;P

Altså når jeg sniffer TCP-pakker.

Men etter litt Googling fant jeg ingenting.

 

Jeg bruker Wireshark, og et eksempel på en kode er:

00 18 4d 81 e1 b6 00 16 44 15 2f ff 08 00 45 00

00 28 2f 30 40 00 40 06 11 ad 0a 00 00 04 d5 b9

1a 36 c1 87 bb 03 3e 1f 26 d9 0d 1b 7d 7f 50 10

ff ff 49 c3 00 00

 

Og i Ascii eller noe (oversettelsen fra Wireshark) er dette:

..M.....D./...E.

.(/0@.@.........

.6....>.&...}.P.

..I...

 

Det jeg prøver på, er å lære meg hva dette betyr; lære meg når hex-kodene blir brukt til hva..

 

OT: Det samme med executable filer kjørt gjennom en hex editor: hvordan finner man ut hver enkel funksjon?

Hvem som helst kan jo endre clear-texten som er der, med ctrl+f, men selve funksjonene, eller fargene; hvordan finner man ut hvor farge-koden er der? ved å søke etter farge-koden og gjette seg frem?

[Dead_Rabbit]

Det er ikke noe mer hokus-pokus med det der enn at det ikke gir mening å representere det i ASCII format. Det kan f.eks. være en del av et bilde eller en lydfil, noe binært, e.l. Det kan være mye.

[Dark Fire]

Det er ikke noe mer hokus-pokus med det der enn at det ikke gir mening å representere det i ASCII format. Det kan f.eks. være en del av et bilde eller en lydfil, noe binært, e.l. Det kan være mye.

Så det er ingen måte å finne det ut på, annet enn å sende pakken til seg selv, via samme port som pakken skulle sendes til, og kjøre samme softwaren som porten stammer til?

Er det ingenting standard?

Ikke et språk noe av dette kan tolkes i?

Helt individuelt?

Endret 1. august 2008 av Dark Fire

[Hårek]

Det er litt meningsløst å bare ta en tilfeldig pakke og prøve å finne ut hva den betyr. Kun hvis man tilfeldigvis plukker opp en pakke i ren tekst kan man lese innholdet.

Det vanlige når man bruker verktøy som Wireshark er at man plukker ut bestemte pakker med et filter. Det kan være en gitt avsender eller mottaker, en port, et gitt innhold, eller en kombinasjon av flere ting.

Man må kjenne protokollen ("språket") først, så kan man tolke innholdet.

 

Angående standarder, det er jo hundrevis av dem, de brukes etter behov. TCP/IP standarden f.eks er den som pakker inn data. En nettverkspakke vil bestå av mye mer enn selve innholdet som du normalt ser i Wireshark. Du kan også velge om du vil se hele pakken med headere og innhold.

 

For å si det slik, du har begynnt å pirke borti noe som ikke er enkelt å forstå i en håndvending. Det er et stort felt med mange nivåer man må lære seg, de fleste bruker noen års studier på slikt.

[Dark Fire]

Mmk, takk for svar.

 

Jeg tenkte litt som..

Siden det er en hex verdi, bør jo noe representere disse verdiene, og at disse kan gi mening i et hvilket som helst språk, men det er fult forstålig om det ikke er det.

 

Hva med såkalt RE..?

Hvordan forstår man noe som ikke er i ren tekst-format når det kommer til binary filer?

Man bør jo i det minste kunne lære seg det, via å analysere operativ systemet man bruker, siden operativsystemet kan kjøre filene.

Men det er altså ingen tutorials på sånt som dette?

 

PS: Hvordan lærer man seg hvordan de forskjellige protokol-språkene fungerer?

MSN for eksempel.

Det er vel veldig få tutorialer på dette og?

Endret 1. august 2008 av Dark Fire

[___]

Jeg tenkte litt som..

Siden det er en hex verdi, bør jo noe representere disse verdiene, og at disse kan gi mening i et hvilket som helst språk, men det er fult forstålig om det ikke er det.

 

At du ser innholdet av en fil som heksadesimale verdier har kun å gjøre med at editoren du bruker har denne visningen. Mange tekst-editorer (f.eks. UltraEdit, som jeg har brukt i mange herrens år) switcher automatisk over til HEX-view hvis fila inneholder non-ASCII tegn.

 

Det heksadesimale tallsystem er benyttet i dataverdenen fordi det er den mest lesbare måten å representere en byte på.

 

Hex Binær	 Desimal
=====================
00  0000 0000	   0
0F  0000 1111	  15
55  0101 0101	  85
AA  1010 1010	 170
F0  1111 0000	 240
FF  1111 1111	 255

 

Det blir galt å si at en fil inneholder heksadesimale verdier (hvis man da ikke snakker om en tekst-fil der heksadesimale tegn framkommer som tekst).

 

Hva med såkalt RE..?

Hvordan forstår man noe som ikke er i ren tekst-format når det kommer til binary filer?

Man bør jo i det minste kunne lære seg det, via å analysere operativ systemet man bruker, siden operativsystemet kan kjøre filene.

Men det er altså ingen tutorials på sånt som dette?

 

Et binærfil-format trenger ikke å følge noen regler i det hele tatt. Det er helt opp til forfatteren av programmet som produserer binærfilen, å bestemme formatet.

 

Men la oss ta vanlige exe-filer i Windows. Disse filene vil alltid starte med to ASCII-verdier, som identifiserer hvilket OS filene er kompilert for. Som en kuriositet kan nevnes exe-filer for 16-bit MS-DOS, som alltid starter med MZ, som er initialene til en fyr ved navn Mark Zbikowski, som var en av utviklerne bak MS-DOS. Les mer om dette her: http://en.wikipedia.org/wiki/EXE og her: http://en.wikipedia.org/wiki/DOS_executable

 

Når du "starter" en fil, ved f.eks. å dobbeltklikke på den, så vil altså operativsystemet lese de to første bytene i fila, for å avgjøre om det er en kjørbar fil. Hvis ikke, så vil operativsystemet basert på fil-endelsen prøve å starte programmet som er assosiert med fil-endelsen, og gi programmet beskjed om å åpne fila. Hvis fil-endelsen ikke er registrert, eller filen ikke har noen fil-endelse, så vil du få en feilmelding.

 

PS: Hvordan lærer man seg hvordan de forskjellige protokol-språkene fungerer?

MSN for eksempel.

Det er vel veldig få tutorialer på dette og?

 

MSN er vel en ganske så lukket og proprietær protokoll. Vi snakker jo om Microsoft her. Men det finnes vel mange brave sjeler der ute som har analysert protokollen og dokumentert hva de har funnet ut. Søk på nettet så får du svar.

 

De fleste åpne protokoller på nettet, som FTP, HTTP, o.l. er behørig dokumentert i såkalte RFC-dokumenter (Request For Comment). Du kan finne en indeksert RFC-liste her: http://tools.ietf.org/rfc/ Det første RFC-dokumentet ble opprettet så tidlig som i 1969.

 

Werner

[Hårek]

Siden det er en hex verdi, bør jo noe representere disse verdiene, og at disse kan gi mening i et hvilket som helst språk, men det er fult forstålig om det ikke er det.

Blir vel nesten som om du plukker ut en tilfeldig bokstav fra en bok, eller en note fra et musikkstykke. Ingen tvil om at bokstaven representerer noe, men det er umulig å vite om den kommer fra noe Shakespeare skrev eller kladdeboken til en førsteklassing.

 

For å begynne med det mest elementære:

Grunnlaget for en datamaskin er en bit, som har verdien 0 eller 1. Det kalles binært, eller to-tall-system.

Når vi skal skrive datakoder på papir blir det veldig tungvindt å bruke binært, så vi bruker heller grupper av bits. 4 bit kan representere tall fra 0 til 15, men vi bruker bokstavene A til F for 10 til 15, slik at vi klarer oss med en karakter. Dette er hexadesimalt (hex).

To hex karakterer representerer en byte (8 bit), som er den mest brukte 'enheten' for å skrive data.

ASCII er en standard for å representere hver karakter i alfabetet, tall, tegn, etc, i en byte. F.eks er hex 4D en 'M', og 45 er 'E'.

 

Når man dumper data i hex og ASCII slik du er inne på i første innlegg, så er det fordi det er lett å se klartekst i ASCII. Men når det er binære data (4D kan bety absolutt hva som helst) så er ASCII dumpen helt meningsløs.

[Giddion]

PS: Hvordan lærer man seg hvordan de forskjellige protokol-språkene fungerer?

MSN for eksempel.

Det er vel veldig få tutorialer på dette og?

 

Vel du kan jo prøve å Goooooogle det å se hva som kommer opp.

[Dark Fire]

@Giddion

Thanks mate!

Selv om jeg har nevnt Google flere ganger her, har jeg faktisk ikke prøvd det!

Jeg bare dro det opp for morro skyld!

MSN var et eksempel, og Google var åpenbart utelukket som et svar; det prøver jeg alltids først.

 

@0110100011100101011100100110010101101011

 

Jeg kan 0110001001101001011011101110011001110010, og jeg kan 686578.

 

Men poenget med å ikke bruke denne clear-teksten, er altså at folk ikke skal lage sine egne kopier osv av programmet?

En slags kryptering, om man skal kunne kalle det det?

For eksempelet ditt med en note fra en sang, passer virkelig ikke inn i bildet.

[Hårek]

Men poenget med å ikke bruke denne clear-teksten, er altså at folk ikke skal lage sine egne kopier osv av programmet?

En slags kryptering, om man skal kunne kalle det det?

For eksempelet ditt med en note fra en sang, passer virkelig ikke inn i bildet.

Jeg vet ikke hvilket bilde du har av hvordan ting fungerer, men det virker på meg som du har helt feil bilde. Det har overhodet ingenting med kryptering å gjøre.

 

Jeg kan gjøre et forøk til:

Når et program skal snakke med et annet program så kan det være hensiktsmessig å bruke ASCII. Det er en standard alle kjenner.

Men intern i et program brukes binær koding, da er ASCII ikke naturlig.

 

Eksempel tallet 1234 som ASCII og binær:

  Hex			 ASCII
31 32 33 34	   1234		  Her brukes ASCII
04 D2			 ..			Her er samme tallet som en 16-bit integer
D2 04			 ..			Samme, men annen byte order
00 00 04 D2	   ....		  Samme tallet, men som 32-bit integer
D2 04 00 00	   ....		  Samme, men annen byte order

 

Det jeg vil fram til er at du ikke kan ta en enkelt byte (eller en bokstav, eller en note) ut av sin sammenheng og forstå hva den betyr.

Endret 2. august 2008 av hårek

[Dead_Rabbit]

Det du ser i Wireshark er ikke programkode, det er informasjon som utveksles mellom to maskiner. Dette har som hårek sier overhodet ingenting med kryptering å gjøre. Dette handler om å overføre informasjon.. Hvis du åpner en bildefil med en teksteditor, vil du sannsynligvis se en masse dritt som du ikke forstår. Dette er fordi det ikke gir mening å representere et bilde som tekst. Du blir derfor nødt til å bruke et program som kan bruke informasjonen til å representere bildet som pixeler på skjermen din, og ikke som tekst.

[Dark Fire]

Jeg ser for meg at man kan programmere et bilde i binær ved å beskrive hver enkelt piksel's fargekode.

 

Med HTTP HEADERS, kan man lese http-pakker, ikke sant?

GET og POST.

Jeg tenkte at det var en måte å analysere pakkene man sender ut på samme måte, og de som blir sent inn. Et budskap har jo åpenbart alle pakker (untatt evt DoS), så spørsmålet er ikke om pakkene kan bli analysert, men hvordan.

 

Altså poenget mitt er at pakken er sendt fra et vilkårlig program, ta MSN messenger, over til MSN serveren, som et eksempel.

Både protokollen og serveren har jo da hver sin hensikt på dette området?

Protokollen prøver å si noe til serveren, og serveren hører på hva protokollen sier.

Og med Wireshark tyvlytter man på samtalen.

Problemet er jo da at de ikke prater norsk, right?

Endret 2. august 2008 av Dark Fire

[Dead_Rabbit]

HTTP headere er ikke et verktøy for å lese HTTP-pakker, nei. Det er heller en beskrivelse av en pakke som kommer. Jeg anbefaler at du leser en bok om hvordan internett fungerer egentlig. Og leser litt om hvordan filer og slikt fungerer også. Jeg vet ikke helt hva du mener med "at de ikke prater norsk". Enten så forstår man ikke protokollen, og du skjønner f.eks. ikke hva "GET /index.html" betyr, eller så gir det ikke mening å representere informasjonen som tekst, og du vil se en masse dritt. Evt. så er informasjonen kryptert.

 

Edit: Har ikke sovet på altfor lenge nå, så mulig jeg ikke skjønner spørsmålet eller at jeg bare er litt borte..

Endret 3. august 2008 av staalezh

[Dark Fire]

Om jeg bruker NetCat til å sende en GET request med kommandoen:

nc google.com 80

GET http://google.com/index.html

 

og kjører Wireshark på samme tid, og fanger opp denne ene pakken som blir sendt, så kan jeg oversette det som står i hex til det jeg nettopp skrev i netcat, ikke sant?

Nå orker ikke jeg å faktisk gjøre dette, siden jeg ikke akkurat er i humør right now, men hvordan ville Wireshark ha tolket pakken, da?

Ville pakken ha vært nettopp "GET http://google.com/index.html" i Hex?

Uansett så kunne man ha lest denne pakken, fordi man vet allerede hva pakkens hensikt er, og man kan da, på en eller annen måte, oversettet det.

Om dere til og med er uenig med det, gir jeg opp.

Enten forstår dere da ikke hva jeg mener, eller så er data/elektronik mere komplekst enn jeg noen gang kunne ha sett for meg (jeg er selv en hobby-kvantefysiker)

Endret 3. august 2008 av Dark Fire

[Hårek]

Nå er du litt slapp. Det ville jo vært enkelt å utføre.

 

Er selv slapp nok til ikke å gjøre det, men det er vel klart nok at du vil se det akkurat slik du sier. Det er fordi HTTP (som de fleste internett protokoller) går i klartekst (ASCII).

Det i motsetning til den pakken du viser i første innlegg, som er i binær form. Som jeg har vært inne på før, ASCII pakker er lett å lese, det er de binære som er problematisk.

[L4r5]

OffT: Wireshark er kos. Det er en ting å sniffe rene tekstfiler, men når man prøver å finne ut hva de forskjellige OSPF-pakkene osv. betyr så blir det morsomt.

[Dead_Rabbit]

Protokoller kan gjerne representeres i ASCII. Når du sender en GET-request, kan du derfor lese denne som "GET /blablaba" i Wireshark. Responsen trenger imidlertid ikke å være tekst; det kan være bilde/video/whatever. Dette gir det ikke mening å representere i ASCII.

 

Sjekk ut denne Ruby-koden:

Net::HTTP.start("static.flickr.com") { |http|
 resp = http.get("/92/218926700_ecedc5fef7_o.jpg")
 open("fun.jpg", "wb") { |file|
file.write(resp.body)
  }
}

Her sendes en HTTP GET request til static.flickr.com som ber om å få "/92/218926700_ecedc5fef7_o.jpg". Hvis dette var en tekstfil, hadde det vær mulig å se innholdet av fila når den ble overført. Siden det ikke er en tekstfil, blir det vanskelig.

[___]

Enten så kødder du med oss, eller så har du virkelig gått med rævva først inn i hele denne problemstillingen.

 

Du har hengt deg skikkelig opp i dette med heksadesimale tall. Jeg har vel sagt det en gang tidligere men jeg kan gjerne gjenta det: At du ser noe i hex, er fordi det verktøyet du bruker har bestemt seg for å vise det som hex.

 

En datastrøm inneholder data, ikke kroner og øre. Ikke pund eller zloty. Ikke dinarer eller yen. Men en strøm av nuller og enere.

 

At et eller annet verktøy viser data heksadesimalt, er at det er mer hensiktsmessig og mindre plasskrevende enn å vise bare nullere og enere.

 

Noen verktøy viser data i f.eks. 16 bytes pr linje i heksadesimal, etterfulgt av de samme 16 bytene, i ASCII. Der hvor innholdet av byten faller utenfor det som er skrivbare ASCII-tegn, vises f.eks. bare et punktum, eller ingenting i det hele tatt. Fordelen med en slik visning er at det er lett å spotte tekst. Det er fremdeles ingenting ved det jeg har forklart som insinuerer at filen INNEHOLDER heksadesimale tall, eller ASCII-verdier.

 

Du må skille innhold fra visning!

 

En datafil / datastrøm inneholder BYTES. En BYTE er en gruppering av 8 BITS. Og BYTES vises som heksadesimale verdier i binære editorer og andre lignende verktøy, fordi det er den mest HENSIKTSMESSIGE måten å vise dem på.

 

Så å si at en fil inneholder heksadesimale tall er feil. En fil, uansett om det er en plain ASCII-fil, en JPEG-fil, eller en MP3-fil, inneholder BYTES. Den eneste gangene man kan si at en fil inneholder heksadesimale tall, er:

 

-Du har skrevet dem i klartekst i en ASCII-fil.

-Du har skrevet dem i klartekst i Microsoft Word.

-Du har tegnet de heksadesimale tallene, i f.eks. Microsoft Paint

-Du har lest de inn på en lydfil via mikrofon.

 

Osv, osv.

 

Håper du ikke ble altfor forvirret av de siste eksemplene mine.

 

Werner

Endret 3. august 2008 av wernie

[cyclo]

OffT: Wireshark er kos. Det er en ting å sniffe rene tekstfiler, men når man prøver å finne ut hva de forskjellige OSPF-pakkene osv. betyr så blir det morsomt.

Enig der. Satt og brukte masse tid på google maps mobile protokollen her forleden, for deretter å oppdage at en eller annen dust hadde allerede gjort det (selvfølgelig).

[Dark Fire]

@Wernie

Jeg har aldri sagt at filen inneholder heksidesimale verdier, og om du har tolket det sånn, får det nesten være ditt issue; jeg har aldri ment det.

Wireshark viser heksidesimale og ASCII-verdier.

Disse er en oversetting fra de egentlige binære verdiene, right?

 

Jeg har skjønt nå, som var hele spørsmålet fra starten av, at det ikke er et "språk" for pakker som blir sent, fordi det er relativt til hvor pakken skal sendes; hvilke software som skal lese pakken, men jeg har forstått det riktig når jeg sier at jeg selve pakken representerer noe (vanligvis; ikke nødvendigvis), som blir lest av softwaren på den andre siden?

Hvordan fungerer egentlig dette?

Softwaren på andre siden er jo også bare 0 og 1; hvordan handler de med hverandre?

Blir det et ganske enkelt "mattestykke", hvor informasjonen som blir sent, legges sammen med informasjonen på den andre siden?