1 Востаннє редагувалося Пам'ять не може бути READ (25.08.2013 17:55:29)

Тема: Генерування уінакльного хешу для звязки клієнта та сервера.

Всім привіт, останнім часом почав сильно задумуватися над безпекою ігрового лаунчера, який зробив для minecraft сервера.
Суть полягає у тому, що в лаунчері перевіряється хеш деяких файлів. Якщо хеш не співпадає, то авторизація не проходить.
Але от біда у тому, що коди цього лаунчера якраз є у мережі, та й можна обійти навіть сам лаунчер.
Перевірка хешу файлів відбувається для того, щоб запобігти появі чітерів.

Отож, як працює лаунчер:
1) Появляється вікно, з 2 полями та кнопкою. Юзер вводить логін і пароль, натискає кнопку авторизуватися.
2) Лаунчер перевіряє хеш(md5 та sha1) одного файлу. Якщо хеш не співпадає, запит на сервер не подається.
3) Якщо хеш співпадає, відправляється запит на скрипт xAuth.php з параметрами login=Його_нік&password=його_пасс
4) На сервері перевіряється логін і пасс, якщо все вірно, створюється запис із сесією для нього у бд, і віддається результат типу:
різні_букви_і_цифри:Нік_гравця ну тобто щось таке: a6fba7a0e6f104f:Hanter
Ті букви і цифри - то ідентифікатр сесії.
5) Якщо сервер відповів результатом типу як показано вище, він запускає сам minecraft з різними параметрами, і в одному із параметрів є якраз той ідентифікатор сесії. Без нього на сервер не зайдеш.

Все було б добре, якби не одне але.
Чітер може взяти вихідні коди лаунчера, і скомпілювати його так, що він буде посилати точно такий же запит як і мій, але без перевірки файлів. Тут він і має пряму дорогу до встановлення різних чітів.
Другий метод, взагалі без лаунчера. Чітер напряму звертається до файлу xAuth.php з потрібними параметрами(логін і пасс) і отримує якраз id сесії. Далі він бере і запускає minecraft з типу: java -jar -session=те_що_отримав /bin/minecraft.jar і все.
Так двома способами можна обійти лаунчер.

І в мене виникла така ідея. Розробити якийсь алгоритм, який при запуску лаунчера генерує своєрідний хеш чи щось таке, і коли йде запит до xAuth.php воно в той запит додає ще наприклад ?hash=те_що_згенерувало. Сервер в свою чегру перевіряє чи вірний хеш. Якщо не вірний або відсутній зразу посилає. Але от біда в тому, що якщо хеш буде постійно однаковий, то чітер це побачить і це не складе проблеми знову ж таки обійти лаунчер.
І от я подумав, а що якщо зробити так, що хеш буде кожного разу унікальний і не буде повторятися. І тут знову проблема, як зробити так, щоб сервер знав чи хеш вірний чи ні ? І взагалі, підкажіть будь ласка ще якісь методи захисту. Може хтось робив щось подібне ?

2

Re: Генерування уінакльного хешу для звязки клієнта та сервера.

Ніяк так зробити не можна. Якщо ми не довіряємо середовищу виконання, то надійних операцій в ньому робити не можна (насправді... можна. Але то важкий матан, і швидкість вкрай обмежена, та й розміщати доведеться в ньому всі розрахунки - і гру теж). Нормально можна тільки крізь нього щось передавати з одного надійного середовища до іншого.
Я б ще запропонував створити:
- завантажувальник, який би закачував лаунчер з сервера і запускав би;
- лаунчер, що перевіряє хеші (за різними алгоритмами) всіх файлів з додачею власного унікального ключа, дійсного протягом 1 хвилини з моменту завантаження;
- якщо все збіглося, лаунчер отримає закодований його унікальним ключем дозвіл продовжувати.
Але це збочення, яке теж реально обійти. Не хочете несканкціонованих дій - не обчислюйте важливу інформацію в недовіреному середовищі. Іншого шляху поки що нема.

3 Востаннє редагувалося Vo_Vik (25.08.2013 22:53:57)

Re: Генерування уінакльного хешу для звязки клієнта та сервера.

Згоден з Коалою, всі дії виконуються на сервері, клієнт посилає тільки запит на виконання дії.
Тобто:
клієнт: Хочу знищити отой блок.
сервер: ніфіга той блок в іншому кінці карти і в тебе нема кірки для того щоб рубати алмази
хочу поставити золотий блок
сервер: ніфіга, в тебе в інвентарі нема золотого блоку

і тд. довіряти будь-якій інфі з клієнта не варто.

Невже сервак майнкрафту інакше зроблений?

4

Re: Генерування уінакльного хешу для звязки клієнта та сервера.

Чесно - майнкрафт я бачив тільки далеко збоку. Але цілком можу припустити, що деякі чіти можна запровадити і з клієнтського боку, як-от точний розрахунок часу певної дії, автоматичне наведення, комбінації клавіш із правильними паузами і т.д. Сервер же не може перевірити, чи мишкою клієнт клацав, чи імітував.

5

Re: Генерування уінакльного хешу для звязки клієнта та сервера.

Ну майнкрафт це не контра, там точності і розрахунку часу не треба, єдине з чим там є смисл чітерити це з ресурсами, а це походу на серваку контролюється.

6

Re: Генерування уінакльного хешу для звязки клієнта та сервера.

Один з моїх варіантів:
Гравець запускає ланчер,
вводить логін і пароль
відправляє на сервер.
Якщо логін і пароль вірні тоді:
З сервера завантажується згенерований файл на 100 кб максимум (назвемо це міні програма - дальше просто файл)
Файл унікальний і генерується на льоту. Містить алгоритм перевірки файлів.
Для прикладу у файлі записано що потрібно отримати хеш файлу1 і файлу 2
Скрипт перевіряє ці файли і відправляє на сервер результат.
Сервер знає завжди який має бути хеш від даного алгоритму.
Отже сервер знає який має бути результат.

Таким чином що б зламати прогу потрібно на ходу розбирати файл який віддається з сервера і мати всі можливі згенеровані варіанти для всіх файлів. в різних комбінаціях.

Як на мене це класний варіант так як 100 кб не багато займає. Різні варіанти перевірки можна втулити.

Для прикладу:


Залогінюємось на сервер.
Сервер випадково придумує алгоритм генерації хешу. Ось декілька варіантів.
0. Перевірити файл file1 і файл f2.
1. Перевірити файл 1. 2. 10. 16
2. Перевірити хеш функцій А і Б і файл 12

Суть така:
Кожен раз видаємо різний алгоритм отримання хешів файлів. Приблизно прикидуємо що хеш має віддатись за 15 секунд. або за10. якщо більше залогінення не вдалось.


Це супер варіант так як можна придумати 100000 алгоритмів перевірки хешу. Можна робити рандомні фішки і тд.

7

Re: Генерування уінакльного хешу для звязки клієнта та сервера.

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

Подякували: Очі.завидющі1