Как перехватывать нужные пакеты 1.7.10
- Автор темы Karambula
- Дата начала
-
- Теги
- пакеты 1.7.10
- 1,074
- 72
- 372
Что мешает поставить нормальный фикс уязвимости?
- 42
- 8
Простой перехват конкретного пакета работает по тому же принципу, что и фикс - лезешь в обработчик пакета со стороны сервера и вносишь нужные тебе правки в самое начало
will0376
Токсичная личность
- 2,077
- 55
- 585
Ну удачи тогда... Гримоиром быстрее было бы поправить пакет...
- 31
- 0
"лезешь в обработчик пакета со стороны сервера и вносишь нужные тебе правки в самое начало"
Можно чутка разжевать?)
- 31
- 0
Если подскажешь как это верно сделать, было бы тоже очень хорошо
- 42
- 8
Можно. Вскрывай мод тинкера, либо найди где-нибудь исходники. Я вскрываю обычным jd-gui и деобфусцирую через bon2.
Ищешь класс с обработкой нужного тебе пакета, копипастишь его целиком в новый проект в IDE(с сохранением пакета), добавляешь деобфусцированную версию мода в либы этого же проекта.
Собираешь, копируешь из собранного джарника изменённый класс в джарник с модом.
Сделал всё правильно - должно заработать.
- 1,074
- 72
- 372
Облегчу вашу участь, избавив от поиска...
tconstruct.util.network.PatternTablePacket
- 7,099
- 324
- 1,510
Это хороший подход только для тестирования фикса в среде. На проде лучше переписать на кормоды или без кормодов заменить обработчик пакета(это возможно)
Иногда это вызывает NoClassDefFoundError
- 1,074
- 72
- 372
Это хороший подход для фикса всех модов и он давно успешно применяется. По крайней мере, ничего точно не отвалится, потому что сохраняется целостность мода. Сложный подход с патчами имеет смысл только для самого майна, поскольку есть много желающих модов внести свои правки в код и здесь нужно сохранять совместимость. Моды же никто не патчит, кроме какого-нибудь alfheim'а.
- 42
- 8
Никогда не испытывал потребности в этом, прекрасно всё работало описанным мной способом, уже года 2 так делаю. В нём есть только пара серьёзных проблем:
1. Затруднительный деплой изменений через манипуляции с джарниками.
2. Крайне по-идиотски это выглядит, когда работаешь над одним таким репо в команде, поэтому я в команде с таким подходом к фиксам не работал
Могла возникнуть ситуация, когда мод не поднимался, но связано это было в 90% случаев с хешами классов, которые из папки META-INF достаточно просто удалить.
Если не хочется так упарываться - можно декомпить мод полностью и работать с его исходниками, собирать всё по-новому у себя. Этот способ самый адекватный, хотя и долгий. К примеру, если взять мод DivineRPG не учитывая то, что у него сурсы на гитхабе лежат, то это займёт часов 6 с учётом поиска либов и написания билд-скрипта, с нормальным декомпилём.
Смысла в нём для одной мелкой правки нет.
Последнее редактирование:
- 7,099
- 324
- 1,510
Минусы подхода с перекомпиляцией части классов:
Минусы подхода с кормодами(миксины, хуклиба)
- С некотором шансом вызывает NoClassDefFoundError
- Я не особо это исследовал, но вроде это связано с различными версиями компилятора
- Редактирование сорцев мода означает потенциальную несовместимость с будущими версиями мода, которые выпустит автор
- Иногда очередной исполнитель после внесения фикса может не оставить актуальных сорцев
- Требуется повторно декомпилировать или декомпилировать еще не редактированные классы
- java 8 иногда обновляется, поэтому этот минус помножается на первый
- Легаси копится
- Без системы контроля версий становится совсем тяжко, а заказчики обычно об этом не парятся
- Низкий порог вхождения
- Дешево делается(если словить NoClassDefFoundError, то плюс нивелируется)
- Для манки-кодеров самое то
Минусы подхода с кормодами(миксины, хуклиба)
- Требуются дополнительные знания
- Большое количество правок в один и тот же метод затрудняет осознание полной картины
- Работает безотказно
- Модульность - правки в отдельном моде
- Правильно написанный миксин или хук с большой вероятностью продолжит правильно работать даже если целевой класс будет изменен в следующей версии мода
- И вручную не нужно будет мержить свои изменения и новую версию
- Не нужно декомпилировать целевой класс до состояния, когда его можно скомпилить назад. Достаточно знать сигнатуру целевого метода и примерное содержимое тела
Да, это тоже хороший подход. Имеет смысл когда правок нужно внести много или они требуются периодически
- 1,074
- 72
- 372
- Никогда не встречался NoClassDefFoundError. Обычно проблемы возникают, если мод подписан. Удаляем файлы сертификатов и валуя!
- Если мод обновился, изменённые классы тоже подлежат обновлению. Ничего такого сложно в этом нет.
- Нормальный исполнитель обязан предоставлять исходники, иначе за что платить? За продукт "одноразового" использования?
- Любой нормальный человек должен пользоваться VCS. От этого одни плюсы; отсутствие «Ой, я потерял исходники».
- 1,074
- 72
- 372
Доверьте всю "грязную" работу Gradle - он для этого и существует. В публичных фиксах геймера можно посмотреть, как реализовать замену классов в Jar.
- 31
- 0
- 31
- 0
