Что такое DHT и Magnet-ссылки? Ошибка uTorrent — DHT ожидание входа.

DHT в БитТорренте используется для нахождения новых участников файлообмена.

При подключении к DHT сети БТ клиент устанавливает соединения с несколькими другими клиентами (узлами сети) и сам становится очередным узлом этой сети.

Для поиска пиров клиент посылает своим соседям по сети infohash нужного ему торрент файла. Они спрашивают у своих соседей, а те у своих, и таким образом через некоторое время по возможности находят ему других участников раздачи этого торрента.

DHT есть в клиентах BitTorrent (официальный), µTorrent, BitSpirit, BitComet, а также (несовместимо со всеми остальными) в Azureus.

В более общем смысле DHT означает децентрализованную распределенную систему для объединения большого количества постоянно исчезающих и появляющихся узлов и эффективной передачи сообщений между ними. На основе DHT структур можно строить более сложные системы, такие как P2P файлообмен, кооперативное веб кеширование, DNS сервисы и т.п.

Реализация DHT в БТ основана на варианте DHT, называемом Kademlia, и использует UDP протокол.

PEX

PEX (Peer exchange) - это обмен списками пиров между участниками одной и той же БТ раздачи.

В то время как DHT фактически образует независимую от БТ протокола сеть, PEX гораздо проще - это дополнительные сообщения между уже соединенными по БТ протоколу клиентами.

PEX может быть только вспомогательным средством получения пиров, хотя бы потому, что не может помочь подключиться к раздаче новым участникам.

PEX есть в клиентах Azureus, BitComet, µTorrent и BitTornado, причем в каждом клиенте по-своему, поэтому PEX между собой пользуются только одинаковые клиенты.

Функции

И DHT и PEX фактически выполняют основную функцию трекера - помогают участникам файлообмена узнать друг о друге. Они:
• снижают нагрузку на трекер: некоторые клиенты, получая пиров через DHT или PEX, реже обращаются за списком пиров на трекер
• поддерживают участников вместе в периоды, когда трекер временно недоступен

Кроме того, DHT может использоваться и как единственный источник информации о других участниках - если торрент файл сразу создавался без трекера (trackerless)

DHT/PEX и закрытые трекеры

На открытых трекерах, где каждый может скачать торрент и участвовать в раздаче, функции DHT и PEX служат на благо всего участников.

Закрытым трекерам в первую очередь важно, чтобы в раздачах могли участвовать только зарегистрированные пользователи, и чтобы они соблюдали определенные правила.

При первом обращении клиента закрытый трекер имеет возможность не допустить его к раздаче, просто не сообщая ему адреса других клиентов-участников. Поэтому для закрытого трекера важно, чтобы клиенты не получали эти адреса через DHT/PEX.

Private key

DHT и PEX появились в клиентах Azureus и BitComet примерно летом 2005 года. Администраторы многие закрытых трекеров были недовольны такой новой функциональностью, и поэтому стали запрещать на трекере эти новые версии клиентов.

Тогда разработчики клиентов предложили новый ключ внутри торрент файла: private. Если он равен 1, то клиент обязан для этого торрента автоматически отключать DHT/PEX независимо от желания пользователя.

Правильно настроенные закрытые трекеры сами принудительно вставляют private:1 во все торренты, выкладываемые на трекере, а также запрещают несколько устаревших версий клиентов (имеющих DHT или PEX, но еще не знающих про private key).

Пользователи трекера просто не могут на раздачах использовать DHT/PEX, и проблемы нет.

Заблуждение про статистику

Иногда встречается мнение, что включенный в клиенте DHT как-то влияет на учет статистики клиента, например "раздавал через DHT, значит статистика шла мимо трекера". Это неверно:

1. клиент рапортует статистику только на трекер , через DHT/PEX вообще никакого подсчета статистики не ведется
2. клиент рапортует трекеру суммарные данные об объемах им скачанного и отданного всем пирам, с которыми общался , независимо от того, узнал клиент об отдельных пирах через трекер, DHT или PEX, или тот пир вообще начал соединение сам. То есть даже если из-за DHT/PEX на раздаче появятся левые пользователи, клиент все равно сообщит на трекер все, что у них скачал и отдал.

Правильный учет статистики зависит только от состояния трекера: работает трекер - статистика учитывается, не работает - не учитывается. Только в случае длительно неработающего трекера DHT/PEX может играть косвенную роль, не давая постепенно затухнуть файлообмену на такой "раздаче без учета статистики".

1. Кроме того, часто пользователи просто забывают, что на их закрытом трекере все торренты private, и следовательно DHT/PEX в раздачах в принципе не используется.

Отключать ли DHT

Безусловно отключать DHT стоит в следующих двух случаях:

1) Вы качаете с закрытого трекера с системой passkey, на котором администраторы не хотят или не умеют делать все торренты private. Дело в том, что через DHT пользователи могут узнать passkey других пользователей, и нечестные пользователи могут использовать чужие passkey для скачивания под чужой учетной записью.

2) Вы качаете только с правильных закрытых трекеров. Если при этом в клиенте разрешить DHT, то получится, что клиент подключается к DHT сети, тратит на это трафик, но ни на одной раздаче DHT не использует.

На многих так называемых «приватных» трекерах торренты раздаются с установленным флагом, не позволяющим использовать сеть DHT . Цель этого - не допускать раздачу материала клиентам, не зарегистрированным на данном трекере. Однако для пользователя это означает уменьшение количества сидеров, иногда - значительное.

Ниже мы рассмотрим, как отключить такое ограничение в популярных торрент-клиентах. Будет рассмотрен общий подход, а также практическое применение к актуальной версии uTorrent и qBitTorrent .

1. Вступление.

Мы попытаемся не просто создать готовое решение, а проанализировать основные шаги так, чтобы читатель мог даже в случае изменение в будущем самостоятельно снимать ограничения DHT в новых версиях клиентов.

2. Подготовка.

1. Актуальный дистрибутив торрент-клиента.
2. Архиватор, способный распаковывать инсталляционные файлы, например в случае uTorrent и qBitTorrent - 7-zip .
3. Распаковщик исполняемых файлов клиента, в случае uTorrent - UPX .
4. IDA или любой другой дизассемблер.

• в случае uTorrent - файл Carrier.exe;
• В случае qBitTorrent - файлы qbittorrent.exe и qbittorrent.pdb (либо их 64-разрядные аналоги, если будет изменяться 64-битный клиент).

2. Поиск и изменение кода.

Call TestPrivate test eax, eax jz NotPrivate
по этой причине сам патч будет выражаться в простом изменении одного байта кода 74 => EB, превращающего условный переход jz в безусловный и таким образом игнорирующий проверку на «приватность».

Остаётся найти данную функцию.

На самом деле это совершенно не сложно, учитывая специфику данного кода и наличие ключевого слова «private». Откроем распакованный файл клиента uTorrent в IDA и выполним поиск по данному ключевому слову:

Видно, что с указанным ключом в uTorrent присутствует всего три участка кода. Вот как они выглядят:

Совершенно очевидно, что необходимый нам код - это третий в списке, поскольку только он представляет собой вызов функции и проверку возврата на ноль с последующим условным переходом.

Наша задача заключается в простом замене функции, как мы уже упоминали ранее:

По сути, это замена характерной последовательности
68 00 FF 69 00 E8 19 F1 FA FF 85 C0 74 07
на
68 00 FF 69 00 E8 19 F1 FA FF 85 C0 EB 07

В случае qBitTorrent задача упрощается ещё больше, поскольку разработчик вложил pdb-файл в установщик, так что названия функций будут более очевидными, и поиск по ключевому слову упрощается:

Так выглядит сам код проверки:

Как видите, по сути он неотличим от uTorrent. Патч будет аналогичным:

E8 20 CB FA FF 84 C0 74 59
на
E8 20 CB FA FF 84 C0 EB 59

QBitTorrent также предлагается в виде 64-разрядного клиента. Действия в отношении него буду совершенно аналогичными, за исключением того, что нам потребуется 64-разрядная версия IDA. Результат поиска по ключевому слову ожидаемо аналогичен:

Вид соответствующей функции несколько отличен, однако суть осталась та же:

Ну и соответствующий патч, здесь это будет три байта:

Это замена характерной последовательности
E8 8F 0E F8 FF 4C 8D 3D 54 E5 46 01 83 CB FF 84 C0 0F 84 DB 00 00 00
на
E8 8F 0E F8 FF 4C 8D 3D 54 E5 46 01 83 CB FF 84 C0 E9 DC 00 00 00 00

3. Итоги

Для автоматизации процесса мной были созданы два патчера для актуальных версий uTorrent и qBitTorrent. Для uTorrent патчер также распаковывает исходный инсталлятор. Файлы можно скачать здесь:

Патчер qBitTorrent версии x32
Патчер qBitTorrent версии x64
Патчер распакованного файла uTorrent
Silent всё-в-одном патчер uTorrent : распаковывает, патчит и обратно упаковывает инсталлятор, а также распаковывает, патчит и упаковывает обратно уже установленный uTorrent (при условии, что установочная папка - по умолчанию, то есть "%userprofile%\AppData\Roaming\uTorrent\"

Одним из краеугольных протоколов децентрализованных сетей без преувеличения является DHT (Distributed Hash Table). Он был изобретен в конце 90-х годов для решения задачи индексации и поиска среди большого количества данных. Несмотря на то, что сами данные (файлы и т.д) могут храниться на разных серверах, таблица ссылок на данные потенциально может быть бесконечно большой, что исключает вариант ее хранения в одном месте. Кроме того, важной задачей была защита от атак на центральный узел-справочник. Как раз для решения этих двух проблем был разработан DHT.

DHT решает проблему поиска контента (информации) по его хеш значению (InfoHash).

Условия, в которых работает протокол:

1. участники друг друга не идентифицируют (между ними нет доверия);
2. участников может быть неограниченное количество;
3. отсутствует центральный сервер;
4. контент хранится у самих участников (заранее не известно у каких именно);
5. каждый участник может поддерживать связь (открыть сетевое соединение и вести обмен сообщениями) только с ограниченным количеством других участников.

Для участника, который ищет данные, задача состоит в том, чтобы получить сетевой адрес другого участника, который хранит порцию контента с определенным InfoHash.

Среда, в которой контент хранится, и по которой выполняется поиск, получается полностью распределенной - множество компьютеров, которые запустили определенную версию протокола DHT и ведут независимый обмен сообщениями.

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

В соответствии с правилами протокола каждый участник выделяет память (5-50 МБ) для таблицы. В этой таблице он хранит соответствия между InfoHash и контентом, а также между идентификаторами участников и их сетевыми адресами. Все записи в этой таблице отсортированы по первому столбцу (идентификатор или InfoHash) и она постоянно обновляется по следующим правилам:

1. Если данный участник в ходе общения с другими узнает о новом для него участнике (идентификатор + сетевой адрес), то эта запись вносится в таблицу.
2. Если участник скачивает или генерирует контент, то от этого контента вычисляется хеш значение (InfoHash) и это соответствие также вносится в таблицу.
3. Если таблица по размеру приближается к пределу выделенной памяти, то из нее удаляются те строки идентификатор, которых больше всего отличается от идентификатора самого участника.

Таким образом, удаление осуществляется только самых верхних и самых нижних в таблице строк. Через определенный промежуток времени после начала работы участником будет сформирована собственная таблица, в которой будут храниться идентификаторы, максимально приближенные (т.к. они отсортированы в порядке увеличения) к его собственному идентификатору. Соответственно, каждый участник хранит список идентификаторов участников (и ссылки на контент), которые максимально приближены к его собственному идентификатору.

Активному участнику протокола для поиска необходимого контента нужно знать только соответствующий InfoHash. Процедура поиска участником конкретного контента начинается с обращения в собственную таблицу. Из таблицы выбирается строка, которая по идентификатору максимально приближена к InfoHash. В этой строке будет храниться сетевой адрес того участника, который по идентификатору ближе всего находится к искомому контенту. Тогда ищущий участник открывает соединение по этому адресу и посылает запрос на поиск по InfoHash. В ответ на запрос он получает либо искомую порцию контента, либо сетевой адрес участника, который еще больше приближен к этому контенту. Запросы будут повторяться, пока искомый контент не будет получен. В случае неудачи запросы можно повторить через определенный промежуток времени.

Получается, что каждый участник локально хранит и обновляет такую таблицу соответствия как показано на рисунке. Быстрый поиск и вставка новых строк возможна благодаря отсортированному списку. Заметим, что у участников с близкими идентификаторами часть таблицы может совпадать.

Для повышения надежности и скорости поиска запросы выполняются параллельно по нескольким приближенным участникам сети. На практике такой механизм поиска обладает достаточно высокой степенью надежности, не поддается цензуре и хорошо масштабируется. Количество участников в сети и количество порций хранимого контента практически не ограничено. Существует дюжина модифицированных версий данного протокола, нацеленных на повышение различных его свойств, таких как скрытность поиска, увеличенный объем хранимых данных, устойчивость к атакам (sybil attack), ускоренный поиск популярного контента, обеспечение целостности запросов и ответов.

Протоколы DHT являются незаменимым компонентом многих популярных проектов: I2P, IPFS, GNUnet, Bittorrent, Tox.

До появления DHT подобную задачу поиска контента решали с использованием централизованных сервисов или группы централизованных сервисов, которые синхронизируются между собой. Также у них реализован публичный API для запросов и, как правило зарегистрировано доменное имя. По сути такие сервисы хранят полные таблицы соответствия между InfoHash и сетевыми адресами, которые по объему получались значительно больше чем 50 МБ. Примером такого сервиса является Torrent Tracker, как известно, такие трекеры легко поддаются цензуре и даже блокированию.

Самая распространенная атака на протоколы DHT заключается в том, что злоумышленник может почти полностью заблокировать один конкретный контент. Для этого ему необходимо запустить несколько десятков специально модифицированных узлов. Модификация заключается в том, что в качестве идентификатора участника выбирается не случайное число, а число близкое к целевому InfoHash (контент который нужно заблокировать). Также эти узлы иначе реагируют на запросы поиска по этому InfoHash, отдавая в ответ не существующие сетевые адреса. Тогда получается, что большое количество фейковых участников “окружают” целевой контент, за счет чего к ним обращаются практически все участники которые ищут этот контент. Таким образом доступ к одному конкретному контенту можно временно заблокировать.

Illustration by Katerina Krashtapuk

Часто многие пользователи торрент-клиента uTorrent сталкиваются с ошибкой «dht ожидание входа» в процессе загрузки или раздачи файлов. При возникновении подобной ошибки обычно скорость всех активных загрузок падает до нуля и закачки останавливаются. Рассмотрим некоторые причины и способы устранения данной ошибки.

Причины возникновения ошибки uTorrent — dht ожидание входа могут быть разные, но все они так или иначе связаны с вашим сетевым подключением и его настройками, попросту с вашим подключением к интернету.

Вот некоторые основные причины возникновения ошибки «dht ожидание входа»:

Не настроен форвардинг портов для UDP пакетов

Блокированы входные развертывающие узлы router.bittorrent.com и router.utorrent.com. uTorrent по данным адресам получает IP адреса остальных узлов DHT.

Неправильная конфигурация uTorrent

Так же могут быть и другие причины, но выше приведенные причины одни из основных при возникновении данной ошибки.

Теперь рассмотрим варианты решения данной проблемы.

Форвардинг портов необходим для того, чтобы к вашему компьютеру могли подключаться из внешней сети, т.е. из интернета. Обычно на многих роутерах это все работает по умолчанию, но для uTorrent важно, чтобы так же перенаправлялись и пакеты UDP. В настройках вашего роутера нужно отредактировать перенаправление нужных пакетов на ваш компьютер.

Если у вас заблокированы узлы router.bittorrent.com и router.utorrent.com то uTorrent не сможет подключиться к ним и получать адреса узлов DHT. Для того, чтобы проверить, заблокированы ли данные узлы, необходимо в командной строке windows сделать команду ping router.bittorrent.com и ping router.utorrent.com если пакеты возвращаются и есть связь с данными узлами, то этот пункт можно отбросить, если же в командной строке будет написано, что данный узел или сервер не доступен, значит данные узлы блокируются или файерволом или антивирусной программой. Нужно отключить в защитных программах фильтрацию пакетов по данным адресам.

Иногда причина бывает очень банальна, и все решается постой переустановкой торрент-клиента uTorrent, но перед тем как устанавливать поверх старой версии новую, необходимо полностью удалить старый клиент, включая все файлы настройки и т.п. Только после этого устанавливать новую или обновленную версию уТоррента. Если вы не хотите удалять ваш старый клиент, то можно как минимум попробовать удалить файлы настроек dht.dat и dht.dat.old из папки %APPDATA%\uTorrent. После запуска программы эти файлы пересоздаются заново с новыми настройками.

Здесь мы рассмотрели самые популярные причины возникновения ошибки программы uTorrent — dht ожидание входа. Но это не исчерпывающий список причин и способов их решения, на различных компьютерах и сетевых конфигурациях причины могут быть разные, необходимо пробовать различные решения для удаления данной ошибки.