Вопрос Не находит кол-во хп

[aershok]

нашел все оффсеты, адреса выводит в правильном порядке, но как только смещение доходит до хп (2A8) то выводится хуй пойми какой адрес, хотя я ожидал хп, что не так?

#include <iostream>
#include "memory.h"
memory mem;
int main()
{
    uintptr_t myHp = 0;
    mem.Attach(L"dota2.exe", PROCESS_ALL_ACCESS);
    std::cout << mem.pID << std::endl;
    uintptr_t serverBase = mem.GetModule(L"server.dll");
    uintptr_t baseAddr = serverBase + 0x042EBA50;
    ReadProcessMemory(mem.pHandle, reinterpret_cast<LPVOID>(baseAddr), &baseAddr, sizeof(baseAddr), 0);
    std::cout << "Base: " << std::hex << baseAddr << std::endl;
    ReadProcessMemory(mem.pHandle, reinterpret_cast<LPVOID>(baseAddr + 0x0), &baseAddr, sizeof(baseAddr), 0);
    std::cout << "Next: " << std::hex << baseAddr << std::endl;
    ReadProcessMemory(mem.pHandle, reinterpret_cast<LPVOID>(baseAddr + 0x38), &baseAddr, sizeof(baseAddr), 0);
    std::cout << "Next: " << std::hex << baseAddr << std::endl;
    ReadProcessMemory(mem.pHandle, reinterpret_cast<LPVOID>(baseAddr + 0x30), &baseAddr, sizeof(baseAddr), 0);
    std::cout << "Next: " << std::hex << baseAddr << std::endl;
    ReadProcessMemory(mem.pHandle, reinterpret_cast<LPVOID>(baseAddr + 0x2A8), &baseAddr, sizeof(baseAddr), 0);
    std::cout << "Next: " << baseAddr << std::endl;
  


}

скрин не загружется че то, вот ссылка -

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

 

[Liberalist]

server.dll отвечает за локалхост сервер и все его вычисления и логику. в пабе у тебя локалхост сервера не будет. тебе с client.dll работать нужно
ну а по твоей ошибке - у тебя 8 байт считывается вместо 4.
baseAddr + 0x2A8 это уже адрес где лежит хп(инт, 4 байта). не надо оттуда указатель какой-то считывать
на скрин свой посмотри, там нету [] вокруг прибавления 2A8, значит это финальный адрес(откуда уже инт будет считываться)

int myhealth;
ReadProcessMemory(mem.pHandle, reinterpret_cast<LPVOID>(baseAddr + 0x2A8), &myhealth, sizeof(int), 0);

и на ошибки проверять не забывай, ReadProcessMemory не всегда успешна
ну и выводится не совсем "хуй пойми что". 0x272 это и есть 626(твое хп), просто у тебя выводится больше чем надо, т.к. ты 8 байт читаешь(т.е. 4 байт лишнего говна читаешь). там просто на этих лишних 4 байтах лежит еще и m_iMaxHealth, т.е. твое максимальное хп, поэтому у тебя два раза 0x272 там

 

[Morphling]

А в чем смысл юзать мемори класс и не юзать враппер на рид/врайт оттуда?

 

[aershok]

А в чем смысл юзать мемори класс и не юзать враппер на рид/врайт оттуда?

чисто из за attach, getmodule, мне как то RPM больше заходит

 

[aershok]

server.dll отвечает за локалхост сервер и все его вычисления и логику. в пабе у тебя локалхост сервера не будет. тебе с client.dll работать нужно
ну а по твоей ошибке - у тебя 8 байт считывается вместо 4.
baseAddr + 0x2A8 это уже адрес где лежит хп(инт, 4 байта). не надо оттуда указатель какой-то считывать
на скрин свой посмотри, там нету [] вокруг прибавления 2A8, значит это финальный адрес(откуда уже инт будет считываться)
Посмотреть вложение 259792

int myhealth;
ReadProcessMemory(mem.pHandle, reinterpret_cast<LPVOID>(baseAddr + 0x2A8), &myhealth, sizeof(int), 0);

и на ошибки проверять не забывай, ReadProcessMemory не всегда успешна
ну и выводится не совсем "хуй пойми что". 0x272 это и есть 626(твое хп), просто у тебя выводится больше чем надо, т.к. ты 8 байт читаешь(т.е. 4 байт лишнего говна читаешь). там просто на этих лишних 4 байтах лежит еще и m_iMaxHealth, т.е. твое максимальное хп, поэтому у тебя два раза 0x272 там

я уже сам понял эту хуйню, но от души за подробный ответ и советы, лучший

 

[qellzXan]

Может проще гуглить как работает ReadProcessMemory ?
Это прям детское непонимание основ. Все у тебя правильно работает. Тебе лучше не отличатся от стада и идти как все по ооп готовому.
Не пойми не правильно, просто дальше еще сложнее будет. И тут тебе не помогут.
Если ты лично находил офсеты, то потратив 2 минуты на просмотр что лежит в памяти через CE, ты бы понял какая тут ошибка(которой нет).

Ты идешь по пути говнокодера, а не програмиста. Надо было сначала код в голове скомпилировать. Или если ты совсем новичек, то расписывать проверки на каждом шагу.
Этот путь приведет тебя к тому, что если валв на секунду не будут глупцами и решат что-то поменять, то все сломается и тебе придется потратить немало времени на починку.

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

 

[og]

Может проще гуглить как работает ReadProcessMemory ?
Это прям детское непонимание основ. Все у тебя правильно работает. Тебе лучше не отличатся от стада и идти как все по ооп готовому.
Не пойми не правильно, просто дальше еще сложнее будет. И тут тебе не помогут.
Если ты лично находил офсеты, то потратив 2 минуты на просмотр что лежит в памяти через CE, ты бы понял какая тут ошибка(которой нет).

Ты идешь по пути говнокодера, а не програмиста. Надо было сначала код в голове скомпилировать. Или если ты совсем новичек, то расписывать проверки на каждом шагу.
Этот путь приведет тебя к тому, что если валв на секунду не будут глупцами и решат что-то поменять, то все сломается и тебе придется потратить немало времени на починку.

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

С каких пор RPM с хендлом до твоего проца считается надеждным и безопасным? Мы вернулись в 2012?

 

[qellzXan]

С каких пор RPM с хендлом до твоего проца считается надеждным и безопасным? Мы вернулись в 2012?

Ты судишь не по тем критериям. В твоем понимании античит легко видит эти хендлы. И ты сделал вывод, что если их легко найти, то они не такие безопасные.
Если не брать вак, а нормальный античит, то они видят все. И как бы ты не скрывал все обнаружено.
И я предлагаю тебе судить по критериям реверса античитов. Они быстрее забанят лишний "Скрытый по всем правилам безопасности" драйвер запущеный через процес(например) Инвидиа или дискорда, чем забанят обычное RPM. Если наешь логику античитов то среди выборки аргументов arg1 && arg2 && arg3 && arg3 я могу правильно ткнуть хотя бы в один из них и античит меня не забанит. Поэтому RPM такой безопасный. В отличии от супер навороченых методов внедрения,которые сразу же имеют приоритет бана выше, чем RPM. Только потому, что шанс того что это чит - выше. Так как античиты учитывают момент с чтением процесса других программ и в своей логике они учтены как возможная погрешность.

 

[VUNTA]

Ты судишь не по тем критериям. В твоем понимании античит легко видит эти хендлы. И ты сделал вывод, что если их легко найти, то они не такие безопасные.
Если не брать вак, а нормальный античит, то они видят все. И как бы ты не скрывал все обнаружено.
И я предлагаю тебе судить по критериям реверса античитов. Они быстрее забанят лишний "Скрытый по всем правилам безопасности" драйвер запущеный через процес(например) Инвидиа или дискорда, чем забанят обычное RPM. Если наешь логику античитов то среди выборки аргументов arg1 && arg2 && arg3 && arg3 я могу правильно ткнуть хотя бы в один из них и античит меня не забанит. Поэтому RPM такой безопасный. В отличии от супер навороченых методов внедрения,которые сразу же имеют приоритет бана выше, чем RPM. Только потому, что шанс того что это чит - выше. Так как античиты учитывают момент с чтением процесса других программ и в своей логике они учтены как возможная погрешность.

Я согласен с тем, что античиты быстрее забанят лишний "Скрытый по всем правилам безопасности" драйвер запущеный через процес, чем забанят обычное RPM. Это связано с тем, что античиты учитывают момент с чтением процесса других программ и в своей логике они учтены как возможная погрешность.