Вопрос Как лучше накладывать крипту с кастом жвм на фабрик

[paster_nurika]

Ну типо если наложить крипту на миксины то будет крашить, их просто исключать надо или есть способы реализовать декрипт в жвм для миксинов(у меня есть декрипт обычных классов и он работает но если на миксины то крашит)

 

[crownless]

Ну типо если наложить крипту на миксины то будет крашить, их просто исключать надо или есть способы реализовать декрипт в жвм для миксинов(у меня есть декрипт обычных классов и он работает но если на миксины то крашит)

Проблема, с которой вы столкнулись, — классический случай конфликта на уровне байт-кода. Короткий ответ: да, миксины лучше полностью исключить из процесса шифрования. Если же вам принципиально нужна тотальная защита, придется реализовать дешифрацию на уровне загрузчика классов (JVM), что технически крайне сложно.

Вот почему стандартное шифрование "ломает" миксины и какие есть варианты решения.

Почему миксины нельзя шифровать как обычные классы

Чтобы понять причину краша, нужно разобраться, как работают миксины. Это не просто код, а инструкции для трансформера байт-кода (MixinTransformer), который "сшивает" ваш код с кодом игры .

Представьте процесс так:

1. Загрузка: Игра (через Fabric Loader) начинает загрузку класса, например, net.minecraft.class_239.
2. Перехват: Срабатывает механизм миксинов. Он ищет все @Mixin-классы из вашего мода, которые "целятся" в этот игровой класс.
3. Слияние (Weaving): Трансформер берет ваш зашифрованный класс, расшифровывает его в оперативной памяти и буквально вставляет ваш код в тело оригинального метода игры .
4. Ошибка: Если на любом из этих этапов JVM встретит вместо валидного байт-кода какую-то абракадабру (результат работы вашей ЖВМ), процесс слияния прервется с фатальной ошибкой MixinApplyError или InvalidMixinException .

Сравнение подходов к решению

Вот три подхода, которые вы можете рассмотреть, с их последствиями:

Подход Сложность Надежность защиты Риски для мода
Исключить миксины из шифрования Низкая Минимальная (код миксинов открыт) Нулевые (рекомендованный путь)
Дешифровать миксины в кастомном ClassLoader'е Экстремально высокая Высокая Крайне высокие (нестабильность)
Создать "прокси-классы" (Абстракция) Средняя Средняя Низкие (универсальный вариант)

Реализация и рекомендации

Исходя из опыта разработчиков и анализа проблемы, вот как можно поступить на практике:

1. Лучшее решение: Исключить миксины.
Самое надежное и прагматичное решение — не шифровать классы, содержащие @Mixin. В вашей системе защиты (кастомной ЖВМ) просто добавьте проверку: если класс имеет аннотацию @Mixin или указан в mixins.json, он не отправляется на дешифрацию. Это полностью устранит конфликт на этапе трансформации байт-кода.
2. Альтернатива: Создать уровень абстракции.
Если вы хотите защитить логику, но оставить миксины "прозрачными":
· Пусть ваш @Mixin класс будет очень "тонким" — просто оберткой.
· Внутри метода миксина (@Inject или @Overwrite) вызовите метод из вашего обычного, зашифрованного класса.
· Пример кода:
```java
// Это НЕ шифруем. Он виден всем, но логики в нем нет.
@Mixin(SomeGameClass.class)
public class MyMixin {
@Inject(method = "gameMethod", at = @At("HEAD"))
private void onGameMethod(CallbackInfo ci) {
// А вот этот вызов идет в ваш защищенный код
EncryptedCore.doSecretLogic();
}
}
```
3. Если вы настаиваете на тотальном шифровании (Технически сложно):
· Вам нужно внедриться в процесс загрузки классов до того, как MixinTransformer начнет свою работу.
· Это подразумевает создание собственного ClassLoader или модификацию существующего KnotClassDelegate (стандартного загрузчика Fabric), чтобы он перехватывал и дешифровал байт-код миксинов до передачи его трансформеру.
· Предупреждение: Этот путь требует глубоких знаний байт-кода Java (asm-библиотеки), внутреннего устройства Fabric Loader и, скорее всего, приведет к крашам при каждом обновлении игры или загрузчика модов .

Итог

Надежная защита кода миксинов через шифрование на JVM-уровне — задача нетривиальная и чревата нестабильной работой мода.

Исходя из этого, рекомендую остановиться на исключении миксинов из шифрования. Это стандартная практика, которой следуют многие разработчики для обеспечения совместимости.

Какой из этих подходов кажется вам наиболее приемлемым для вашей задачи?

 

[paster_nurika]

Проблема, с которой вы столкнулись, — классический случай конфликта на уровне байт-кода. Короткий ответ: да, миксины лучше полностью исключить из процесса шифрования. Если же вам принципиально нужна тотальная защита, придется реализовать дешифрацию на уровне загрузчика классов (JVM), что технически крайне сложно.

Вот почему стандартное шифрование "ломает" миксины и какие есть варианты решения.

Почему миксины нельзя шифровать как обычные классы

Чтобы понять причину краша, нужно разобраться, как работают миксины. Это не просто код, а инструкции для трансформера байт-кода (MixinTransformer), который "сшивает" ваш код с кодом игры .

Представьте процесс так:

1. Загрузка: Игра (через Fabric Loader) начинает загрузку класса, например, net.minecraft.class_239.
2. Перехват: Срабатывает механизм миксинов. Он ищет все @Mixin-классы из вашего мода, которые "целятся" в этот игровой класс.
3. Слияние (Weaving): Трансформер берет ваш зашифрованный класс, расшифровывает его в оперативной памяти и буквально вставляет ваш код в тело оригинального метода игры .
4. Ошибка: Если на любом из этих этапов JVM встретит вместо валидного байт-кода какую-то абракадабру (результат работы вашей ЖВМ), процесс слияния прервется с фатальной ошибкой MixinApplyError или InvalidMixinException .

Сравнение подходов к решению

Вот три подхода, которые вы можете рассмотреть, с их последствиями:

Подход Сложность Надежность защиты Риски для мода
Исключить миксины из шифрования Низкая Минимальная (код миксинов открыт) Нулевые (рекомендованный путь)
Дешифровать миксины в кастомном ClassLoader'е Экстремально высокая Высокая Крайне высокие (нестабильность)
Создать "прокси-классы" (Абстракция) Средняя Средняя Низкие (универсальный вариант)

Реализация и рекомендации

Исходя из опыта разработчиков и анализа проблемы, вот как можно поступить на практике:

1. Лучшее решение: Исключить миксины.
Самое надежное и прагматичное решение — не шифровать классы, содержащие @Mixin. В вашей системе защиты (кастомной ЖВМ) просто добавьте проверку: если класс имеет аннотацию @Mixin или указан в mixins.json, он не отправляется на дешифрацию. Это полностью устранит конфликт на этапе трансформации байт-кода.
2. Альтернатива: Создать уровень абстракции.
Если вы хотите защитить логику, но оставить миксины "прозрачными":
· Пусть ваш @Mixin класс будет очень "тонким" — просто оберткой.
· Внутри метода миксина (@Inject или @Overwrite) вызовите метод из вашего обычного, зашифрованного класса.
· Пример кода:
```java
// Это НЕ шифруем. Он виден всем, но логики в нем нет.
@Mixin(SomeGameClass.class)
public class MyMixin {
@Inject(method = "gameMethod", at = @At("HEAD"))
private void onGameMethod(CallbackInfo ci) {
// А вот этот вызов идет в ваш защищенный код
EncryptedCore.doSecretLogic();
}
}
```
3. Если вы настаиваете на тотальном шифровании (Технически сложно):
· Вам нужно внедриться в процесс загрузки классов до того, как MixinTransformer начнет свою работу.
· Это подразумевает создание собственного ClassLoader или модификацию существующего KnotClassDelegate (стандартного загрузчика Fabric), чтобы он перехватывал и дешифровал байт-код миксинов до передачи его трансформеру.
· Предупреждение: Этот путь требует глубоких знаний байт-кода Java (asm-библиотеки), внутреннего устройства Fabric Loader и, скорее всего, приведет к крашам при каждом обновлении игры или загрузчика модов .

Итог

Надежная защита кода миксинов через шифрование на JVM-уровне — задача нетривиальная и чревата нестабильной работой мода.

Исходя из этого, рекомендую остановиться на исключении миксинов из шифрования. Это стандартная практика, которой следуют многие разработчики для обеспечения совместимости.

Какой из этих подходов кажется вам наиболее приемлемым для вашей задачи?

Фрик

 

[w1ndyxz]

Фрик

Сейчас так модно.

 

[paster_nurika]

Я кароч сделал декрипт на джава парте жвм в ZipFile.java которая декриптит перед тем как класс чекает фабрик но хз насколько это будет защищать

 

[Shreek1337]

Ну типо если наложить крипту на миксины то будет крашить, их просто исключать надо или есть способы реализовать декрипт в жвм для миксинов(у меня есть декрипт обычных классов и он работает но если на миксины то крашит)

Можно сделать и на миксины просто сделать вызов декрипт класса перед загрузкой фабрик лоадера ZipFile.java вроде

 

[paster_nurika]

Можно сделать и на миксины просто сделать вызов декрипт класса перед загрузкой фабрик лоадера ZipFile.java вроде

Я так уже делал но хз насколько это эффективно в защите
У меня вопрос что лучше сделать там либо исключить миксины и сделать в .cpp