Что такое dht в кроссаут

Обновлено: 06.07.2024

DHT (англ. Distributed hash table распределенная хэш-таблица) — это протокол, который позволяет битторрент-клиентам находить друг друга без использования торррент-трекера. DHT используется для поиска одноранговых узлов, в основном в дополнение к трекеру.

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

Фактически DHT содержит информацию о 90% всех раздач. Существует множество поисковых систем, которые анализируют сеть DHT в режиме реального времени и осуществляют поиск по активным торрентам.

Поисковики по сети DHT индексируют имена файлов в раздачах и выдают в результатах поиска magnet-ссылки на них. Поэтому рекомендуем искать раздачу по возможному имени торрент-файла на латинице, например "elki novie 2017".

Все результаты можно сортировать по релевантности, популярности, размеру и дате. Чтобы загрузить необходимый торрент, нужно просто нажать на Magnet Link и она автоматически добавится в торрент-клиент.

Поисковики по DHT являются удобной альтернативой торрент-трекерам. Приятного пользования!

Kademlia DHT: Основы

Здравствуйте!
В этой статье, как и, надеюсь, в последующих, я хочу рассказать об одной из современных структурированных пиринговых сетей. Данный материал включает в себя мою переработку документаций, описаний и статей, найденных по теме. В качестве введения представлена общая краткая теория p2p-сетей, DHT, а уж затем следует основная часть, которой посвящена заметка.

1. Общая теория p2p

Распределение данных, процессорного времени и других ресурсов между пользователями заставляют искать решения организации сетей разного уровня и взаимодействия.
На смену клиент-серверному взаимодействую приходят сети p2p (point-to-point), чтобы предоставить больший уровень масштабируемости, автономности, анонимности, отказоустойчивости.
Далее будет приведена общая классификация.

  • Централизованные
  • Гибридные
  • Полностью децентрализованные
  • Сервер представляет узкое место сети. Отказ приводит к полной потере работоспособности системы.
  • Законодательная уязвимость сервера
  • При значительном росте популяции сети сервер подвергнется своего рода DDoS атаке, приводящей к его отказу.
  • Весь процесс от поиска до получения файла проходит по максимально короткой схеме: поисковый запрос к серверу, выдача результатов от сервера, соединение с нужным узлом.
    При этом вполне возможен поиск не только по точным совпадениям, что немаловажно, как будет показано далее.

Минусы и плюсы зависят от степени «гибридности» — какие характеристики она наследует от централизованных, а какие от децентрализованных (о которых речь пойдет далее).

Децентрализованные — Данный тип сетей подразумевает полное отсутствие серверов. Таким образом, исключается узкое место из сети.

  • Необходимы определенные алгоритмы маршрутизации и поиска, порою не гарантирующие достоверности результата.
  • Для включения в такую сеть нужно знать координаты хотя бы одного узла, следовательно, списки с определенным количеством адресных данных участников сети необходимо публиковать в общедоступных источниках (например, на сайтах). Сам процесс подклчючения подразумевает стадию начальной загрузки/инициализации (bootstrap), поэтому такие списки еще называются bootstrap-листами.
  • Исключение сервера позволяет сети быть отказоустойчивой, даже при быстро растущем/падающем количестве участников.
  • Большая степень защищенности от цензуры

При проектировании топологии и протоколов структурированных сетей оптимальным считается выполнение соотношений:
— Размер таблицы маршрутизации на каждом узле: O(log(n))
— Сложность поиска: O(log(n))

2. DHT

DHT (Distributed Hash Table) — распределенная хэш-таблица. Данная структура зачастую используется для децентрализованных топологий. Однако, это не единственный выбор (как подсказывает литература, впрочем, здесь лучше заняться дальнейшим самостоятельным поиском).
Для каждого значения (данных) на каждом узле вычисляется по определенным правилам хэш (например, с помощью SHA-1), который становится ключом. Также, вычисляется идентификатор узла (той же длины, что и хэш, а зачастую, той же функцией). Таким образом, каждый узел сети обладает своим идентификатором. Ключи публикуются в сети. Узел несет ответственность за ключи таблицы, которые близки к нему по определенной метрике (т.е. расстоянию), здесь подразумевается «похожесть» ключа на идентификатор, если опустить язык математики. Благодаря этому, каждый узел занимает свою зону ответственности при хранении ключей и связанных с ней информации (координаты узла, на котором расположено значение). Это позволяет определенным образом организовать алгоритм поиска по точным значениям (сначала вычислить ключ значения для поиска, например, имени файла, а затем искать этот ключ, направляя запросы к узлу, ответственному за него через посредников, предоставляющих полный путь).
DHT в полной степени обеспечивает отказоустойчивость и масштабируемость. В сочетании с Peer Exchange, например, DHT позволяет перехватить функции Torrent-трекера.

3. Kademlia

Метрика

Создателями данной топологии являются Petar Maymounkov и David Mazières. В основе работы протокола и построения таблиц лежит определения расстояния между узлами через XOR-метрику:
d(x, y) = x XOR y. Важно отметить, что расстоянием является результат операции XOR, интерпретируемый, как число, а не количество различающихся бит (такой критерий тоже может порождать метрику в пространстве ключей/идентификаторов). Т.е. при длине ключа 4 бита: d(2,5) = 0010 XOR 0101 = 0111 = 7.
XOR метрика удовлетворяет всем аксиомам метрики:

  1. d ( x , y ) >= 0 // Неотрицательность
  2. d ( x , y ) == 0 <=> x == y
  3. d ( x , y ) = d ( y , x ) // Симметричность
  4. d ( x , y ) <= d ( x , z ) + d ( z , y ) // Неравенство треугольника

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

Таблица маршрутизации

На вычислении расстояний между узлами (посредством применения метрики к их идентификаторам) базируется алгоритм построения таблиц маршрутизации.
Каждый i-ый столбец таблицы ответственен за хранение информации об узлах на расстоянии от 2^(i+1) до 2^i. Таким образом, последний столбец для узла 0111 может содержать информацию о любых узлах 1xxx, предпоследний об узлах 00xx, еще на уровень ближе — об узлах 010x.

Конечно, в реальной сети, применяется обычно длина ключа в 128, либо в 160 бит. Зависит от реализации.

Далее, вводится ограничение на число хранимых узлов на каждом уровне, K. Поэтому столбцы таблицы, ограниченные таким K, называют K-buckets (к сожалению, русский эквивалент, звучит совсем неблагозвучно).


Если рассмотреть бинарное дерево поиска, в листах которого лежат идентификаторы узлов, становится понятно, что такая структура K-buckets не случайна: каждый узел (а на примере 110) получает знания хотя бы об одном участнике каждого поддерева (для 110 выделенных залитыми овалами). Таким образом, каждый K-bucket отражает связь узла с не более, чем K участниками поддерева на уровне i.

Протокол
  • PING
  • STORE
  • FIND_VALUE
  • FIND_NODE

FIND_VALUE запрос, который, зачастую, повторяется для образования итерации, позволяющий найти значение по ключу. Реализует поиск значения в сети. Возвращает либо K ближайших узлов, либо само значение, в зависимости от достижения узла, хранящего искомые данные. Итерации прекращают как раз либо при возвращении значения (успех), либо при возврате уже опрошенных K узлов (значения нет в сети).

FIND_NODE запрос, используемый для поиска ближайших K к заданному идентификатору (поведение сходно с FIND_VALUE, только никогда не возвращает значение, всегда узлы!). Используется, например, при присоединении узла к сети по следующей схеме:
— Контакт с bootstrap узлом
— Посылка запроса FIND_NODE со своим идентификатором к bs узлу, дальнейшая итеративная рассылка
— Обновление K-buckets (при этом обновляются как K-buckets нового узла, так и всех, мимо которых проходил запрос (здесь на руку симметричность метрики XOR))

Как видно, протокол в своей спецификации практически не покрывает вопросы безопасности, что нашло отражение в исследованиях и работах по атаке Kademlia-based сетей.
Из особенностей стоит подчеркнуть наличие репликации, времени жизни значения (необходимость повторного размещения через определенный промежуток времени), параллелизм при посылке запросов FIND_*, дабы достигнуть нужных узлов за более короткое время (обозначается α, в реализациях обычно равно 3). При каждом прохождении запросов происходит попытка обновить K-bucket, что позволяет держать таблицы маршрутизации максимально оптимальными.

4. Реализации

Прежде всего, самой известной сетью, базирующейся на Kademlia является Kad Network, доступная в aMule/eMule. Для bootstrap используются существующие узлы в eDonkey.
Khashmir — Kademlia-реализация на Python, использующаяся в BitTorrent
Из ныне развивающихся и активных библиотек я бы еще отметил
maidsafe-dht — C++ реализация инфраструктуры с поддержкой UDT и NAT Traversal.
Mojito — Java библиотека от LimeWire.

5. Что дальше?

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

Децентрализованное Torrent хранилище в DHT


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

Вместе с этой системой существуют команды для взаимодействия с ней. Их не так уж много, но для создания децентрализованной БД нужно всего два: put и get. Об этом и пойдёт речь далее.

По логике все могут понять. Put - это положить. А Get - это получить. Так вот достоверно положить с помощью команды Put можно до 1000 байт любой информации. И достоверно эта информация будет хранится в DHT около часа. Get - это получить, то что положили. Всё просто.

Команда Put имеет два вида. Первый - это положить без возможности изменения. Второй - положить с возможностью изменения. Т.е. можно мало того, что положить в DHT 1000 байт, так ещё и менять их, как хочется.

Что бы положить или менять изменяемые данные нужно 2 ed25519 ключа. Публичный и приватный. И каждый у кого есть эти два ключа может менять данные, как ему хочется.

напомню, как работают приватные и публичные ключи

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

На этом и можно построить децентрализованную БД

Вариантов много. Это дело вашей фантазии. Рассмотрим, например, такие:

Вариант 1.

У всех пользователей = пиров есть публичный и приватный ключ.

Пользователь 1 хочет изменить БД. Он получает содержимое DHT с помощью Get и публичного ключа. В полученных данных, может быть всё что угодно. У нас это будет sha1 ссылка торрента по которой можно скачать торрент. Её размер около 20 байт. По этой ссылке он скачивает торрент в котором находится БД. Изменяет БД. Генерирует торрент (получая sha1 ключ) и раздаёт его. Публикует Putом полученный sha1 ключ по которому уже можно скачать новую, изменённую БД.

Пользователь 2 хочет изменить БД. аналогично.

Для того что бы данные в DHT не пропали нужна регулярная синхронизация пиров. Синхронизация это Get с публичным ключом через udp. Очень малозатратно. И если данные изменились, то скачивание их. Это уже немного более затратно, но тут тоже можно ставить ограничение по скорости скачивания, например.

Если данные в DHT пропали, то пир, который хочет синхронизироваться просто делает Put с последними данными, какие у него есть, либо с чистыми данными.

А теперь немного о том, почему это БД, а не обмен файлами

В 1000 байт можно зашить всё что угодно. А в передаваемую БД бесконечное количество информации. Так как пользователь не знает публичного и приватного ключа, то он не может сам публиковать что-то. Это может только программа. А программа в зависимости от данных в этих 1000 байт может делать всё что угодно. Может получить блокировку пользователя и перевести его только в режим чтения. Получается это БД с правами доступа на изменение определённой информации. Особенно, это будет похожим на БД, если скачиваемые данные шифровать и хранить в одном файле без расширения.

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

Теперь о недостатках и проблемах

Например, если пользователь 1 опубликовал новый хеш, изменённой БД, но не стал раздавать его. В DHT можно хранить 5 записей sha1 это 100+байт всего и если какой либо из пользователей не смог скачать изменённую версию, то он качает следующую из 5ти и затем перепубликовывает на ту, которая скачивается. Соответственно другие пользователи уже не будут пытаться скачать, то что не качается и получат БД быстрее. Чем больше пользователей, тем лучше и быстрее будет работать БД.

Главная проблема подобной системы это время ожидания. Публикация (Put) занимает от 20 до 60 секунд + время что бы кто-то скачал эти данные. Если пользователь не выключает программу, то это только 20-60 секунд. Зато получение данных так как это торренты - выполняется на максимальной скорости устройства с использованием множества торрент технологий и протоколов. Скачивание только изменённых данных? Думаю можно, но не спрашивайте как.

Вторая не менее важная проблема это то что каждый пользователь имеет программу в которой хранятся публичный ключ и приватный. И если взломать программу, то можно получить эти ключи и с помощью них публиковать свои ложные данные. Тут можно сочинить немало способов борьбы с этим. Возможно в комментариях подскажут ещё какие-то. Но например: можно хранить ключ в шифрованном виде и расшифровывать его только при использовании. Можно шифровать БД отдельным ключом так что злоумышленнику понадобится вычислить ещё и этот ключ. Можно хранить ключи тоже в DHT и менять их периодически или на сайте. Способов столько на сколько фантазия богата. Поэтому нельзя точно сказать, что это уязвимость.

Вариант 2.

Пользователь генерирует пару ключей. Приватный и публичный. Связывается с менеджером (человек) и обменивается с ним публичными ключами (например через Bluetoth, Wifi). Далее у пользователя есть публичный ключ по которому он может получить БД и своя пара ключей для публикации изменений к БД. Пользователь с помощью своей пары ключей публикует изменения к БД. Менеджер делает опрос всех публичных ключей пользователей. Получает изменения пользователей, вносит их в БД и публикует. Пользователи получают новую БД и так по кругу.

Такую систему невозможно взломать, так как ключи не зашиты в программе, как в предыдущем примере. Однако и тут есть небольшой недостаток. Количество пользователей, которых нужно опросить менеджеру влияет на скорость обновления БД. Однако не существенно. В одну секунду можно опрашивать около 1000 пользователей и получать ответы в течении 30 секунд, как обычно. Думаю, в реальности опрос 1000 пользователей (=1000 UDP запросов) займёт около минуты. Для увеличения скорости можно подумать о распределённой БД. Например, у каждого менеджера будет по 1000 пользователей и менеджеры обменявшись публичными ключами для обмена информацией (между БД) могут публиковать изменения для другого менеджера под специальным публичным ключом. Таким образом падение производительности из-за количества пользователей удастся избежать.

Таким образом получается децентрализованная, но управляемая менеджерами БД.

Подобную систему уже можно использовать даже для биллинга. Отличие от блокчейн систем тут будет в том, что менеджер может управлять содержимым БД. Т.е. если пользователи используют БД для хранения денег, то они должны доверять менеджеру секрет транзакций. Для надёжности менеджеров может быть несколько. Чем их больше, тем быстрее будет происходить обновление БД и тем надёжнее будут данные в БД, но так же возрастает количество людей, знающих о транзакциях. Впрочем вместо менеджера может быть просто компьютер, которому все доверяют :)

Так как все публикуемые данные публичны, то для передачи транзакций от пользователей к менеджеру можно использовать всё те же публичные и приватные ключи для шифрования текста уже.

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

Вариант 3.

Возможно сделать децентрализованный интернет.

Например, если менеджеры будут хранить БД не с биллингом, а с ДНС именами и публичными ключами. То пользователи могут добавлять свои ДНС имена и могут скачивать БД с ДНС именами или обращаться к БД через публичный ip.

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

Для работы подобного интернета нужно разработать специальный торрент-браузер и серверную часть.

Технически это возможно сделать на основе любой торрент библиотеки. Например Libtorrent. Она весит после компиляции всего 2,5Мб, написана на с++ и работает максимально быстро. Там есть техническая информация про Put.

Подобная система используется в моём приложении "Media Library", для публикации плейлистов. У меня уже есть даже админка для модерации. Всё успешно работает. Пользуйтесь.

Отключаем блокировку DHT в популярных торрент-клиентах


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

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

В сети в прошлом выкладывалось достаточно много информации касательно так называемых «патчей DHT», равно как выкладывались и сами патчи. Однако при анализе этих данных зачастую они оказываются противоречивыми и даже в ряде случаев полностью нерабочими. Связано это с постоянным обновлением клиентов, изменением структуры программ, а в ряде случаев — неправильным подходом авторов патчей.

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

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

  1. Актуальный дистрибутив торрент-клиента.
  2. Архиватор, способный распаковывать инсталляционные файлы, например в случае uTorrent и qBitTorrent — 7-zip.
  3. Распаковщик исполняемых файлов клиента, в случае uTorrent — UPX.
  4. IDA или любой другой дизассемблер.
  • в случае uTorrent — файл Carrier.exe;
  • В случае qBitTorrent — файлы qbittorrent.exe и qbittorrent.pdb (либо их 64-разрядные аналоги, если будет изменяться 64-битный клиент).

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

В общем, реализация блокировки DHT во всех клиентах на уровне Ассемблера выглядит одинаково, это вызов функции проверки флага, и если эта функция возвращает нулевое значение — переход на область кода, которая позволяет использовать DHT:


по этой причине сам патч будет выражаться в простом изменении одного байта кода 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. Итоги

Нами было последовательно изучена процедура поиска и отключения функции ограничения использования DHT для приватных торрентов в популярных клиентах uTorrent и qBitTorrent.
Думаю, что предложенный механизм будет аналогичен и для любых других клиентов — во всяком случае я проверил его и на ComboPlayer.

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

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

Читайте также: