Начинающий
-
Автор темы
- #1
всем приветсвтую!
короче когда я через CheatEngine либо NOP-аю, либо модифицирую инструкции что бы получить хак(к примеру MultiJump или LongJump), то какое то время у меня все работает, и закономерно ломается.
Если я не совсем дурачье, то виной этому особенность языка Java, динамическое выделение памяти и сборщик мусора.
И в один момент у меня к нужной мне переменной ссылаются одни инструкции, а через какое то время уже другие.
Опять же если взять пример, у нас есть значение isOnGround к которой ссылаются множество инструкций, и одна из этих инструкций проверяет на земле мы или нет, и если нет то не дает нам прыгнуть второй раз, и если эту инструкцию нопнуть то проверка ломается и мы можем прыгать неограниченное кол-во раз. Но повторюсь через какое то время что то ломается, и к значению isOnGround ссылаются уже другие инструкции.
Поиск указателя на переменную и ее заморозка не вариант, на сервере античит который не дает этого сделать и крашит.
Единственное решение проблемы которое я нашел, это после слета инструкции искать новую инструкцию которая относится к нашей переменной, и делать с ней тоже самое(либо нопнуть либо модифицировать смотря какой хак делается)
Опять же взять тот же MultiJump, после слета инструкции идет новый поиск переменной, смотрится какие инструкции обращаются к ней и нопается нужная инструкция, и после 5-6 таких повторений хак уже не слетает.
Проблема данного подхода в том, что без отладчика очень тяжело найти все эти инструкции, потому что каждый раз паттерны инструкции разные, и через код найти их не получается.
Скорее всего вы скажете зачем вообще такая ебка с этой памятью и инструкциями нужна, когда можно делать нормальные читы используя Java/JNI, и вы будете правы!
Но вот такой я абалдуй и перед проблемой которая передо мной стала пассовать не хочу, и очень уж хочется разобраться как можно все же сделать чит на памяти который слетать не будет.
Особо на помощь или какое то объяснение не надеюсь, но если хотя бы подскажете про че почитать и в какую сторону вообще копать буду чрезмерно благодарен
короче когда я через CheatEngine либо NOP-аю, либо модифицирую инструкции что бы получить хак(к примеру MultiJump или LongJump), то какое то время у меня все работает, и закономерно ломается.
Если я не совсем дурачье, то виной этому особенность языка Java, динамическое выделение памяти и сборщик мусора.
И в один момент у меня к нужной мне переменной ссылаются одни инструкции, а через какое то время уже другие.
Опять же если взять пример, у нас есть значение isOnGround к которой ссылаются множество инструкций, и одна из этих инструкций проверяет на земле мы или нет, и если нет то не дает нам прыгнуть второй раз, и если эту инструкцию нопнуть то проверка ломается и мы можем прыгать неограниченное кол-во раз. Но повторюсь через какое то время что то ломается, и к значению isOnGround ссылаются уже другие инструкции.
Поиск указателя на переменную и ее заморозка не вариант, на сервере античит который не дает этого сделать и крашит.
Единственное решение проблемы которое я нашел, это после слета инструкции искать новую инструкцию которая относится к нашей переменной, и делать с ней тоже самое(либо нопнуть либо модифицировать смотря какой хак делается)
Опять же взять тот же MultiJump, после слета инструкции идет новый поиск переменной, смотрится какие инструкции обращаются к ней и нопается нужная инструкция, и после 5-6 таких повторений хак уже не слетает.
Проблема данного подхода в том, что без отладчика очень тяжело найти все эти инструкции, потому что каждый раз паттерны инструкции разные, и через код найти их не получается.
Скорее всего вы скажете зачем вообще такая ебка с этой памятью и инструкциями нужна, когда можно делать нормальные читы используя Java/JNI, и вы будете правы!
Но вот такой я абалдуй и перед проблемой которая передо мной стала пассовать не хочу, и очень уж хочется разобраться как можно все же сделать чит на памяти который слетать не будет.
Особо на помощь или какое то объяснение не надеюсь, но если хотя бы подскажете про че почитать и в какую сторону вообще копать буду чрезмерно благодарен
