Вопрос Minecraft 1.21.11 — альтернатива OpenGL‑хуку для DLL

[absolutedev]

Парни, кто шарит за майн на новых версиях, нужен совет по архитектуре.

На 1.8.9 я просто хукал OpenGL и спокойно делал аим‑ассист и прочие штуки из DLL — всё работало стабильно почти на всех клиентах и сборках. В 1.21.11 та же схема уже не заходит: через старый OpenGL‑хук ничего толком не получается, а уходить в JNI + маппинги вообще боль.

Проблемы, с которыми столкнулся:

– Хотелось бы остаться на DLL, без JAR‑модов.
– На новых версиях начинаются танцы с бубном вокруг JNI и маппингов:
• у разных клиентов маппинги отличаются;
• в каких‑то билдах маппинги зашифрованы, в каких‑то нет;
• из‑за этого любое решение, привязанное к конкретным названиям/сигнатурам в Java, разваливается от клиента к клиенту.
– Старый подход, когда достаточно было один раз подцепиться к OpenGL‑рендеру и дальше жить в своём мире, на 1.21.11 уже не выглядит универсальным.

Собственно, вопрос:

Какие сейчас есть адекватные альтернативы OpenGL‑хуку для 1.21.11, если нужен именно DLL‑вариант (не JAR), который:

1) не разваливается от клиента к клиенту из‑за разных маппингов;
2) не требует после каждого клиента заново разбирать JNI/обфуску;
3) позволяет реализовать аим/визуал и т.п. примерно так же удобно, как старый OpenGL‑хук на 1.8.9?

Интересует, чем вы сейчас заменяете классический OpenGL‑hook:

– хук рендера/свопа на уровне `opengl32.dll` / `wglSwapBuffers` / DX‑слоя;
– инъекция в сам рендер‑поток LWJGL (но без жёсткой привязки к Java‑именам);
– или вообще переход на другой слой (инпут, матрицы, world‑данные), который можно стабильно трогать из C++‑DLL независимо от того, как клиент замаплен/зашифрован.

Кто уже адаптировал свои DLL‑читы под 1.21.x без прямого OpenGL‑хука — отпишитесь, какой вариант показался самым живучим и менее зависимым от конкретного клиента.

 

[GoogleEmoloyer]

Парни, кто шарит за майн на новых версиях, нужен совет по архитектуре.

На 1.8.9 я просто хукал OpenGL и спокойно делал аим‑ассист и прочие штуки из DLL — всё работало стабильно почти на всех клиентах и сборках. В 1.21.11 та же схема уже не заходит: через старый OpenGL‑хук ничего толком не получается, а уходить в JNI + маппинги вообще боль.

Проблемы, с которыми столкнулся:

– Хотелось бы остаться на DLL, без JAR‑модов.
– На новых версиях начинаются танцы с бубном вокруг JNI и маппингов:
• у разных клиентов маппинги отличаются;
• в каких‑то билдах маппинги зашифрованы, в каких‑то нет;
• из‑за этого любое решение, привязанное к конкретным названиям/сигнатурам в Java, разваливается от клиента к клиенту.
– Старый подход, когда достаточно было один раз подцепиться к OpenGL‑рендеру и дальше жить в своём мире, на 1.21.11 уже не выглядит универсальным.

Собственно, вопрос:

Какие сейчас есть адекватные альтернативы OpenGL‑хуку для 1.21.11, если нужен именно DLL‑вариант (не JAR), который:

1) не разваливается от клиента к клиенту из‑за разных маппингов;
2) не требует после каждого клиента заново разбирать JNI/обфуску;
3) позволяет реализовать аим/визуал и т.п. примерно так же удобно, как старый OpenGL‑хук на 1.8.9?

Интересует, чем вы сейчас заменяете классический OpenGL‑hook:

– хук рендера/свопа на уровне `opengl32.dll` / `wglSwapBuffers` / DX‑слоя;
– инъекция в сам рендер‑поток LWJGL (но без жёсткой привязки к Java‑именам);
– или вообще переход на другой слой (инпут, матрицы, world‑данные), который можно стабильно трогать из C++‑DLL независимо от того, как клиент замаплен/зашифрован.

Кто уже адаптировал свои DLL‑читы под 1.21.x без прямого OpenGL‑хука — отпишитесь, какой вариант показался самым живучим и менее зависимым от конкретного клиента.

 

[fetedevanilla]

Парни, кто шарит за майн на новых версиях, нужен совет по архитектуре.

На 1.8.9 я просто хукал OpenGL и спокойно делал аим‑ассист и прочие штуки из DLL — всё работало стабильно почти на всех клиентах и сборках. В 1.21.11 та же схема уже не заходит: через старый OpenGL‑хук ничего толком не получается, а уходить в JNI + маппинги вообще боль.

Проблемы, с которыми столкнулся:

– Хотелось бы остаться на DLL, без JAR‑модов.
– На новых версиях начинаются танцы с бубном вокруг JNI и маппингов:
• у разных клиентов маппинги отличаются;
• в каких‑то билдах маппинги зашифрованы, в каких‑то нет;
• из‑за этого любое решение, привязанное к конкретным названиям/сигнатурам в Java, разваливается от клиента к клиенту.
– Старый подход, когда достаточно было один раз подцепиться к OpenGL‑рендеру и дальше жить в своём мире, на 1.21.11 уже не выглядит универсальным.

Собственно, вопрос:

Какие сейчас есть адекватные альтернативы OpenGL‑хуку для 1.21.11, если нужен именно DLL‑вариант (не JAR), который:

1) не разваливается от клиента к клиенту из‑за разных маппингов;
2) не требует после каждого клиента заново разбирать JNI/обфуску;
3) позволяет реализовать аим/визуал и т.п. примерно так же удобно, как старый OpenGL‑хук на 1.8.9?

Интересует, чем вы сейчас заменяете классический OpenGL‑hook:

– хук рендера/свопа на уровне `opengl32.dll` / `wglSwapBuffers` / DX‑слоя;
– инъекция в сам рендер‑поток LWJGL (но без жёсткой привязки к Java‑именам);
– или вообще переход на другой слой (инпут, матрицы, world‑данные), который можно стабильно трогать из C++‑DLL независимо от того, как клиент замаплен/зашифрован.

Кто уже адаптировал свои DLL‑читы под 1.21.x без прямого OpenGL‑хука — отпишитесь, какой вариант показался самым живучим и менее зависимым от конкретного клиента.

Было дело

 

[Markst]

Парни, кто шарит за майн на новых версиях, нужен совет по архитектуре.

На 1.8.9 я просто хукал OpenGL и спокойно делал аим‑ассист и прочие штуки из DLL — всё работало стабильно почти на всех клиентах и сборках. В 1.21.11 та же схема уже не заходит: через старый OpenGL‑хук ничего толком не получается, а уходить в JNI + маппинги вообще боль.

Проблемы, с которыми столкнулся:

– Хотелось бы остаться на DLL, без JAR‑модов.
– На новых версиях начинаются танцы с бубном вокруг JNI и маппингов:
• у разных клиентов маппинги отличаются;
• в каких‑то билдах маппинги зашифрованы, в каких‑то нет;
• из‑за этого любое решение, привязанное к конкретным названиям/сигнатурам в Java, разваливается от клиента к клиенту.
– Старый подход, когда достаточно было один раз подцепиться к OpenGL‑рендеру и дальше жить в своём мире, на 1.21.11 уже не выглядит универсальным.

Собственно, вопрос:

Какие сейчас есть адекватные альтернативы OpenGL‑хуку для 1.21.11, если нужен именно DLL‑вариант (не JAR), который:

1) не разваливается от клиента к клиенту из‑за разных маппингов;
2) не требует после каждого клиента заново разбирать JNI/обфуску;
3) позволяет реализовать аим/визуал и т.п. примерно так же удобно, как старый OpenGL‑хук на 1.8.9?

Интересует, чем вы сейчас заменяете классический OpenGL‑hook:

– хук рендера/свопа на уровне `opengl32.dll` / `wglSwapBuffers` / DX‑слоя;
– инъекция в сам рендер‑поток LWJGL (но без жёсткой привязки к Java‑именам);
– или вообще переход на другой слой (инпут, матрицы, world‑данные), который можно стабильно трогать из C++‑DLL независимо от того, как клиент замаплен/зашифрован.

Кто уже адаптировал свои DLL‑читы под 1.21.x без прямого OpenGL‑хука — отпишитесь, какой вариант показался самым живучим и менее зависимым от конкретного клиента.

Что будешь делать на 26.1.2 версии? где вулкан