null

Все клиентские проверки вырезаются, это просто вопрос времени и средств.
Но так как почти все читеры даже на ммору слились, то даже такое говно как JCR защищало сервер от школьников (ну пока УО1.3 не вышел).

 

В таком случае возвращаюсь к своей старой тактике.

 

Присланный с сервера байткод можно выполнить, но как новый класс из нового загрузчика классов. (классы в Java неьзя перезагружать без debug-режима)
А патчить классы можно так:

Спойлер: FMLPlugin

Код:

package fml.plugin;

import cpw.mods.fml.relauncher.IFMLLoadingPlugin;
import java.util.Map;

public class Plugin
  implements IFMLLoadingPlugin
{
  public String[] getLibraryRequestClass()
  {
    return null;
  }
  public String[] getASMTransformerClass()
  {
    return new String[] { "fml.plugin.Transformer" };
  }
  public String getModContainerClass()
  {
    return null;
  }
  public String getSetupClass()
  {
    return null;
  }
  public void injectData(Map<String, Object> data) {}
}

Спойлер: Трансформер

Код:

package fml.plugin;

import java.io.PrintStream;
import net.minecraft.launchwrapper.IClassTransformer;

public class Transformer
  implements IClassTransformer
{
  public Transformer()
  {
     ...................
  }
  public byte[] transform(String name, String transformedName, byte[] bytes)
  {
    ///name -название класса до деобфускации
   ///transformedName - название класса после деобфускации
   ///bytes - байткод
   ///здесь можно патчить байткод (как через ASM, так и читая классы, например, из зашифрованного файла и возвращая новый байткод
  }
  private static void dbg(String str)
  {
    System.out.println(str);
  }
}

Спойлер: MANIFEST.MF

Manifest-Version: 1.0
FMLCorePlugin: fml.plugin.Plugin

Но стоит учесть, что трансформеров в Forge достаточно много и не факт, что ваш сработает самым последним (или самым первым). Для этого существуют аннотации типа @SortingIndex(int) и другие.

Но смысла патчинга почти нет, т.к. классы дампить из JVM не так сложно. Спасет только от большей части читеров.

P.S: ASM не лучший вариант для работы с байткодом.

 

А зачем перезагружать классы? Можно просто прислать пакет и имя класса, а также указать, какой метод в этом классе надо выполнить (Reflection в помощь). Вот и всё. Единственный способ обхода такой защиты, который мне приходит в голову - это перехват получаемого байт-кода, поиск части, отвечающей за ответ серверу (а она может быть всегда разная и находиться в любой точке класса), и выполнение только оной.
P.S. У меня есть ещё идея, как можно заставить сервер/клиент выполнять любой код, но я пока не нашёл мода, в пакете которого передавался бы объект, а на принимающей стороне вызывался какой-либо метод из экземпляра полученного объекта.

 

По поводу объекта - используя Json, сериализируй, посылай String и десириализируй, а мод - DropChanger.
Но что мешает выпилить, допустим, метод выполнения кода на стороне клиента?

 

В передаваемый байт-код я могу добавить код, например, для отправки на какой-то сайт рандомного числа. Если выполнение кода будет вырезано, то и число не отправится. Сервер будет проверять, получал сайт число или нет, если в течении 10 секунд никакого числа не было, то игрока кикает с сервера.

 

Я подчеркиваю:

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

 

Ответ может быть всегда разный. Сегодня, например, я требую отправить число на сайт, а завтра уже мне нужен будет скриншот и т.д. Ответ не содержится в обработчике пакета, он содержится в отсылаемом коде и всегда находится в разных местах. Ещё код перед отправкой можно обфусцировать и т.д. Клиент никогда не будет знать, какой код он получит и что с ним надо будет делать.
Вот пример:
Код сегодня:

Код:

public void start()
{
     sendIntToURI(new URI("http://test.ru/test.php?int=" + Minecraft.getMinecraft().theWorld.getTime());
}

Код завтра:

Код:

public void start()
{
     Thread timeSendingThread = new Thread()
     {
           public void run() {while(true) sendIntToURI(new URI("�������p�����������������������p����������" + Minecraft.getMinecraft().thePlayer.getName());}
      };
     timeSendingThread.start();
     timeSendingThread.setDaemon(true);
}

 

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

 

Деобфускатор можно впихнуть в отсылаемый код.

 

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

 

Но пока человек поймёт, как и что устроено в новом коде, 10 секунд сто раз успеют пройти, а следующие пакеты с кодом могут быть уже другими. Я уже придумал, как всё можно организовать, если кому-то нужна будет такая системка, то могу написать (для 1.7.10).
P.S. Генерация кода будет выполняться при помощи ASM.

 

Это будет полезно в случае с сотнями шаблонов, хотя умелый программист может попросту отловить/проанализировать и запилить "автоответчик", тем более, что пакеты будут высылаться каждые 10 секунд. Как-то оно дыряво звучит.

 

Не каждые 10 секунд, а только тогда, когда потребуется.

 

Это будет решаться выполнением данного кода в сэндбоксе.
Не стоит придумывать велосипед.

 

SecurityManager? Интересно...

 

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

 

Это как вообще? Есть какая-нибудь документация?

 

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

 

Тогда как это решит отлов исходного кода пакетов?
Иными словами, что представляет из себя сэндбокс?