Wifi ցանցերի վերլուծության փոքր գործիք ստեղծելու մտահղացումը ինձ մոտ առաջացավ .
Շնորհակալություն նրանց գաղափարի համար։ Ես հենց այն ժամանակ զբաղվելու բան չէի ունենում։
Աշխատանքը կատարվել է որպես հոբբի՝ նպատակ ունենալով երիտասարդանալ և ստանալ փորձառություն ցանցային տեխնologien领域: Մարշիկորեն, շաբաթական 1-4 ժամ, այս տարվա սկզբից։
Առավելապես կիրառում նախատեսված չէ: Առանցքային է, որ սա hacker-ի գործիք չէ։
Ներկայիս գիտական ֆունկցիաները աշխատում են: Ավելին, բոլոր սկզբնաղբյուրները, որոնք պատրաստ են հավաքման, Այ那里 էլ կա հավաքման ցուցագիր և այլն։ Այս հոդվածում ես չեմ կրկնակի տեղեկատվությունը, որը թողնված է github-ում։ Դուրս կբերեն միայն այն, ինչը կարծում եմ, պետք է թարգմանել առանձին։
Իմ կարծիքը "ալդո-գործի" մասին և ESP32-ի ընտրության պատճառը
Ես չեմ առաջադառնում ճշգրտության: Այն յուրաքանչյուրյանում տարբեր է։ Փորձեմ հիմնավորել իմ ընտրությունը "հալեցում"։
արդյունքը Linux (պատահաբար Raspberry Pi) + "պերիպերիա" ի տես STM32- контролլեր + CC1110 (8051 ядром) տարբերակի համակցումը, որը պետք է հաջողվի դրա մեջ ամեն ինչ մտցնել (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) ինձ համար անբավարար է։ Սակայն, Ծանոթների նման հսկայական մնալու է (flipper-zero github "Այս կազմակերպությունը չունի հանրային ռեպոզիտորներ.") և գնացի ավելի քիչ տարածված ապարատների ճանապարհը:
Հնարավոր է, որ սխալվում եմ, և կաթված-արա, հեղինակները կթողնեն ծրագրային ապահովման սկզբնաղբյուրները։ Բայց եթե ոչ, ապա ես նման ապարատ ձեռք չեմ առնի առանց սկզբնաղբյուրի։
Իմ պահանջները "գործիքի"
Պատկերասեղանը պետք է փոքր լինի (մինչև նվազագույնի):
Այդ իսկ պատճառով՝
- Ինքնաուժեղ բեռն անհրաժեշտ չէ: Wifi-ի աշխատանքում ավելի քան 100 mA հոսանքի պայմաններում, ինքնաուժեղ բեռը կամ մեծ կլինի, կամ չափազանց երկար չի տևի։ Այդ պատճառով թող "փոքրիկ պետք է միացվի ստանդարտ նկարահանման սարքի միջոցով կամ էլ առկա նկարահանող սարքն իմ գրպանում/մեքենայում միշտ կգտնվի։
- Պետք է պահպանել "փոքրիկում" Linux-ով սարքեր, առաջին հերթին բազմաթիվ լեզվերով բազմաթիվ տարիների համար փոքրիկ էկրանով և սահմանափակ կառավարման մետաղակտորի հետ ոչ մի օգտագործման իմաստ չկա։ Արդյունքները կարելի է դիտել/փորձել և նորմալ նոթբուքում՝ լիարժեք ստեղնափոփոխությամբ և էկրանի շուրջ։
- Կազմակցությունները պետք է լինեն հեշտ տեղահատանք և հայտնի (հասանելի SDK, շատ օրինակներ և փաստաթղթեր):
Այսպիսով, ինձ համար ընտրությունը ակնառու էր` ESP32:
Հոդվածի շրջանակներում նշված բոլոր խնդիրներին ESP32-ի հնարավորությունները բավական են։ Իհարկե, ավելորդ է, որ ես կարող եմ միայն փորձարկել:
- Bluetooth-ի հետ խաղալ։
- 433mHz հատվածի հետ փորձարկել պարզ սարքերի միջոցով (միայն ալիքային մոդուլացնում, ինչն էլ բավարար է շուրջանակ դիմումների համար):
ESP32-ում մի վատ կողմ
- SDK (IDF) ESP32 մի փոքր կիսանկարում է։
- Ֆունկցիոնալության մի մասը (Wifi ստեկտոր, օրինակ) գալիս է առանց սկզբնաղբյուրների որպես հավաքված ունիպային գրադարաններ։
- 5gHz диапазոնը միSupported չէ, եւ WiFi-ի աշխատանքում կան որոշ սահմանափակումներ եւ հարթություն:
Բայց գինը/չափերը բավականաչափ փոխհատուցում են այս թերությունները:
Ծրագրային ապահովման հիմնական ֆունկցիաները:
Կարճ կպատմեմ ֆունկցիայի եւ իմ կարծիքի մասին:
Կարգավորումների կառավարումը եւ ֆայլերի բեռնման գործընթացը SD-ից:
Բոլոր արտաքին կառավարման գործընթացները կատարվում են պարզ Web էջի միջոցով, որը սկսվում է ապրանքանիշի մենյուի առանձին կետում: ESP32-ն սկսվում է WiFi AP ռեժիմում եւ տրամադրում է էջը պինդ IP հասցեով:
Չնայած ESP32-ի միջուկները բավական արագ են, սակայն փորձերը ցույց տվեցին, որ ներկառուցված Web ծառայության եւ, օրինակ, ռոուտերի ռեժիմի համատեղ աշխատանքը միանշանակ չէ: Այդ պատճառով, դինամիկ կառավարման ռեժիմ չկա, եւ բոլոր մնացած ռեժիմներում էջը մատչելի չէ:
Հատկապես, որ հետազոտական նպատակներով դինամիկ կառավարումը հարկավոր չէ:
Beacon տուփերի հետ աշխատանքային ռեժիմ:
Ռեժիմները սովորական եւ ոչ հետաքրքիր են: Ավելացված են «ինչպես կարելի է» սկզբունքով: Ցուցանիշի համար:
Օրինակներ կան պաշտոնական Espressif օրինակներում:
AP-ների ցանկերը սկանավորելու ռեժիմ:
Դրան կարող է ցանկացած սմարթֆոն:
Այս ռեժիմում պահպանվում է AP-ների ցանկ:
Beacon Spam-er:
ESP32-ն սկսվում է որպես AP՝ գաղտնի SSID-ով եւ պատահական MAC-ով եւ սկսում է ուղարկել [beacon frame] նախապես ստեղծված SSID ցուցակից (ձեռնարկված կամ ստացված AP-ների ցանկից):
WiFi փաթեթների sniffing ռեժիմ:
Espressif-ի մշակողները ավելացրել են հնարավորությունը, որ հավելվածային ծրագրերը կարող են callback ֆունկցիայի միջոցով ստանալ բոլոր WiFi փաթեթները «օդում անցնող»: Այսինքն բոլորը չէ, որովհետեւ հնարավոր է սահմանել ռեժիմ միայն մեկ պինդ ալիքով:
Callback ֆունկցիայի գործառույթի վրա սահմանվում են շատ խիստ ժամանակային սահմանափակումներ: Եթե պարզ վիճակագրություն հավաքելու ռեժիմը խնդիրներ չի առաջացնում, ապա PCAP ֆայլի գրելն SD քարտում կազմակերպելու համար անհրաժեշտ էր որոշակի ժամանակ պահանջել, կազմակերպել գրանցումը հիշողության հերթով եւ սեմաֆորներով: Նշելով, որ ֆունկցիան, որը գործում է callback վերադառնում, անցնում է մեկ միջուկով, իսկ SD-ում գրող գործընթացը՝ մյուսով:
Հեռահարովի «ցնցված» ալիքի պատճառով որոշ փաթեթներ կորցվում են (ընտրանի հերթը տեղ չի ունենում եւ հեռանում են), բայց, երբ տարածքը սովորական «ալիք» գիշերային (5..7 AP տեսադիտման շրջանակի մեջ), գրությունը PCAP-ով կատարվում է առանց փաթեթների pertes:
Ավելացնում՝ PCAP մոնիտորինգի եւ գրանցման համար MAC-ի ցանկերի միջոցով ֆիլտրելու ռեժիմ:
Օրինակ, կարելի է հետևել մարդու հայտնվելուն ակումբում/թեյարանում, մինչև նա ընդմիշտ մտնելուց կամ հայտնվելուց: Քիչ կան, ովքեր WiFi-ն մեկնում ու ավտոմատորեն միանում են հայտնի AP-ներին: (Ես հիմա մեկնում եմ..)
Wireshark-ում գրանցված տրաֆիկը դիտելը հետաքրքրաշարժ է ու ուսուցողական, որպեսզի հասկանալ ինչպես է այն իսպառու:
Deauth փաթեթներով աշխատանքային ռեժիմ:
Ավտոմատ կերպով, այս փաթեթների փոխանցումը արգելված է libnet80211.a գրադարանում, որը հասանելի է առանց աղբյուրների։ Սակայն դա հեշտ է կրճատել, փոխելով մի քանի բիթ։ Բeginning, ես կասկածում էի, թե արդյոք արժե հրապարակել patch-ը։ Բայց տեղ-տեղ անցնելով ռադիոտածման աղբյուրները [deauthentication frame], ես մտածեցի՝ «ինչո՞ւ ոչ»։ Եվ առավել ևս, որ esp8266–ում այս փաթեթների փոխանցումը փակված չէ, և github-ում esp8266-ի համար հանդիպում են հավաքումներ։
Դուք գիտե՞ք, որտեղ շատ տեղերում (ճիշտ չեմ ասի որտեղ) օգտագործվում է undesirable AP-ների ճնշումը այս մեթոդով։ Եվ դա չի վերաբերվում «թույլ տվածներին»…
Միևնույն ժամանակ, ես դեռ կարոտել էի, որ իմ հեռախոսից ինտերնետը տեղ-տեղ չի աշխատում…
Այդ փաթեթների քանակի և RSSI-ի հետախուզական ռեժիմը շատ օգտակար է հասկանալու համար՝ «որտեղ չեն սիրում լևե AP-ները»։
Ռաութերի ռեժիմ
Այս ֆունկցիան, կարծես թե, ամենաս интересная из всех для исследования։
ESP32-ը կարող է միաժամանակ աշխատել STA + SoftAP ռեժիմներում։ Այն posibilit разрабатывать классический NAT router։
Espressif-ի ցանցային դիագրաֆը աջակցում է lwip գրադարանի fork-ը (շատ քիչ փոփոխություններով)։
Բայց, ավտոմատ կերպով, ստանդարտ հավաքման մեջ, esp-lwip գրադարանում ‘ap’ (SoftAP) և ‘st’ (STA) ցանցային ինտերֆեյսների միջեւ տարանցում չի նախատեսվել։
Իհարկե, կարելի է անել նաև առանց NAT-ի, սակայն առաջանում է դժվարություն ‘ap’ ինտերֆեյսին միացում ունեցող երկու և ավելի STA-ների միաժամանակյա կապի հարցում և IP հասցեների սինխրոնիզացմամբ ‘st’ ինտերֆեյսից ‘ap’։ Այս պատճառով դժվարությունները լավ չեն արդարացնում, և ավելի հեշտ է օգտվել NAT-ից։
Մնում է, որ գոյություն ունի martin-ger-ի կողմից esp-lwip-ի fork, որտեղ ավելացված է IP4-ի համար պարզ NAT իրականացում։
Թեև իմ ձեռքերն ուզում էին վերափոխելն այդ տեսքով (իմ կարծիքով, ավելի հեշտ էր առանց fork նախագծի, և LWIP–ի միջոցով)HOOK ֆունկցիաները, որոնք որոշվում են հավաքման ժամանակ), բայց ժայլի է հաղթեց, և martin-ger-ի տարբերակը օգտագործվում է այնպես, ինչպես կա։
Ռաութերի ռեժիմում դիտվում է մուտքային և ելքային IP4 տրաֆիկը։
Հատուկ, դա դուրս է բերվում էկրանին ցույց տալու և统计统计文件收集的信息：
- Ամրագրված սարքի անուն, որը միացել է ESP32 SoftAP-ին (DHCP փաթեթներ)
- Սկիզբը DNS հարցումների (UDP պորտ 53) URL-ը միացած ESP32 SoftAP-ի սարքից։
Լրացուցիչ կարող եք միացնել տրաֆիկի գրանցումը PCAP ֆայլում։
Այս ռեժիմը շատ օգտակար է, օրինակ, հասկանալու համար, թե ինչ է ձեր հեռախոսը ուղարկում ցանց և թե ուր է գնում։
Կարող եք մտածել նաև այլ օգտագործման միջոցներ այս ռեժիմի համար, հաշվի առնելով, որ համամբաց միտումնային կերպով կառավարել SoftAP ESP32-ին մուտքային և ելքային տրաֆիկը ցանցային ինտերֆեյսի մակարդակում： Ehernet պիտակ (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DCHP և այլ type)।
Հիմնականում, ESP32-ն բավականին լավ է կատարում WiFi->WiFi ռաութերի ֆունկցիան, առանց հատուկ ուշացումների անցկացնելով պարզ տրաֆիկը։ Սուբյեկտիվորեն, ESP32-ի միջոցով ռաութերում միացած հեռախոսում ուշացումներ ճանաչելի չեն։
Դաժանաբար պետք է նշեմ, որ Espressif API-ում անհնար է MAC-ով անցնել SoftAP EPS32-ով միացողների ֆիլտրացիա: Այս փոխարեն առաջարկվում է ասել «հրաժեշտ» (esp_wifi_deauth_sta) արդեն միացած STA-ներին, որոնք «անհրաժեշտ չեն»:
MAC ֆիլտրացիա միացող STA-ների համար իրականացվում է esp_wifi_deauth_sta() կանչելու միջոցով
Ընդհանուր առմամբ
Մինչև հիմա նոր բան չեմ մտածել ESP32-ի վերաբերյալ, սակայն հնարավոր է, որ որոշ մարդկանց (source-ները) արդյունքը հետաքրքրի:
Կցանկանայի նշել, որ կոդը գրել եմ բացառապես ուսումնական նպատակներով: «թափանցիկ» լինելու համար այն մասնագիտորեն ստեղծվել է այնքան էլ հարմարավետ:
Տպագրվող վահան չեմ ստեղծել, քանի որ արդեն պատրաստված վահանակների մալուխով մշակումն իմ վրա տևեց 1.5-2 ժամ:
Այստեղից էլ, եթե անելու են, ապա պետք է պատրաստված վահանակների փոխարեն հավաքել առանձին բաղադրիչներից: Այդ դեպքում չափերը կլինեն դեռ ավելի փոքր:
Ընտանիք: habr.com
