Речь про LPX. Не про «где-то в jar нашлась строка». Про метод, который у автора решает, жить плагину или нет. В моём файле этот метод больше ничего не решает.
Что делает стоковая дверца
У автора проверка сидит в it.ytnoos.lpx.z. Имени этого класса в констант-пуле соседей нет. Ядро на старте достаёт его из зашифрованной строки, делает Class.forName, берёт конструктор от API и сразу зовёт метод проверки.
Строки закрыты DES/CBC. Пока таблица не открыта, адрес в файле не ищется. Я её открыл отдельно, сервер для этого не нужен. Там одна дверь:
Второй слот, force-fallback, ведёт туда же. С третьей попытки код сам переключается на вторую строку и снова приходит сюда. Запасного сервера нет.
Из конфига читаются два поля. license уходит как есть. force-fallback только выбирает слот, а слоты одинаковые.
Дальше POST. На соединение 15 секунд, на чтение 6. Живым считается только ответ 200. Обрыв повторяется, пока счётчик не станет больше 6, потом обычный IOException и плагин тушит сам себя. Ключ при обрыве мог быть любым. До него просто не дошли.
User-Agent каждый раз один и тот же труп:
Тело — три кадра. Сначала длина, потом байты.
- Ключ из конфига. Открытый.
- Версия jar. Открытая.
- Порт сервера. Закрытый ключом от байтов собственного z.class. Сам class по сети не едет.
До 1.20.5 байты класса берутся как ресурс: точки в имени меняются на слэши, хвост .class. С 1.20.5 класс ищет себя в plugins по маске LPX*.jar, запись должна кончаться на /z.class. Не нашёл — в лог пишет, чтобы jar не переименовывали, и проверка мертва ещё до сокета. Имя файла тут часть протокола, не каприз.
Ответ — не true. Первые два кадра открываются тем же ключом и становятся именем класса и именем метода. Дальше Class.forName, конструктор без аргументов, invoke. В метод передаётся сам LPX. Поведение после проверки приезжает с lpx.ytnoos.it и поднимается в уже запущенной JVM. Третий кадр — boolean, его запоминают как флаг обновления.
Сошлось:
Не сошлось:
И disable. Середины нет. Канал при этом голый http. Кто отвечает по этому имени, тот и выбирает класс.
Что я с этим сделал в 3.9.1
Верхний метод проверки я не трогал ради красоты. Я вырезал тот, на который он опирается.
Сток: верхний зовёт проверку и по boolean пишет успех или гасит плагин.
Мой файл: этот вызов больше не доходит до сокета.
Тело метода теперь такое.
- Поднимается локальный хук it.ytnoos.lpx.q. Он сам регистрирует чеки и доводит старт, который раньше должен был приехать классом в ответе.
- setUpdated(true). Флаг, который автор ждал с того конца, ставится здесь.
- com.blackminecraft.patch.Banner.run(). Один раз в лог плагина LPX пишется Black-Minecraft.com.
- return true.
Наверх уходит успех. Верхний метод честно пишет, что лицензия проверена. Проверять было нечего: true собрано локально. lpx.ytnoos.it в этой секунде не участвует. Конфигный ключ можно не класть. Переименование jar эту дверцу больше не роняет, потому что байты z.class для замка больше не читаются.
Старый POST, Firefox 3.6.2, поиск LPX*.jar и Class.forName по ответу в классе z лежат ниже. Это труп. Я его не вычищал до последней инструкции: на живой путь он не подписан. Кто откроет метод, который реально зовётся с onEnable, увидит баннер и ireturn единицы. Кто откроет соседний метод, увидит лицуху автора целиком и ни одного вызова на неё.
Вот и вся защита. У них удалённый класс по голому HTTP, привязанный к байтам собственного файла. У меня на ресурсе этот класс больше не имеет голоса.
