Здравствуйте, господа кодеры. Давно интересовал вопрос, как эмулируется код сервера на стороне клиента и как клиент получает всю информацию о игре. Каким образом происходит авторизация? Я заметил только лишь то, что клиент отправляет серверу свой login, key, ctime, а где же ckey, каким пакетом отправляется - неизвестно.
nurik040404 (26 February 2017 - 15:16) писал: писал:
Здравствуйте, господа кодеры. Давно интересовал вопрос, как эмулируется код сервера на стороне клиента и как клиент получает всю информацию о игре. Каким образом происходит авторизация? Я заметил только лишь то, что клиент отправляет серверу свой login, key, ctime, а где же ckey, каким пакетом отправляется - неизвестно.
есть мнение что очень многое отправляется не "при старте" а уже "в процессе". т.е. конфиги железа выдираются и отправляются не "по умолчанию", а уже либо средствами игры, либо средствами бионда вшитыми в игру. косвенно на это же может указывать то что клиент достаточно активно юзает жабу, штмл и даже флэш.
0
Gravitational Singularity (17 September 2016 - 16:11) писал: писал:
есть мнение что очень многое отправляется не "при старте" а уже "в процессе". т.е. конфиги железа выдираются и отправляются не "по умолчанию", а уже либо средствами игры, либо средствами бионда вшитыми в игру. косвенно на это же может указывать то что клиент достаточно активно юзает жабу, штмл и даже флэш.
Ну чтож, методом тыкания хуем в небеса, а так же с помощью умений обращения с памятью, было выяснено, что эта хуйня базарит с юзером таки и посреди игрового процесса, а в частности получение computer_id происходит рандомно, но он все таки спалился
Я тут глянул, клиент при подключении частенько глядит на мой жесткий диск. Товарищи, GetVolumeInformation . Заглянем в сорсец ByondCore.dllпо ссылкам на GetVolumeInformation. Бац.
Параметр lpVolumeSerialNumber насколько мы видим, является указателем на внешнюю переменную, значит ID нашего жесткача возвращается результатом из этой функции, а вызовов этой функции в DreamSeeker-e ОООЧЕНЬ МНОГО! Да, и в основном они связаны с авторизацией на сервере. Т.е. для того, чтобы подделать computer_id достаточно инжектировать DLL в игру, которая хуканет функцию GetVolumeInformation, затем подделает результат этой функции и все, вуаля доступ на сервер открыт!
Планирую добавить все фичи ByondCore в мою библиотеку ByondAPI, там пока говно-код на плюсах, но сейчас проходит стадия исследования.
К сожалению, в Open Source виде их нет, поэтому вы можете достать их сами, в папке с Byondом есть файл ByondCore.dll , в нем заэкспортированы все функции BYOND
nurik040404 (27 February 2017 - 10:44) писал: писал:
Обход через длл не новый. Раньше работал, но тгшники создали систему для распознавания длл. Сначала идет один коннект, он обрывается, после чего идет второй. Если твой компуктер_ид поменялся - тебе пизда.
А вообще обычно авторизация в таких вещах делается следующим образом: клиент авторизируется в клиентском сервере бульенда и получает код своей сессии, которая сохраняется на клиент-сервере. Когда клиент пытается зайти на какой-то сервер, то он скидывает серверу свой сикей и номер сессии. В случае если отправленный клиентом и хранящийся на клиент-сервере код сессии совпадают, то клиент попадает на сервер. Это я к тому, что зайти под другим сикеем не получится, если ты сделать это хотел
ochen_bombanyTI (27 February 2017 - 11:02) писал: писал:
Обход через длл не новый. Раньше работал, но тгшники создали систему для распознавания длл. Сначала идет один коннект, он обрывается, после чего идет второй. Если твой компуктер_ид поменялся - тебе пизда.
К счастью, это не проблема, тебе не нужно заменять DLL библиотеки сокетов, так что все будет чистенько
ochen_bombanyTI (27 February 2017 - 11:02) писал: писал:
Обход через длл не новый. Раньше работал, но тгшники создали систему для распознавания длл. Сначала идет один коннект, он обрывается, после чего идет второй. Если твой компуктер_ид поменялся - тебе пизда.
Никто не мешает в обоих случаях использовать одинаковый компуктер_ид
А вообще обычно авторизация в таких вещах делается следующим образом: клиент авторизируется в клиентском сервере бульенда и получает код своей сессии, которая сохраняется на клиент-сервере. Когда клиент пытается зайти на какой-то сервер, то он скидывает серверу свой сикей и номер сессии. В случае если отправленный клиентом и хранящийся на клиент-сервере код сессии совпадают, то клиент попадает на сервер. Это я к тому, что зайти под другим сикеем не получится, если ты сделать это хотел
Не думаю, что с сикеем ничего не получится, да и к тому же, я к такой цели не шел.
А вообще обычно авторизация в таких вещах делается следующим образом: клиент авторизируется в клиентском сервере бульенда и получает код своей сессии, которая сохраняется на клиент-сервере. Когда клиент пытается зайти на какой-то сервер, то он скидывает серверу свой сикей и номер сессии. В случае если отправленный клиентом и хранящийся на клиент-сервере код сессии совпадают, то клиент попадает на сервер. Это я к тому, что зайти под другим сикеем не получится, если ты сделать это хотел