Это Multi SSID так работает. Потому что у windows к беспроводной связи хроническая неприязнь. Кое-какой интерфейс для подключения к беспроводным сетям, появился только в xp, а вменяемым он стал начиная с windows 7. При этом, задать настройки ip для каждой сети было нельзя. Есть еще один интерфейс, bluetooth называется, с ним в windows полный 3,14здец. Несколько лет назад, в одной wannabe европейской стране, не было даже 3G связи. В этих условиях, никакущий wifi от жилых домов, был гораздо лучше перегруженного 24/7 мобильного интернета. Он хотя бы работал. В 2020 году, смысла в этих мучениях нет никакого, вообще. У такого способа выхода в сети, есть гора недостатков: 1) Дохлый сигнал почти всегда. 1 или 2 деления, в лучшем случае скорости чуть ниже 10 мегабит. 2) На роутерах dhcp сервер почти всегда долго думает, прежде чем выдать ip. Особенно грешны этим роутеры с чипсетами рыгалтек, они несколько минут иногда не могут родить. 3) На ходу пользоваться не получится - радиус действия слишком мал, покрытие роутера можно прошагать за десятки секунд. Про автомобиль даже не заикаюсь. 4) Сервера веб-сайтов очень плохо переваривают постоянные перескоки с одного ip на другой. Тот же ютуб даже сегодня провиснет на пару секунд, прежде чем отдавать видео. Бесшовный роуминг - это куда то в сторону дорогущего оборудования для организаций, с контроллером беспроводных зон. Именно он, а не клиентское оборудование, этот роуминг обеспечивает. В России теле2 вроде бы предоставляет бесплатный интернет на околонулевой скорости. В Украине МТС делает то же самое - телега, вк через vpn, почта и т.д. работает. Даже хендшейки можно выгружать на брут. Никакого онлайн-видео и т.д., но связь есть, и бесплатно. А музыку можно и закачать на устройство в виде .mp3 файлов, только никому не говори.
Ну что то совсем бедненько и програмистов.. Толкового софта почти нет ни у кого.. ток вирусяги писать умеют)) Вот РС - толковая прога. Но взаимодействия с другими аппаратами нету. Сейчас столкнулся с тем что бы Перекинуть WiFi пароли (с РС) на андроид Охспди - пальцы устанут вбивать (закорючки) всё по очереди)))))))- ну уж чего чего, а тут подвоха не ожидал вообще(( Искал софт чтобы переписать 171 пароль с винды на андроид - думал по любасу есть что нить (какой нить синхронизатор, или ресторатор.. восстановитель програмный - с конвертацией для Андроида) - НЕТУ!!!!!!! от слова вообще!! Капец (((((((((
Подскажите пожалуйста, как исправить такую ситуацию: собираю в ттекстовый файл probe requests. Делаю вот так: sudo tshark -i wlan0mon -Y 'wlan.fc.type_subtype == 4' -T fields -e wlan.ssid | sudo tee -i -a probes.txt Все работает, но много пустых строк от широковещательных запросов и много строк с ссидом моего же вайфая dlink. Подскажите, как их отфильтровать перед записью в файл? Сразу скажу, что в программировании я совсем не аллё и на эту строчку ушло полдня, поэтому прошу конкретного примера, а не общих советов.
После tshark поставьте Code: egrep -v "^$|^dlink$" - заблокирует пустые строки, и строку dlink (dlink1234 - пропустит). Если задача - ловить пароли из эфира, то я бы вместо этого поставил бы фильтр, просто удаляющий дубликаты. Code: perl -ne 'BEGIN{%h} if (!$h{$_}) {$h{$_}=1; print $_;}'
Спасибо, но не выходит. В файл не записывает. Не могли бы вы полностью выложить всю строчку с тшарком и записью в файл? Фильтр от дубликатов хорошая идея, но там я вообще ничего не понял. Может у меня не работает из-за того, что в кали 2020 сделали идиотское "усовершенствование" лишив юзера прав суперпользователя по умолчанию?
У вас было так (упрощённо): tshark | tee сделайте так: tshark | egrep -v "^$|^dlink$" | tee полностью: Code: tshark -i wlan0mon -Y 'wlan.fc.type_subtype == 4' -T fields -e wlan.ssid | egrep -v "^$|^dlink$" | sudo tee -i -a probes.txt Вариант с удалением дубликатов: Code: tshark -i wlan0mon -Y 'wlan.fc.type_subtype == 4' -T fields -e wlan.ssid | perl -ne 'BEGIN{%h} if (!$h{$_}) {$h{$_}=1; print $_;}' | sudo tee -i -a probes.txt
Не работает ни тот, ни другой вариант. И вообще никакие. Я уже переустановил кали 2019 чтобы получить права суперпользователя, но это ничего не изменило. Чтото принципиально не так. Когда я запускаю только тшарк без тии, то вывод идет в терминал. С тии вывод в терминал прекращается, выводится только количество пойманных пакетов, а их список в терминале появляется только после остановки ctrl/C. Любые попытки вмешаться в поток между тшарком и тее заканчиваются неудачей.
Это из-за буферизации вывода (tshark и grep). Вот так должно работать: Code: sudo tshark -i wlan0mon -Y 'wlan.fc.type_subtype == 4' -T fields -e wlan.ssid -l 2>/dev/null | egrep -v --line-buffered "^$|^dlink$" | sudo tee -a probes.txt sudo tshark -i wlan0mon -Y 'wlan.fc.type_subtype == 4' -T fields -e wlan.ssid -l 2>/dev/null | perl -ne 'BEGIN{%h;$|=1} if (!$h{$_}) {$h{$_}=1; print $_;}' | sudo tee -a probes.txt
Може кто знает, как решить проблему русских букв? Что странно, опенврт в своем вебинтефейсе отображает русский текст нормально, а в аиродампе каракули. В кали тоже каракули или ромбики с вопросительным знком.
Определись, в какой кодировке тебе нужны русские буквы. Некоторые прошивки представляют русские имена сетей в кодировке OEM 866, некоторые более новые в UTF-8.
Мне все равно в какой. Просто непонятно, где надо кодировку исправлять? В аиркрэке, тшарке или в кали?
Функция перехвата в Wireshark или airodump-ng? Что лучше для захвата трафика с сохранением в файл с последующей расшифровкой в Wireshark? Есть ли какие различия между этими инструментами? Или разницы нет с чем работать?
Wireshark не управляет содержимым интерфейса, а только веде пасивно анализ/захват. Airodump-ng же способен виставить нужний канал( навестись на мишень) и так же записать результат. С выше перечисленного: 1.airodump-ng 2. чем запишеш пофиг, но без airodump-ng не запишеш нужную инфу в любом случае. 3. если разница между отверткой и шуриком?
Что касается tshark. Там в коде есть Spoiler: пояснение по этому вопросу 18037 /* 18038 * XXX - the 802.11 specs aren't particularly clear on how the SSID 18039 * is to be interpreted. 18040 * 18041 * IEEE Std 802.11-1999, section 7.3.2.2 "Service Set Identity (SSID) 18042 * element" says just 18043 * 18044 * The length of the SSID information field is between 0 and 32 18045 * octets. A 0 length information field indicates the broadcast SSID. 18046 * 18047 * with no indication that those octets encode a string. 18048 * 18049 * IEEE Std 802.11-2012, section 8.4.2.2 "SSID element", says that *but* 18050 * says after it 18051 * 18052 * When the UTF-8 SSID subfield of the Extended Capabilities element 18053 * is equal to 1 in the frame that includes the SSID element, the 18054 * SSID is interpreted using UTF-8 encoding. 18055 * 18056 * NOTE -- This is true for Beacon and Probe Response frames when the 18057 * MLME-START.request primitive was issued with the SSIDEncoding 18058 * parameter equal to UTF-8. 18059 * 18060 * and the SSIDEncoding parameter can either be UNSPECIFIED or UTF-8. 18061 * 18062 * So I *guess* that means that, if the UTF-8 SSID subfield isn't 18063 * equal to 1, the SSID is, in theory, just a bunch of octets, but 18064 * in practice, *probably* ASCII as that's the typical convention, 18065 * and, if it is equal to 1, it's a UTF-8 string. (Of course, a 18066 * host can put anything there it wants to, so we shouldn't just 18067 * assume that it's *valid* ASCII or *valid* UTF-8.) 18068 * 18069 * So we really should extract it as an array of ssid_len bytes, 18070 * pass those bytes to Dot11DecryptSetLastSSID(), and: 18071 * 18072 * If the UTF-8 SSID subfield isn't set to 1, put the SSID in 18073 * as an ENC_ASCII string; 18074 * 18075 * If the UTF-8 SSID subfield is set to 1, put it in as an 18076 * ENC_UTF_8 string; 18077 * 18078 * and rely on the libwireshark core code to somehow deal with 18079 * non-ASCII characters or invalid UTF-8 sequences or valid-but- 18080 * not-all-printable ASCII or UTF-8 strings in the protocol tree 18081 * display. I'm not sure we can currently rely on it to handle 18082 * invalid UTF-8 or non-printable characters in UTF-8 strings, 18083 * however, so we just treat it as ASCII for now. 18084 * 18085 * We also need a better way of getting the display format of a 18086 * string value, so we can do something other than run it through 18087 * format_text(), which won't handle UTF-8. 18088 * 18089 * Addendum: 802.11 2012 points out that a Zero-length SSID means 18090 * the Wildcard SSID. Make it so. From 8.4.2.2 of 802.11 2012: 18091 * 18092 * "The length of the SSID field is between 0 and 32 octets. A SSID 18093 * field of length 0 is used within Probe Request management frames to 18094 * indicate the wildcard SSID. The wildcard SSID is also used in 18095 * Beacon and Probe Response frames transmitted by mesh STAs." 18096 * 18097 * Also, we have to return a non-zero value here to prevent an ugly 18098 * undissected field warning. Since this code is only called from 18099 * one place and is used in call to dissector_try_uint_new, it is 18100 * OK to do so. 18101 */ Если кратко - он проверяет специальный флаг "UTF-8 SSID" в пакете, если его нет, то всё, что не соответствует ASCII фильтруется. Этот флаг, разумеется, никто не ставит. airodump-ng. Он вроде нормально отдаёт UTF-8. И в терминал, и в csv https://0x0.st/iZ15.png - Это kali самая свежая, загрузка с live cd, без всяких настроек терминала.
