Warden

[Chestarfild]

Вобщем видел на английском форуме тему, с раскопками сего чуда. Сейчас же меня почему-то туда не пускает (наверное опять учетку удалили). И собственно вопрос: что там уже смогли достичь?

[timmit]

А заново зарегистрироваться?

[Dereka]

Warden*

[zhenya]

Увы.. Он не очень согласуется с мангосом..

[Chestarfild]

Он не очень согласуется с мангосом..

А в чем его проблема согласования то?

[zhenya]

Сообщение от Chesterfield

А в чем его проблема согласования то?

используется модуль в чистом виде всем известной компании.. а раздавать модуль отдельно как то бредово. плюс надо кому то это все поддерживать, речь идет о базе проверок (мало того, что её надо наполнять, её нужно обновлять при смене клиента).

[abdula123]

Сообщение от zhenya

используется модуль в чистом виде всем известной компании.. а раздавать модуль отдельно как то бредово. плюс надо кому то это все поддерживать, речь идет о базе проверок (мало того, что её надо наполнять, её нужно обновлять при смене клиента).

в базе сейчас 147 проверок (они в постоянной ротации, так-что клиент постоянно что-то проверяет).

7 из них обновлять не требуется вообще.

44 обновляются скриптом за пару минут из файлов клиента (контольные суммы файлов и куски wow.exe) или из логов сниффера.

остальные 96... ну тут вопрос интересный. для обновления каждой из них нужна копия файла бота или чита, которую эта проверка ищет.
посмотрим, как они обновятся в 3.3.3 (и обновятся ли вообще - или просто добавятся проверки новых версий).

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

[zhenya]

Сообщение от abdula123

в базе сейчас 147 проверок (они в постоянной ротации, так-что клиент постоянно что-то проверяет).

7 из них обновлять не требуется вообще.

44 обновляются скриптом за пару минут из файлов клиента (контольные суммы файлов и куски wow.exe) или из логов сниффера.

остальные 96... ну тут вопрос интересный. для обновления каждой из них нужна копия файла бота или чита, которую эта проверка ищет.
посмотрим, как они обновятся в 3.3.3 (и обновятся ли вообще - или просто добавятся проверки новых версий).

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

Уже имеется 822 проверки из снифов + 5 самописных. для поддержания базы необходим парсер\снифер.
также как

    #S->C Warden Opcode: 03
    #Unk bytes:
    #14 00 60 D0 FE 2C 01 00 02 00 20 1A 36 00 C0 E3
    #35 00 50 F1 35 00 C0 F5 35 00 03 08 00 77 6C 93
    #A9 04 00 00 60 A8 40 00 01 03 08 00 36 85 EA F0
    #01 01 00 90 F4 45 00 01

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

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

[TOM_RUS]

Сообщение от zhenya

Уже имеется 822 проверки из снифов + 5 самописных. для поддержания базы необходим парсер\снифер.

Там дюпов полно, т.к. seed разный и искомые байты не известны.

[abdula123]

Сообщение от zhenya

для поддержания базы необходим парсер\снифер.

только не нужно говорить, что ни у кого его нету
все равно не поверю.

Сообщение от zhenya

также как

    #S->C Warden Opcode: 03
    #Unk bytes:
    #14 00 60 D0 FE 2C 01 00 02 00 20 1A 36 00 C0 E3
    #35 00 50 F1 35 00 C0 F5 35 00 03 08 00 77 6C 93
    #A9 04 00 00 60 A8 40 00 01 03 08 00 36 85 EA F0
    #01 01 00 90 F4 45 00 01

для текущей версии клиента.

seed модуля + новый клиентский и серверный ключ для изменения после шифрации

вот парсинг твоего пакета.

data = decode("""
03
14 00 60 D0 FE 2C 01 00 02 00 20 1A 36 00 C0 E3
35 00 50 F1 35 00 C0 F5 35 00 03 08 00 77 6C 93
A9 04 00 00 60 A8 40 00 01 03 08 00 36 85 EA F0
01 01 00 90 F4 45 00 01
""")

from pkt_parser import *
pkt = Packet(SMSG_WARDEN_DATA, data)
print pkt

------------

warden_opcode       : WARDEN_MODULE_LOADLIB (0x3)
check_len           : 20
check_crc           : 754896992
data                : 01000200201a3600c0e3350050f13500c0f53500
real_crc            :   754896992
check_opcode_1      : 3
check_len_1         : 8
check_crc_1         : 2845011063
data_1              : 04000060a8400001
real_crc_1          :   2845011063
check_opcode_2      : 3
check_len_2         : 8
check_crc_2         : 4041901366
data_2              : 01010090f4450001
real_crc_2          :   4041901366

кстати, пакет явно от старой версии клиента, в 3.3.2.11403 эти значения вот такие:

010002006089310000523100e05e3100f0623100
040000f0303f0001
010100d03f440001

на 03 опкод модуль реагируется прогрузкой несколькх функций через GetModuleHandle / GetProcAddress

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

Сообщение от zhenya

чтобы обойти ограничения ОС приходиться использовать 1 модуль. после того как это выйдет в паблик читерам не составит труда подменивать ответы на проверки...

не понял, о каких ограничениях идет речь?


сам процесс создания ключа выглядит так:

04:29:52
SMSG_WARDEN_DATA
warden_opcode       : WARDEN_MODULE_SEED (0x5)
seed                : f377c0dcb7f1625af8ee9ee352450442

04:29:52
CMSG_WARDEN_DATA
warden_response     : WARDEN_RESPONSE_HASH (0x4)
SHA1                : 67b3c364930ee3dd10fdbf6596b2aaa55e57a279

по одному и тому-же сиду разные модули выдадут разные хэши и сгененрируют разные ключи. это да.

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

и из этой базы уже потом проверять клиентов.

благо там новый ключ от предыдущего не зависит - только от встроенной в модуль функции и сида.

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

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

повторяю еще раз, АБСОЛЮТНО ВСЯ НЕОБХОДИМАЯ ИНФОРМАЦИЯ ЕСТЬ НА АНГЛОЯЗЫЧНЫХ ФОРУМАХ в открытом виде уже наверное год как. если не больше.

[LordJZ]

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

[zhenya]

Сообщение от LordJZ

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

имхо единственный в данный момент кто сможет поддерживать это [TOM_RUS].. увы даже мне знаний не хватает :-\
+ это даст повод всем известной компании сделать изменения в обсуждаемой вещи.

[LordJZ]

Сообщение от zhenya

имхо единственный в данный момент кто сможет поддерживать это [TOM_RUS].. увы даже мне знаний не хватает :-\
+ это даст повод всем известной компании сделать изменения в обсуждаемой вещи.

Я имел ввиду это:

обновлять при смене клиента

[zhenya]

Сообщение от LordJZ

Я имел ввиду это:

Обновлять без снифера и парсера [TOM_RUS] невозможно (парсер ладно в общем доступе, а вот снифер ..). Также нужны еще навыки владения ida pro..

[valsha]

Сообщение от zhenya

Обновлять без снифера и парсера [TOM_RUS] невозможно (парсер ладно в общем доступе, а вот снифер ..). Также нужны еще навыки владения ida pro..

погоди, след. ответ/пост будет такого плана.
"выкладывайте что есть, а люди найдутся с снифером и знанием IDA"

[abdula123]

Сообщение от zhenya

имхо единственный в данный момент кто сможет поддерживать это [TOM_RUS].. увы даже мне знаний не хватает :-\
+ это даст повод всем известной компании сделать изменения в обсуждаемой вещи.

известная компания даже не почешется.

уж если она не реагирует на публичные BNLS сервера для War3 / Diablo2 (а они есть ну очень давно) которые генерят для ботов правильные ответы на запросы вардена - то один пост на форуме ничего не изменит.

тем более, что АБСОЛЮТНО вся нужная для снифа/реализации поддержки вардена информация есть на англоязычных форумах.

кстати, если кому интересно - проект vanllawow таки продвинулся в этом не очень благом начинании (реализации поддежки вардена). http://beta.assembla.com/code/vanill...rden.vb?rev=63


да, и если кто не видел, снифы варденовских проверок выглядят примерно так:

04:29:57
SMSG_WARDEN_DATA
warden_opcode       : WARDEN_MODULE_RUN (0x2)
module_run          : 
  result              : 
1 : HideEx
xor_byte: 88
check_byte : 189
check_type : TIMING_CHECK

check_byte : 117
check_type : FIND_MODULE_CHECK
seed : 2d03398a
hmacsha1 : 9daa58b3aa1bb3c5406269f820117c1643125483
offset : 34176
size : 25

check_byte : 117
check_type : FIND_MODULE_CHECK
seed : 9757094e
hmacsha1 : 865dd3cf96294367fd861647206634caf97b2b95
offset : 24812
size : 14

check_byte : 145
check_type : MEM_CHECK
module : wow.exe
offset : 5922925
size : 8

check_byte : 235
check_type : DRIVER_CHECK
seed : 3322769657
sha : e1f1737c12dc6a857bf0ef7b42c1b24f04859753
driver : HideEx

check_byte : 117
check_type : FIND_MODULE_CHECK
seed : 3d06f29e
hmacsha1 : aea13c0af70ab6ab32c2bea246756bb86bc090df
offset : 41096
size : 24

check_byte : 62
check_type : FIND_MEMORY_CHECK
seed : 21fb4723
hmacsha1 : fe6cb25012e0c6a8f74265a400248a7d3c021125
offset : 198
size : 10




04:30:01
CMSG_WARDEN_DATA
warden_response     : WARDEN_RESPONSE_RESULT (0x2)
report              : 
  result              : 
checks: TIMING_CHECK, FIND_MODULE_CHECK, FIND_MODULE_CHECK, MEM_CHECK, DRIVER_CHECK, FIND_MODULE_CHECK, FIND_MEMORY_CHECK
pkt_sz: 19
pkt_checksum: 84cb5dea (MATCH)

check_type : TIMING_CHECK
unk1 : 1
GetTickCount : 506898242

check_type : FIND_MODULE_CHECK
result : 233

check_type : FIND_MODULE_CHECK
result : 233

check_type : MEM_CHECK '8 @ 0x005a606d'
result : 0
memory_content : …А‰EьЫEь

check_type : DRIVER_CHECK 'HideEx'
result : 233

check_type : FIND_MODULE_CHECK
result : 233

check_type : FIND_MEMORY_CHECK
result : 233

ничего особо интересного. чтобы не попасться - читеру нужно только не писать в некотоыре области памяти, не трогать некоторые файлы, не загружать драйвера с некоторыми названиями и не пользоваться широко-распространенными модулями, для которых есть сигнатуры. И ВСЁ.

ну или если читер - маньяк, он может просто исправлять ответы вардена на нужные (не забывая перешифровывать на лету, конечно).

[SilverIce]

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

[TOM_RUS]

Сообщение от SilverIce

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

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

[Dereka]

в той базе которая у меня 822- проверки

[RomanRom2]

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

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

[Nomad]

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

[TOM_RUS]

Там же 2048 бит ключ, а не 1024...

[Nomad]

Сообщение от TOM_RUS

Там же 2048 бит ключ, а не 1024...

не буду говорить за последние версии, но в Burning Crusade (как и в предыдущих версиях, да и в D2/StarCraft) используется 1024-битный ключ.

Вот из моей внутренней переписки:

Если кратко, то алгоритм кодирования подписи работает так:

s = m ^ e mod n

где m - тело подписи, s - полученное закодированное значение, n -
публичный ключ, e - ключ кодирования

для декодирования используется та же формула, с другими параметрами:

m1 = s ^ d mod n

m1 - раскодированное значение = m, s - закодированная подпись из
первой формулы, d - ключ декодирования

сами циферки:

s = 46049804728145012343901299101872202636468323809492 24436530335917249410350409467137541337452629492041 77761570257872709948308156309859008211724880292584 67676921777518583919636286632633111272280408507008 44101382788120753659439446570170756797882490235081 33604809978372861986591328760802562279920871113869 80098001708893723811388499870509658863057602217659 09751978138655425055645311722385578715446449040532 76827857674288132204022506168237751514059598220184 37173819905758533983189865686253612390064896944190 42225642615431607838208952150029708611756587121340 73810196742212471130179217272294112699707212032203 1976847995755493

m = 14811961116017545012827651815640394648536880390286 26351472640832094880027198111665938205064694800200 41906623987558699256014714646106416721685820698437 88796430289152126679623208718840635595257215614859 75092603096879352976687786738824084245990513491146 56832543488499731446568056169563218289451281829318 01426697544069470264656942813946777175427685142414 01619123094328566092719338700499137764398553518839 60811784993908183709616846222325776114715877061850 28072731923314312432605492459262790697004958176856 59026933201613431988689608208132845770918211570126 18254454574843120681946616429284733701581953862750 0389061640693981

n = 25208188434192790481075204094145423499348681474845 56914299333490034359367848211550635355002076314355 77510286761462498447665320751009951082461055308536 59534424451081327409048703329313939827774534939344 06891938559088315633046971366385510532638320996391 55569323614771544531272869189950703410184308289281 10508238144824941249178292626204963318699727024806 61643136952281072450330516589684190052169136732065 76077284224192404496459581472030698464090686160838 04912555145577875702129681601959862786494392034053 50960517473102046506497266274677962342138056186659 09742490759404960921180160823735518059762327891259 30707570325311083

d = 257

нам надо найти e.

[Nomad]

Теперь немного теории. Весь алгоритм я описывать не буду, читайте Википедию.
В общем случае задача взлома 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 лежит в фиксированных пределах и мы можем одним движением вычеркнуть десятки машинных лет перебора

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

[Nomad]

коллеги, я прошу прощения, что ввел вас в заблуждение
наш случай не попадает ни под одно из частных решений (в т.ч. и с теоремой Винера, ибо у нас малое значение известного ключа, а не искомого), а разложение на множители (факторизация) 1024-битового числа n не возможна с нашими ресурсами. Вот исследования американского Агенства Национальной Безопасности:

Просеивание. Для 1024-битного RSA-модуля время просеивания экстраполируется до числа от двух до четырёх миллионов лет на ядро процессора.
(речь об условных процессорах 3-ГГц Pentium D)
...
Для 1024 бит, 2 гигабайта RAM на ядро подходят близко к этому пределу, но должны работать 32 или 64 гигабайта памяти на многоядерный или многопоточный процессор (или даже на материнскую плату).

Фильтрование. Преобразование просеянных данных в матрицу один из наименее вызывающих шагов факторизации и не требует здесь обсуждения. Для 1024-битных модулей RSA это потребует несколько сотен терабайтов дискового пространства, что является относительно лёгким в управлении в сравнении с предыдущим и последующим шагом.
Матрица. Матрица требует времени и памяти, растущих также быстро, как и для просеивания. ....
Для 1024-битного RSA-модуля хватит от четверти миллиона до миллиона лет на ядро. Для каждого компактно соединённого кластера, участвующего в шаге работы с матрицей, комбинированный объём памяти 10 терабайт будет адекватным значением.

Допустим, что процессор Pentium D 955 имеет вычислительную мощность 14 GFLOPs. Для сравнения возьмем видеокарту ATI Radeon 5770, имеющую около 1400 GFLOPs (на самом деле, сравнивать напрямую нельзя, но это просто для примера).
Разница в 100 раз сокращает время с 4000000 лет на станцию до 40 000. Это значит, что сорок тысяч компьютеров с такими карточками будут год считать один из этапов подбора. Если работать с картами 5970, то это будет 10 000 компьютеров за год времени, что тоже очень далеко от наших реалий.

Я еще буду читать, консультироваться на форумах и пр. В этом топике я видел, что есть несколько сотен оригинальных варденов - это все примеры подписывания, потому может получиться как-то скомбинировать из них.. Но простой брут-форс нам не светит

[Deamon]

Бесполезно. Даже если знать несколько пар значений (s, m) - то это все равно ничего не дает. Если расписать мат. формулы по этим парам, то получится система из (n-1) уравнений с n неизвестными.

[Nomad]

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

Вариант 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.

[alien]

Господи да хватит пытаться найти способ ломануть 2048 битный RSA это бесполезно.

[Deamon]

Сообщение от alien

Господи да хватит пытаться найти способ ломануть 2048 битный RSA это бесполезно.

Не, вариант с атакой на SHA-1 мне понравился. И может действительно "прокатить" . Но вот атака на RSA до появления полиноминального алгоритма факторизации - действительно бесполезна.

[Nomad]

Сообщение от alien

Господи да хватит пытаться найти способ ломануть 2048 битный RSA это бесполезно.

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

Есть еще один вариант. Если из имеющихся подписей модулей (расшифрованых) можно получить умножением (в т.ч. и по модулю n) подпись нашего собственного модуля (тоже не зашифрованную), то можно без особых проблем ее подписать. К сожалению, я не представляю как можно из чего-то вроде 0xBBBBB234234 получить что-то вроде 0xBBBBB765651

[Deamon]

Сообщение от Nomad

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

Есть еще один вариант. Если из имеющихся подписей модулей (расшифрованых) можно получить умножением (в т.ч. и по модулю n) подпись нашего собственного модуля (тоже не зашифрованную), то можно без особых проблем ее подписать. К сожалению, я не представляю как можно из чего-то вроде 0xBBBBB234234 получить что-то вроде 0xBBBBB765651

А почему бы патчером на лету не заменять RSA ключик в клиенте? Один фиг у вас лаунчер уже есть.

[Nomad]

Сообщение от Deamon

А почему бы патчером на лету не заменять RSA ключик в клиенте? Один фиг у вас лаунчер уже есть.

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

А по какому адресу в памяти надо "хукнуть" чтобы сделать замену, этот адрес статический?

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

[Konctantin]

А по какому адресу в памяти надо "хукнуть" чтобы сделать замену, этот адрес статический?

[zergtmn]

Не нашел информацию, как расшифровывать пакеты после получения 0x00. Первый пакет приходит:

SMSG_WARDEN_DATA Warden opcode: 0
MD5: C128B52AD08980F95A2FCD5FF7424D1 Length: 17781
RC4: D26D1CF3975E8CD45F51F59714162BAC

Данные верны, DLL-ку извлек Warden Extractor'ом.
Следом идет:

CMSG_WARDEN_DATA Warden opcode: 158 (Unknown)

При попытке расшифровать его и все последующие получаю бред. По логике это 0x1, т.к. модуль уже был загружен.

[TOM_RUS]

Там до 0x05->0x04 (включительно) все одинаково шифруется, клиентский и серверный ключи разные...

Packet S->C, SMSG_WARDEN_DATA (742), len 37
0000: 00 CB 35 FD DB 9F B9 16 2C 24 39 6C AB FB 34 5F : ..5.....,$9l..4_
0010: C6 03 5C B8 F8 BB 3A 1C 18 E3 65 63 0C D5 F4 B4 : ..\...:...ec....
0020: F3 7D 4D 00 00 -- -- -- -- -- -- -- -- -- -- -- : .}M.............

S->C Warden Opcode: 00
MD5: 0xCB35FDDB9FB9162C24396CABFB345FC6
RC4: 0x035CB8F8BB3A1C18E365630CD5F4B4F3
Len: 19837

Packet C->S, CMSG_WARDEN_DATA (743), len 1
0000: 01 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- : ................

C->S Warden Opcode: 01
Module loaded successfully...

Packet S->C, SMSG_WARDEN_DATA (742), len 17
0000: 05 42 61 73 0A 19 60 7F 6A 86 40 E1 93 A1 F5 F6 : .Bas..`j.@.....
0010: F1 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- : ................

S->C Warden Opcode: 05
Seed: 0x4261730A19607F6A8640E193A1F5F6F1

Packet C->S, CMSG_WARDEN_DATA (743), len 21
0000: 04 29 33 29 B1 3B BB DB DC 50 A9 DC E6 8E 7A 8A : .)3).;...P....z.
0010: 47 AF FC 14 7B -- -- -- -- -- -- -- -- -- -- -- : G...{...........

C->S Warden Opcode: 04
SHA1: 0x293329B13BBBDBDC50A9DCE68E7A8A47AFFC147B

Packet S->C, SMSG_WARDEN_DATA (742), len 57
0000: 03 14 00 B3 EA 4F B1 01 00 02 00 80 87 31 00 E0 : .....O.......1..
0010: 4F 31 00 B0 5C 31 00 90 60 31 00 03 08 00 F1 CA : O1..\1..`1......
0020: A4 33 04 00 00 70 2A 3F 00 01 03 08 00 FB 1B EE : .3...p*?........
0030: B6 01 01 00 B0 38 44 00 01 -- -- -- -- -- -- -- : .....8D.........

S->C Warden Opcode: 03
Len: 20
Checksum: 0xB14FEAB3 is valid!
Data: 0x0100020080873100E04F3100B05C310090603100

Len: 8
Checksum: 0x33A4CAF1 is valid!
Data: 0x040000702A3F0001

Len: 8
Checksum: 0xB6EE1BFB is valid!
Data: 0x010100B038440001

Packet S->C, SMSG_WARDEN_DATA (742), len 161
0000: 02 00 F1 89 87 5D 75 56 BD 6E FC 31 02 79 AF E8 : .....]uV.n.1.y..
0010: 3E F1 E0 7B 8E FA 06 8A 49 1A 1F 71 38 0F 02 00 : >..{....I..q8...
0020: 20 95 00 36 DB 96 00 06 89 92 96 19 42 87 94 42 :  ..6........B..B
0030: E6 3B 16 FB 92 47 31 7D 99 D1 2F B4 FC 6F 51 29 : .;...G1}../..oQ)
0040: EF 64 61 00 00 10 D4 01 32 00 22 31 FD A6 FB 4D : .da.....2."1...M
0050: 18 10 30 5E 19 58 D5 C3 AE EF C4 76 4E 04 70 DC : ..0^.X.....vN.p.
0060: C5 0D 00 2A 89 07 A0 A4 43 7D CC 95 B0 5F 91 52 : ...*....C}..._.R
0070: 1F 4A 70 75 7A CD 00 93 A9 6D 30 F8 16 F8 70 00 : .Jpuz....m0...p.
0080: 00 11 89 1E 31 CE BF 7B 40 5F 05 12 48 D4 31 55 : ....1..{@_..H.1U
0090: 8E F2 BC A1 A2 86 59 EE 0D 48 12 C8 D7 06 00 30 : ......Y..H.....0
00A0: E6 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- : ................

S->C Warden Opcode: 02
====== CHEAT CHECKS START ======

====== TIMING_CHECK START ======
CheckType 17 (F1)
====== TIMING_CHECK END ======

====== PAGE_CHECK_A_B START ======
CheckType 6F (89)
Seed: 0x56755D87
SHA1: 0xBD6EFC310279AFE83EF1E07B8EFA068A491A1F71
Address: 0x00020F38
Bytes to read: 32
====== PAGE_CHECK_A_B END ======

====== MEM_CHECK START ======
CheckType 73 (95)
Module: base
Offset: 0x0096DB36
Bytes to read: 6
====== MEM_CHECK END ======

====== PAGE_CHECK_A_B START ======
CheckType 6F (89)
Seed: 0x42199692
SHA1: 0x879442E63B16FB9247317D99D12FB4FC6F5129EF
Address: 0x00006164
Bytes to read: 16
====== PAGE_CHECK_A_B END ======

====== PAGE_CHECK_A_B START ======
CheckType 32 (D4)
Seed: 0x22003201
SHA1: 0x31FDA6FB4D1810305E1958D5C3AEEFC4764E0470
Address: 0x000DC5DC
Bytes to read: 42
====== PAGE_CHECK_A_B END ======

====== PAGE_CHECK_A_B START ======
CheckType 6F (89)
Seed: 0x43A4A007
SHA1: 0x7DCC95B05F91521F4A70757ACD0093A96D30F816
Address: 0x000070F8
Bytes to read: 17
====== PAGE_CHECK_A_B END ======

====== PAGE_CHECK_A_B START ======
CheckType 6F (89)
Seed: 0xBFCE311E
SHA1: 0x7B405F051248D431558EF2BCA1A28659EE0D4812
Address: 0x0006D7C8
Bytes to read: 48
====== PAGE_CHECK_A_B END ======

====== CHEAT CHECKS END ======

Packet C->S, CMSG_WARDEN_DATA (743), len 24
0000: 02 11 00 D7 81 DD B3 01 DE 09 FC 00 E9 00 89 46 : ...............F
0010: 44 89 4E 54 E9 E9 E9 E9 -- -- -- -- -- -- -- -- : D.NT............

C->S Warden Opcode: 02
Cheat check result:
Len: 17
Checksum: 0xB3DD81D7 is valid!
====== CHEAT CHECKS RESULTS START ======

====== TIMING_CHECK result START ======
Result: 0x01
Ticks: 0x00FC09DE
====== TIMING_CHECK result END ======

====== PAGE_CHECK_A_B result START ======
Result: 0xE9
====== PAGE_CHECK_A_B result END ======

====== MEM_CHECK result START ======
Result: 0x00
Bytes: 0x894644894E54
====== MEM_CHECK result END ======

====== PAGE_CHECK_A_B result START ======
Result: 0xE9
====== PAGE_CHECK_A_B result END ======

====== PAGE_CHECK_A_B result START ======
Result: 0xE9
====== PAGE_CHECK_A_B result END ======

====== PAGE_CHECK_A_B result START ======
Result: 0xE9
====== PAGE_CHECK_A_B result END ======

====== PAGE_CHECK_A_B result START ======
Result: 0xE9
====== PAGE_CHECK_A_B result END ======

====== CHEAT CHECKS RESULTS END ======

Packet S->C, SMSG_WARDEN_DATA (742), len 173
0000: 02 08 41 66 64 65 33 32 75 75 00 F1 95 00 00 FE : ..Afde32uu......
0010: 4A 00 0C 89 D5 67 0E 10 77 00 5A 8A E0 05 E6 60 : J....g..w.Z....`
0020: 20 16 9B 86 56 4F B3 17 5B F7 E8 9D 00 71 00 00 :  ...VO..[....q..
0030: 0D 89 BD CC 44 BD C1 D8 83 D4 8D 98 25 06 93 AE : ....D.......%...
0040: 43 77 07 CF 37 60 CF A6 45 34 EC 60 00 00 0F 95 : Cw..7`..E4.`....
0050: 00 36 DB 96 00 06 D4 B3 75 07 08 54 BF 86 0A EE : .6......u..T....
0060: A9 11 E9 AD CD DE 37 B9 E0 CB 58 40 1D B3 E3 97 : ......7...X@....
0070: 8E 26 00 16 F7 73 E5 2D 8D B1 75 BE 94 34 C6 AA : .&...s.-..u..4..
0080: 7E 4E C9 DF C7 8F 4C A9 74 2C DA 44 6B 01 89 8D : ~N....L.t,.Dk...
0090: CE 51 4E 9A 48 85 11 C6 E1 EE F7 8B C9 1C FC 39 : .QN.H..........9
00A0: AD 69 5D 93 0D EE 2B C8 D7 06 00 30 E6 -- -- -- : .i]...+....0....

S->C Warden Opcode: 02
====== CHEAT CHECKS START ======

====== TIMING_CHECK START ======
CheckType 17 (F1)
====== TIMING_CHECK END ======

====== MEM_CHECK START ======
CheckType 73 (95)
Module: base
Offset: 0x004AFE00
Bytes to read: 12
====== MEM_CHECK END ======

====== PAGE_CHECK_A_B START ======
CheckType 6F (89)
Seed: 0x100E67D5
SHA1: 0x77005A8AE005E66020169B86564FB3175BF7E89D
Address: 0x00007100
Bytes to read: 13
====== PAGE_CHECK_A_B END ======

====== PAGE_CHECK_A_B START ======
CheckType 6F (89)
Seed: 0xBD44CCBD
SHA1: 0xC1D883D48D98250693AE437707CF3760CFA64534
Address: 0x000060EC
Bytes to read: 15
====== PAGE_CHECK_A_B END ======

====== MEM_CHECK START ======
CheckType 73 (95)
Module: base
Offset: 0x0096DB36
Bytes to read: 6
====== MEM_CHECK END ======

====== PAGE_CHECK_A_B START ======
CheckType 32 (D4)
Seed: 0x080775B3
SHA1: 0x54BF860AEEA911E9ADCDDE37B9E0CB58401DB3E3
Address: 0x00268E97
Bytes to read: 22
====== PAGE_CHECK_A_B END ======

====== DRIVER_CHECK START ======
CheckType 11 (F7)
Seed: 0x8D2DE573
SHA1: 0xB175BE9434C6AA7E4EC9DFC78F4CA9742CDA446B
Driver: Afde32uu
====== DRIVER_CHECK END ======

====== PAGE_CHECK_A_B START ======
CheckType 6F (89)
Seed: 0x4E51CE8D
SHA1: 0x9A488511C6E1EEF78BC91CFC39AD695D930DEE2B
Address: 0x0006D7C8
Bytes to read: 48
====== PAGE_CHECK_A_B END ======

====== CHEAT CHECKS END ======

Packet C->S, CMSG_WARDEN_DATA (743), len 37
0000: 02 1E 00 19 7E C1 E5 01 EB 6A FC 00 00 55 8B EC : ....~....j...U..
0010: B8 C4 4D 00 00 E8 13 BD F5 E9 E9 00 89 46 44 89 : ..M..........FD.
0020: 4E 54 E9 E9 E9 -- -- -- -- -- -- -- -- -- -- -- : NT..............

C->S Warden Opcode: 02
Cheat check result:
Len: 30
Checksum: 0xE5C17E19 is valid!
====== CHEAT CHECKS RESULTS START ======

====== TIMING_CHECK result START ======
Result: 0x01
Ticks: 0x00FC6AEB
====== TIMING_CHECK result END ======

====== MEM_CHECK result START ======
Result: 0x00
Bytes: 0x558BECB8C44D0000E813BDF5
====== MEM_CHECK result END ======

====== PAGE_CHECK_A_B result START ======
Result: 0xE9
====== PAGE_CHECK_A_B result END ======

====== PAGE_CHECK_A_B result START ======
Result: 0xE9
====== PAGE_CHECK_A_B result END ======

====== MEM_CHECK result START ======
Result: 0x00
Bytes: 0x894644894E54
====== MEM_CHECK result END ======

====== PAGE_CHECK_A_B result START ======
Result: 0xE9
====== PAGE_CHECK_A_B result END ======

====== DRIVER_CHECK result START ======
Result: 0xE9
====== DRIVER_CHECK result END ======

====== PAGE_CHECK_A_B result START ======
Result: 0xE9
====== PAGE_CHECK_A_B result END ======

====== CHEAT CHECKS RESULTS END ======

[zergtmn]

Разобрался, в rc4 не сохранялось состояние...

[abdula123]

похоже со времен 3.3.3 у вардена поменялась таблица xored кодов проверок.


по крайней мере те пакеты, что приходят сейчас (модуль 27F52E18F0DA417A40CEB786192C7669) в нее не попадают

[LordJZ]

Насколько я помню она поменялась чуть раньше

[abdula123]

Сообщение от LordJZ

Насколько я помню она поменялась чуть раньше

прошлая версия снифера разбирала варден с середины марта до начала июня без всяких изменений.


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


теперь еще и в строках не видно имен файлов для MPQ_FILE_CHECK.

[MaS0n]

На 4.0.х не снифал, но пакеты 3.3.5.12340 неплохо дешифровались и парсились без каких-то изменений
Мб в 4.0.х что-то изменили...или я ошибаюсь оО