- Баллы
- 93
- Имя в Minecraft
- Dj_Arktic
Ни для кого не секрет, что предприимчивые пользователи давно поняли, что лаунчер на самом деле не защищает сервер от читов.
Например:
Что же, давайте усложним им их читерскую жизнь.
В этой теме я выложу идею своей защиты. Она не идеальна, но для ее взлома понадобится написать мод для клиента как минимум.
Нам понадобится:
Для подключения к серверу с online-mode: true клиенту игры необходимо знать ник и сессию.
Сессия - наш ключик, который нужно защитить от злобного WireShark (программы для просмотра траффика).
Авторизация проходит следующим образом:
1) лаунчер запрашивает сессию у loginserver.php (палит сессию для WireShark'a)
2) лаунчер передает клиенту игры сессию
3) при подключении к серверу клиент передает сессию на joinserver.php (палит сессию для WireShark'a), для того, чтобы joinserver установил нужный serverid и checkserver завершил авторизацию.
Как мы видим, у нас аж две уязвимости. Давайте их фиксить.
Т.к. loginserver палит нашу драгоценную сессию, нужно, чтобы он передавал лаунчеру не сессию, а ключ для получения этой самой сессии.
Фикс первой дырки
Идея проста:
loginserver генерирует сессию, отдает ее клиенту, а в базу заносит md5($сессия.$key).
Далее, дело за лаунчером. Лаунчер получает сессию, а клиенту игры передает md5(сессия+ключ)
Компилируем лаунчер, проверяем.
Отлично, первая дырка залатана!
Для того, чтобы запутать читера этого достаточно. Но юзер, имеющий мозги сразу поймет, что сессия, передающаяся loginserver'ом - невалидная, а joinserver передает валидную сессию.
Фикс второй дырки
Это сложнее, потребуется умение обращаться с MCP. Этому я учить не буду, гугл научит.
Вы установили MCP, декомпилировали чистый клиент.
Или же вы декомпилировали клиент в связке с Forge.
Я буду приводить куски кода для второго случая, однако, и без Forge суть та же.
Идея фикса:
joinserver, при получении сессии, авторизует пользователя, однако, делает сессию невалидной, меняя ее на md5($сессия.$key);
Клиент, после успешного запроса к joinserver обновляет свою сессию, чтобы она оставалась валидной, на md5(сессия+ключ);
Для joinserver.php:
Теперь клиент должен поддерживать валидность сессии:
Готово!
Что имеем теперь:
Перед WireShark loginserver палит невалидную сессию.
joinserver палит валидную сессию, но после выполнения запроса она становится невалидной.
ВАЖНО!!!
Защита не идеальна, программист сможет ее обойти. Но ему придется потрудиться написать мод, и для каждого сервера нужно будет делать индивидуальный обход.
Можно усложнить ему работу шифрованием классов лаунчера в jar2exe и антидеобфускаторскими штучками для minecraft.jar.
Спасибо за внимание.
Для серверов с Forge и на версии 1.4.7 выложу готовый ayh.class, замените ключ с помощью InClassTranslator (строка your_key).
Например:
В этой теме я выложу идею своей защиты. Она не идеальна, но для ее взлома понадобится написать мод для клиента как минимум.
Нам понадобится:
- Minecraft Coder Pack
- Исходники любого лаунчера
- Прямые руки
- Базовые знания Java, PHP
Для подключения к серверу с online-mode: true клиенту игры необходимо знать ник и сессию.
Сессия - наш ключик, который нужно защитить от злобного WireShark (программы для просмотра траффика).
Авторизация проходит следующим образом:
1) лаунчер запрашивает сессию у loginserver.php (палит сессию для WireShark'a)
2) лаунчер передает клиенту игры сессию
3) при подключении к серверу клиент передает сессию на joinserver.php (палит сессию для WireShark'a), для того, чтобы joinserver установил нужный serverid и checkserver завершил авторизацию.
Как мы видим, у нас аж две уязвимости. Давайте их фиксить.
Т.к. loginserver палит нашу драгоценную сессию, нужно, чтобы он передавал лаунчеру не сессию, а ключ для получения этой самой сессии.
Фикс первой дырки
Идея проста:
loginserver генерирует сессию, отдает ее клиенту, а в базу заносит md5($сессия.$key).
Для loginserver.php:
Заменяем строки
На
Заменяем строки
Код:
$sessid = generateSessionId();
mysql_select_db($db_database,$connectmysql);
mysql_query("UPDATE $db_table SET $db_columnSesId='$sessid' WHERE $db_columnUser = '$login'");
Код:
$sessid = generateSessionId();
$fsessid = md5($sessid."ваш_ключ");
mysql_select_db($db_database,$connectmysql);
mysql_query("UPDATE $db_table SET $db_columnSesId='$fsessid' WHERE $db_columnUser = '$login'");
В исходниках лаунчера, в LauncherFrame.java в конец добавляем:
Далее в этом же классе находим строку
И заменяем ее на
Код:
public static String getHash(String str){
MessageDigest m;
try {
m = MessageDigest.getInstance("MD5");
m.reset();
try {
m.update(str.getBytes("utf-8"));
String s2 = new BigInteger(1,m.digest()).toString(16);
while(s2.length() < 32 ){
s2 = "0"+s2;
}
return s2;
} catch (UnsupportedEncodingException e) {
}
} catch (NoSuchAlgorithmException e) {
}
return "";
}
Код:
launcher.customParameters.put("sessionId", values[3].trim());
Код:
launcher.customParameters.put("sessionId", getHash(values[3].trim()+"ваш_ключ"));
Отлично, первая дырка залатана!
Для того, чтобы запутать читера этого достаточно. Но юзер, имеющий мозги сразу поймет, что сессия, передающаяся loginserver'ом - невалидная, а joinserver передает валидную сессию.
Фикс второй дырки
Это сложнее, потребуется умение обращаться с MCP. Этому я учить не буду, гугл научит.
Вы установили MCP, декомпилировали чистый клиент.
Или же вы декомпилировали клиент в связке с Forge.
Я буду приводить куски кода для второго случая, однако, и без Forge суть та же.
Идея фикса:
joinserver, при получении сессии, авторизует пользователя, однако, делает сессию невалидной, меняя ее на md5($сессия.$key);
Клиент, после успешного запроса к joinserver обновляет свою сессию, чтобы она оставалась валидной, на md5(сессия+ключ);
Для joinserver.php:
Перед каждым
Добавляем
Код:
echo "ok";
Код:
$fsessid = md5($sessionid."ваш_ключ");
mysql_query("UPDATE $db_table SET $db_columnSesId='$fsessid' WHERE $db_columnUser = '$user'");
Отрываем эклипс с рабочим каталогом MCP
Идем в net.minecraft.client.multiplayer.NetClientHandler
И в конец добавляем
Теперь находим строчку
И под ней добавляем
Сохраняем.
Запускаем recompile.bat
Затем reobf.bat
идем в %MCP%/reobf/Minecraft
Забираем класс, лежащий в ней (на версии 1.4.7 это ayh.class)
С помощью InClassTranslator меняем в новом классе путь до joinserver
Заливаем класс в ваш minecraft.jar
Идем в net.minecraft.client.multiplayer.NetClientHandler
И в конец добавляем
Код:
private void func198i (){
String x0 = this.mc.session.sessionId;
x0 = getHash(x0+"ваш_ключ");
this.mc.session.sessionId = x0;
}
public static String getHash(String str){
MessageDigest m;
try {
m = MessageDigest.getInstance("MD5");
m.reset();
try {
m.update(str.getBytes("utf-8"));
String s2 = new BigInteger(1,m.digest()).toString(16);
while(s2.length() < 32 ){
s2 = "0"+s2;
}
return s2;
} catch (UnsupportedEncodingException e) {
return e.toString();
}
} catch (NoSuchAlgorithmException e) {
return e.toString();
}
}
Код:
URL var4 = new URL("http://session.minecraft.net/game/joinserver.jsp?user=" + urlEncode(par1Str) + "&sessionId=" + urlEncode(par2Str) + "&serverId=" + urlEncode(par3Str));
Код:
func198i();
Запускаем recompile.bat
Затем reobf.bat
идем в %MCP%/reobf/Minecraft
Забираем класс, лежащий в ней (на версии 1.4.7 это ayh.class)
С помощью InClassTranslator меняем в новом классе путь до joinserver
Заливаем класс в ваш minecraft.jar
Что имеем теперь:
Перед WireShark loginserver палит невалидную сессию.
joinserver палит валидную сессию, но после выполнения запроса она становится невалидной.
ВАЖНО!!!
Защита не идеальна, программист сможет ее обойти. Но ему придется потрудиться написать мод, и для каждого сервера нужно будет делать индивидуальный обход.
Можно усложнить ему работу шифрованием классов лаунчера в jar2exe и антидеобфускаторскими штучками для minecraft.jar.
Спасибо за внимание.
Для серверов с Forge и на версии 1.4.7 выложу готовый ayh.class, замените ключ с помощью InClassTranslator (строка your_key).
