4 way handshake explained, или зачем нам третий пакет

Discussion in 'Беспроводные технологии/Wi-Fi/Wardriving' started by gpuhash, 17 Oct 2015.

  1. gpuhash

    gpuhash Elder - Старейшина

    Joined:
    22 Sep 2011
    Messages:
    430
    Likes Received:
    1,287
    Reputations:
    94

    Вот уж точно, ровно 50%: суслик либо есть, либо его нет :D

    Надеюсь, все местные завсегдатаи знают что такое WPA хэндшейк, как и где его лучше ловить и что с ним потом делать.
    В этой небольшой заметке я хочу сконцентрировать внимание на самом процессе хендшейка, или говоря научным языком, проведения процедуры аутентификации беспроводной точки доступа (AP) и клиента беспроводной сети.

    Итак что мы имеем в начале пути?

    Мы знаем, что каждый беспроводный интерфейс имеет псевдоуникальный шестибайтовый MAC-адрес, обычно записываемый через двоеточие или тире, например 00:03:BF:08:CA:04. Только шесть байт на интерфейс и больше ничего. Со стороны точки доступа (далее AP, Access Point) этот адрес именуется BSSID.
    Но поскольку людям свойственна тяга к прекрасному, а цифры скучны и однообразны, разработчики семейства стандартов 802.11 добавили нам каплю радости в виде возможности называть свои любимые сеточки красивыми именами, например xyi, kvartira_22 или Trump4President.
    Для этого они ввели еще один идентификатор, в терминологии 802.11 он называется ESSID или просто SSID, это обычная строчка символов длиной до 32 байт (именно байт, а не символов, т.к. символы в ESSID допустимы и многобайтные).
    Помимо своего развлекательного назначения, ESSID играет весьма важную роль в процессе аутентификации клиента и AP, но об этом чуть позже.
    Каждая WPA-PSK или WPA2-PSK сеть имеет статически предустановленный пароль (собственно PSK, или Pre-Shared Key это он и есть). Стандартом оговорен лимит длины пароля от 8 до 63 символов в кодировке ASCII. Пароль устанавливается владельцем точки доступа и затем он же вводится пользователем мобильного устройства при подключении к сети. Пароль статичен, это важно.

    В процессе аутентификации и вообще обмена данными по протоколам семейства 802.11 принимает участие туева хуча самых разных статических и динамических ключей. Все они имеют более-менее вменяемые названия и зачастую легко вычисляются, но вполне могут запутать человека мало знакомого с этим процессом. Чтобы было более понятно, основные ключи и связи между ними приведены на рисунке 1 (рисунок не мой, нашел в интернете). Далее мы поверхностно пройдемся по процедуре вычисления этих ключей и роли каждого из них.

    [​IMG]

    Прежде чем начать процедуру аутентификации, каждая из сторон вычисляет PMK (Pairwise Master Key). PMK это статический ключ, вычисляемый с помощью воздействия алгоритма PBKDF2 на пару ESSID+пароль. Как следует из названия (мастер-ключ), этот ключ является важнейшим во всей процедуре аутентификации. Алгоритм PBKDF2 включает в себя 4096 циклов хэширования по алгоритму HMAC-SHA1, и нужен исключительно для усложнения жизни хакерам пытающимся подбирать пароли WPA, т.к. им для проверки каждой следующей кандидатуры пароля нужно заново пересчитать хэш SHA-1 4096 раз, что нехило нагружает считалку. Важно заметить, что исходными данными для PBKDF2 наравне с паролем является и ESSID сети, а это значит что если мы не знаем ESSID или знаем, но неточно, рассчитать PMK "как надо" нам не удастся и все попытки аутентифицироваться будут безуспешны.
    В случае подбора пароля WPA важен не то что каждый символ, а каждый бит ESSID атакуемой сети, не говоря уже о кодировке, регистре символов и возможных пробелах до и после них. Именно поэтому "голого" хэндшейка недостаточно для полноценной атаки на WPA, а желательно еще наличие beacon frame или другого метода однозначного определения ESSID атакуемой сети.

    Все, у нас закончены все приготовления, PMK посчитан, начинаем процесс аутентификации.
    Естественно, инициатором является клиент, который начинает обмен с AP пакетами Probe Request, Authentication и Association Request. AP отвечает пакетами Probe Response, Authentication и Association Response, где указывает свои возможности и пожелания, и начинает процесс собственно EAPOL-аутентификации отправкой первого (из четырех) ключевого пакета EAPOL (Wireshark называет его Key 1/4, мы будем называть также).
    Чтобы упростить понимание процедуры аутентификации, смотрим на рисунок 2.

    [​IMG]

    В первом пакете содержится только ANonce - "придуманное" AP псевдослучайное 256-битное число, призванное внести некий элемент динамики в процесс аутентификации.
    Получив от AP ANonce, клиент аналогично "загадывает" подобное число со своей стороны, назовем его SNonce, и вычисляет сессионный ключ PTK (Pairwise Transient Key).
    Вычисление PTK также выполняется с помощью HMAC-SHA1, а в качестве параметров задаются собственно мастер-ключ PMK, BSSID, MAC-адрес клиента, свежепридуманные ANonce и SNonce и, зачем-то, строка с фразой "Pairwise key expansion" (ну захотелось им так).
    Вычислив сессионный ключ PTK, клиент не передает его в эфире, а вместо этого отвечает вторым ключевым пакетом key 2/4, который содержит SNonce и некий проверочный код MIC (Message Intergity Code), который вычисляется как HMAC-MD5 от первых 16 байт PTK (иногда называемых KCK, Key Confirmation Key) и собственно тела EAPOL frame с заполненым нулями полем MIC. AP, получив SNonce, теперь имеет все необходимые ингридиенты для вычисления PTK, чем и занимается сразу после получения второго ключевого пакета. Вычислив PTK, AP затем временно запоминает MIC из пакета клиента, зануляет поле MIC в EAPOL frame, вычисляет свою версию MIC и сравнивает его с запомненым значением MIC полученным от клиента. В случае совпадения, продолжает процедуру аутентификации (да-да, мы еще только на середине пути). Если же вычисленное значение MIC не совпадает с вариантом клиента, AP завершает процедуру аутентификации и игнорирует последующие пакеты.
    Для продолжения процесса аутентификации AP вычисляет групповой сессионный ключ GTK используя случайное значение GMK, шифрует GTK с помощью ключа шифрования ключей KEK (Key Encryption Key, пздц...), также являющегося частью PTK. Процесс вычисления GTK в принципе похож на вычисление PTK, и для упрощения и без того сложного рассказа мы вполне можем его опустить, нам оно сейчас не надо. Важно то, что вычисленное и зашифрованное значение группового сессионного ключа GTK передается в третьем пакете хендшейка (от AP к клиенту), равно как и новое значение MIC, смысл которого (помимо контроля целостности сообщения) убедить клиента что AP знает и умеет вычислять PTK, а значит не является Fake AP и к ней можно подключаться. Новое значение MIC вычисляется аналогично предыдущему как HMAC-MD5(KCK, EAPOL frame с зануленным полем MIC) и для нас является важнейшим параметром. Почему? Ответ в следующем абзаце. Итак, получив от АР третий пакет, клиент расшифровывает ключ GTK, рутинно проверяет значение MIC и если все в порядке, вычисляет MIC еще раз по той же схеме и отправляет в сторону AP четвертый пакет с очередным новым значением MIC, получение которого означает для AP что ключи шифрования на клиенте установлены успешно и теперь можно гнать зашифрованный трафик.

    Теперь перейдем к тому, зачем мы морщили ум и все это писали и читали.
    При подборе паролей к WPA хендшейкам иногда складывается ситуация когда пароль подобрался по хендшейку (ура!), причем самыми разными программами включая aircrack-ng, но увы "не подходит" к сети. Чисто физически причин подобному явлению может быть несколько, однако учитывая сложность процесса аутентификации и количество циклов хеширования данных на всех этапах, все нюни про нестабильность приема сигнала, интерференцию и помехи с соседних каналов и т.д. можно смело отбросить и остается только одна причина - пока мы ловили хендшейк кто-то (а зачастую это и есть сам "хакер") пытался подключиться к АР c неправильным паролем. В результате мы имеем "обрезанный" заведомо левый хендшейк из двух первых ключевых пакетов, в котором MIC есть только во втором пакете, идущем (внимание!) от клиента к АР. А значит, подбором мы найдем пароль "верный" по версии клиента, но неверный для АР. Имея в своем распоряжении третий ключевой пакет от АР к клиенту, мы без всяких сомнений можем убедиться, что АР умеет вычислять PTK (еще бы!), а значит, быть уверенными, что найденный пароль верен для точки доступа. Строго говоря, для полноценной атаки достаточно только 2-го и 3-го ключевых пакетов, т.к. параметр ANonce передается и в первом, и в третьем.
    Если же никто не мешал "истинному" клиенту аутентифицироваться на собственной точке доступа, а нам в силу различных причин (интерференция, помехи, бла-бла-бла) от всего хендшейка достались только два первых пакета, но в целости и сохранности - не беда, это вполне рабочая ситуация и моя практика показывает, что в подавляющем большинстве случаев из двух первых пакетов удается подобрать вполне себе неплохой парольчик.
    Самая хреновая ситуация когда ключевые пакеты битые. Тогда пароль будет либо неподобрать вообще, либо (что крайне сомнительно и я бы сказал невозможно) он подберется неверно.

    Еще один важный вывод - все ключевые пакеты всегда должны относиться к одному хендшейку. Виною тому случайные числа ANonce и SNonce, различные для разных сессий. Взяв первый и второй пакет (или второй и третий) от разных хендшейков, успеха не добьешься.

    Небольшой апдейт:

    Еще легче понять ситуацию можно разглядывая формат всеми любимого файла .hccap, вот он:

    [​IMG]

    Что мы видим? Сначала идут компоненты PTK: ESSID, BSSID, MAC клиента, ANonce (1 или 3 пакет), SNonce (2-й без вариантов), потом один EAPOL frame (2 или 3 пакет) и MIC соответствующий этому пакету, и всё, больше ничего нет!

    При этом если EAPOL frame и его MIC взяты из второго ключевого пакета - всего лишь невозможно проверить умеет ли AP вычислять PTK, т.е. подходит ли к ней возможный пароль. Если из третьего - никаких проблем.

    Какие могут быть варианты если у нас только первых два пакета?
    1. Пароль не найден - неопределённость (пароля нет в словаре, пакеты от разных хендшейков, просто битые пакеты)
    2. Пароль найден но не подходит - кто-то подключался с неправильным паролем в момент снятия хендшейка
    3. Пароль найден и подходит - здесь всё понятно

    А если есть второй и третий? Всё то же самое, кроме п.2

    \\ добавил в Карту раздела.
     
    #1 gpuhash, 17 Oct 2015
    Last edited by a moderator: 18 Oct 2015
    WELK, AlexSP, joelblack and 21 others like this.
  2. Buran

    Buran Elder - Старейшина

    Joined:
    25 Feb 2011
    Messages:
    1,193
    Likes Received:
    6,597
    Reputations:
    109
    Если уж меня процитировали, то отвечу. Моя практика показывает, что в большинстве случаев неудача при подборе пароля является результатом битых пакетов в перехваченном файле. Особенно если перехват сделан с помощью besside-ng. Пакеты от разных хэндшейков определяются сразу по счётчику и по времени прибытия, в расчёт не берутся и отсекаются сразу.
    Логично. Да вот besside-ng никогда не собирает 3-ий пакет, следовательно атака на 1 и 2 "неполноценна"!? Ваши слова.
    А многие, если не большинство новичков, используют именно besside-ng в разных "обёртках".
    И что в итоге получили?
    Путём долгих и кропотливых разбирательств в сути происходящих процессов при аутентификации клиента на точке, в итоге мы и пришли к тому, что вероятность наличия пароля в "неполноценном" хэше с пакетами "1/4 + 2/4" около 50%. Именно "наличие", а не вероятность "нахождения".

    Для новичков столь подробное углубление в детали слишком утомительно и трудно для восприятия. К тому же в интернете уже давно полно таких статей - изучай на здоровье если есть желание. Я же в двух(!) предложениях изложил самую суть. Всем понятно - все довольны. :) Чего и вам желаю!
     
    Af5G4337, hydra, sim900d and 3 others like this.
  3. 4pips

    4pips Elder - Старейшина

    Joined:
    15 Sep 2013
    Messages:
    526
    Likes Received:
    1,399
    Reputations:
    40
    Хорошая статья от участника gpuhash, можно сказать мат.часть.
    А я попробую описать то же самое чуть другими словами, может кому-то будет проще.

    Представьте, начинающий пентестер решает проверить на возможность подключения какую-то точку wi-fi. Он берет свой смартфон (планшет, нетбук, ноутбук) и пытается подключиться по паролям типа 12345678, 123123123, qwertyui, 1qaz2wsx и другим подобным «паролям простаков». После какого-то количества неудачных попыток он бросает это занятие и начинает изучение задачи.
    Через какое-то время ему удается записать переговоры точки с каким-то клиентом (хендшейк) и он начинает подбирать пароль перебором или просит помощи. И каково же его удивление, когда он сам или другие брутеры находят, что паролем, о котором идет речь в хендшейке, является один из тех «паролей простаков», которые он уже пробовал, но они не подошли. А все дело в том, что те гаджеты, на которых начинающий пентестер пробовал подключиться к точке, продолжают попытки подключения по последнему испробованному неудачному паролю и пойманный хендшейк – это как раз запись этих самых попыток.
    Были случаи, когда начинающий пентестер уверенно утверждал, что он не пробовал найденный в хендшейке пароль. Брутеры же настаивали, что в хендшейке именно такой пароль, какой они называют, хотя он не позволяет подключиться к точке. Это значит, что кто-то еще пытался подключаться к точке и так же бросил свои попытки не удалив эту точку из списка возможных в своем гаджете, и именно эти продолжающиеся попытки подключения и были записаны в хендшейк. Почти невероятно, но возможно, что точку пытаются изучать сразу два начинающих пентестера! И как же диагностировать такую ситуацию?

    Наибольшее распространение получила запись переговоров (хендшейка) в файлы формата .cap/.pcap. Их содержание можно посмотреть в программе wireshark. В мат.части выше сказано, что если есть три из четырех или все четыре ключевых пакета, то можно утверждать, что клиент успешно подключился к точке. Если только первые два пакета из четырех, то этого утверждать нельзя, это вполне могли быть и шальные попытки подключения с неправильным паролем.
    Еще в мат.части выше сказано, что для возможности подбора пароля необходимо наличие в хендшейке «привязки» к названию точки wi-fi. Как правило для «привязки» используют пакет Beacon frame, но еще подойдут Probe Response или Association Request (смотреть в wireshark). В сети очень во многих местах в инструкции о том, как пользоваться программой CommViewforwifi написано, что beacon пакеты не нужны и предлагают поставить галочку на Игнорировать beacon. Это странно, потому что эти пакеты необходимы для «привязки» в процессе перебора в любой программе. (Встречали фразу «нет бекона»?)

    Одной из программ для подбора паролей является hashcat. Для нее необходимо провести конвертацию хендшейка из .cap файла в .hccap, при которой из файла .cap берется только минимум необходимых данных. Конвертируют обычно утилитой aircrack-ng, которая до сих пор развивается и некоторые ее бета версии глючно проводили конвертацию. Чтобы минимизировать возможность глюков, рекомендуется оставлять в .cap файле лишь необходимый минимум - лишь пакет-«привязку» и пару ключевых пакетов, желательно 1-й и 2-й (Key (Message 1 of 4) и Key (Message 2 of 4)). Вот почему большинство утилит и скриптов для ловли хендшейков, получив эти пакеты сразу заканчивают запись в .cap файл, а некоторые даже удаляют лишние ненужные пакеты. Казалось бы, для уверенности, что подбирается не шальная попытка подключения, нужно выбирать 2-й и 3-й ключевые пакеты, но брутеры на форумах пишут, что самый лучший вариант с точки зрения минимизации возможного пропуска пароля (а такое случается) - это оставлять для перебора или конвертации 1-й и 2-й ключевые пакеты. Наличие 3-го ключевого пакета в хендшейке лишь убеждает, что это было реальное подключение, а не попытка. Для перебора 3-й ключевой пакет не нужен при наличии 1-го и 2-го.
    В мат.части выше упоминалось, что ключевые пакеты должны быть близки по времени друг к другу (принадлежать одной сессии переговоров). При этом пакет-«привязка» может быть далеко по времени, даже вставлен из другого хендшейка другой календарной даты. Каков временной диапазон сессий у различных устройств сказать трудно. Были случаи успешного подбора пароля по ключевым пакетам с разницей в 12 секунд, а бывало, что 6 секунд -это уже разные сессии и пароль не находился (находился потом в другом, правильном хендшейке). Считается, что интервал до 1 секунды – это хорошо, а в идеале не более 0.05 секунды.
    Еще пакеты могут быть неполными, как говорят «битыми». В wireshark сильно "битые" пакеты выделяются красным. Но бывает так, что не хватает совсем немного данных или они не полностью соответствуют стандартам, и тогда wireshark указывает на это подсвечивая часть данных в пакете голубым цветом во втором окне (если встать на интересующий пакет). Иногда с такими, отмеченными голубым пакетами подобрать пароль не получается, хотя процесс перебора идет как обычно, а иногда получается. Видимо это зависит от устройств и от характера "голубой" проблемы - вопрос в стадии изучения.

    Теперь должно быть понятно, почему брутеры просят предоставлять для перебора хендшейк в виде .cap/.pcap файла. Они предпочитают самостоятельно выбрать пакеты и, при необходимости, самостоятельно конвертировать его прежде чем начать перебор. А если найденный пароль не позволит подключиться к точке, то отсутствие 3-го и 4-го ключевых пакетов в хендшейке даст одну из возможных причин.
     
    #3 4pips, 18 Oct 2015
    Last edited: 21 Oct 2015
    esemyuron, Af5G4337, hydra and 16 others like this.
  4. gpuhash

    gpuhash Elder - Старейшина

    Joined:
    22 Sep 2011
    Messages:
    430
    Likes Received:
    1,287
    Reputations:
    94
    Не надо передергивать.
    Написано "для полноценной атаки достаточно только 2 и 3 пакетов", т.е. все четыре не нужны. Не написано, что хендшейк из 1 и 2 пакетов является неполноценным. Далее по исходному тексту разбираются все возможные ситуации.

    Да ничего подобного, я в корне не согласен, что если в хендшейке два пакета, то вероятность что он рабочий 50%. Ну бред же. Неполноценным хэндшейк может быть и с третим битым пакетом. Почему второй пакет может быть битым, а третий нет? Заколдован?
    И откуда вообще такая цифра в 50%? Я про вероятность нахождения пароля кстати вообще нигде не говорю.

    В последнем абзаце вроде четко указано - разница между 1/2 и 2/3 наступает только в случаях когда пойман левый хендшейк. Именно левый, когда клиент вводил неверный пароль и получил отлуп. Этих случаев 50% что ли? Или я что-то не так понимаю в хендшейках.

    Вот из-за таких скоропалительных заявлений про 50% люди будут выкидывать годные хендшейки.
    Смысл этой статьи как раз разобраться какой хендшейк годный, а какой нет.
     
    #4 gpuhash, 18 Oct 2015
    Last edited: 18 Oct 2015
  5. Buran

    Buran Elder - Старейшина

    Joined:
    25 Feb 2011
    Messages:
    1,193
    Likes Received:
    6,597
    Reputations:
    109
    Никаких "передёргиваний" нет и в помине. Только ваши слова. Раз существует атака полноценная, то и неполноценная тоже обязана существовать! Иначе такие заявления - просто выдумка... Бред? :)

    Ваше право. Мне практика как-то ближе, чем рассуждения на тему "может быть - не может быть"... "...потому что не может быть никогда". А вот на практике и выходит те самые 50 на 50. Се-ля-ви.
    Вот где "бред"! :) Выкинуть годный хэш - убыток на миллион! Лучше поймать один хороший хэндшейк, чем десяток "обрезанных" - вероятность взлома выше. Потому что валидный пароль в нём присутствует, хоть и в виде хэша.
    Не согласны - ваше дело, "каждый выбирает по себе: женщину, религию, дорогу"... :)
     
    daemon_mors, Payer and ms13 like this.
  6. gpuhash

    gpuhash Elder - Старейшина

    Joined:
    22 Sep 2011
    Messages:
    430
    Likes Received:
    1,287
    Reputations:
    94
    На этом обсуждение предлагаю прекратить, ибо моя практика как раз доказывает обратное, и при этом полностью согласуется с теорией.
     
  7. Buran

    Buran Elder - Старейшина

    Joined:
    25 Feb 2011
    Messages:
    1,193
    Likes Received:
    6,597
    Reputations:
    109
    Согласен. Тем более что и моя практика никак теории не противоречит, если вникнуть. :)
     
  8. HaronSVD

    HaronSVD New Member

    Joined:
    16 Sep 2015
    Messages:
    25
    Likes Received:
    1
    Reputations:
    0
    Господа, так чем же лучше ловить хендшейк и проверять его на пригодность?
     
  9. TOX1C

    TOX1C Elder - Старейшина

    Joined:
    24 Mar 2012
    Messages:
    810
    Likes Received:
    1,068
    Reputations:
    17
    ловить стандартным инструментом, airodump. Всякие автоматические перехватчики типа besside или kismet лучше не использовать, они обрезают хендщейк до 2 пакетов, это делает утилита wpaclean, которая неоднократно замечена в порче хендшейков.
    Проверять вручную, открыв cap файл в wireshark и найти где хендшейк.
    Вот так выглядит идеальный, 1000% рабочий хендшейк.
    [​IMG]
    Но это только хендшейк, а для успешного перебора ещё нужен пакет с именем сети, Beacon Frame или Probe Responce пакет подойдет прекрасно.
    ***
    Вот так в идеале должен выглядеть тот файл, который пойдет на перебор. Ни один брутер не придерется ни к чему, а для вас - это 1000% процентов гарантии успешного перебора, в случае, если пароль найдется в словарях.
    [​IMG]
     
    #9 TOX1C, 21 Oct 2015
    Last edited: 21 Oct 2015
    wh0nixx, PERAND75, uzeerpc and 12 others like this.
  10. binarymaster

    binarymaster Elder - Старейшина

    Joined:
    11 Dec 2010
    Messages:
    4,164
    Likes Received:
    8,047
    Reputations:
    105
    Code:
    wlan.fc == 0x8000 || wlan.fc == 0x5008 || eapol.type == 3
    Вот вам быстро-фильтр для Wireshark, который будет показывать необходимый минимум пакетов. Первое выражение пропускает Beacon frame, второе - Probe Response, а третье - собственно хендшейки.

    Остаётся только посмотреть на тайминги, чтобы выбрать идеальный набор пакетов для выкладывания в соответствующей теме. ;)
     
    Af5G4337, eu8cc, alian and 3 others like this.
  11. AlexRU

    AlexRU Well-Known Member

    Joined:
    11 Oct 2015
    Messages:
    98
    Likes Received:
    465
    Reputations:
    4
    из всех скриптов, программ для автоматического перехвата хендшейков, которые встречались мне, только одна программа захватывает полный пакет хендшейка -это minidwep-gtk, кроме того сохраняет свой результат в трех форматах .cap, .hccap и .wkp
     
  12. Buran

    Buran Elder - Старейшина

    Joined:
    25 Feb 2011
    Messages:
    1,193
    Likes Received:
    6,597
    Reputations:
    109
    Code:
    (eapol || wlan.fc.type_subtype == 0x08)
    А вот вам ещё фильтр - ничего лишнего.
    Code:
    wps.wifi_protected_setup_state == 0x02
    Для WPS.
     
    #12 Buran, 21 Oct 2015
    Last edited: 22 Oct 2015
    BEPMOPH, VladimirV, eu8cc and 3 others like this.
  13. TOX1C

    TOX1C Elder - Старейшина

    Joined:
    24 Mar 2012
    Messages:
    810
    Likes Received:
    1,068
    Reputations:
    17
    А теперь яркий пример того, для чего в реальности нужен полный шейк со всеми пакетами, и важны временные интервалы между пакетами.
    Пару часов назад (относительно времени написания сего поста) в тему с перебором был сброшен шейк, снятый с отличным сигналом, и к нему был прикреплен перечень промешенных словарей, в которых пароля, естественно, не нашлось.
    Качаем хендшейк, и смотрим что там есть.
    [​IMG]
    А там картина маслом: у пакетов нет временных отметок, да еще и один пакет подсвечен синим, с флагом R - означает, что пакет был передан повторно. На лицо использование софта для автоматической чистки cap файлов от мусора: cleancap или wpaclean, не важно. Важно то, что этот софт тупо видя первый и второй пакет, просто склеивает их в один файл.
    В теме была дана просьба переловить, и был сброшен новый, полный шейк. Посмотрим на него:
    [​IMG]
    То же самое, но теперь с подробностями: первый ключевой пакет был переотправлен + временная метка 64:81, в то время как остальная часть имеет метку 64:92. Может это не критично? Иногда такие шейки удается подобрать, но посмотрим внимательнее на 1 и 3 пакет. Напоминаю, что хеши в 1 и 3 пакете ДОЛЖНЫ быть одинаковыми, это указывает на то, что перед нами полный хендшейк.
    [​IMG]
    Всего лишь 2 байта разницы и пароль к хендшейку не подберется. Что собственно и произошло, испробовано масса словарей и уйма времени была потрачена ЗРЯ на подбор пароля к битому рукопожатию. А пасс оказался простым и из ходового словаря.
     
    #13 TOX1C, 20 Apr 2016
    Last edited: 20 Apr 2016
    Valeriios, BEPMOPH, uzeerpc and 15 others like this.
  14. pnzkav

    pnzkav New Member

    Joined:
    28 Nov 2015
    Messages:
    15
    Likes Received:
    3
    Reputations:
    0
    Вот спасибо ! Вот это разживали ! Эх мнеб пораньше эту инфу !
     
  15. m0tion

    m0tion Member

    Joined:
    18 Aug 2016
    Messages:
    8
    Likes Received:
    6
    Reputations:
    0
    Забудь про Windows.
    А если уж по теме, то есть Wireshark с фильтрами.
     
  16. m0tion

    m0tion Member

    Joined:
    18 Aug 2016
    Messages:
    8
    Likes Received:
    6
    Reputations:
    0
    Чем тебя Wireshark не устраивает?
     
  17. m0tion

    m0tion Member

    Joined:
    18 Aug 2016
    Messages:
    8
    Likes Received:
    6
    Reputations:
    0
    Открыть .cap файл, ввести фильтр. Очень долго.
     
    ivann likes this.
  18. hcker

    hcker New Member

    Joined:
    2 Jun 2017
    Messages:
    38
    Likes Received:
    0
    Reputations:
    0
    besside-ng до сих пор портит хендшейк?
     
  19. alian

    alian Member

    Joined:
    7 Dec 2009
    Messages:
    61
    Likes Received:
    52
    Reputations:
    0
    С чего бы вдруг? Нормально он ловит хэндшейки. Только по прежнему по 2 штуки.
     
  20. Mistral

    Mistral Well-Known Member

    Joined:
    30 Aug 2015
    Messages:
    1,913
    Likes Received:
    9,192
    Reputations:
    101
    Все хендшейки без временных меток и только с message 1 и 2-это лотерея.Анализировать невозможно,выбирать не из чего.
    В теме перебора полно таких проходило,где либо вообще ничего не находилось,либо были захвачены "левые" пароли.
    Если нравится такое,можно и дальше пользоваться besside.
    И в самой последней версии конвертера cap в hccapx для хэшкета https://hashcat.net/cap2hccapx/
    из-за отсутствия временных меток будете получать отказ вот такого вида и это правильно.

    Zero value timestamps detected in file: in ***.cap.
    This prevents correct EAPOL-Key timeout calculation.
    Do not use preprocess the capture file with tools such as wpaclean.
     
    Triton_Mgn, uzeerpc, alian and 2 others like this.
Loading...