На думку зрабіць кішэнную прыладу для аналізу WiFi сетак мяне падштурхнула .
Дзякуй ім за ідэю. Мне якраз не было чым заняцца.
Уся праца была выканана ў рамках хобі з мэтай атрымання задавальнення і пашырэнні сваіх ведаў у галіне сеткавых тэхналогій. Не спяшаючыся, па 1..4 гадзіны на тыдзень, з пачатку гэтага года.
Прыкладное выкарыстанне не планаваў. Г.зн. гэта НЕ інструмент для хакера.
На дадзены момант увесь задуманы функцыянал працуе. Усе зыходнікі, цалкам гатовыя для зборкі, . Там жа інструкцыя па зборцы і інш. У дадзенай нататцы я не буду дубляваць інфармацыю, выкладзеную на github. Раскажу толькі тое, што лічу патрэбным апісаць асобна.
Маё меркаванне з нагоды "універсальнай прылады" і чыннік выбару ESP32
Я не прэтэндую на ісціну. Яна ў кожнага свая. Паспрабую абгрунтаваць свой выбар "жалеза".
варыянт выкарыстання спалучэнне Linux (першапачаткова Raspberry Pi) + "перыферыі" у выглядзе кантролер (STM32) + CC1110 (ядро 8051) і план упіхнуць туды ўсё што толькі можна (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) здаўся не прыдатным для мяне. Зрэшты, падобна так застанецца прыватным і зачыненым і пайшоў у бок не занадта распаўсюджанага жалеза.
Магчыма я не мае рацыю, і ў далейшым аўтары выкладуць зыходнікі ПЗ у адкрыты доступ. Але калі не, то я б такую жалязяку без зыходнікаў не купіў бы.
Мае патрабаванні да "інструменту"
Скрыначка павінна быць маленькая (чым менш, тым лепш).
таму:
- Убудаваны акумулятар не патрэбен. Пры току > 100 mA пры працы з Wifi, убудаваны акумулятар альбо будзе вялікі, альбо яго хапае не на доўга. Таму няхай "скрыначка" сілкуецца ад стандартнага power bank. Усё роўна power bank у кішэні/машыне валяецца ў мяне заўсёды.
- Трымаць ўнутры "скрыначкі" Linux з інструментамі, напісанымі за шмат гадоў на ўсіх мовах пры наяўнасці дробнага экрана і беднага набору кіраўнікоў кнопак сэнсу няма. Вынікі можна глядзець/апрацоўваць і на нармальным ноўтбуку з паўнавартаснай клавіятурай і экранам.
- Кампаненты павінны быць даступнымі і шырока вядомымі (даступны SDK, шмат прыкладаў і дакументацыі).
У выніку, для мяне, выбар быў відавочны - ESP32.
Пад усе задачы, заяўленыя ў артыкуле, які падштурхнуў мяне да дзеянняў, магчымасцяў ESP32 цалкам хапае. Хоць максімум што я хачу яшчэ зрабіць гэта:
- Пагуляць з Bluetooth.
- Пагуляцца з 433mHz дыяпазонам з найпростым hardware (толькі амплітудная мадуляцыя, чаго дастаткова для практычна патрэб).
Лыжка дзёгцю ў ESP32
- SDK (IDF) ESP32 некалькі караў.
- Частка функцыяналу (стэк WiFi, напрыклад) ідзе без зыходнікаў у выглядзе сабраных статычных бібліятэк.
- Не падтрымліваецца дыяпазон 5gHz і ёсць некаторыя абмежаванні і каранасці па працы з WiFi.
Але кошт/памеры цалкам кампенсуюць гэтыя недахопы.
Асноўны функцыянал ПЗ
Коратка апішу функцыянал і сваё меркаванне аб…
Кіраванне наладамі і выгрузка файлаў з SD
Усё вонкавае кіраванне зроблена праз найпростую Web старонку, якая запускаецца ў асобным пункце меню. ESP32 запускаецца ў рэжыме WiFi AP і выдае старонку па фіксаваным IP адрасе.
Хоць ядра ESP32 даволі хуткія, але, як паказалі эксперыменты, адначасовая праца ўбудаванага Web сэрвісу і, напрыклад, рэжыму router не занадта спалучаюцца. Таму дынамічнага кіравання няма і ва ўсіх астатніх рэжымах старонка не даступная.
Тым больш, што для даследчых мэт дынамічнае кіраванне не трэба.
Рэжым працы з Beacon пакетамі
Рэжымы банальныя і не вельмі цікавыя. Зроблены "таму што можна". Для галачкі.
Прыклады ёсць у афіцыйных examples прыкладах Espressif.
Рэжым сканавання спісаў AP.
Уласна, гэта ўмее рабіць любы смартфон.
Ну і ў гэтым рэжыме захаваецца спіс AP.
Beacon spammer.
ESP32 стартуе як AP са ўтоеным SSID і выпадковым MAC і пачынае слаць [beacon frame] па загадзя створаным спісе SSID (створаным уручную або атрыманаму раней пры сканаванні спісу AP)
Рэжым sniffing пакетаў WiFi
Распрацоўнікі Espressif дадалі магчымасць прыкладному ПА атрымліваць праз callback функцыю ўсе WiFi пакеты "якія пралятаюць у паветры". Насамрэч не ўсё, паколькі можна ўсталяваць рэжым толькі для аднаго фіксаванага канала.
На апрацоўку выкліку callback функцыі накладваюцца вельмі цвёрдыя часавыя абмежаванні. Калі для рэжыму простага збору статыстыкі гэта праблем не выклікае, то для рэжыму запісу PCAP файла на SD карту прыйшлося павазіцца, арганізуючы запіс праз чаргу ў памяці і семафоры. З улікам асаблівасці, што працэс, які выклікае callback круціцца на адным ядры, а працэс, які выконвае запіс на SD у іншым.
Пры «зашумленым эфіры» некаторыя пакеты губляюцца (у чарзе няма месца і яны адкідаюцца), але пры тыповым «эфіры» кватэры ўвечар (5..7 AP у межах бачнасці) запіс у PCAP паспявае выконваюцца без страт пакетаў.
Дадаткова, для маніторынгу і запісы PCAP ёсць рэжым фільтрацыі па спісе MAC у загалоўках пакетаў.
Напрыклад, можна адсачыць з'яўленне чалавека ў клубе/кавярні, да таго, як ён наогул увайшоў ці з'явіўся ў поле зроку. Мала хто адключае WiFi і аўтаматычныя злучэнне з вядомымі AP. (Я зараз адключаю..)
Праглядаць запісаны трафік у Wireshark пазнавальна і цікава для разумення карт гэта ўсё працуе.
Рэжым працы з deauth пакетамі
Па змаўчанні, пасылка гэтых пакетаў забаронена ў бібліятэцы libnet80211.a, якая ідзе без зыходнікаў. Але гэта нескладана купіраваць, падправіўшы пару байцікаў. Спачатку я сумняваўся, а ці варта выкладваць patch. Але пахадзіўшы па розных месцах з уключаным рэжымам сканавання крыніц пасылкі [deauthentication frame], падумаў: "якага чорта". Тым больш, што ў esp8266 пасылка гэтых пакетаў не зачынена і зборкі на github пад esp8266 ёсць.
У вельмі многіх месцах (не буду казаць дзе) выкарыстоўваецца прыгнечанне непажаданых AP праз гэты метад. І гэта не "хуліганы"…
А я яшчэ дзівіўся, што гэта ў мяне раздача інтэрнэту з тэлефона месцамі не працуе…
Рэжым адсочванне колькасці і RSSI такіх пакетаў вельмі карысны што б зразумець "дзе не любяць левыя AP".
Рэжым router
Гэтая функцыя, мусіць, самая цікавая з усіх для даследавання.
ESP32 падтрымлівае адначасовую працу ў рэжыме STA + SoftAP. Таму на ім можна рэалізаваць класічны NAT router.
Для падтрымкі сеткавага стэка Espressif выкарыстоўвае fork (практычна без змен) бібліятэкі lwip.
Але, па змаўчанні, у стандартнай зборцы, у бібліятэцы esp-lwip паміж netif інтэрфейсамі 'ap'(SoftAP) і st' (STA) не прадугледжаны пракід.
Можна вядома зрабіць і без NAT, але ўзнікае праблема з адначасовым падлучэнне двух і больш STA да інтэрфейсу 'ap' і сінхранізацыі IP адрасоў ад сеткавага інтэрфейсу 'st' да 'ap'. Так што складанасці не вартыя таго і прасцей праз NAT.
Тым больш, што існуе fork esp-lwip ад martin-ger у якім дададзена простая рэалізацыя NAT для IP4.
Хоць у мяне рукі свярбелі яе перарабіць чыста касметычна (на маю, прасцей было без fork праекту, а праз LWIPHOOK функцыі, якiя вызначаюцца пры зборцы), але лянота перамагла і варыянт ад martin-ger выкарыстоўваецца як ёсць.
У рэжыме router праглядаецца ўваходны і выходны IP4 трафік.
У прыватнасці, з яго здабываецца для паказу на экранчыку і збору статыстыкі ў файл:
- Імя прылады, якое падключылася да SoftAP ESP32 (DHCP пакеты)
- URL з DNS запытаў (UDP port 53) ад падлучанага да SoftAP ESP32 прылады.
Дадаткова можна ўключыць запіс трафіку ў PCAP файл.
Дадзены рэжым вельмі карысны, напрыклад, для таго, каб зразумець, напрыклад, што ваш тэлефон шле ў сетку і куды пры гэтым ходзіць.
Можна прыдумаць і іншыя спосабы выкарыстання гэтага рэжыму з улікам магчымасці цалкам кіраваць праграмна ўваходным і выходным трафікам SoftAP ESP32 на ўзроўні сеткавага інтэрфейсу: Ehernet загаловак (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DCHP, і іншае type).
У прынцыпе, ESP32 цалкам нармальна спраўляецца з функцыяй WiFi->WiFi роўтара, прапускаючы праз сябе без асаблівых затрымак звычайны трафік. Суб'ектыўна, затрымкі ў тэлефоне, падлучаным праз router на ESP32 не прыкметныя.
Нажаль, у API Espressif няма магчымасці ўсталяваць фільтр па MAC падлучальным да SoftAP EPS32. У месца гэтага прапануецца казаць "да спаткання" (esp_wifi_deauth_sta) ужо падлучаным STA, якія "не пажаданыя".
Фільтраванне па MAC для якія падключаюцца STA прыйшлося зрабіць праз выклік esp_wifi_deauth_sta()
У заключэнне
Хоць нічога новага ў рамках працы з ESP32 я не прыдумаў, але магчыма камусьці вынік (зыходнікі) будзе цікавы.
Хацеў бы адзначыць, што код пісаў выключна ў пазнавальных мэтах. Для "узлому" і інш. ён адмыслова рабіўся не вельмі зручным.
Друкаваны поплатак не рабіў, паколькі на тое, што бы спаяць провадам гатовыя хусткі сышло гадзіны 1.5-2.
Ды і калі рабіць, то трэба не з гатовых поплаткаў збіраць, а з асобных кампанент. Тады габарыты будуць яшчэ меншыя.
Крыніца: habr.com