Написание читов на Майнкрафт

"я писал простые моды и как то меня затянуло в написание читов" - даже не пытайся шагнуть из простых модов сразу аж в читы.

Начнем с того, что большинство современных античитов оперируют не только на уровне пакетов, а на уровне математики, и если ты плохо с программированием, математикой тебе там делать нечего. Методы инжекта в методы разнятся из версии к версии, ибо сигнатура функций, их адреса, разные. Даже если будешь делать инжект в методы через Java нативно, а не используя JNA в C/C++, то это мало тебе что даст, если ты не умеешь оперировать и пакетами и математикой сразу.

А поскольку тебе, как ты сам сказал, надо внедряться в сам процесс, ты столкнешься еще с тем, что тебе придется инжектиться в методы используя адресацию и методы Майна через JNA, которые так то тоже варьируется от версии к версии. В Java, нативно, это было бы легче, так как ты можешь вызывать аннотации вроде @Inject и @Redirect, а в плюсах ты этого не сделаешь. Так же учитывай обфускацию методов, ручные маппинги (для field_ и method_), ибо их тут не будет, как в Fabric, Forge, и т.д, а они меняются из апдейта в апдейт, хоть и у них у всех одна и та же структура. К примеру, для классов:

 MappingInst, SimpleID, ObfuscatedName, ObfuscatedDescriptor, IsStatic
-----
method(m, "getID", "S", "()I", false); 

Насчет математики и тригонометрии это отдельная проблема. Взять за пример тот же GrimAC и его проверку на Reach.

Грим проверяет ричи на базе вычисления пространственного параллелепипеда, ограничивающий размеры и положение сущности, и сама коробка расширяется на некоторое значение порога, которое зависит от конфигурации проверки и версии клиента игрока. Пространственную (B) коробку грим вычисляет забавно, но концепция проста, и он поверяет вектор центра сущности цели (c^->), радуиса (r^->) и... вектор положения кристалла (d^->). То-есть:

 B = { { C^-> - r^->,c^-> + r^->} , { d^-> - (1,0,1),d^-> + (1,2,1)} 

и два условия, если t != или t = конец кристалла, а далее Грим вычисляет точку пересечения между пространственной коробкой (B) цели и лучом, который проходит через вектор положения глаз игрока и вектор конца радиуса атаки игрока.

Эта точка представляет собой ближайшее место, где игрок может попасть по цели своим оружием, и нынче у грима это часто слабое место, триггящее missed hitbox. Но в основном фейлятся проверки, работающие на анализе единичного вектора, несмотря на то, что грим проверяет текущие и предыдущие углы поворота игрока (проверка вычисляет вектор направления взгляда игрока, который представляет собой единичный вектор, указывающий в направлении, куда смотрит игрок.

Этот же вектор зависит от углов поворота головы игрока, которые могут меняться в течение тика): (собственно сам вектор l) l^-> = ( -sin(0)cos(ф) -sin(ф) cos(0)cos(ф) ), где 0 - угол поворота головы игрока по горизонтали (yaw), а - угол поворота головы игрока по вертикали (pitch). И как мне кажется, Нурик его обходит методом смещения вектора относительно головы игрока, опираясь на предикт грима и на очередь атаки которую тот использует (все атаки игрока на другие сущности за последний тик, а также позицию игрока в момент атаки). Если обобщать, то получаем

 d = {  0, min'l^->эL min'p^->эP min'l^->э I(l^->, p^->,B) | e^-> + p^-> - i^->|| } 

но последнее условие, если вектор е пренадлежит B, иначе выполняется другое условие, и где I(l^->, p^->,B) - множество точек пересечения между коробкой B и лучом, проходящим через вектор е + p и вектора е + р + 6l^->.