Høres artig ut, har en pc som står for det meste og idler med 3stk geforce 9800GTX kort.

Skal tho ikke på tg i år. .

har vært i fjellet mange av påskens dager, skal få sendt ut info til alle som har sendt meg epost nå snart så fort jeg kan.

*mail mottatt*

Som jeg mener jeg sa i tråden så kan jeg stille med datakraft.
Om vi skulle trenge en informasjonserver/wiki kan jeg også stille med hosting og domene til dette. Men så tidlig i prosjektet som vi er nå tror jeg vi klarer oss med denne tråden.

Hvordan ligger prosjektet ann?

Blueshift: er det du som tar ansvar for arbeidsfordelingen/"arbeidsliste"?

Har dere andre postlister enn det som har vært skrevet her på forumet? Dere bør i alle fall prøve å få samlet og organisert ressursene som skal være med på dette på et vis. Samtidig hoste opp en form for prosjektplan og se an hvem som skal være ansvarlig for hvilke deler av prosjektet.

Skjema og beskrivelse av systemet bør også bli produsert, noenlude viktig hvis noe slikt blir utviklet med internett som eneste kommunikasjonsmedium.

Forstår det slik at det må utvikles systemer for å kunne gjennomføre dette. Har dette blitt kartlagt på noe vis?

Jeg kan hjelpe til med evt. kode som må skrives hvis dere trenger det

Ja, da er det på høy tid å få startet dette prosjektet, men jeg har bare mottat info om hva de kan bidra med fra halvparten av de som meldte seg på til å begynne med. Hadde vært kjekt om alle kunne maila meg for sikkerthets skyld slik at jeg får med hva alle kan bidra med, slik at det blir lettere å dele ut arbeider, og lage ei arbeids liste. Folk som har erfaring innen programmering; har noen av dere tips til hvilket programmerings språk som ville få dette til å flyte best? Hva må til for å utnytte GPU? Som sagt må vi få bilen på veien; og for at dette skal skje må alle være med helst

Jeg er ikke helt sikker på om dette er den beste måten å gjøre det på. Sånn som jeg ser det så er den eneste måten å starte et ikke-kommersielt open source prosjekt med flere deltakere at en eller annen setter seg ned og begynner å kode. Rett og slett, kode, noe å vise til, noe som kan føre til et produkt. Sånn som det er nå så er det bare en gjeng som driver å snakker løst og fast om ting og stiller sine ressurser til disposisjon, mens det dere egentlig trenger er noen som kan programmere skiten for dere.

Jeg ville startet med en klient som kan drive å bruteforce, så når denne begynner å bli mer eller mindre brukbar så lager man en tjener som kan koordinere arbeid mellom flere klienter. Før en grunnleggende arkitektur som dette er på plass er brukere, vevtjenere, domener, båndbredde og avsatt maskinkraft nytteløst, og alle som ikke kan bidra med kode er, sånn som jeg ser det, beklageligvis overflødige på dette stadiet.

Begynn å kode!

En ganske grei ide faktisk, vi trenger bare rett og slett at folk som er kompetente starter å kode noe, slik at vi får et utgangspunkt.

Det blir mye lettere å distributere versjoner, forslag og nyheter om vi holder oss til denne tråden her, så om alle kan gjøre dette hadde det vært kjekt.

Vi er på en tidlig fase av prosjektet, og har mye å gjøre, men vi har problemer også, vi kan ikke planlegge i hytt og pine enda, da vi ikke vet hva vi kommer til å ende opp med rent cracker messig. Da det viktigste er å få til dette for de som er kompetente til å programmere noe slikt, setter vi dette som prio 1.

For andre som ikke driver med programmering, men fortsatt vil hjelpe til, er det ikke så mye dere kan gjøre på dette stadiet, bortsett fra ideer til det web baserte kansje.

Alle ideer blir godt motatt, skal det web baserte være noe ala. et torrent system, med ratios etc?

Som sagt er det viktig at vi får noe å jobbe med i dette stadiet, og dette er under construction av flere forum members as we speak. Det skal bli spennende å teste noe av det som kommer frem, og det ser ut som at dette kan bli en success!!

Skal det være windows eller linux?
Trodde det ble avklart om det skulle være ratio system på den første eller den andre siden, jeg forsto det nå hvertfall slik at vi skulle ha det.
Vet ikke men tror det kanskje kunne være en ide og dele prosjektet opp i 4 grupper?
eks. gruppe 1 lager websiden, gruppe 2 lager alt av design til alt, gruppe 3 lager server siden og gruppe 4 client siden.

Hmm...
Vel jeg tror det vi bør gjøre først er ikke å starte med å kode. Blir fort rot. Vi bør tenkte litt lurere og planlegge hva vi trenger.

Hva trenger klienten og hva trenger serveren?
Jeg tror ikke vi trenger å bry oss om programvaren skal kjøre på windows/linux/os x/bsd osv. Kan alltids lage programmer til hver enkelt OS.

Klienten må kunne ta imot en liste, wordliste eller en oversikt over antall tegn som klienten skal brute force med og hva den skal brute force. Serveren må ha oversikt over alle brutte passord samtlig med hvilke tegn/ordlister som er brukt på hver enkelt. Den må også kunne utdele og holde oversikt over alle klienter og hvem som gjør hva.

For å prøve å holde en litt bedre oversikt.

Klient:
- Bør vel lages i C/C++ og for å utnytte GPU er det vel CUDA vi skal ty til. Verdt å merke seg at python støtter CUDA(Se PyCUDA) som kan være greit for linux/bsd/os x.
- Ta imot liste eller avgrenset område for brute force(Eksempel: a-i, fra 5 til 6 tegn)
- Sende tilbake enten om den fant riktig passord og i såfall hvilke slik at server kan få andre klienter til verifisere passordet, eller at den ikke har funnet og er enten klar til å ta imot nye lister eller er ferdig og skal ikke ta imot mer.

Server:
- Når det kommer til utviklingen se lenger ned.
- Skal ha oversikt over klienter, hvilke klient som brute forcer med hvilke ordliste eller gitt antall tegn(Se eksempel under klient).
- Skal kunne ha oversikt over alle WPAer som er brutt og de som ikke er.

Selve serveren kan skrives i php/ruby, men C/C++ burde også gå. Har sett på en del parallel prosjekter som BOINC, men det blir kanskje litt mye for hva vi trenger. Skader ikke å sjekke det ut og eventuelt teste det.

Bare å pynte på med hva som trengs eller ikke trengs under klient/server. Viktigste for nå er å vite hva vi trenger og hvor det trengs.

Selve prosjektet høres artig ut, men dette er ikke noe som blir gjort over natta og vil nok ta en liten stund før den blir ferdig(Nå er vel utviklingen spennende også :-).

Som Tias påpeker må bare noen som er kompentente begynne i en ende, og få opp noe kode. Dersom det går rette veien vil nok flere hive seg på, da dette sikkert er noe som er attraktivt for ganske mange på teh internets. Dessverre kan jeg ikke kode selv, så jeg stiller meg på sidelinjen foreløpig, men jeg støtter idéen og lover å dele GPU. Håper dere får noe kode opp, slik at det blir noe virkelighet i snakket. Lykke til

Even better:

Sett sammen 'et styre' av de med mest kompetanse, la de sette opp regler, forutsetninger, rammer, krav. Begyn så smått med et Open Source-prosjekt, deretter vil andre henge seg på!

vi har nok av server med faste ip'er, så 0 problem der. fast ip er ikke noe og tenke på. er mere og få alt til og funke først.

Ok, da sitter jeg på en HELT basic shit.

Kobler til serveren og teller fra angitt nr til 9999.. bare for å teste litt.
Tenkte jeg skulle lage en bruteforce versjon med maks 4bokstaver nu.
Cya tonight

Jeg håper virkelig ikke du mener det er likegyldig hvilket språk det er skrevet i? Jeg ville unngått stack intensiv databehandling i php.

Dette høres fornuftig ut, å dele ut ansvaret på 4 pers gjør at det blir lettere å få en rask start, da en person kan fokusere mer på spesifikke ting, enn at en styrer alt. Jeg har fått epost fra folk som har lyst å være med å organisere, og litt kompetanse kreves innen et felt for å kunne organisere dette.

Da er det vel rimelig greit det altså, vi kjører oss opp i 3/4 grupper;

• Web Interface, for brukere til å kommunisere med tjenesten, denne kan deles opp i design og web koding om det blir aktuelt.
• Server siden, her den delen som skal motta data fra klienter og behandle den slik at den blir brukbar.
• Client siden, da det er her en god del av jobben ligger med tanke på programmering som skal kunne fungere sømløst med en server, slik at sammarbeidet ikke krever manuelt inngrep for å fungere på en grei måte. Regner med at det kan kreves til å begynne med dog, men det da.

Det virker fornuftig at planlegging er et fornuftig neste steg, så å få delt inn grupper slik hadde vært kjekt.

Etter hvert som at vi får en virkende versjon av clienten, og noen får sett på serverene, slik at vi har noe som liksom funker, vil dette sannsynligvis fatte interesse hos langt flere, og dette er vel et stadie som er ønskelig for oss å nå.

Kommer til å følge med i tråden, IRC kanal hørtes ikke dårlig ut, avtale et felles tidspunkt vi kan møte opp helts i løpet av morgendagen, kveldstid om mulig, så blir det lettere å ha en live diskusjon om hvordan ting bør kjøres.

Bare husk at det aller viktigste er er optimaliseringer for å bruke paralellprosesseringen en grafikkprosessor har å gi. Skriver du kun noe helt basic med nøstede løkker i C for så å semiporte det til CUDA vil det gå altfor tregt til at det er noe vits i.

Det aller første bør være å lage algoritmer, det er bare helt basic lineær algebra, så burde ikke ta lange tiden. I tillegg kan det være greit å teste litt om hva som faktisk er raskest på den spesifike plattformen, jeg vil tippe MIMD, men ikke sikker der.

Jeg kan ihvertfall som jeg nevnte på mail hjelpe til med kode (hovedsaklig i Ruby, men kan litt C++ osv også).
Så ihvertfall web koding, jeg er helt forferdelig på design.

Men hvis vi først kommer igang med dette foreslår jeg at evt. data som skal hentes fra serveren av websiden bør gjøres tilgjengelig fra et slags REST-api (xml output)

Er vel en fordel hvis dette er i windows siden flere kan benytte dette da.

det er vel en fordel hvis det kodes med tanke på alle platformer. ihvertfall nå først for linux og windows Burde gå bra I ruby/C#/C++

eller Python, det funker på mange platformer

Folk som foreslår språk å skrive client programmet i; skriv Pros and cons liste også slik at det kan diskuteres av flere på et helt annet nivå enn c++ folk vs. python folk.

Er vel mest spørsmål om hvilket språk som er raskest til disse oppgavene

tenkte jeg kunne legge til den linken her

http://www.digi.no/811186/skal-utnyt...i-datamaskinen

Hva om en del av oss møtes rund 22:00ish i kveld på #nff, så ser vi hvor vi tar ting nærmere derfra?

Hva om dere bare joiner #nff.dwpac ? (Distributed wpa cracker)

Da har en del av oss samlet oss på IRC (irc.efnet.org #nff.dwpac).

Vi har begynt å snakke litt om hvordan dette bør gjøres og hva ting skal kodes i.

Har ikke kommet fram til så mange svar enda, men vi er vel så smått igang.

Folk får komme på IRC å snakke, eller snakke her.

Sovetid for min del \o

Vel, det har vært lite informasjon på forumet i det siste, så vi får ta en aldri så liten oppdatering. I tillegg tenkte jeg å si litt om metodene som benyttes i wpa autentiseringen, og å belyse noen av problemene vi står ovenfor.

Så langt har vi fått snekra sammen kode som genererer PMKs på GPU i form av et lite benchmarking program som viser hvor mange PMKs skjermkortet ditt klarer å generere i sekundet. I tillegg holder ranvik på med å sette opp server som vi kan benytte til lagring av rainbow tabellene. Vi er altså langt unna noe ferdig system. Flere som kunne tenke seg å bidra?

For å enklere kunne belyse noen problemer er jeg først nødt til å forklare litt hvordan WPA-PSK fungerer. WPA-PSK (Pre-shared key) er som dere sikkert vet et system for å passordbeskytte tilgang til et trådløsnettverk. WPA-PSK benytter en algoritme kalt PBKDF2 (Password-Based Key Derivation Function) for å regne ut PMK (Pairwise Master Key) fra pre-shared key og SSID på nettverket. Dette betyr at vi må ha en database over PMKs for hver SSID. PMK blir senere brukt til å generere andre nøkler.

PBKDF2 anvender en pseudorandom funksjon (f.eks en kryptografisk hash-funksjon, eller HMAC) på et passord og en salt-verdi, og repeterer denne prosessen tusenvis av ganger for å generere en nøkkel. I WPA er passordet=pre-shared key og salt-verdi=SSID. Pseudorandom funksjon som blir benyttet er HMAC-SHA, og prosessen repeteres 4096 ganger. Dette er årsaken til at det er komputasjonelt krevende å knekke WPA. (Husk; dette må gjøres for hver eneste nøkkel vi lagrer i tabellen, og dem blir det mange av)

PMK er dessverre ikke slutten på kapittelet. For å faktisk opprette en kobling til trådløsruter må klienten kommunisere med ruter i et 4-way handshake. Det genereres da en PTK (Pairwise Trancient Key) basert på PMK, to nonce-verdier (number used once, tilfeldig tall) og MAC-adressene til klient og ruter. Algoritmen som benyttes til dette kalles SHA1-PRF.

Til sist kalkuleres en verdi kalt MIC fra de første 16 bytene i PTK og EAPoL-data (EAP over LAN).

Blandt alle disse verdiene kan vi finne MIC, EAPoL, nonce-verdiene og MAC-adressene ved å sniffe 4-way handshake idet tilkoblingen opprettes. Til dette kan vi anvende programmer som f.eks aerodump.

Problemet blir nå å finne pre-shared key fra disse data. Hvis vi på forhånd har en database med passord og tilsvarende PMK's for et gitt SSID, så kan vi benytte disse data til å generere en MIC verdi og sammenligne med den som vi har i 4-way handshake. Er de like så har vi PMK og pre-shared key, og WPA er cracket

Så, første utfordring blir å programmere et distribuert system som genererer PMKs som lagres i en sentral database. Server kan generere "slots" over en range med passord som klient skal generere PMKs for. Andre utfordring blir å faktisk søke i databasen. Den som søker må oppgi data fra 4-way handshake, kanskje i form av capture fila fra aerodump. Problemet nå er at det vil ta lang tid å søke i databasen fordi vi må gjøre en del komputasjoner for å regne ut MICs som vi skal sammenligne med referansedata. På grunn av dette vil jeg anslå at et søk i databasen, med tilhørende beregninger, kun er 2000-4000 ganger kjappere enn å generere PMK. Med en svæær database kan dette ta tid. Spørsmålet blir så om vi skal lage et system for å distribuere søket også. Dette vil isåfall kreve mye båndbredde hos server, da den må sende ut blokker med PMKs til klientene.

Kommentarer anyone?

ved og ha pkm's så vil du kune søke med ca 500'000 i sek isteden for 1000 hvis du skule generet alt sammen selv.
så akuratt foreløpig er ikke det store problemet, kom og med forslage og lage en torrent pr ssid som folk kan joine for og søke selv.
jeg føler at det er første biten med pkm som må løses først.

hvis alt går greit og prosjektee kommer så langt at vi kan kjøre p2p måten på søk mellom tabelen så er det mye mer jobb, enn det første.


For dem som ikke skjønte det, så er pkm keys det som bruker mest cpu for og genere.

Blir vel kanskje en god del enklere hvis dere basserer det på pyrit?
http://code.google.com/p/pyrit/

er det noen som har kommet videre med prosjekte ?

ja starta litt på det ja, var litt problemer med disk plass hvis vi skal ha så veldig mange ssid'er og forsjelige wpa kombinasjoner. men vi har tenkt ut annen løsning alle må bare få tid til og starte. dem som har tid til og programere blei litt mer opp tatt med router prosjekte mitt for den måten kan vi skafe oss en sikelig password liste som er ekte.

er dette prosjektet lakt på is eller?

I bunn og grunn: Ja! Det er veldig lite aktivitet atm, men hovedproblemet som gjorde at vi stoppet var at vi trengte noe sånt som 8 petabyte hdd plass for å lagre hashes på decent-sized passphrases.

ikke glem at det er pr ssid da.

Kan ikke alle som har en HDD som de ikke bruker, sende den til ranvik elns da?:P Så kan han sette opp en svær lagringsstasjon eller noe. :P

for leit, har fulgt med i spenning nesten helt siden tråden ble startet

Vi fant jo rimelig fort ut at det ikke er noe særlig prosjekt å holde på med på hobbybasis, og at vi ikke kan få tak i den slags hardware gratis.

I tillegg er det vel bortimot umulig å finne sponsorer til et prosjekt som vil egentlig A) Kun være til de bytter ut WPA med noe bedre, og B) Faktisk muliggjør cracking av wpa keys på et helt annet nivå enn før...


Muligheten er jo alltids der hvis vi lagrer mindre data og heller bruker mer tid på regenerere data, men da vil ikke løsningen bli like rask som den kunne ha blitt.

flexh vi har jo værtfall server, ellers må folk joine med disk + cpu kraft.