Принцип работы программы SpeedGear v5.0 - Защита от SpeedGear v5.0

zergnm

Ну а что тут непонятного? Кстати даже нафик этот GetSystemTime Вот такой тред решит все проблемы:

Код (Text):

1. while(true)
2. {
3.     DWORD t = timeGetTime();
4.     Sleep(1000);
5.     if(abs(timeGetTime() - t - 1000) > 10)
6.     {
7.         throw std::exception("We gonna fuck you for a long-long time, CHEATER!!! Jay & Bob.");
8.     }
9. }

 

ща попробуем)

 

Я нашел на винте версию 2.00 от 2002 года. Проверил на игре manhunt, потому что у нее в главном меню есть таймер со временем игры типа. Как и ожидалось, оно и ускоряется и замедляется!
А еще игра просто вылетает через некоторое время, даже если не менялась скорость.

 

У меня к тебе просьба, проверь пожалуйста на игре "Manhunt" SpeedGear v5.0 и скажи результат, так как SpeedGear v5.0 намного продвинутее и сделан уже мудрее чем SpeedGear v2.0 !!!

P.S. -> Проверь SpeedGear v5.0 на игре Manhunt и скажи результат пажалуйста !!!!

 

По поводу советов товарища Артема:
Все это слишком банально находится, к тому же надо знать байты разных версии программы, я не думаю что все ваши юзеры используют 5-ю версию проги.

 

BCB6: Call to undefined function timeGetTime()
а в msdn пишет Windows NT/2000/XP: Included in Windows NT 3.1 and later.

 

zergnm

Ну в MSDN-то надо заглядывать

#include <mmsystem.h>
#pragma comment (lib, "winmm.lib")

 

Проверил. Тоже самое-все меняется. А вот вылетать перестала, по changelog'у видно что с версии 2.0 почти ничего не изменилось, тока баги в совместимости. А еще в игре перестал очищатся звуковой буффер, эхо от выстрела звучит постоянно...

 

_DEN_
прям под носом было, не увидел)

 

_DEN_
Там посложнее код Есть еще длл под названием ntport, которая к тому же упакована UPX.

 

crypto

Ну какая разница-то? Sleep-то работает не через timeGetTime, а программа обманывает только его. Значит их можно сравнивать. А насколько сложна реализация обмана timeGetTime - уже не важно.

 

_DEN_
Хуку подвергается 4 функции (а не только timeGetTime). Но если все работает (?), то, как говорится, и хрен с ними, с тонкостями.

 

crypto

Короче, полюбому перехватывается не все API, отвечающее за время. Системные часы ведь свой ход не меняют. А это значит что защиту можно сделать довольно просто.

 

_DEN_
Ну да. Вот такой код у функции GetTickCount() (WinXP SP2):

Код (Text):

1. mov edx,7ffe0000h
2. mov eax,[edx]
3. mul dword ptr [edx+4h]
4. shrd eax,edx,18h
5. ret

Как видишь, никаких лишних вызовов, int 2Eh, sysenter-ов... Стоит добавить такой же код в античит, и от юзермодного перехвата можно избавиться раз и навсегда Да и в кернеле это пофиксить так, чтобы не влияло на другие проги, не просто.

Upd:
Посмотрел этот SpeedGear. Перехватывает заменой первых 5 байт функции timeGetTime, timeSetEvent, GetTickCount, QueryPerformanceCounter. Так что если первый байт этих API - 0E9h, то дело пахнет керосином

 

Гм... Может я ща скажу глупость, но все же

А что если timeGetTime из импорта сравнить с LoadLibrary("winmm.dll") -> GetProcAddress("timeGetTime") ?

 

В смысле сравнить адреса? Тогда без толку - функция перехватывается сплайсингом...

 

_DEN_
Код работает, только иногда (редко) выдает что есть чит когда его на самом деле нет...

 

zergnm

Ну видимо это погрешности Надо сделать типа двойную или тройную проверку. Чтобы 2-3 подряд итерации этого while окончились неудачей например.

UPDATE

Кстати, можно и в одну итерацию. Там в моем примере разница не должна привышать 10 миллисекунд. Т.е. 1%. Можно поднять этот порог до нескольки процентов.

 

Atlantic

Да, речь шла об адресах. А что если с помошью ReadFile прочитать winmm.dll а потом у нее уже делать GetProcAddress ?

 

_DEN_
При сплайсинге адрес самой функции не поменяется. Поменяются только ее первые байты. Поэтому можно просто проверять первый байт по адресу, возвращаемому GetProcAddress. И если это jmp - чит есть.