Warden
Вобщем видел на английском форуме тему, с раскопками сего чуда. Сейчас же меня почему-то туда не пускает :( (наверное опять учетку удалили). И собственно вопрос: что там уже смогли достичь? :)
|
А заново зарегистрироваться?
|
Warden*
|
Увы.. Он не очень согласуется с мангосом..
|
Цитата:
|
Цитата:
|
Лучше бы (имхо) выложили (хотя бы под хайдом) что-то уже созданное, тогда и люди, желающие поддерживать, найдутся.
|
Цитата:
+ это даст повод всем известной компании сделать изменения в обсуждаемой вещи. |
Цитата:
Цитата:
|
Цитата:
|
Цитата:
"выкладывайте что есть, а люди найдутся с снифером и знанием IDA" =))) |
Цитата:
|
Цитата:
http://ru-mangos.ru/showpost.php?p=2067&postcount=7 |
Цитата:
|
насколько я понял из темы на офф форуме он позволяет высылать клиенту другие модули и выполнять их на клиенте/машине клиента.. то есть это могут быть как безопасная проверка целостности так и нечто вредоносное, зависит от того кто его использует
|
Цитата:
|
Цитата:
уж если она не реагирует на публичные BNLS сервера для War3 / Diablo2 (а они есть ну очень давно) которые генерят для ботов правильные ответы на запросы вардена - то один пост на форуме ничего не изменит. тем более, что АБСОЛЮТНО вся нужная для снифа/реализации поддержки вардена информация есть на англоязычных форумах. кстати, если кому интересно - проект vanllawow таки продвинулся в этом не очень благом начинании (реализации поддежки вардена). http://beta.assembla.com/code/vanill...rden.vb?rev=63 да, и если кто не видел, снифы варденовских проверок выглядят примерно так: Код:
04:29:57 ну или если читер - маньяк, он может просто исправлять ответы вардена на нужные (не забывая перешифровывать на лету, конечно). |
Цитата:
7 из них обновлять не требуется вообще. 44 обновляются скриптом за пару минут из файлов клиента (контольные суммы файлов и куски wow.exe) или из логов сниффера. остальные 96... ну тут вопрос интересный. для обновления каждой из них нужна копия файла бота или чита, которую эта проверка ищет. посмотрим, как они обновятся в 3.3.3 (и обновятся ли вообще - или просто добавятся проверки новых версий). в любом случае - особых знаний для поддержания базы в актуальном состоянии не требуется. |
в той базе которая у меня 822- проверки
|
Цитата:
также как Код:
#S->C Warden Opcode: 03 seed модуля + новый клиентский и серверный ключ для изменения после шифрации :) чтобы обойти ограничения ОС приходиться использовать 1 модуль. после того как это выйдет в паблик читерам не составит труда подменивать ответы на проверки... Для того чтобы налету криптовать пакеты вардена необходимо знать ключи для каждого модуля :) или доставать из памяти ключи. |
Цитата:
|
Цитата:
все равно не поверю. Цитата:
Код:
data = decode(""" Код:
010002006089310000523100e05e3100f0623100 к шифрованию отношения не имеет вообще никакого, т.к. делается уже после создания новых ключей. Цитата:
сам процесс создания ключа выглядит так: Код:
04:29:52 однако что мешает по очереди загрузить все имеющиеся на руках модули к себе в процесс, накормить тысячей разных сидов и записать полученные хэши\ключи в базу? и из этой базы уже потом проверять клиентов. благо там новый ключ от предыдущего не зависит - только от встроенной в модуль функции и сида. Цитата:
повторяю еще раз, АБСОЛЮТНО ВСЯ НЕОБХОДИМАЯ ИНФОРМАЦИЯ ЕСТЬ НА АНГЛОЯЗЫЧНЫХ ФОРУМАХ в открытом виде уже наверное год как. если не больше. |
Данный пакет был для 3.3.2 :) и оно даже работает нормально.. другое дело в том, что в опенсорсе разбирать один модуль фи (есть все ключи и читерам подделывать ответы не составит труда... тем более все эти ключи и проверки будут как на ладони). идеи есть как собирать seed, и новые ключи шифрации для каждого модуля ?:)
Код:
byte seed[16]; // taken from 0x05 packet п.с. хотелось бы посмотреть на модуль для macos клиента.. а на деле кому оно надо те уже написали простейшую поддержку.. |
Цитата:
в логах за последние 10 дней - только те значения, что я написал. Цитата:
Цитата:
адаптировать его под цикл - не проблема. Код:
wmod = WardenModule("2A7BD368FF3D0795B4DE7F823F487175.raw") Цитата:
учитывая, что варден там абсолютно тот-же самый, адаптировать под вов - дело недолгое и нехитрое. есть основания предполагать, что: база модулей набирается за несколько месяцев игры. их не очень много (всяко меньше 3-4 сотен) и они тоже в ротации. ну время от времени свежие добавляются. чтобы окончательно проверить это предположение - нужно эти самые несколько месяцев заходить в игру каждые несколько часов и автоматом подлавливать свежие модули. их сыпется по 3-4 штуки в день. за последние 10 дней повторов не было. оно надо коммерческим ботописателям - у некоторых из них действительно давно всё налажено. ну или ботописателям-любителям, если кому делать нехер. |
В d2gs используется только 1 модуль заданный в d2warden.ini также как и ключ.
Код:
;Please don't modify following values! Если вы поможете мне найти для всех модулей Seed, new client key, new server key. 0х3 пакет если отличается для различных модулей то необходимо еще и это. также 0х4 пакет необходимо hash который возращает клиент. На текущий момент у TOM_RUS чуть больше 210 различных модулей с RC4 ключами к ним. Все равно как я понимаю в git не будут включены модули т.к. они подписаны RSA близарда. имхо это откроет путь для начинающих читописателей, ботописателей. п.с. если интересно #rmdc@rusnet |
Цитата:
BNLS сервера точно поддерживают загрузку разных модулей. причем на лету. http://bnls.ghostbot.net:9367/ Цитата:
нагенерить пар (модуль, состояние) для нескольких сидов - могу (хз сколько они будут генериться, но не дольше одной в секунду). завтра, скорее всего. кстати, если кто в криптографии силен - можно ли из начального состояния RC4 (с I и J равными 0) вычислить ключ за небольшое время? что-то мне подсказывает, что нет - т.к. неизвестно J, которое было на момент окончания заполнения BOX. а атаковать RC4 по всем правилам - слишком долгое удовольствие. впрочем, вопрос чисто теоретический, и без начального ключа всё работает нормально. :) Цитата:
Цитата:
я, кстати, их храню уже расшифроваными и распаковаными - меньше мороки при загрузке =))) |
Заранее извиняюсь за нубский вопрос - последние год-полтора я отошел от копаний во внутренностях ВоВ и остановился на версии 2.3.3, потому могу не знать современных реалий.
Вопрос таков - есть ли возможность варденом следить за целостностью трафика? Проверки модулей, памяти, драйверов и пр. банально не спасают от редактирования трафика на шлюзе, потому логично было бы сверять контрольную сумму исходящих данных, но это реально сделать лишь в собственном модуле (через задницу и с внутренними хуками, но можно). Собственный модуль же требует взлома 1024-битного ключа RSA, либо модификации клиента. О ключе, кстати, отдельный разговор. Может таки есть смысл набрать нужное количество единомышленников, написать OpenCL/CUDA модули и подобрать его? Ключ не менялся со времен д2, за эти годы можно было уже и на CPU посчитать :) |
это отдельная dll, в которой можно делать все что угодно :)
но проблема в том, что и она "подписана". это даже не совсем обычная dll. просто очень похожа, с модифицированным близзами заголовком. мы в свое время полностью разобрали механизмы загрузки в клиента этой dll, но клиент ее ессно не принимает. селяви. начинаем подбирать ключик? только тут опять проблема - как только станет известно о подобранном ключе, начнуться мегахаки и близы его сменят. не думаю что удастся сохранить ключ в тайне среди трех-четырех команд-разработчиков. |
Можно попробовать и сохранить. Все-таки это не маленькое число и "на словах" или "по аське" оно не утечет, только если закоммитить код куда-то, где доберутся поисковики.
подыму старые наработки, почитаю математические выкладки. там не такой уж и страшный диапазон перебора, т.е. надо не 2^1024 чисел перепробовать, а заметно меньше :) |
Там же 2048 бит ключ, а не 1024...
|
Цитата:
Вот из моей внутренней переписки: Цитата:
Цитата:
|
Теперь немного теории. Весь алгоритм я описывать не буду, читайте Википедию.
В общем случае задача взлома RSA это нахождение значения d при известных e (публичный ключ) и m (модуль). При этом рекомендуется выбирать небольшие значения e, но не меньше 256 степени значащих бит для 1024-битного ключа, иначе действует теорема Винера и есть некий упрощенный способ поиска d. У нас же e и d поменяны местами, что совершенно не влияет на теорему Винера и вообще формулы поиска. При этом число d совсем небольшое (гораздо меньше 256 бит). Также e и d связаны общими правилами: d*e = 1 mod n' 1 < e < n' как следствие из этих двух формул произведение d*e должно обязательно быть больше n' e > n'/d и e < n' значения n и n' связаны так: n' = (p-1)*(q-1) n = p * q из чего следует что n' = n - p - q +1 при этом p и q - простые числа, заметно меньшие, чем n. Даже примерно прикинув, что n' ~= n мы можем обозначить границы значений e как n/d < e < n. На самом же деле n' намного меньше n и диапазон для перебора еще меньше. Ради эксперимента можно перебрать простые числа до 8-10 знаков, чтобы еще на несколько порядков сузить диапазон значений e. Еще надо рассмотреть вариант с теоремой Винера - она актуальна если q < p < 2q, т.е. когда p и q одного порядка. Такое упрощение может очень сильно сузить диапазон поиска, ведь получится, что n < p*p < 2*n, а значит n ^ 1/2 < p < 2 * n ^ 1/2, т.е. число p лежит в фиксированных пределах и мы можем одним движением вычеркнуть десятки машинных лет перебора :) Но вообще, перед тем как перебирать, надо еще хорошенько почитать литературу. Ибо можно годами перебирать значения, которые окажутся откровенно лишними. |
коллеги, я прошу прощения, что ввел вас в заблуждение :(
наш случай не попадает ни под одно из частных решений (в т.ч. и с теоремой Винера, ибо у нас малое значение известного ключа, а не искомого), а разложение на множители (факторизация) 1024-битового числа n не возможна с нашими ресурсами. Вот исследования американского Агенства Национальной Безопасности: Цитата:
Разница в 100 раз сокращает время с 4000000 лет на станцию до 40 000. Это значит, что сорок тысяч компьютеров с такими карточками будут год считать один из этапов подбора. Если работать с картами 5970, то это будет 10 000 компьютеров за год времени, что тоже очень далеко от наших реалий. Я еще буду читать, консультироваться на форумах и пр. В этом топике я видел, что есть несколько сотен оригинальных варденов - это все примеры подписывания, потому может получиться как-то скомбинировать из них.. Но простой брут-форс нам не светит :( |
Бесполезно. Даже если знать несколько пар значений (s, m) - то это все равно ничего не дает. Если расписать мат. формулы по этим парам, то получится система из (n-1) уравнений с n неизвестными.
|
Распишу еще два тупиковых варианта взлома, на случай если кто-то захочет этим заняться и будет идти моим путем.
Вариант 1 У нас известна пара значений s и m для формулы s = m ^ e mod n т.е. число m возводится в степень e и затем ищется его остаток от деления на n. Это можно записать в виде: s + n * k = m ^ e где k - целое число раз, которое n встречается в числе m ^ e. Моим логичным предположением было, что никто не станет возводить в очень большую степень и можно найти перебором число k. Через какое-то время (заодно перебрав 16 десятичных знаков от 1 для числа k) я осознал неравенство, указанное выше: e > n`/d n` - число того же порядка, что и n, но немного меньше его. т.е. к примеру если у n 300 знаков, то у n` может быть 300-298 знаков. Если разделить на наше число d = 257, то получится число из ~298-296 знаков. А теперь представьте на секунду, что число 2 в 64-й степени равно 18 446 744 073 709 551 615 (задача о зернах на шахматной доске), а какого размера будет число из 300+ знаков (число m) в степени из 300 знаков? Я подозреваю, что такой результат нельзя будет уместить на всех информационных носителях Земли :) Естественно, число k тоже невообразимо велико и суть тут в том, что есть математический алгоритм получения остатка от возведения в степень - т.е. m ^ e mod n считается без реального возведения в степень, потому эта функция не обратима. Вариант 2 Ключ 1024-битный, но на самом деле им подписывается 160-битное значение - хеш SHA1 от тела модуля*. Для обеспечения безопасности к хешу дописываются числа 0xBB, чтобы дополнить его до 1024 бит. При некотором желании (дописывая в конец не значащие данные, используя хитрые алгоритмы, вычисления на GPU и пр.) можно было бы создать модуль, хеш от которого совпадает с уже имеющимся. Это значит, что он автоматически уже был бы подписан и наши проблемы решились бы. Но тут вступает в силу символ *, поставленный мной выше. Систему делал человек, сведущий в криптоанализе (или просто параноик), потому хеш считается не от "чистого" модуля, а от бинарного блока в таком виде: "реальная длина модуля" + "тело модуля в архиве" + "MAIEV.MOD" Мы можем вручную нарастить этот блок и через годы перебора получить такой же хеш код, как у существующего модуля. Но клиент на своей стороне не будет ничего "наращивать". Это значит, что надо менять само тело модуля, чтобы его в архиве биты стали на "нужные места". Сложность такой операции может оказаться даже больше, чем для факторизации 1024-битного ключа.. :( Вариант реален, но для его реализации (или хотя бы оценки) нужны ОЧЕНЬ хорошие знания как алгоритма архивации, так и SHA1. |
Господи да хватит пытаться найти способ ломануть 2048 битный RSA это бесполезно.
|
Цитата:
|
Цитата:
но ведь мы не хакеры, а конструкторы, у нас другая задача - нарастить функционал клиента без явного его изменения. Для этого любые методы хороши, вплоть до buffer overflow attack какого-то из имеющихся варденов дабы он загрузил наш модуль с сервера :declare: Есть еще один вариант. Если из имеющихся подписей модулей (расшифрованых) можно получить умножением (в т.ч. и по модулю n) подпись нашего собственного модуля (тоже не зашифрованную), то можно без особых проблем ее подписать. К сожалению, я не представляю как можно из чего-то вроде 0xBBBBB234234 получить что-то вроде 0xBBBBB765651 :( |
Цитата:
|
А по какому адресу в памяти надо "хукнуть" чтобы сделать замену, этот адрес статический?
|
Текущее время: 18:27. Часовой пояс GMT +3. |
ru-mangos.ru - Русское сообщество MaNGOS