Sain idean tehdä taskutyökalu WiFi-verkkojen analysointiin .
Kiitos heille ideasta. Minulla ei vain ollut mitään tekemistä.
Kaikki työ tehtiin osana harrastusta hauskanpidon ja verkkoteknologioiden tietämyksen laajentamisen vuoksi. Hitaasti, 1..4 tuntia viikossa, tämän vuoden alusta.
En suunnitellut mitään käytännön käyttöä. Nuo. Tämä EI ole hakkerin työkalu.
Tällä hetkellä kaikki suunnitellut toiminnot toimivat. Kaikki lähteet, täysin valmiina koottavaksi, . Siellä on myös kokoamisohjeet jne. Tässä huomautuksessa en kopioi githubissa julkaistuja tietoja. Kerron vain sen, minkä katson tarpeelliseksi kuvata erikseen.
Oma mielipiteeni "yleistyökalusta" ja ESP32:n valinnan syystä
En väitä olevani totuus. Jokaisella on omansa. Yritän perustella laitteistovalintani.
Linuxin (alun perin Raspberry Pi) + "oheislaitteiden" yhdistelmän käyttötapaus ohjaimen (STM32) + CC1110:n (8051 ydin) muodossa ja suunnitelma ahtaalla kaikki mahdollinen (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) ei vaikuttanut sopivalta minulle. Kuitenkin, Näyttää siltä, että se pysyy yksityisenä ja suljettuna (flipper-zero github "Tällä organisaatiolla ei ole julkisia tietovarastoja.") ja siirtyi harvoin yleiseen laitteistoon.
Ehkä olen väärässä, ja tulevaisuudessa tekijät asettavat ohjelmistolähteet julkisesti saataville. Mutta jos ei, en ostaisi sellaista laitteistoa ilman lähdekoodia.
Vaatimukseni "työkalulle"
Laatikon tulee olla pieni (mitä pienempi sen parempi).
siksi:
- Sisäänrakennettua akkua ei tarvita. Kun virta on > 100 mA Wifi-yhteyden kanssa työskennellessä, sisäänrakennettu akku on joko suuri tai ei kestä kauan. Anna siksi "laatikon" saada virtansa tavallisesta virtapankista. Joka tapauksessa minulla on aina taskussa/autossa virtapankki.
- Pidä Linuxin "laatikko" työkaluineen sisällä, kirjoitettu useiden vuosien ajan kaikilla kielillä Pienellä näytöllä ja niukalla ohjauspainikkeilla ei ole mitään järkeä. Tuloksia voi tarkastella/käsitellä tavallisella kannettavalla tietokoneella, jossa on täysi näppäimistö ja näyttö.
- Komponenttien tulee olla helposti saatavilla ja laajalti tunnettuja (saatavilla oleva SDK, monia esimerkkejä ja dokumentaatiota).
Tämän seurauksena valinta oli minulle ilmeinen - ESP32.
ESP32:n ominaisuudet ovat aivan riittävät kaikkiin artikkelissa mainittuihin tehtäviin, jotka saivat minut ryhtymään toimiin. Vaikka eniten haluan vielä tehdä:
- Pelaa Bluetoothilla.
- Pelaa 433 MHz:n alueella yksinkertaisimmalla laitteistolla (vain amplitudimodulaatio, joka riittää käytännön tarpeisiin).
Helposti ESP32:ssa
- ESP32 SDK (IDF) on hieman kömpelö.
- Osa toiminnoista (esimerkiksi WiFi-pino) tulee ilman lähdekoodia koottujen staattisten kirjastojen muodossa.
- 5 gHz:n taajuutta ei tueta, ja WiFin kanssa työskentelyyn liittyy joitain rajoituksia ja kömpelyyttä.
Mutta hinta/koko kompensoi täysin nämä puutteet.
Ohjelmiston päätoiminnot
Kuvaan lyhyesti toimintoja ja mielipiteeni...
Asetusten hallinta ja tiedostojen lataaminen SD:ltä
Kaikki ulkoinen ohjaus tapahtuu yksinkertaisen Web-sivun kautta, joka käynnistetään erillisessä valikkokohdassa. ESP32 käynnistyy WiFi AP -tilassa ja näyttää sivun kiinteällä IP-osoitteella.
Vaikka ESP32-ytimet ovat melko nopeita, kuten kokeet ovat osoittaneet, sisäänrakennetun verkkopalvelun ja esimerkiksi reititintilan samanaikainen toiminta eivät ole kovin yhteensopivia. Siksi dynaamista ohjausta ei ole, eikä sivu ole käytettävissä kaikissa muissa tiloissa.
Lisäksi dynaamista ohjausta ei tarvita tutkimustarkoituksiin.
Toimintatapa Beacon-pakettien kanssa
Tilat ovat banaalisia eivätkä kovin mielenkiintoisia. Tehty "koska se on mahdollista". Tarkistaa varten.
Esimerkkejä on virallisissa Espressif-esimerkeissä.
AP-luettelon skannaustila.
Itse asiassa mikä tahansa älypuhelin voi tehdä tämän.
No, tässä tilassa AP-luettelo tallennetaan.
Beacon roskapostittaja.
ESP32 alkaa tukiasemana, jolla on piilotettu SSID ja satunnainen MAC, ja alkaa lähettää [majakkakehys] valmiiksi luodun SSID-luettelon mukaisesti (luodettu manuaalisesti tai saatu aiemmin skannaamalla tukiasemaluettelo).
WiFi-pakettien haistelutila
Espressif-kehittäjät ovat lisänneet sovellusohjelmistoille mahdollisuuden vastaanottaa kaikki "ilmassa lentävät" WiFi-paketit takaisinsoittotoiminnon kautta. Itse asiassa ei kaikki, koska voit asettaa tilan vain yhdelle kiinteälle kanavalle.
Takaisinsoittotoiminnon käsittelylle on asetettu erittäin tiukat aikarajoitukset. Jos tämä ei aiheuta ongelmia yksinkertaisessa tilastonkeruutilassa, niin PCAP-tiedostojen tallennustilassa SD-kortilla jouduin näpertämään ja järjestämään tallennuksen muistin ja semaforien jonon kautta. Ottaen huomioon sen erikoisuuden, että takaisinsoittoa kutsuva prosessi toimii yhdessä ytimessä ja prosessi, joka kirjoittaa SD:lle toisessa.
”Meluisen ilman” aikana osa paketeista katoaa (jonossa ei ole tilaa ja ne heitetään pois), mutta tyypillisellä asunnon ”ilmalla” illalla (5...7 AP:tä näkyvyyden sisällä), tallennus PCAP:iin. valmistuu ilman pakettihäviöitä.
Lisäksi PCAP-valvontaa ja -tallennusta varten on suodatustila, joka perustuu MAC-luetteloon pakettiotsikoissa.
Voit esimerkiksi seurata henkilön ilmestymistä klubiin/kahvilaan ennen kuin hän edes tulee sisään tai ilmestyy näkyville. Harvat ihmiset poistavat käytöstä WiFi-yhteyden ja automaattiset yhteydet tunnettuihin tukipisteisiin. (Poistan sen nyt pois päältä..)
Tallennetun liikenteen katseleminen Wiresharkissa on opettavaista ja mielenkiintoista karttojen ymmärtämisen kannalta – kaikki toimii.
Tila death-pakettien kanssa työskentelyyn
Oletusarvoisesti näiden pakettien lähettäminen on kielletty libnet80211.a-kirjastossa, joka tulee ilman lähteitä. Mutta se on helppo korjata säätämällä paria bittiä. Aluksi epäilin, kannattaako korjaustiedoston julkaiseminen. Mutta kävellessäni eri paikoissa autentikointikehyksen skannaustilan ollessa päällä, ajattelin: "mitä helvettiä." Lisäksi esp8266:ssa näiden pakettien toimitus ei ole suljettu ja githubissa on kokoonpanoja esp8266:lle.
Monissa paikoissa (en sano missä) käytetään ei-toivottujen tukipisteiden estämistä tällä menetelmällä. Ja nämä eivät ole "kiusaajia"...
Ja yllätyin myös siitä, että Internet-jakelu puhelimestani ei toiminut joissain paikoissa...
Tällaisten pakettien lukumäärän ja RSSI:n seurantatila on erittäin hyödyllinen, jotta voidaan ymmärtää, "missä vasemmanpuoleiset tukiasemat eivät pidä siitä".
reititintila
Tämä ominaisuus on luultavasti mielenkiintoisin tutkittava.
ESP32 tukee samanaikaista käyttöä STA + SoftAP -tilassa. Siksi voit toteuttaa siihen klassisen NAT-reitittimen.
Verkkopinon tukemiseksi Espressif käyttää lwip-kirjaston haarukkaa (käytännössä muuttumattomana).
Mutta oletuksena vakiokoontiversiossa esp-lwip-kirjasto ei tarjoa edelleenlähetystä netif-rajapintojen "ap" (SoftAP) ja "st" (STA) välillä.
Tietysti voit tehdä sen ilman NAT:ia, mutta kahden tai useamman STA:n yhdistäminen samanaikaisesti "ap"-liitäntään ja IP-osoitteiden synkronointi "st"-verkkoliitännästä "ap"-liitäntään aiheuttaa ongelmia. Joten vaikeudet eivät ole sen arvoisia, ja se on helpompaa NAT: n kautta.
Lisäksi martin-geristä löytyy haarukka esp-lwip, joka lisää yksinkertaisen NAT-toteutuksen IP4:lle.
Vaikka käteni kutisivat tehdä sen uudelleen puhtaasti kosmeettisesti (mielestäni se oli helpompaa ilman projektin haarukkaa, mutta LWIP:n kauttaHOOK kokoonpanon aikana määritellyt toiminnot), mutta laiskuus voitti ja martin-gerin vaihtoehtoa käytetään sellaisenaan.
Reititintilassa tarkastellaan tulevaa ja lähtevää IP4-liikennettä.
Siitä poimitaan erityisesti seuraavat tiedot näytölle näyttämistä ja tilastotietojen keräämistä tiedostoon:
- SoftAP ESP32:een (DHCP-paketit) yhdistetyn laitteen nimi
- URL DNS-pyynnöistä (UDP-portti 53) SoftAP ESP32:een yhdistetystä laitteesta.
Lisäksi voit ottaa käyttöön liikenteen tallennuksen PCAP-tiedostoon.
Tämä tila on erittäin hyödyllinen esimerkiksi sen ymmärtämiseksi, mitä puhelimesi lähettää verkkoon ja minne se menee.
Voit ajatella muita tapoja käyttää tätä tilaa ottaen huomioon kyvyn hallita täysin softAP ESP32:n tulevaa ja lähtevää liikennettä verkkorajapinnan tasolla: Ehernet-otsikko (destMAC[6]+srcMAC[6]+tyyppi[2]) + hyötykuorma (IP4, IP6, DCHP jne. tyyppi).
Periaatteessa ESP32 pärjää varsin hyvin WiFi->WiFi-reititintoiminnon kanssa, kulkee normaalin liikenteen läpi ilman erityisiä viiveitä. Subjektiivisesti ESP32:n reitittimen kautta yhdistetyn puhelimen viiveet eivät ole havaittavissa.
Valitettavasti Espressif API:lla ei ole mahdollisuutta asettaa suodatinta SoftAP EPS32:een liitetylle MAC:lle. Sen sijaan ehdotetaan sanottavan "näkemiin" (esp_wifi_deauth_sta) jo yhdistetyille STA:ille, joita "ei haluta".
MAC-suodatus yhdistetyille STA:ille oli tehtävä esp_wifi_deauth_sta() -kutsun kautta
lopuksi
Vaikka en keksinyt mitään uutta ESP32:n kanssa työskentelyn puitteissa, ehkä tulos (lähdekoodi) on mielenkiintoinen jollekin.
Haluan huomauttaa, että koodi on kirjoitettu yksinomaan koulutustarkoituksiin. "Hakkerointia" varten jne. se tehtiin tarkoituksella ei kovin käteväksi.
Piirilevyä en tehnyt, koska valmiiden huivien juottaminen langalla kesti 1.5-2 tuntia.
Ja jos teet, sinun ei tarvitse koota se valmiista levyistä, vaan yksittäisistä komponenteista. Silloin mitat ovat vielä pienemmät.
Lähde: will.com