Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
AbonnerSkjul
Host1.no - Webhotell fra 29,-, virtuell server fra 249,-. 15% rabatt med rabattkode "nFF". Besøk oss på Host1.no!
  5 1448
method139
5 0
7. januar 2010
Hei,

Etter å ha sett noen av Lena151 sine video tutorials om Reverse Engineering, bestemte jeg meg for å teste ut det jeg hadde lært. Jeg fant et gammelt program fra 1998 (beskyttelsen var svakere da, så tenkte det var et bra sted å starte) og satte igang med å trace meg gjennom det med Olly Debugger. Great success - jeg forbedret til og med programmet en smule ved å endre det slik at det lagrer filer med lowercase ending (hater uppercase i filnavn).

Nå lurer jeg på hvordan man oppdager svakheter i programmer - buffer overflow og liknende. Bruker man debuggere til dette også?
Glyserol
92 45
8. januar 2010
Sitat av method139 Vis innlegg
Nå lurer jeg på hvordan man oppdager svakheter i programmer - buffer overflow og liknende. Bruker man debuggere til dette også?
Vis hele sitatet...
Det er vel mulig å finne en potensiell buffer overflow med bare en disassembler, men tror man må være ganske klar i hodet for å oppdage en eller annen overflow uten å sjekke eller teste. En debugger er vel egentlig helt nødvendig hvis du skal lage en exploit ut av det.

Lena sine tutorials er vel greie til et viss punkt. Man lærer vel ikke egentlig helt hva man gjør i de(Hvorfor manipulering av flags fungerer som de gjør/Hvorfor de blir satt slik av programmet). Ikke for å si at de er dårlige, Lena gjorde en god jobb og tutorialene hennes veldig nybegynner vennlige.

Sitat av method139 Vis innlegg
Jeg fant et gammelt program fra 1998 (beskyttelsen var svakere da, så tenkte det var et bra sted å starte) og satte igang med å trace meg gjennom det med Olly Debugger. Great success - jeg forbedret til og med programmet en smule ved å endre det slik at det lagrer filer med lowercase ending (hater uppercase i filnavn).
Vis hele sitatet...
Stillig. RE(Reverse Engineering) er en fantastisk kunnskap og gir deg en del mer kontroll over programmer.
saroth
731 78
8. januar 2010
Ved buffer overflows pleier man som oftest å kjøre programmet i en debugger, fuzze det, og se hva du har klart å overskrive når det krasjer. Har du klart å overskrive EIP, kan du få få programmet til å hoppe dit du vil i minne, f.eks. dit du har lagt en shellcode.
Carrier Return
Carrier Return's Avatar
294 132
10. januar 2010
Hvis du vil teste for buffer overflows, sjekk ut:

SPIKE
Sully Fuzzer

Disse er veldig bra på nettverksbasert fuzzing. Altså der du kommunserer mot en port på en annen maskin.
En stor fordel er å sette opp en pcap og logge vanlig trafikk først. På denne måten vet du hvilke kall fuzzeren må gjøre først for å komme inn mot applikasjonen du skal teste. Så du ikke begynner med ftp kommandoer mot en mailserver (for å illustrere problemet).

Deretter kan du be fuzzerne begynne å teste når applikasjonen har kommet til det punktet der den forventer generell input. Altså der tjenesten forventer data, etter at sesjonen er etablert.

En fordel med Sully, er at den kan wrappe en vmware sesjon på maskinen din, og hver gang den merker at den har crashet applikasjonen du tester så lagrer den en pcap av det den gjorde og restarter vmware imaget før den fortsetter.

Sully har også utrolig god protokollforståelse, og det er ikke noe problem å f.eks. teste mailservere (smtp protokollen) eller enda mer avanserte servertjenester der man må sende mange kommandoer frem og tilbake før man kan begynne å sende data.

Mer på:
http://fuzzing.org/
Sist endret av Carrier Return; 10. januar 2010 kl. 18:27. Grunn: La inn link til fuzing site
[lc]lamerlord
98 93
11. januar 2010
Har du en debugger som sjekker hvilke funksjoner programmet kaller (istedet for en addresse) kan du sjekke om den sender bruker spesifisert data igjennom dårlige funksjoner som sprintf, strcat, strcpy etc..

andre måter er som sagt å fuzze, altså å sende halveis tilfeldig data inn i alle "innganger" til programmet, som for eksempel stdin, program parametere (argv[]), filer som det eventuelt skulle lese og sjekke om programmet krasjer og %eip eller %ebp er overskrevet.

eller du kan få tak i mindre populære open source programmer og lese igjennom kildekoden etter sprintf, strcat, strcpy og elendig kode som "while(*ptr != '\0') {ptr ++; *ptr = *otherptr;}". Hvis du finner dårlig kode i open source programmer kan du fikse dem og bli elsket av richard stallman(aka julenissen)
▼ ... over en uke senere ... ▼
method139
Trådstarter
5 0
18. januar 2010
Takk for tipsene. Jeg kjøpte et par bøker om dette emnet:

"Writing Security Tools and Exploits"
"Open Source Fuzzing Tools"