Вопрос Camerahack как сделать?

[Blackbro]

всем хай пишу простенький чит на pymem

хочу узнать как сменить дистанцию камеры? нашел адресс, но не уверен так ли написал код.


могу предположить что если тот адресс то код может быть таким

import pymem
import pymem.process

pm = pymem.Pymem("dota2.exe")

client = pymem.process.module_from_name(pm.process_handle, "client.dll")

print("BaseAddres: ", hex(client.lpBaseOfDll))
print("Size: ", client.SizeOfImage)

C_PointCamera = pm.read_longlong(client.lpBaseOfDll + 0x598)

pm.write_int(C_PointCamera + 0x538, 2000)

Спойлер: p.s.

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

если я что-то сделал не так можете меня поправить?

 

[abjk]

ты как камеру получаешь

 

[Blackbro]

ты как камеру получаешь

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

 

[abjk]

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

откуда ты вообще этот оффсет камеры взял

 

[Blackbro]

откуда ты вообще этот оффсет камеры взял

а блять
я конченый
я не тот оффсет запихал

 

[abjk]

Посмотреть вложение 271956
а блять
я конченый
я не тот оффсет запихал

это какого класса блять вообще

 

[Blackbro]

это какого класса блять вообще

мб правильная C_PointCameraVFOV
вот поэтому и спрашиваю что не шарю в этой теме почти 0

 

[abjk]

Посмотреть вложение 271957
мб правильная C_PointCameraVFOV
вот поэтому и спрашиваю что не шарю в этой теме почти 0

а как ты C_PointCamera получаешь?

 

[Blackbro]

не ну принт фов вроде выводит, а при изменении этих значений ошибка
не ебу мб я тупень

 

[Liberalist]

C_PointCamera это не то. и фов(field of view) это не дистанция. и фов это не инт а флоат. и оффсеты которые ты там видишь это не RVA, это оффсеты от адреса объекта.
есть квар dota_camera_distance, он при изменении записывает в "реальную" дистанцию камеры(из которой уже сама камера(CDOTA_Camera) берет дистанцию каждый кадр). поищи в чит енджине дистанцию камеры(флоат) и поизменяй ее через квар. найдешь три - значение квара(от него не зависит дистанция камеры напрямую. только при изменении квара(с вызовом коллбека именно) идет запись в "реальную" переменную), зеленый адрес(т.е. лежащий в модуле) - "реальная" дистанция, член CDOTA_Camera(который каждый кадр из зеленой переменной берет свое значение)
кароче можешь в зеленую фигню записывать(она в .data)
но ничто не мешает габену ее(или член CDOTA_Camera) сравнивать с 1200 и давать тебе пизды если не равно(по крайней мере в теории)

 

[Morphling]

это не та камера.

Пожалуйста, авторизуйтесь для просмотра ссылки.

 

[Blackbro]

это не та камера.

Пожалуйста, авторизуйтесь для просмотра ссылки.

тут не подписанно что за оффсет откуда его взять под нью патч

 

[Morphling]

Посмотреть вложение 272006
тут не подписанно что за оффсет откуда его взять под нью патч

всмысле не подписано? а должно быть? в реклассе ввбиваешь класс cdotacamera, через конвар меняешь камеру и смотришь

 

[Liberalist]

всмысле не подписано? а должно быть? в реклассе ввбиваешь класс cdotacamera, через конвар меняешь камеру и смотришь

в идеале на самом деле да, все подписывать нужно(оффсеты сиги индексы вмт как найти)(хуже от этого не станет). потом через пару лет откроешь проект и будешь думать бля откуда я взял этот оффсет/сигу/и тд, и если старой версии игры не будет чтобы там посмотреть откуда что взялось, то придется заново все искать. особенно это игр без ртти касается и игр с разными версиями и тд. даже если что-то простое типа "в читенджине или в реклассе потыкал" все равно лучше описать это(я в одну 32 битную игру без ртти пару лет не заходил открыл ее а там поменяли к хуям структуру ентити(пару новых полей добавили в начало структуры)(и не только), там ваще все оффсеты сместились а у меня ничего не задокуметировано было заебался фиксить(для таких случаев удобно старые версии игры хранить))

Посмотреть вложение 272006
тут не подписанно что за оффсет откуда его взять под нью патч

это член CDOTA_Camera, найдешь его в чит енджине если будешь искать дистанцию камеры(меняя ее через квар). хвбп(в чит енджине это называется Find out what accesses this address) ставишь и вот тебе оффсет
только он каждый кадр выставляется заново в "реальную" дистанцию камеры(тот код что на скрине байтпатчит(модифицирует .text(он ридонли), за это пизды могут дать) это)

 

[ayneeee]

в идеале на самом деле да, все подписывать нужно(оффсеты сиги индексы вмт как найти)(хуже от этого не станет). потом через пару лет откроешь проект и будешь думать бля откуда я взял этот оффсет/сигу/и тд, и если старой версии игры не будет чтобы там посмотреть откуда что взялось, то придется заново все искать. особенно это игр без ртти касается и игр с разными версиями и тд. даже если что-то простое типа "в читенджине или в реклассе потыкал" все равно лучше описать это(я в одну 32 битную игру без ртти пару лет не заходил открыл ее а там поменяли к хуям структуру ентити(пару новых полей добавили в начало структуры)(и не только), там ваще все оффсеты сместились а у меня ничего не задокуметировано было заебался фиксить(для таких случаев удобно старые версии игры хранить))

это член CDOTA_Camera, найдешь его в чит енджине если будешь искать дистанцию камеры(меняя ее через квар). хвбп(в чит енджине это называется Find out what accesses this address) ставишь и вот тебе оффсет
только он каждый кадр выставляется заново в "реальную" дистанцию камеры(тот код что на скрине байтпатчит(модифицирует .text(он ридонли), за это пизды могут дать) это)

А есть ли хуки, которые не затрагивают ридонли память? Тот же минхук помоему затирает пролог функции и вставляет туда переход. Вмт вроде тоже легко детектятся. Что тогда делать? Вообще хуки не юзать?

 

[creamy89]

C_PointCamera это не то. и фов(field of view) это не дистанция. и фов это не инт а флоат. и оффсеты которые ты там видишь это не RVA, это оффсеты от адреса объекта.
есть квар dota_camera_distance, он при изменении записывает в "реальную" дистанцию камеры(из которой уже сама камера(CDOTA_Camera) берет дистанцию каждый кадр). поищи в чит енджине дистанцию камеры(флоат) и поизменяй ее через квар. найдешь три - значение квара(от него не зависит дистанция камеры напрямую. только при изменении квара(с вызовом коллбека именно) идет запись в "реальную" переменную), зеленый адрес(т.е. лежащий в модуле) - "реальная" дистанция, член CDOTA_Camera(который каждый кадр из зеленой переменной берет свое значение)
кароче можешь в зеленую фигню записывать(она в .data)
но ничто не мешает габену ее(или член CDOTA_Camera) сравнивать с 1200 и давать тебе пизды если не равно(по крайней мере в теории)

Do you think this will happen? In CS GO they did a convar check, although it was poorly implemented with timers. What's stopping them from doing this in Dota? I've heard that perhaps client.dll is too big to be constantly analyzed? After changing client.dll from plain text to encrypted and also doing file checks, convar checks seem to be the last step, at least for a noob like me.

 

[Liberalist]

А есть ли хуки, которые не затрагивают ридонли память? Тот же минхук помоему затирает пролог функции и вставляет туда переход. Вмт вроде тоже легко детектятся. Что тогда делать? Вообще хуки не юзать?

минхук это .text модификация. вмт хук это .rdata модификация. оба ридонли. содержимое этих сегментов в памяти должно быть равно содержимому сегментов с диска после релокации(в файле лежат виртуальные адреса относительно имейджбазы которая указна в файле(ну наверно все видели фигню в иде типа "sub_138001000". так вот это как раз виртуальный адрес относительно имейджбазы. в файле который я взял имейджбаза 0x138000000, а функция находится на RVA 0x1000, в итоге ее виртуальный адрес 0x138001000). изза ASLR(секьюрити фича) в память файлы выгружаются на рандомных адресах, и чтобы они нормально работали нужна таблица релокаций(не всегда). она содержит адреса всех переменных(и их типы) которые содержат виртуальные адреса относительно имейджбазы(их может не быть). из этих адресов вычитается имейджбаза оригинальная(она в заголовках PE лежит. в нашем примере 0x138000000) и прибавляется реальная имейджбаза(ну т.е. где мы аллоцировали память под наш модуль)) и резолва импортов(импорт таблица в .rdata обычно. собственно и экспорты тоже в .rdata)
хороший пример того что надо релоцировать - втейблы.
вот допустим втейбла:

.rdata:0000000140031658 ; const std::exception::`vftable'
.rdata:0000000140031658 ??_7exception@std@@6B@ dq offset sub_140001070
.rdata:0000000140031658                                         ; DATA XREF: sub_140001010+C↑o
.rdata:0000000140031658                                         ; sub_140001070+A↑o ...
.rdata:0000000140031660                 dq offset sub_140001050

она в файле содержит указатели относительно имейджбазы. если ее прямо так выгрузить в память и потом че-нибудь из нее вызвать то крашнет же нахуй просто - нету такого адреса 140001070(т.к. модуль выгрузился на рандомный адрес а не на 140000000)

после релокации относительно 00007FF6E39E0000(туда выгрузился модуль) втейбла будет выглядеть уже вот так(140001070 - 140000000 + 00007FF6E39E0000 = 00007FF6E39E1070)

вот теперь можно вызвать спокойно.
так вот кароче после релокаций и резолва импортов эти ридонли сегменты становятся уже РЕАЛЬНО ридонли(до резолва импортов и релокаций они еще не совсем ридонли, ведь там лежат те же импорты, а у импортов может быть разный адрес(опять таки изза ASLR + сами дллки откуда импортим могут быть разных версий(на разных версиях винды например) и тд), плюс еще релоцировать надо). античит берет из файла оригинальные сегменты, релоцирует(в .text ваще нет релокаций как правило. он прямо с диска грузится без выебонов и 1 в 1 совпадает(не всегда)), резолвит импорты, и сравнивает с тем что в памяти(только ридонли сегменты. ридврайт сегменты естественно могут отличаться им никто не запрещает), и дает пизды если не совпадает
байтпатч хуки: инструкции лежат в .text(ридонли)
вмт хуки: втейблы лежат в .rdata(ридонли)
иат хуки: импорты лежат в .rdata(ридонли)
еат хуки: экспорты лежат в .rdata(ридонли)
юзай .data хуки и тд, при условии что их сложно будет проверить. например тот же Shadow VMT(свап указателя на вмт в объекте(объект может находиться в ридврайт памяти)). впрочем указатель на вмт должен указывать в .rdata, поэтому если он указывает в ебеня кудато то античит может дать пизды(т.е. шедоу вмт говно), но если он не будет проверять(ну ему чтобы проверить нужна(для удобства) какая-то таблица объектов с вмтшками. т.е. например те же таблицы с CreateInterface могут проверить, могут директикс хуйню проверить и тд и тп, а какието индивидуальные объекты могут не проверить при условии что их нет в таблице или их руками не проверяют) то все норм; альтернативно можно заменить указатель на вмт указателем на другую легальную вмт например(существуют вмтшки которые делегируют всю втейблу на член например. ну т.е. у тебя была нормальная вмт которая сама чето делает, а ты ее поменял на эквивалентную вмтшку(их может и не быть) которая перекидывает всю работу на один из членов(который ты подменил на нужный))(

Пожалуйста, авторизуйтесь для просмотра ссылки.

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

 

[Liberalist]

Do you think this will happen? In CS GO they did a convar check, although it was poorly implemented with timers. What's stopping them from doing this in Dota? I've heard that perhaps client.dll is too big to be constantly analyzed? After changing client.dll from plain text to encrypted and also doing file checks, convar checks seem to be the last step, at least for a noob like me.

nothing is stopping them. like you said they tried it for CSGO

Пожалуйста, авторизуйтесь для просмотра ссылки.

they definitely could try something similar with dota(if they haven't already). even worse, they could go further and obtain the values behind the convars(for example cvar dota_camera_distance doesn't really do shit, that's not the real camera distance. there's just a callback that is invoked whenever the convar is changed and that callback fills the real camera distance with cvar value. you can just directly modify that distance without touching the cvar. the problem is that they might decide to go deeper and check actual variables/members instead of cvars and then you might be fucked. idk if they do that already)
in my opinion, reverse communication(client to server, i.e. sending some of the client's variables, configuration and shit like that to the server(usually the server sends you its state and configuration, not the other way around), for example values of your cvars, or fields of entities(some people change entity color/other stuff for illusion esp and the like(coloring illusions blue for example). if that shit is sent to the server those might get detected(let's say entity should be the original color(according to the server), but if the client arbitrarily set that color to something else - then that client can be considered malicious(then again that could just be due to some packet loss/errors/shit like that, so that's probably a flag rather than an immediate ban)))) is a powerful detection vector. that also includes screenshots(valve probably doesn't collect them, but some other games do. then again valve collects demos(not an actual videostream or anything, but just your mouse/camera movements and shit like that)(that your client sends to the server), that can also be used for detection)

 

[Morphling]

А есть ли хуки, которые не затрагивают ридонли память? Тот же минхук помоему затирает пролог функции и вставляет туда переход. Вмт вроде тоже легко детектятся. Что тогда делать? Вообще хуки не юзать?

Можно понять, когда идёт чек на хуки ина это время снимать их

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

Кстати там оказывается без этого можно сделать было, я чето дико тупанул, попозже обновлю

 

[creamy89]

nothing is stopping them. like you said they tried it for CSGO

Пожалуйста, авторизуйтесь для просмотра ссылки.

they definitely could try something similar with dota(if they haven't already). even worse, they could go further and obtain the values behind the convars(for example cvar dota_camera_distance doesn't really do shit, that's not the real camera distance. there's just a callback that is invoked whenever the convar is changed and that callback fills the real camera distance with cvar value. you can just directly modify that distance without touching the cvar. the problem is that they might decide to go deeper and check actual variables/members instead of cvars and then you might be fucked. idk if they do that already)
in my opinion, reverse communication(client to server, i.e. sending some of the client's variables, configuration and shit like that to the server(usually the server sends you its state and configuration, not the other way around), for example values of your cvars, or fields of entities(some people change entity color/other stuff for illusion esp and the like(coloring illusions blue for example). if that shit is sent to the server those might get detected(let's say entity should be the original color(according to the server), but if the client arbitrarily set that color to something else - then that client can be considered malicious(then again that could just be due to some packet loss/errors/shit like that, so that's probably a flag rather than an immediate ban)))) is a powerful detection vector. that also includes screenshots(valve probably doesn't collect them, but some other games do. then again valve collects demos(not an actual videostream or anything, but just your mouse/camera movements and shit like that)(that your client sends to the server), that can also be used for detection)

Thanks for your explanations! The reverse communication seems kind of advanced, at least in regards to valve. I was just wondering why they are doing the whole filecheck thing without actually checking for manipulated bytes in readonly memory. Seems like they just wanna prevent the easiest abuse of manually editing client.dll.