На думку зробити кишеньковий інструмент для аналізу WiFi мереж мене підштовхнула .
Дякую їм за ідею. Мені якраз не було чим зайнятися.
Вся робота була виконана в рамках хобі з метою отримання задоволення та розширення своїх знань у галузі мережевих технологій. Не поспішаючи, по 1 години на тиждень, з початку цього року.
Прикладне використання не планувало. Тобто. це НЕ інструмент для хакера.
На даний момент весь задуманий функціонал працює. Усі вихідники, повністю готові для збирання, . Там же інструкція зі збирання та ін. У даній замітці я не дублюватиму інформацію, викладену на github. Розповім лише те, що вважаю за потрібне описати окремо.
Моя думка з приводу "універсального інструменту" та причина вибору ESP32
Я не претендую на правду. Вона у кожного своя. Постараюся довести свій вибір "заліза".
варіант використання поєднання Linux (спочатку Raspberry Pi) + "периферії" у вигляді контролер (STM32) + CC1110 (ядро 8051) і план впхнути туди все що тільки можна (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) здався не придатним для мене. Втім, схоже так залишиться приватним і закритим (flipper-zero github "This organization has no public repositories.") і пішов у бік не надто поширеного заліза.
Можливо я не прав, і надалі автори викладуть вихідні програми у відкритий доступ. Але якби ні, то я б таку залізку без вихідних не купив би.
Мої вимоги до "інструменту"
Коробочка має бути маленька (чим менше, тим краще).
Тому:
- Вбудований акумулятор не потрібний. При струмі > 100 mA при роботі з Wifi вбудований акумулятор або буде великий, або його вистачає не на довго. Тож нехай "коробочка" харчується від стандартного power bank. Anyway 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 пакетами
Режими банальні та не дуже цікаві. Зроблені «бо можна». Для галочки.
Приклади є в офіційних прикладах прикладів 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 проекту, а через LWIPДАК функції, що визначаються при складання), але ліньки перемогла і варіант від 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, та інше тип).
В принципі, 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