Warden

[Chestarfild]

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

[timmit]

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

[Dereka]

Warden*

[zhenya]

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

[Chestarfild]

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

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

[zhenya]

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

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

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

[LordJZ]

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

[zhenya]

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

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

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

[LordJZ]

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

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

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

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

[zhenya]

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

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

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

[valsha]

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

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

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

[Deamon]

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

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

. Людей, которые пишут такие предложения, по-моему, в коммунити уже нетъ.

[valsha]

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

. Людей, которые пишут такие предложения, по-моему, в коммунити уже нетъ.

это не считается?
http://ru-mangos.ru/showpost.php?p=2067&postcount=7

[Deamon]

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

это не считается?
http://ru-mangos.ru/showpost.php?p=2067&postcount=7

Куда мои глаза смотрели... Не заметилъ

[SilverIce]

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

[TOM_RUS]

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

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

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

[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

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

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

[abdula123]

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

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

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

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

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

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

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

[Dereka]

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

[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

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

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

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

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

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

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

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

[zhenya]

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

byte seed[16]; // taken from 0x05 packet
byte[] rc4_seed_client = ModuleSpecificHash(&seed); // this value than stored at module+4
byte[] rc4_seed_server = ModuleSpecificHash(&seed); // so we have double processed seed here
clientRC4Crypt_Init(rc4_seed_client);
serverRC4Crypt_Init(rc4_seed_server);
byte[] seedHash = SHA1(rc4_seed_client); // used in 0x04 packet

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

[abdula123]

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

Данный пакет был для 3.3.2 и оно даже работает нормально..

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

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

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

после вычитывания ключа из памяти - проверки и так "как на ладони" - до окончания сессии.

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

идеи есть как собирать seed, и новые ключи шифрации для каждого модуля ?

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

wmod = WardenModule("2A7BD368FF3D0795B4DE7F823F487175.raw")
wmod.load()
wmod.prepare()
wmod.init()

# state - текущее крипто-состояние
wmod.live_rc4_data = state

print " -> GenerateRC4Keys"
wmod.GenerateRC4Keys("")

# теперь шифруем пакет SEED и скармливаем вардену
# если ключи принялись нормально - он его обработает и выдаст HASH

s_pkt = decode("""
05 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
xx
""")

pkt_crypted = server_crypt.crypt(s_pkt)

print " -> PacketHandler"
print wmod.PacketHandler(pkt_crypted)

resp_crypted = wmod.send_queue.pop(0)
resp_decrypted = client_crypt.crypt(resp_crypted)

print "decrypted responce"
print dump2hexstr(resp_decrypted)

# после SEED->HASH  грузим новые ключи
rc4_states = cast(wmod.rc4_keys_ptr, POINTER(c_ubyte))

print "unload"
wmod.UnloadModule()

byte seed[16]; // taken from 0x05 packet
byte[] rc4_seed_client = ModuleSpecificHash(&seed); // this value than stored at module+4
byte[] rc4_seed_server = ModuleSpecificHash(&seed); // so we have double processed seed here
clientRC4Crypt_Init(rc4_seed_client);
serverRC4Crypt_Init(rc4_seed_server);
byte[] seedHash = SHA1(rc4_seed_client); // used in 0x04 packet

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

варден работающий с любым модулем уже давно есть - для War3 / Diablo2.

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

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

чтобы окончательно проверить это предположение - нужно эти самые несколько месяцев заходить в игру каждые несколько часов и автоматом подлавливать свежие модули. их сыпется по 3-4 штуки в день. за последние 10 дней повторов не было.


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

[zhenya]

В d2gs используется только 1 модуль заданный в d2warden.ini также как и ключ.

;Please don't modify following values!
;І»ТЄРЮёДПВГжµДЦµЈЎ
MOD=3ea42f5ac80f0d2deb35d99b4e9a780b.mod
MOD_RC4_Key=4f340a327dc8b4b8a7d1c15cf73c0e78

У близов есть ротация, у нас её нету. => Написав "Антиварден" для одного сервера, оно будет работать везде. А если держать в открытом все данные ключи шифрация для каждого модуля.. это не составит труда уже под бли**** написать бота или прогу подделывающую варден проверки.
Если вы поможете мне найти для всех модулей Seed, new client key, new server key.
0х3 пакет если отличается для различных модулей то необходимо еще и это.
также 0х4 пакет необходимо hash который возращает клиент. На текущий момент у TOM_RUS чуть больше 210 различных модулей с RC4 ключами к ним. Все равно как я понимаю в git не будут включены модули т.к. они подписаны RSA близарда.

имхо это откроет путь для начинающих читописателей, ботописателей.

п.с. если интересно #rmdc@rusnet

[abdula123]

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

В d2gs используется только 1 модуль заданный в d2warden.ini также как и ключ.

;Please don't modify following values!
;І»ТЄРЮёДПВГжµДЦµЈЎ
MOD=3ea42f5ac80f0d2deb35d99b4e9a780b.mod
MOD_RC4_Key=4f340a327dc8b4b8a7d1c15cf73c0e78

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

http://bnls.ghostbot.net:9367/

У близов есть ротация, у нас её нету. => Написав "Антиварден" для одного сервера, оно будет работать везде. А если держать в открытом все данные ключи шифрация для каждого модуля.. это не составит труда уже под бли**** написать бота или прогу подделывающую варден проверки.
Если вы поможете мне найти для всех модулей Seed, new client key, new server key.

с ключами ой. самих ключей я никогда не вижу - т.к. забираю у модулей готовые крипто-состояния RC4 (т.е. BOX, I, J - и клиентский и серверный). и подсовываю им тоже крипто-состояния. для шифрования этого хватает. и вардену, и мне.

нагенерить пар (модуль, состояние) для нескольких сидов - могу (хз сколько они будут генериться, но не дольше одной в секунду). завтра, скорее всего.



кстати, если кто в криптографии силен - можно ли из начального состояния RC4 (с I и J равными 0) вычислить ключ за небольшое время?

что-то мне подсказывает, что нет - т.к. неизвестно J, которое было на момент окончания заполнения BOX. а атаковать RC4 по всем правилам - слишком долгое удовольствие.

впрочем, вопрос чисто теоретический, и без начального ключа всё работает нормально.

0х3 пакет если отличается для различных модулей то необходимо еще и это.

за последние 10 дней изменений не было. раньше - не следил

также 0х4 пакет необходимо hash который возращает клиент. На текущий момент у TOM_RUS чуть больше 210 различных модулей с RC4 ключами к ним. Все равно как я понимаю в git не будут включены модули т.к. они подписаны RSA близарда.

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

[Nomad]

Заранее извиняюсь за нубский вопрос - последние год-полтора я отошел от копаний во внутренностях ВоВ и остановился на версии 2.3.3, потому могу не знать современных реалий.
Вопрос таков - есть ли возможность варденом следить за целостностью трафика? Проверки модулей, памяти, драйверов и пр. банально не спасают от редактирования трафика на шлюзе, потому логично было бы сверять контрольную сумму исходящих данных, но это реально сделать лишь в собственном модуле (через задницу и с внутренними хуками, но можно). Собственный модуль же требует взлома 1024-битного ключа RSA, либо модификации клиента.
О ключе, кстати, отдельный разговор. Может таки есть смысл набрать нужное количество единомышленников, написать OpenCL/CUDA модули и подобрать его? Ключ не менялся со времен д2, за эти годы можно было уже и на CPU посчитать

[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 ключик в клиенте? Один фиг у вас лаунчер уже есть.

[Konctantin]

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