Идеята за създаване на портативен инструмент за анализ на WiFi мрежи дойде от .
Благодаря им за идеята. Тъкмо нямах с какво да се занимавам.
Цялата работа беше извършена в рамките на хобито с цел получаване на удоволствие и разширяване на знанията ми в областта на мрежовите технологии. Без да бързам, по 1-4 часа седмично, от началото на тази година.
Не планирах практически приложение. Т.е. това НЕ е инструмент за хакер.
В момента всичките предвидени функции работят. Всички изходни кодове, напълно готови за компилиране, . Там също има инструкции за компилиране и др. В тази бележка няма да дублирам информацията, публикувана в github. Ще части само това, което смятам за нужно да опиша отделно.
Моето мнение за "универсалния инструмент" и причината за избора на ESP32
Не претендирам за истината. Тя е различна за всеки. Ще се постарая да обосная избора си на "железо".
вариант на употреба съчетава Linux (първоначално Raspberry Pi) + периферия под формата на контролер (STM32) + CC1110 (ядро 8051) и план за внедряване на всичко възможно (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) ми се стори не подходящ за мен. Въпреки това, изглежда ще остане частен и затворен (flipper-zero github "Тази организация няма публични хранилища.") и започнах да се насочвам към не толкова разпространени устройства.
Възможно е да греша, и в бъдеще авторите да публикуват изходния код на софтуера в открит достъп. Но ако не, то такова устройство без изходен код не бих купил.
Моите изисквания към "инструмента"
Коробката трябва да е малка (колкото по-малка, толкова по-добре).
Следователно:
- Вграден акумулатор не е нужен. При токове > 100 mA при работа с Wifi, вграденият акумулатор или ще е голям, или издържа само за кратко. Затова нека "коробката" да се захранва от стандартен power bank. Все пак, power bank в джоба/колата ми е винаги наличен.
- Да държи в "коробката" Linux с инструменти, написани през много години на всички езици при наличие на малък екран и оскъден набор от управляващи бутони няма смисъл. Резултатите могат да се преглеждат/обработват и на нормален лаптоп с пълна клавиатура и екран.
- Компонентите трябва да са леснодостъпни и широко известни (достъпен SDK, много примери и документация).
В резултат, за мен, изборът беше очевиден — ESP32.
За всичките задачи, посочени в статията, която ме подтикна към действия, възможностите на ESP32 са напълно достатъчни. Въпреки това, максималното, което искам да направя, е:
- Да поекспериментирам с Bluetooth.
- Да поекспериментирам с диапазона 433mHz с основен хардуер (само амплитудна модулация, което е достатъчно за практически нужди).
Лъжлива лъжица в ESP32
- SDK (IDF) на ESP32 е малко неуместен.
- Част от функционалността (напр. WiFi стек) идва без изходен код под формата на събрани статични библиотеки.
- Не се поддържа 5gHz диапазон и има някои ограничения и несъответствия при работа с WiFi.
Но цената/размерите напълно компенсират тези недостатъци.
Основна функционалност на софтуера
Ще опиша накратко функционалността и моето мнение за...
Управление на настройките и извеждане на файлове от SD
Всички външни управления са направени чрез най-простата уеб страница, която се стартира в отделна точка от менюто. ESP32 се стартира в режим WiFi AP и предоставя страница на фиксиран IP адрес.
Въпреки че ядрото на ESP32 е доста бързо, експериментите показаха, че паралелната работа на вградения уеб сървър и, например, режим рутер не се съчетават добре. Следователно динамичното управление не е налично и на всички останали режими страницата не е достъпна.
Още повече, че за изследователски цели динамичното управление не е необходимо.
Режим работа с Beacon пакети
Режимите са банални и не много интересни. Направени са «защото е възможно». За галочка.
Примери има в официалните примери на 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 рутер.
За поддръжка на мрежовия стек 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 проекта, а чрез LWIP).HOOK функции, определяни при компилирането), но мързелът победи и вариантът от martin-ger се използва такъв, какъвто е.
В режим на рутер се проследява входящият и изходящият IP4 трафик.
По-специално, от него се извлича, за да се показва на екрана и да се събира статистика в файл:
- Името на устройството, което е свързано към SoftAP ESP32 (DHCP пакети).
- URL адреси от DNS запитвания (UDP порт 53) от свързано към SoftAP ESP32 устройство.
Допълнително може да се включи запис на трафика в PCAP файл.
Този режим е изключително полезен, например, за да разберете какво вашият телефон изпраща в мрежата и къде ходи.
Може да се измислят и други начини за използване на този режим с оглед на възможността напълно да се управлява входящият и изходящият трафик на SoftAP ESP32 на ниво мрежов интерфейс: Ethernet заглавие (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DCHP и други типове).
В принцип, ESP32 напълно нормално се справя с функцията на WiFi->WiFi рутер, пропускайки обикновен трафик без особени забавяния. Субективно, забавянията на телефона, свързан чрез рутера на ESP32, не са забележими.
За съжаление, в API на Espressif няма възможност да се установи филтър по MAC за свързващите се към SoftAP EPS32. Вместо това се предлага да се каже "сбогом" (esp_wifi_deauth_sta) на вече свързаните STA, които са "нежелателни".
Филтрацията по MAC за свързващите се STA се наложи да се направи чрез извикване на esp_wifi_deauth_sta()
В заключение
Въпреки че не измислих нищо ново в рамките на работата с ESP32, възможно е на някого резултатът (източниците) да бъде интересен.
Искам да отбележа, че кодът е написан изключително с образователна цел. За "хакване" и пр. е създаден нарочно не много удобен.
Не направих печатна платка, тъй като за това, че да споя жиците към готовите платки, отне около 1.5-2 часа.
Да и ако все пак направя, трябва да събирам не от готови платки, а от отделни компоненти. Тогава размерите ще бъдат още по-малки.
Източник: habr.com
