Wifi probe что это
Атака на беспроводные сети. Чуть меньше теории и чуть больше практики
-1. Пара слов от себя
Хочу сказать, что я категорически против злоупотребления подобными действиями. Хоть в крупных городах сейчас в основном правит сэр «безлимитный интернет» (поэтому моя совесть тихо-мирно спит), но все-таки не стоит пакостить и злоупотреблять, тем более, что это может выйти боком, о чем я напишу ниже… В остальном же, я не вижу в этом ничего предосудительного, и считаю, что подобные действия равноценны тому, как погреться зимой у чужой батареи)))
Я не буду рассматривать всяческие нюансы и подводные камни, которые могут встретится на пути, те кто захочет — разберутся сами, остальные будут крепче ночью спать 🙂
Также хочу отметить, что я не «кул-хацкер» и вообще никак не связан с беспроводными сетями и защитой информации. Просто после покупки нетбука эта тема стала для меня актуальна и интересна, что и подтолкнуло меня с ней разобраться. Ну а теперь мне захотелось поделиться с хабра-публикой.
Это моя первая статья, так что сильно не бейте :))
Итак, поехали!
0. Запасаемся основным софтом
Существует множество программ для подобного рода действий, но мы будем использовать пакет Aircrack-ng, в котором уже есть все для нас необходимое. Программа эта разрабатывается под линукс, хотя есть версия и под винду, но как я понял, она не особо поддерживается и не особо работает)))
Cкачиваем и собираем последнюю доступную на данный момент версию rc3 (от 26.03.09):
Хотя разработчики рекомендуют использовать последнюю версию, т.к. в ней исправлено множество ошибок и добавлено множество улучшений.
1. Собираем информацию
Для начала нужно перевести нашу wi-fi карточку в режим «monitor mode»
В моём случае (c драйвером Madwifi-ng) это делается так:
sudo wlanconfig ath0 destroy
sudo wlanconfig ath0 create wlandev wifi0 wlanmode monitor
Теперь нам понадобится программа для мониторинга всех беспроводых сетей в радиусе действия нашего вай-фай адаптера. Лично мне нравится использовать Airodump-ng из скачанного нами ранее програмного пакета Aircrack-ng.
Запускаем airodump указывая обязательный параметр — имя интерфеса (в данном случае ath0) :
Что мы видим? наша карточка переключается с канала на канал и отображает всю активность в пределах досягаемости. В верхней половине показаны обнаруженные точки доступа, в нижней обнаруженные клиенты (в данном случае обнаружены 3 клиента, ни один из которых никуда не подключен):
Это только с виду кажется что табличка выглядит непонятно, на самом деле все просто, вот основные значения которые нам интересны:
2. Выбираем жертву 😀
Итак, что мы имеем? Чтобы действовать дальше, нам нужно выбрать нашу жертву.
Надо отметить, что очень важным критерием является уровень сигнала. Если сигнал ниже 5-10, то ничего хорошего от взаимодествий с этой сетью не выйдет.
Следующим шагом смотрим на алгоритм шифрования (ENC):
3. Привет WEP!
Я не буду описывать как справиться с SSID Cloaking, MAC Filtering и другими возможными препятствиями, достаточно почитать статьи n3m0 или документацию по aircrack, поэтому перейду сразу к делу.
Не вникая в тонкости, взлом wep сети сводится к сбору достаточного количества пакетов, поэтому можно просто сидеть и терпеливо ждать пока нужное количество наберется само, но если между точкой доступа и клиентом нет никакой активности, то мы можем просидеть так неделю… Поэтому нужные нам пакеты будут генерироваться не без нашей помощи 🙂
Далее идет пример взятый с сайта aircrack-ng.org. Взлому подвергается сеть с именем (essid) — teddy, MAC адресом (bssid) — 00:14:6C:7E:40:80, и «живущая» на 9-ом канале. Все эти данные находятся используя airodump (см. пункт 1 — «Собираем информацию»)
Запускаем airodump нацеленный на выбранную сеть, располагающуюся на 9-ом канале, с указанием адреса точки доступа, и имени файла в который будут записаны пойманные пакеты:
Далее в новом терминале запускаем aireplay, чтобы подружиться с точкой доступа
где:
-e teddy — название сети
-a 00:14:6C:7E:40:80 — MAC точки доступа
-h 00:0F:B5:88:AC:82 — наш MAC
На выходе должны получить:
18:18:20 Sending Authentication Request
18:18:20 Authentication successful
18:18:20 Sending Association Request
18:18:20 Association successful 🙂
Теперь можно начать создавать паразитный траффик, снова открываем новое окно:
В идеале на выходе должны получить примерно это:
Saving ARP requests in replay_arp-0321-191525.cap
You should also start airodump-ng to capture replies.
Read 629399 packets (got 316283 ARP requests), sent 210955 packets.
Теперь переключаемся на окно в котором у нас запущен airodump и созерцаем бешено растущее (при должном уровне сигнала) количество пакетов. Обычно хватает 20 тысяч пакетов для нахождения 64-х битного ключа.
Когда нужное количество пакетов собрано, что показывает airodump в графе «# Data», запускаем и наслаждаемся процессом нахождения пароля:
UPD.
Пароль в большинстве случаев возвращается в шестнадцатиричном формате, т.к. большинство роутеров переводят пароль в HEX каждый по своему, поэтому перевести значения обратно в ASCII чаще всего не удается, хотя в некоторых случаях изначальный пароль пишется рядышком в скобочках.
Вот собственно и всё. Этот пароль можно смело вводить, только двоеточия убрать.
При благоприятных условиях абсолютно ничего сложного 🙂
Если пароль не нашелся, о чем aircrack нам сообщит, скорее всего нужно наловить еще пакетов, например 40 тысяч.
4. Неприступный WPA/WPA2
В этом случае все выглядит намного проще, но к конечному результату прийти намного сложнее.
Для начала, как обычно, запускаем airodump нацеленный на выбранную сеть…
В случае с WPA/WPA2 сбор пакетов не срабатывает, чтобы сдвинуться с места нам нужен клиент подключенный к сети, а если говорить еще точнее, нам надо застать момент подключения клиента к сети. Если клиента нету, то сидим и ждем.
Если клиент уже подключен, запускаем aireplay и обрываем его аутентификацию, тем самым заставляя его соединиться заново:
где:
-a 00:14:6C:7E:40:80 — MAC точки доступа
-c 00:0F:B5:FD:FB:C2 — MAC клиента
И на выходе получаем:
В идеале мы должны получить т.н. handshake, о чем нас опять же уведомит airodump, отобразив в самой верхней строке справа сообщение «WPA handshake: 00:14:6C:7E:40:80».
Если этого не произошло, снова используем aireplay.
Когда handshake пойман, запускаем aircrack, но на этот раз с использованием словаря:
В данном случае результат напрямую зависит от наличия нужного пароля в нашем словаре, поэтому наши шансы прямо пропорциональны размеру и качеству нашего словаря.
Словари можно без проблем найти на просторах интернета, плюс в архиве aircrack-ng уже небольшой лежит 🙂
5. Пару слов про защиту
6. Заключение
Вот вроде бы и все…
Это были самые простейшие способы обойти и усилить защиту, но даже они не всегда срабатывают.
Для тех кто хочет узнать больше, советую посетить сайт http://www.aircrack-ng.org/
В итоге мы узнали, что WEP самый благоприятный для взлома протокол. Мой личный рекорд — около 5-7 минут 🙂
Но это нисколько не значит, что надо очертя голову, бежать и переходить на WPA2… практика показывает что большинство людей не умеет даже устанавливать windows, чего уж тут говорить про взлом wi-fi :)))
Еще раз хочу сказать про злоупотребление. Если от этого вас не останавливает даже морально-этическая сторона вопроса, то имейте ввиду, что при некотором стечении обстоятельств, вы можете лишиться множества своих паролей (icq, контакт и т.п.)… это также относится к любителям пользоваться открытыми wi-fi сетями… Но об этом я напишу в следующей статье. Надеюсь было интересно 🙂
Wifi probe что это
Телефон с включённым WiFi может периодически отправляет в эфир запросы, т.н. probe requests, содержащие MAC самого устройства и имя известной WiFi сети, с которой он соединялся ранее в надежде, что эта сеть ему ответит. Этот механизм, активный поиск, является альтернативным пассивному, когда устройство желая соеденится с сетью слушает эфир ожидая маячковые сообщения (beacon frames) от точки доступа [Passive WiFi Tracking].
Посмотреть пристальнее на эти пакеты можно в Wireshark используя фильтр wlan.fc.type_subtype == 4
Таким образом можно привязать конкретное устройство к wifi сети (с поправкой на то, что сетей с данным именем может быть несколько) и далее попытаться определить географическое положение этой сети. Последнее возможно при помощи геоинформационных сервисов в Интернете, например WiGLE (поиск по сетям доступен после регистрации). Если в Сети данных нет, то можно обойтись собственноручно собранной информацией о местоположении WiFi сетей, например с помощью мобильных приложений (Google Play: Wigle Wifi Wardriving).
Приём probe request
***
Наблюдать устройства посылающие probe requests можно и в airodump-ng. Утилита показывает активные устройства (мак, время появления, время последнего пакета, ESSID и т.д.). в реальном времени. Если включена запись в файл, то данные об эфире также будут сохранены в CSV файл.
Wi-Fi позиционирование «дешево и сердито». О частоте замеров или возможно ли Wi-Fi позиционирование в реальном времени?
Это третья, пока заключительная статья из серии Wi-Fi позиционирования «дешево и сердито»: когда не используются специализированные клиентские устройства и специализированная инфраструктура, а используются только общедоступные персональные устройства (смартфоны, планшеты, ноутбуки) и обычная инфраструктура Wi-Fi.
В первых двух статьях я делал основной акцент на точности и достоверности позиционирования, не касаясь вопроса частоты замеров. Если Клиент находится в статическом положении, частота замеров не имеет критичного значения, а если Клиент движется, то частота замеров начинает играть существенную роль.
Отправной точкой при расчёте частоты замеров является такая характеристика как характерная скорость движения Клиентов. Для человека это 5км/ч или 1.5 м/с. Для обеспечения позиционирования в реальном времени промежуток времени между двумя замерами не должен превышать удвоенную точность позиционирования, что позволяет строить достаточно точные для практических целей траектории движения.
Точность классического позиционирования по тестам, проведенным в предыдущей статье, составляла порядка пяти метров с достоверностью 90%. В этом случае частота замеров должна быть не менее 6,6с (либо 13,3 секунды для точности 10 метров). Теперь осталось выяснить, какова реальная частота замеров и соответствует ли она заявленной точности позиционирования.
Для тестов используется смартфон на Android 4.4.4 и ноутбук с Windows 7.
Что ж, цель ясна, средства понятны, приступим!
В специализированных системах позиционирования частотой замеров можно управлять на уровне работы драйверов беспроводного адаптера и программного обеспечения, регулируя интервалы передачи информации, тем самым подстраиваясь под характерную скорость клиента и точность позиционирования.
С персональными Wi-Fi устройствами (смартфоны, планшеты, ноутбуки) дело обстоит иначе: мы можем работать только с тем, что определено в стандартах IEEE 802.11-2012, драйверами производителя, настройками операционной системы.
Частота замеров, а что это?
Точки доступа (ТД) используют для позиционирования уровень сигнала (RSSI) Wi-Fi клиента (Клиент). Назову наличие на ТД одного измеренного уровня сигнала Клиента Замером.
Для решения задачи позиционирования необходимо иметь как минимум по одному Замеру с трех точек доступа. Чтобы не было путаницы, буду называть такой набор Сэмплом.
А сложно ли получить Сэмпл?
Точки доступа, Замеры которых формируют Сэмпл в общем случае работают на трех разных каналах, допустим, первый, шестой и 11-й (это связано с работой стандартов IEEE 802.11).
В соответствии со стандартами IEEE 802.11, Wi-Fi адаптер может находиться в одном из трех состояниях:
— передача (Tx)
— приём (Rx)
— мониторинг (CCA — Clear Channel Assessment)
Если ТД не передаёт и не принимает, она находится в режиме мониторинга своего канала (в частности для оценки виртуальной (CCA-CS, Carrier Sense) и физической (CCA-ED, Energy Detect) занятости канала).
Если Клиент находится в зоне уверенного приёма одной точки доступа, то он передаёт и принимает на одном канале. Возвращаясь к тому, из чего формируется Сэмпл, возникает вопрос, каким образом сформируется Сэмпл, если Клиент работает только в одном канале, а Замеры должны быть на трех разных каналах?
Современные точки доступа небольшую часть времени тратят на мониторинг смежных каналов, но так как основной задачей точек доступа остаётся обслуживание клиентов, а мониторинг всех каналов происходит последовательно, то время нахождения на смежном канале очень мало. К примеру, в инфраструктуре Cisco точка доступа обходит все каналы за 16 секунд. В этом случае вероятность «поймать» Замер клиента на смежном канале невелика. Поэтому этот способ мы отметаем.
Для мониторинга смежных каналов производители часто применяют дополнительное радио. К таким технологиям относится Cisco FastLocation. Модуль мониторинга перебирает все возможные каналы, но находится на каждом канале заметно дольше. Но опять же, эта роскошь по условиям задачи нам не доступна. Более детально технологии Cisco FastLocation я собираюсь посвятить отдельную статью.
Откуда все-таки тогда берется Сэмпл?!
В беспроводной среде есть огромное количество процессов, которые протекают незаметно для пользователя. Есть три типа пакетов (Data, Control, Management) и как минимум 39 типов фреймов, и есть всего один фрейм (и один режим работы беспроводного клиента), который позволяет решить поставленную задачу.
Это режим активного сканирования (active scanning), когда Клиент активно (посылая пакеты Probe Request) сканирует все доступные каналы на предмет наличия подходящей беспроводной сети. Probe Request, как фрейм управления (management frame), посылается на максимальной мощности и на самой низкой скорости передачи. Именно этот режим позволяет точкам доступа, работающим на других каналах, получить Замер с Клиента и сформировать Сэмпл.
Зачем Клиент посылает эти запросы?
Есть как минимум два режима работы, когда используется сканирование:
1. При выборе клиентом подходящей точки доступа, для подключения к беспроводной сети
2. При выборе клиентом подходящей точки доступа во время перехода с точки на точку (во время роуминга)
Клиенту доступно два механизма сканирования радиосреды:
— пассивное сканирование (passive scanning)
— активное сканирование (active scanning)
В первом случае беспроводной клиент слушает beacon пакеты (посылаемые каждые 102,4мс. по умолчанию), во втором – посылает probe request и дожидается probe response.
Очевидно, что это вопрос выбора между скоростью сканирования и затрачиваемой на это энергией (самый затратный режим работы беспроводного клиента – это передача).
Пассивное сканирование
Допустим, мы производим сканирование в диапазоне 2.4ГГц в России, где разрешено 13-ть каналов. Приёмник беспроводного клиента должен находиться, очевидно, не менее 102.4мс (стандартный интервал между beacon пакетами) в режиме мониторинга на каждом канале. Полный цикл сканирования занимает в районе 1.4с.
Активное сканирование
Клиент посылает запрос в канал (Probe Request). Точки доступа, работающие на этом канале и услышавшие запрос, отвечают на него информацией о имеющихся беспроводных сегментах (SSID).
Запрос может быть направленный (содержащий определенный SSID) — directed probe request, в этом случае ТД должна ответить информацией только об этом SSID (если он на ней есть).
Запрос может быть всенаправленный (Null Probe Request), в этом случае ТД, услышавшая данный пакет, должна предоставить информацию о всех настроенных SSID.
Клиент посылает Probe Request на первом канале и запускает ProbeTimer. Величина ProbeTimer не стандартизована и в зависимости от реализации драйверов сетевого адаптера может отличаться, но в общем случае она составляет 10мс. В течении этого времени беспроводной клиент обрабатывает ответы (Probe Response от ТД). Далее переходит на следующий канал и так по всем каналам. После чего решает, к какой ТД подключиться.
Полный цикл сканирования в этом случае занимает порядка 130мс, что примерно на порядок меньше пассивного сканирования.
Каждый производитель самостоятельно выбирает тип сканирования и условия его применения. Так же в самой операционной системе может быть опции, позволяющие выбрать определенный режим.
Какую частоту сканирования по Probe Request можно ожидать?
С моей точки зрения после подключения к SSID и находясь в зоне уверенного приёма одной точки доступа, Клиент не должен посылать Probe Request вообще.
Производитель Cisco говорит, что интервал передачи может быть в пределах от 10 секунд до 5 минут, в зависимости от типа Клиента, ОС, драйверов, батареи, активности клиента (http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/CMX_FastLocate_DG/b_CMX-FastLocate-DG.html).
Получается, что теория несколько противоречит практике, поэтому тут необходимы тесты.
Измерение частоты посылки Probe Request
Сначала тестам подвергся ноутбук в статическом положении, подключенный к сети, режим максимального потребления. На одном профиле у меня были отметки «подключаться автоматически» и «подключаться, даже если сеть не ведет вещание своего имени (SSID).
Результат показал, что система примерно раз в минуту посылает на все каналы всенаправленный Probe request независимо ни от чего.
То есть система, находясь в статическом положении, в зоне уверенного приёма одной ТД, всё равно каждую минуту отправляет на все каналы Probe request (на каждый запрос все точки доступа посылают probe response, что формирует немалый траффик). В режиме Maximum Battery Life ноутбук показал тот же результат.
Так же видно, что каждый раз Клиент посылает не один запрос, а сразу несколько, с совсем небольшим временным промежутком.
Есть ли корреляция между частотой посылки Probe Request и частотой замеров Cisco CMX
Количество Probe Request и количество Сэмплов на Cisco CMX совпала. Причем по логам видно, что раз в минуту приходит несколько Замеров (как показывает и анализатор), но CMX, очевидно, объединяет такие запросы (и правильно делает), так как счетчик каждую минуту увеличивался на один. Выглядело это примерно так:
Частота замеров в движении
В движении периодичность изменилась и появилась связь с моментом роуминга. Как показал анализатор, действительно, перед моментом роуминга ноутбук слал Probe Request на все каналы, то есть выполнял процедуру активного сканирования.
Тут возникает интересный эффект: чем быстрее двигается человек, тем чаще происходит роуминг. Но, к сожалению, роуминг происходит несколько реже, чем каждые 10 метров (удвоенная точность). Клиент держится «до последнего» за точку доступа и только в последний момент переключается на новую. В результате роуминг происходил не менее, чем каждые 15-20 метров, что примерно в два раза больше требуемого, в результате мы имеем не очень достоверную траекторию движения (см. предыдущую статью).
Далее я проводил тесты со смартфоном на базе Android 4.4.4. У смартфона есть два режима работы: активный и спящий. В спящем режиме есть несколько вариантов работы. Для тестов я использовал самый шумный режим «Never».
Результаты оказались следующими.
Если смартфон лежал на месте, и я им не пользовался, задержки составляли порядка 500-600 секунд. Даже в период активного серфинга задержки составляли порядка 100 секунд. Более частое обновление получалось за счет просмотра беспроводных сетей (в этот момент посылались запросы.
В движении результаты получились аналогичны ноутбуку, то есть прослеживалась прямая связь между посылкой пакетов и роумингом.
Основные выводы
1. В классическом Wi-Fi позиционировании замеры производятся по пакетам Probe Request
2. На персональных устройствах (ноутбуках, планшетах, смартфонах) частота посылки Probe Request зависит от большого количество факторов: типа устройства, ОС, типа драйверов и их настройки, состоянии батареи, активности клиента и может составлять от 5 секунд до 10 минут. Но!
3. Есть прямая связь между скоростью передвижения клиента (частотой роуминга) и частотой посылки Probe Request. Если клиент находится в статическом положении, то частота замеров небольшая (но она и не нужна большая!). А в случае движения начинают формироваться Probe Request по событию роуминга. Но!
4. Частота посылки Probe Request по событию роуминга недостаточна (больше, чем удвоенная точность позиционирования) и при равномерном движении может составлять 10-15 секунд (а требуется как минимум 5-10 секунд), что приводит к ухудшению точности позиционирования в движении не меньше чем в два раза.
НА что следует обратить внимание
Многие производители стараются оптимизировать работу своих устройств для увеличения времени работы устройства и первым претендентом на оптимизацию является режим «активного сканирования». Это приводит в том числе к тому, что такие устройства как iPhone и Android тоже, стали достаточно редко использовать этот режим работы, но в случае роуминга еще не отошли от использования Probe Request.
На помощь производителям, к сожалению, так же приходит протокол IEEE 802.11k, который вошел в новую версию стандарта 802.11-2012. Этот стандарт берет на себя как раз ту функцию, которую сейчас выполняет активное сканирование при роуминге.
Из-за активной работы производителей в сторону уменьшения энергопотребления и внедрения стандарта 802.11k вряд ли можно ожидать на этом направлении улучшений.
Остаётся вариант использования для замеров пакетов данных (Data frame). В этом случае мы логично приходим к рассмотрению технологии Cisco FastLocaton в следующей статье.
P.S. Ниже небольшое отступление про активные Wi-Fi метки, про которые, если удастся с ними поработать, будет отдельная статья.
В случае применения активных Wi-Fi меток мы можем настроить их работу, как нам необходимо. Программное обеспечение настраивается таким образом, что метка постоянно находится в спящем режиме, просыпается с определенной периодичностью для посылки Probe Request на все каналы, после чего засыпает. С помощью такого режима работы можно добиться необходимой частоты обновления и необходимой продолжительности автономной работы.
Вот пример активной метки, которая просыпается каждые 90 секунд для посылки Probe Request, работает от двух АА-батареек порядка 27 дней.
Отслеживание фрейм-запросов с помощью Probemon
Мобильные устройства в процессе использования теряют часть данных и иногда это происходит самым неожиданным образом. Смартфон, ноутбук, принтер и другие устройства передают информацию по Wi-Fi, которую можно собирать и отслеживать. Отслеживание мобильных устройств используется в современном интернет-маркетинге для сегментации целевой аудитории.
Мы сделаем Wi-Fi радар в лабораторных условиях с помощью скрипта Probemon.py для поиска и идентификации ближайших устройств по MAC-адресу, уровню сигнала и точкам доступа, к которым они недавно подключались.
Сбор MAC-адресов в беспроводных сетях может быть незаконным, особенно в сетях, которыми вы не владеете. Пожалуйста, ознакомьтесь с законами вашей страны. Материал опубликован в ознакомительных целях.
Пассивное слежение за беспроводными устройствами
Устройства слежения в сотовых сетях, такие как DRTBOX, сканируют сотовые телефоны находящиеся в диапазоне сигнала на предмет их местоположения и уникального идентификатора. Этих данных, в сочетании с координатами GPS, достаточно для того, чтобы узнать кто вы, и вы где находитесь.
Большинство Wi-Fi устройств теряют идентифицирующую информацию в процессе сканирования беспроводных сетей. Мы будем использовать Wi-Fi радар базирующийся на Python для записи полученной информации от мобильных устройств поблизости.
Как работает Probemon
Смартфоны и другие устройства с беспроводными модулями ищут Wi-Fi вокруг себя двумя способами: сканируют новые точки доступа (трансляционное сканирование) и те точки, к которым устройство подключалось ранее. Процессы поиска доступной сети могут быть перехвачены и записаны, а MAC-адреса идентифицированы.
Probemon.py создает текстовый файл со всеми зарегистрированными беспроводными устройствами в ближайшем диапазоне сигнала.
В дополнение к идентификации устройств, Probemon позволяет узнать последнюю сеть к которой был подключено устройство. Это поможет узнать геолокацию и построить профиль пользователя за определенный период времени при помощи сервиса Wigle.
Специфика iPhone
Этот метод неэффективен против iPhone из-за его особенности поиска сетей Wi-Fi. Он пингует широковещательные и неопределенные узлы, а после запрашивает ближайшие доступные точки доступа. Поэтому скрипт не может отследить iPhone в момент запроса конкретных точек доступа. Отслеживание смартфонов с версией прошивки до iOS 10 еще сложнее, из-за того, что они рандомизируют свой MAC-адрес.
Что нужно для изготовления Wi-Fi радара
Probemon — это программа на Python, которая позволяет беспроводному адаптеру работать в гибком диапазоне устройств. Probemon довольно хорошо работает и легко устанавливается на Kali Linux. Для его использования понадобятся:
Установка зависимостей
Во-первых, необходимо установить некоторые зависимости. Для этого после обновления Kali Linux, нам понадобятся: Python, Netaddr и Libdnet. Kali Linux включает в себя актуальную версию Python, но если его нет, мы можем установить его набрав в терминале:
Установка Netaddr и Scapy:
Установка и запуск Probemon:
Если программа указывает на отсутствие зависимостей или модулей, их нужно найти на GitHub и установить, как Scapy и Netaddr.
Запускаем Probemon для записи фреймов
Probemon идет с набором аргументов, которые указаны в справке.
Переводим адаптер в режим монитора:
Как только все запустилось, переходим к сбору данных. Запустим Probemon набрав в терминале:
Этот скрипт записывает результаты в файл под названием «HowTo», отображает их на экране и показывает, как они попали в эфир. Здесь отображаются MAC-адреса, производители устройств и беспроводные сети которые они искали.
Устранение слежки за MAC-адресами
Простое выключение функции Wi-Fi и режима «smart switch» не позволят вашему телефону отдать свой MAC-адрес. Программа macchanger, может заменить ваш MAC-адрес на что-то жуткое, что отобьет желание следить за вами.
Для этого отключим интерфейс, который будет замаскирован: