Die idee om 'n sakinstrument te maak vir die ontleding van WiFi-netwerke het my aangespoor .
Dankie aan hulle vir die idee. Ek het net niks gehad om te doen nie.
Alle werk is as 'n stokperdjie gedoen met die doel om pret te hê en my kennis op die gebied van netwerktegnologie uit te brei. Stadig, 1..4 uur per week, sedert die begin van hierdie jaar.
Toepassingsgebruik is nie beplan nie. Dié. dit is NIE 'n hacker-instrument nie.
Op die oomblik werk al die beoogde funksionaliteit. Alle bronne, heeltemal gereed vir montering, . Daar is ook monteringsinstruksies, ens. In hierdie nota sal ek nie die inligting wat op github geplaas is, dupliseer nie. Ek sal jou net vertel wat ek nodig ag om afsonderlik te beskryf.
My mening oor die "universele instrument" en die rede vir die keuse van die ESP32
Ek beweer nie die waarheid nie. Elkeen het haar eie. Ek sal my keuse van "yster" probeer regverdig.
die opsie om 'n kombinasie van Linux (oorspronklik Raspberry Pi) + "randapparatuur" te gebruik in die vorm van 'n kontroleerder (STM32) + CC1110 (8051 kern) en 'n plan om alles wat moontlik is te prop (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) daarin het nie vir my geskik gelyk nie. Maar dit lyk of dit privaat en gesluit sal bly (flipper-zero github "Hierdie organisasie het geen publieke bewaarplekke nie.") en het na nie te algemene hardeware gegaan nie.
Miskien is ek verkeerd, en in die toekoms sal die skrywers die bronkode van die sagteware in die publieke domein uitlê. Maar indien nie, dan sal ek nie so 'n stuk yster sonder bronkodes koop nie.
My gereedskapvereistes
Die boks moet klein wees (hoe kleiner hoe beter).
daarom:
- Ingeboude battery is nie nodig nie. Met 'n stroom > 100 mA wanneer jy met Wifi werk, sal die ingeboude battery óf groot wees, óf dit sal nie lank hou nie. Laat die "boks" dus deur 'n standaard kragbank aangedryf word. Tog het ek altyd 'n kragbank in my sak / kar.
- Hou binne die "boks" Linux met gereedskap, geskryf oor baie jare in alle tale in die teenwoordigheid van 'n klein skerm en 'n karige stel beheerknoppies maak dit geen sin nie. Die resultate kan op 'n gewone skootrekenaar met 'n volledige sleutelbord en skerm bekyk/verwerk word.
- Komponente moet geredelik beskikbaar en wyd bekend wees (beskikbare SDK, baie voorbeelde en dokumentasie).
As gevolg hiervan was die keuse vir my voor die hand liggend - ESP32.
Vir al die take wat in die artikel genoem word, wat my aangespoor het om op te tree, is die ESP32-vermoëns genoeg. Alhoewel dit die meeste is wat ek wil doen:
- Speel rond met Bluetooth.
- Speel rond met die 433mHz-reeks met die eenvoudigste hardeware (slegs amplitudemodulasie, wat genoeg is vir praktiese behoeftes).
Vlieg in die salf in ESP32
- SDK (IDF) ESP32 is ietwat lomp.
- Deel van die funksionaliteit (die WiFi-stapel, byvoorbeeld) kom sonder bronkodes in die vorm van saamgestelde statiese biblioteke.
- Die 5GHz-band word nie ondersteun nie en daar is 'n paar beperkings en lompheid om met WiFi te werk.
Maar die prys / grootte vergoed ten volle vir hierdie tekortkominge.
Die hooffunksie van die sagteware
Ek sal kortliks die funksionaliteit en my mening oor ...
Bestuur instellings en laai lêers op vanaf SD
Alle eksterne beheer word gedoen deur 'n eenvoudige webblad wat in 'n aparte kieslys-item bekendgestel word. ESP32 begin in WiFi AP-modus en vertoon 'n bladsy op 'n vaste IP-adres.
Alhoewel die ESP32-kerne redelik vinnig is, maar, soos eksperimente getoon het, meng die gelyktydige werking van die ingeboude webdiens en, byvoorbeeld, die router-modus nie goed nie. Daarom is daar geen dinamiese beheer nie en in alle ander modusse is die bladsy nie beskikbaar nie.
Boonop is dinamiese beheer nie nodig vir navorsingsdoeleindes nie.
Werk met Beacon Packages
Modusse is banaal en nie baie interessant nie. Gemaak "omdat jy kan". Vir tjek.
Daar is voorbeelde in die amptelike Espressif-voorbeelde.
AP lys skandering modus.
Eintlik kan enige slimfoon dit doen.
Wel, in hierdie modus sal die lys AP's gestoor word.
Beacon spammer.
ESP32 begin as 'n AP met 'n versteekte SSID en 'n ewekansige MAC en begin [baken raam] stuur op 'n voorafgeskepte SSID lys (met die hand geskep of vroeër verkry deur die AP lys te skandeer)
WiFi-snuifmodus
Espressif-ontwikkelaars het die vermoë bygevoeg vir toepassingsagteware om alle WiFi-pakkies "wat in die lug vlieg" te ontvang deur 'n terugbelfunksie. Trouens, nie almal nie, aangesien jy die modus vir slegs een vaste kanaal kan stel.
Baie streng tydsbeperkings word opgelê vir die verwerking van 'n terugbelfunksie-oproep. As dit vir die modus van eenvoudige statistiekinsameling nie probleme veroorsaak nie, dan moes ek vir die modus om 'n PCAP-lêer na 'n SD-kaart te skryf, peuter, die opname organiseer deur 'n tou in geheue en semafore. Met inagneming van die eienaardigheid dat die proses wat die terugbeloproep op een kern draai, en die proses wat na SD skryf in 'n ander.
Met 'n "lawaaierige lug" gaan sommige pakkies verlore (daar is geen spasie in die tou nie en hulle word weggegooi), maar met 'n tipiese "lug" van 'n woonstel in die aand (5..7 AP's binne sig), skryf aan PCAP het tyd om te voltooi sonder pakkieverlies.
Daarbenewens, vir PCAP-monitering en -opname, is daar 'n filtermodus gebaseer op die MAC-lys in die pakkieopskrifte.
Byvoorbeeld, jy kan die voorkoms van 'n persoon in 'n klub / kafee dophou, voordat hy selfs in die gesigsveld ingekom of verskyn het. Min mense skakel WiFi en outomatiese verbindings na bekende AP's af. (Ek skakel dit nou af..)
Om aangetekende verkeer in Wireshark te sien is insiggewend en interessant om die kaarte te verstaan, dit werk alles.
Werkswyse met doodspakkies
Die stuur van hierdie pakkette is by verstek verbode in die libnet80211.a-biblioteek, wat sonder bronne kom. Maar dit is maklik om te stop deur 'n paar aas reg te stel. Aanvanklik het ek getwyfel of dit die moeite werd was om pleister op te laai. Maar nadat ek op verskillende plekke rondgeloop het met die [ontautentiseringsraam]-skanderingmodus geaktiveer, het ek gedink: "wat de hel." Verder, in esp8266 is die stuur van hierdie pakkette nie gesluit nie en daar is samestellings op github onder esp8266.
Op baie plekke (ek sal nie sê waar nie) word ongewenste AP-onderdrukking deur hierdie metode gebruik. En dit is nie "hooligans" nie ...
En ek was steeds verbaas dat dit my verspreiding van die internet vanaf my foon was wat op plekke nie gewerk het nie ...
Die dopmodus van die nommer en RSSI van sulke pakkies is baie nuttig om te verstaan "waar die linker AP's nie hou nie."
router-modus
Hierdie kenmerk is waarskynlik die interessantste van almal om te verken.
ESP32 ondersteun gelyktydige werking in STA + SoftAP-modus. Daarom is dit moontlik om 'n klassieke NAT-roeteerder daarop te implementeer.
Om die netwerkstapel te ondersteun, gebruik Espressif 'n (feitlik onveranderde) vurk van die lwip-biblioteek.
Maar by verstek, in die standaardsamestelling, in die esp-lwip-biblioteek, is daar geen aanstuur tussen die netif-koppelvlakke 'ap' (SoftAP) en 'st' (STA).
Natuurlik kan jy dit sonder NAT doen, maar daar is 'n probleem met die gelyktydige verbinding van twee of meer STA's aan die 'ap'-koppelvlak en sinchronisasie van IP-adresse van die netwerkkoppelvlak 'st' na 'ap'. Die kompleksiteit is dus nie die moeite werd nie en dit is makliker deur NAT.
Boonop is daar 'n vurk esp-lwip van marting-ger wat 'n eenvoudige implementering van NAT vir IP4 byvoeg.
Alhoewel my hande gejeuk het om dit suiwer kosmeties oor te doen (na my mening was dit makliker sonder 'n vurkprojek, maar deur LWIPHOOK bou-gedefinieerde funksies), maar luiheid het gewen en die marting-ger-weergawe word gebruik soos dit is.
In roeteerdermodus word inkomende en uitgaande IP4-verkeer bekyk.
Dit word veral daaruit onttrek om op die skerm te vertoon en statistieke in 'n lêer te versamel:
- Toestelnaam wat gekoppel is aan SoftAP ESP32 (DHCP-pakkies)
- URL van DNS-navrae (UDP-poort 53) vanaf 'n toestel wat aan SoftAP ESP32 gekoppel is.
Daarbenewens kan jy die opname van verkeer in 'n PCAP-lêer aktiveer.
Hierdie modus is baie nuttig, byvoorbeeld om te verstaan, byvoorbeeld, wat jou foon na die netwerk stuur en waarheen dit gaan.
Jy kan aan ander maniere dink om hierdie modus te gebruik, met inagneming van die vermoë om SoftAP ESP32 inkomende en uitgaande verkeer op die netwerkkoppelvlakvlak heeltemal programmaties te beheer: Ehernet-kopskrif (destMAC[6]+srcMAC[6]+tipe[2]) + loonvrag (IP4, IP6, DCHP, ens. tipe).
In beginsel hanteer die ESP32 die WiFi->WiFi-roeteerderfunksie redelik goed, en stuur gereelde verkeer sonder veel vertraging deur homself. Subjektief is vertragings in 'n foon wat via 'n router aan die ESP32 gekoppel is, nie opmerklik nie.
Ongelukkig, in die Espressif API is daar geen manier om 'n filter te stel deur MAC gekoppel aan SoftAP EPS32. In plaas daarvan word voorgestel om "totsiens" (esp_wifi_deauth_sta) te sê vir reeds gekoppelde STA's wat "nie gesoek word nie".
Filtrering deur MAC vir gekoppelde STA's moes gedoen word deur 'n oproep na esp_wifi_deauth_sta()
Ten slotte
Alhoewel ek met niks nuuts vorendag gekom het binne die raamwerk van werk met ESP32 nie, sal iemand dalk in die resultaat (bronne) belangstel.
Ek wil daarop let dat die kode uitsluitlik vir opvoedkundige doeleindes geskryf is. Vir "hacking", ens., is dit spesiaal gemaak nie baie gerieflik nie.
Ek het nie 'n gedrukte stroombaan gemaak nie, want dit het 1.5-2 uur geneem om die voltooide serpe met 'n draad te soldeer.
En as jy dit doen, moet jy dit nie van klaargemaakte planke saamstel nie, maar van individuele komponente. Dan sal die afmetings nog kleiner wees.
Bron: will.com