- Stato
Ultima modifica:
l'alfa 36nh con chipset ralink3070 è una buona scheda ,ma comunque di certo non la migliore in assoluto per queste operazioni,comunque l'handshake lo cattura ,solo che come dicevo prima le prestazioni sono meno elevate rispetto ad altri chipset,quindi con rxq e pwr basso si possono riscontrare dei problemi,i chipset migliori sono gli atheros su tutti (specialmente uno ar9271) ma anche realtek 8187l ,comunque continua a provare si puo riuscire lo stesso ,poi un'ultima cosa stai lavorando su virtual machine o direttamente sul pc,perchè con le macchine virtuali con la 36nh almeno io personalmente ho riscontrato problemi ,meglio usarla sul pc in live o persistence mode.
Ultima modifica:
uso kali linux in live 
comunque sei geniale, abbassare il rate a 1Mbps per avere meno perdita di pacchetti.
-update-
stavo provando e niente di meno la scheda mi si è bloccata (led fisso), ad ogni modo aggiornare i driver della scheda su kali linux gioverebbe alla cattura?
comunque sei geniale, abbassare il rate a 1Mbps per avere meno perdita di pacchetti.
-update-
stavo provando e niente di meno la scheda mi si è bloccata (led fisso), ad ogni modo aggiornare i driver della scheda su kali linux gioverebbe alla cattura?
uso kali linux in live
comunque sei geniale, abbassare il rate a 1Mbps per avere meno perdita di pacchetti.
-update-
stavo provando e niente di meno la scheda mi si è bloccata (led fisso), ad ogni modo aggiornare i driver della scheda su kali linux gioverebbe alla cattura?
sui driver non saprei dirti di preciso ,io c'è l'ho pure la 36nh ma non ho mai aggiornato i driver ,anche perchè la uso poco,uso di più una 36h e 36nha ,che secondo me sono migliori,però provare non costa nulla,potrebbe essere che i nuovi driver abbiano migliorato le prestazioni,anche se credo che su kali 2016.1 siano già aggiornati.
infatti dovrei scaricare kali 2016..
comunque credo di aver dei problemi non tanto con l'ap (RXQ=100) ma con il client, se non lo vedo associato in airodump dici che non riusciro' ad ottenere un handshake? oppure inviando segnali di deauth al broadcast ci posso riuscire?
Ti riferisci al power del client? Se l'ap lo prendo bene non dovrei prendere bene anche il client, poiché dovrebbe essere vicino l'ap. Oppure ci vuole maggiore sensibilità a intercettare un client rispetto ad un ap?
no la distanza dei client e quella dall'ap sono due cose diverse,non è automatico che avendo un segnale buono di uno l'avrai anche dell'altro,magari navigano lontano dal modem con pc portatile o cell android,i client devono essere raggiungibili dai pacchetti di aireplay,-1 significa che sono fuori portata e senza client come ti hanno già detto niente stretta di mano.
Ultima modifica:
Quindi ovvio che i pacchetti che manda il client sono più "deboli" rispetto un router / ap
-- update --
Purtroppo il client associato all'ap (ap che ha RXQ=100) ha PWR=0 e RATE=1e- 1 (cosa significa 1e- 1 ?). Non vedo più possibilità di ottenere l'handshake
Al contrario se un ap ha RXQ=0 ma PWR=-69 e il client associato ha PWR=-74 ho qualche possibilità?
Analizzando i pacchetti noto qualcosa che non mi quadra: nonostante io mi sia concentrato su uno specifico client cioè l'unico che appariva come associato e quindi ogni tanto inviavo un segnale di deauth (però il power del client era a 0), mi sono accorto che gli unici messaggi eapol (1 di 4 e 3 di 4) sono stati indirizzati ad un altro client che non appariva nella finestra di airodump. Com'è possibile?
Altra domanda. Ho fatto delle foto ai due messaggi eapol rispettivamente 1 of 4 e 3 of 4. Ci sono abbastanza info per craccare handshake? Cosa manca in particolare?
-- update --
Purtroppo il client associato all'ap (ap che ha RXQ=100) ha PWR=0 e RATE=1e- 1 (cosa significa 1e- 1 ?). Non vedo più possibilità di ottenere l'handshake
Al contrario se un ap ha RXQ=0 ma PWR=-69 e il client associato ha PWR=-74 ho qualche possibilità?
Analizzando i pacchetti noto qualcosa che non mi quadra: nonostante io mi sia concentrato su uno specifico client cioè l'unico che appariva come associato e quindi ogni tanto inviavo un segnale di deauth (però il power del client era a 0), mi sono accorto che gli unici messaggi eapol (1 di 4 e 3 di 4) sono stati indirizzati ad un altro client che non appariva nella finestra di airodump. Com'è possibile?
Altra domanda. Ho fatto delle foto ai due messaggi eapol rispettivamente 1 of 4 e 3 of 4. Ci sono abbastanza info per craccare handshake? Cosa manca in particolare?
Il client non manda nessun pacchetto, poiché li scambia con il punto di accesso wireless. I pacchetti di entrambi vengono poi catturati dalla tua scheda di rete wireless. Il PWR è a 0, perché probabilmente hai inviato troppi pacchetti di deautenticazione. Il rate, sarebbe la velocità massima teorica che la tua scheda di rete vede raggiungere dal client (in questo caso 1 Mbps). Non hai alcuna possibilità di catturare la WPA handshake in entrambi i casi da te sopracitati.
Ultima modifica:
durante questo scambio che avviene tra ap e client ovviamente l'ap avrà più potenza di tramissione (passatemi il termine) rispetto a un dispositivo quale un telefono perchè sprovvisto di antenne, questo era quello che volevo dire.
ps aumentando il tx power della mia scheda potrebbero esserci miglioramenti?
il txpower migliora il segnale in trasmissione della scheda non ricezione,quindi credo che potrebbe migliorare si sensibilmente la deautenticazione di aireplay ,ma ci vuole comunque nun buon segnale,poi l'alfa 36nh puo arrivare anche a 32 db cioè + 2000 mw ma vanno modificati i crda e wireless regb ,ma su kali 2016.1 non se si puo fare,io avevo provato solo su kali 2.0.
ho finalmente trovato dei client associati con un buon PWR però l'ap a cui sono associati ha uno strano ESSID: <length: 0> così non posso inviare il deauth. mi chiedo a cosa serva l'ESSID se già ho il BSSID. Poi questo ap è sul canale 133! qualcuno mi spieghi
il length significa che il ssid è celato cioè la rete non trasmette il nome e solo con airodump si puo vedere nei rilevamenti ,oppure è una cosa momentanea ,mi è capitato pure a me che una rete diventasse celata e poi ritornava trasmesso il nome vero,mentre per il canale mi sembra strano, 133 non esiste ,i canali nella freguenza/banda 2.4 ghz vanno da 1 a 13 ,controlla meglio forse ti sei confuso con un'altro valore.
davvero, non mi sono confuso. comunque ho uno screen con lo stesso BSSID stavolta con il suo ESSID e sul canale 5..
t
era 133, sicuro
nel frattempo sono riuscito ad avere un handshake tra l'ap con il problema del BSSID di cui ho parlato prima (ma con RXQ=0) e il client associato con un buon PWR. ho utilizzato wifite che e' riuscito a inviare segnali di deauth al client (manualmente con airerplay non ci sono riuscito sempre per il problema del BSSID di cui ho parlato sopra e cioe':
root@kali:~# aireplay-ng --deauth 1 -a 14:CC:20
5:8E:5B mon0
16:59:45 Waiting for beacon frame (BSSID: 14:CC:205:8E:5B) on channel 6
16:59:55 No such BSSID available.
Please specify an ESSID (-e).
adesso vorrei craccarlo, non ho la pi\ pallida idea di quanto tempo occorra, non ho un dizionario e sarei propenso a postare il mio handshake su qualche forum dove qualcuno cracchi per me. datemi un consiglio.
root@kali:~# aireplay-ng --deauth 1 -a 14:CC:20
5:8E:5B mon016:59:45 Waiting for beacon frame (BSSID: 14:CC:20
5:8E:5B) on channel 616:59:55 No such BSSID available.
Please specify an ESSID (-e).
adesso vorrei craccarlo, non ho la pi\ pallida idea di quanto tempo occorra, non ho un dizionario e sarei propenso a postare il mio handshake su qualche forum dove qualcuno cracchi per me. datemi un consiglio.
Я
Яǝʌǝɹsǝ
Ho provato con wifite ma ci mette un sacco di tempo.
Oppure tu intendi calcolare il pin?
no intende ricavare il pin dal mac address ,questo https://www.inforge.net/xi/threads/tp-link-pin.450352/ ,però mi sembra funzioni solo su un modello specifico di modem ,leggi bene il post pure le pagine successive.
Я
Яǝʌǝɹsǝ
Ultima modifica:
caro bob79 ho utilizzato wifite perche' non ero riuscito a inviare un deauth manualmente con airodump, l'ho anche spiegato nel mio post!ci hai detto tutto a quanto sei interessato a imparare
per quanto riguarda l'attacco wps ho utilizzato questo comando:
reaver -i mon0 -b 14:CC:20
5:8E:5B -c 5 - vv - p 13995611che mi ha prodotto questo:
[+] Waiting for beacon from 14:CC:20
5:8E:5B[+] Associated with 14:CC:20
5:8E:5B (ESSID: Wi-Fi XXX)sto ancora aspettando da mezz'ora che finisca, ci vuole ancora tanto tempo?
dimenticavo, il power dell'ap e' 35db, puo' bastare?
ps non sono riuscito ad eseguire il comando airodump-ng mon0 --wps --manufacturer perche' --wps non lo riconosce come parametro.
- Stato
DISCUSSIONI SIMILI
-
- 4
-
- 797
-
- 0
-
- 373