Dht патч для utorrent что это
Facebook Если у вас не работает этот способ авторизации, сконвертируйте свой аккаунт по ссылке ВКонтакте Google RAMBLER&Co ID
Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal
DHT, чтобы не иссяк торрент
TL;DR: Не дожидаясь проблем, включите на торрент клиенте DHT, PEX и LPD. Касается любого торрент клиента, не только transmission.
Первым тестом была попытка скачать образ Ubuntu. Скачался влёт. То есть настройка transmission в целом рабочая, сам протокол bittorrent провайдер не блокирует. Но очень похоже, начал блокировать анонсеры, то есть ресурсы, которые централизованно раздают нужную для скачивания информацию. К счастью, уже давно есть противоядие. DHT aka распределённая таблица хешей, позволяет торрент клиенту обходиться без каких-либо центральных узлов. Включение DHT помогло, трансмишн стал качать. Но, если вы пользуетесь торрент клиентом, советую проверить, что DHT, PEX и LPD включены. Не дожидаясь новаций со стороны провайдера. Поможете и себе и другим. Почему - простыми словами ниже.
Включение DHT, PEX и LPD в вебгуе transmission (Services > BitTorrent в самом низу Administrative URL - > гаечный ключ слева-внизу)
И в transmission remote (Инструменты - Параметры transmission)
A, говорят, DHT не включать? Многие помнят, что некоторые торрент трекеры не рекомендовали (и даже запрещали) включать DHT. Причина была простая, вы будете смеяться. DHT позволяет торрент клиенту обходиться без каких-либо центральных узлов. А как, скажите на милость, вести статистику скачано/отдано?! Но с тех пор мир изменился, доля хамья, сваливающего с раздачи немедленно по её скачиванию, упала до приемлемого уровня. И подавляющее большинство трекеров перестали считать сколько отдано сколько скачано ( Но не все, есть важные исключения. Впрочем, если вы одним из них пользуетесь, про DHT и пр вы знаете получше меня :)
А что значат-то эти буковки?
PEX, обмен пирами, позволяет клиентам получать новые пиры друг от друга, а не только от центрального анонсера.
DHT, распределённая таблица хешей, в грубом приближении, позволяет найти нужный кусочек скачиваемого, опрашивая другие пиры, а не центральный анонсер.
LPD, обнаружение локальных пиров, позволяет отыскивать пиры в локальной сети провайдера. Часто с них удаётся скачивать в разы быстрее, чем по Internet. Выше тарифной скорости, если провайдер ограничивает скорость только в мир.
И чем мне лучше, если мой провайдер анонсеры не блокирует?
Во-первых, проще включить и потом не париться почему это перестало работать.
Во-вторых, вы получите дополнительных пиров и, очень вероятно, увеличите скорость скачивания. Но даже в худшем случае скорость от этого точно не упадёт.
В-третьих, помогите другим. Сама идея торрента существует только потому, что одни делают что-то, что считают полезным для других. Если DHT будет выключено у всех, у кого анонсеры не блокированы, как думаете - сильно ли поможет его включение остальным?
В-четвёртых, магнитные ссылки становятся всё популярнее. Чтобы они работали, DHT нужен.
Из минусов, повторю, возможно, не стоит это включать, если пользуетесь трекерами, ведущими статистику. И величины в этой статистике имеют для вас значение.
UPD от 19 марта 2017. Годный коммент от камрада drazer05 :
"DHT рекомендуют выключать, если вы находитесь в стране, где за раздачу закопирайченного, штрафуют быстро, решительно и без суда. Списки фильтрации пиров спасают, но не 100%. Некоторые торрент-клиенты умеют использовать DHT при поиске пиров но не делать Announce при раздаче.
В РФ можно не парится. ПОКА." /UPD
PS Надо ли напоминать, что автор использует торрент технологии только для обмена легальным контентом и ожидает того же от читателя?
Сеть Bittorrent DHT позволяет найти источники торрента по хешу из магнет-ссылки. Сеть состоит из узлов которые могут быть как Bittorent клиентами так и вредоносными программами которые препятсвуют нормальной работе сети. Они мешают клиенту получить источники торрента, перенаправляют запросы на атакуемые узлы, заполняют список узлов бесполезными адресами.
Пока я работал над счетчиком пиров и сидов(DHT Scrape) в этой сети я наткнулся на такие виды атаки.
Порт номер 1
Некоторые узлы выдавали список узлов где в качестве порта был указан первый. В интернете была рекомендация не соеденятся с 0 по 1024 портом. На них находятся критически важные для работы интрнета сервисы. Узел приславший адреса с портом в этом отрезке игнорируется.
Зеркала
Есть узлы которые просто возвращают обратно присланный пакет. Получается что мы спрашиваем сами себя и себе же отвечаем. Поскольку узел ответил корректно он помечается некоторыми клиентами как активный и его адрес передатся другим узлам. Для того чтобы такие узлы исключить из сети надо проверять этот вариант.
Флуд портами
Некоторые узлы выдают один и тотже IP с кучей разных портов. Такое может случиться с узлом за NAT который меняет исходящий порт узла. В таком случе если узел с таким IP и ID уже подтвержден (т.е. с ним была связь) новая информация отбрасывается. В другом случае используется последняя или случайная запись для проверки.
Токен
В каждом пакете имеется токен который позволяет определить что наш запрос попал к адресату и он нам ответил исключая тем самым атаки с подменой адреса. Но надо проверять что токен (как и остальные строки) не вылезает за рамки пакета. Это может позволить читать данные из памяти следующей за пакетом.
Таймер
Токен не панацея от входящих запросов с подельным адресом. В таком случае разрешается только 2 подряд запроса в секунду от одного IP. В случае большего количества они просто игнорируются.
Локальные адреса
Некоторые узлы возврашают локальные адреса которые соответственно недоступны из интернета. Этот также может быть внутренний адрес роутера. Эти адреса также должны игнорироваться если конечно они не получены от узла в этой же локальной сети.
Публикуем только проверенные узлы
Когда у нас спрашивают список узлов из базы узлов выбираются только те от которых мы получали корректный отет на наш запрос (активные). Остальные (неопределнные) опрашиваются постепенно и удаются из базы при отсутствии ответа (мертвые).
Сеть G2 последнее время очень страдала от того что в ней курсирует большое количество адресов мертвых узлов. Это замедляет вход в сеть и поск по ней.
Храним базу узлов
После длительного перерыва в работе клиента в базе узлов все записи становятся просроченными. Но клиент должен использовать их для входа в сеть до получения достаточного количества активных узлов. Если все узлы мертвые то клиент обращается к входным узлам. На моем опыте даже очень старая база с достаточно большим количеством узлов позволяет войти в сеть.
Фильтруем биты
Для получения количества пиров и сидов раздачи в сети используется Фильтр Блума. Поддельные узлы могут заполнить его едницами и исказить тем самым цифры. Поэтому сравниваются данные минимум от трех узлов.
Отправляем пинг перед ответом
Для того чтобы не участвовать в примитивных DDoS атаках перед отправкой большого пакета отправляем пинг на узел. При корректном ответе на пинг отправляем большой пакет.
Заключение
Надеюсь данная статья поможет писать более эффективные и безопасные клиенты для P2P сетей.
Уже много лет, как существует система 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", для публикации плейлистов. У меня уже есть даже админка для модерации. Всё успешно работает. Пользуйтесь.
Ниже мы рассмотрим, как отключить такое ограничение в популярных торрент-клиентах. Будет рассмотрен общий подход, а также практическое применение к актуальной версии uTorrent и qBitTorrent.
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\"
Ошибка uTorrent - DHT ожидание входа довольно таки распространенная ошибка, которая полностью отключает скачивание файлов и скорость падает до нулевой отметки, тем самым все загрузки останавливаются и пользователи не могут воспользоваться программой uTorrent. Обычно ошибка заключается в том, что ваш интернет немного не настроен под данную программу, но есть и другие случаи. Форвардинг портов не разрешен на вашем провайдере, с такой ошибкой может столкнуться практически каждый из пользователей. Эта проблема заключается в том, что ваш провайдер запрещает другим пользователям и ресурсам из интернета отправлять различные сетевые данные, тем самым и закачка не может производиться должным образом. Решение подобных проблем очень легкое и простой. Чтобы разрешить проблему с форвардингом, вам нужно залезть в настройки вашего провайдера (роутера, файрвола) и разрешить получение сетевых данных от других, незнакомых источников, тем самым ошибка, связанная с dnt больше не будет появляться. Так же если у вас в торрент клиенте отключена работа с DHT, то обязательно ее включите. После всего этого вы сможете с легкостью пользоваться программой и никаких проблем у вас не будет возникать. Как включить / отключить DHT в торрент клиенте uTorrent и BitTorrent Полезные ссылки qBittorrent - BitTorrent-клиент Как увеличить скорость Торрента до Максимума? Закачка торрентов с помощью связки uTorrent + Dropbox
Комментарии и отзывы: 2
1. Айгиз • 14.11.2018
Часто проблемы с загрузкой торрентов возникают из-за неверно настроенного роутера, ADSL модема или файрвола, которые и блокируют сетевые пакеты торрент клиентов. У провайдеров как правило проблем с настройкой сети нет, зачем им терять клиентов? Торренты не запрещены.
Ответ:
В основном подобная ошибка появляется у тех, кто скачивает файлы на съемные носители и именно они не могут разрешить эту весьма странную ошибку. Чтобы решить данную проблему существует два способа.
Первый способ:
Довольно таки легкий, простой и надежный способ избавиться от этой ошибки, это открыть программу, найти пункт настройки в котором выбрать подпункт Кэширование. Ну а там пользователю придется убрать отметку с Автовыбора. Но не нужно торопиться выходить из настроек, так как прям там же вам необходимо в ручную написать число сто, тем самым вы сможете окончательно разрешить непоколебимую проблему.
Второй способ:
Одним из более усложненных способов является изменение некоторых настроек в самом компьютере, тем самым вам уже не придется при сбоях программы, постоянно настраивать то, что было описано в первом пункте. Вам нужно войти в свойства вашего персонального компьютера, ну а там воспользоваться пунктом дополнительно, где должны указать автоматический размер подкачки. Тем самым сохранить все что вы сделали, ну а после этого вам уже ничто не будет мешать пользоваться программой и скачивать то, что вам нужно в большом количестве и без никаких проблем.
Keyran 1.1.9
Самый лучший имулятор макросов только у Keyran. Я играл с ни .
Драйвер для USB 2.0 / 3.0
Запуск этого устройства невозможен. (Код 10) - что это означ .
Драйвер для USB 2.0 / 3.0
у меня на компе имеются usb2 3 синего и зеленого цвета usb2 .
World Of Tanks - Мир Танк
Подскажите лучшие танки для начинающего игрока, на которых легче и рез .
Copyright © Софт - Архив 2008 - 2018 Алексей Егоров
Сайт использует технологию Cookie для сохранения настроек пользователя.
2. Подготовка.
- Актуальный дистрибутив торрент-клиента.
- Архиватор, способный распаковывать инсталляционные файлы, например в случае uTorrent и qBitTorrent — 7-zip.
- Распаковщик исполняемых файлов клиента, в случае uTorrent — UPX.
- IDA или любой другой дизассемблер.
- в случае uTorrent — файл Carrier.exe;
- В случае qBitTorrent — файлы qbittorrent.exe и qbittorrent.pdb (либо их 64-разрядные аналоги, если будет изменяться 64-битный клиент).
1. Вступление.
В сети в прошлом выкладывалось достаточно много информации касательно так называемых «патчей DHT», равно как выкладывались и сами патчи. Однако при анализе этих данных зачастую они оказываются противоречивыми и даже в ряде случаев полностью нерабочими. Связано это с постоянным обновлением клиентов, изменением структуры программ, а в ряде случаев — неправильным подходом авторов патчей.
Мы попытаемся не просто создать готовое решение, а проанализировать основные шаги так, чтобы читатель мог даже в случае изменение в будущем самостоятельно снимать ограничения DHT в новых версиях клиентов.
Читайте также: