Xipho

Хорошее исследование провел, а у меня так руки и не дошли за эти выходные

Немного оффтопа - тут я вспомнил "войну" с одним покерным румом, для которого я как-то писал бота )) Вспомнил, и нервно захихикал от слов "никак бы не спалили... потому что... имитирует нажатие клавиш..." )) Впрочем, к онлайн играм, чаще всего, так строго не относятся ) Кстати, вместо отсылки сообщений можно использовать SendInput - у нее более широкие возможности https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-sendinput https://stackoverflow.com/a/22419083 Более широкие - например, можно имитировать сразу нажатие двух клавиш - сброс бомбы и отмену сброса следующей. Тогда, возможно, во втором потоке надобность отпадет.

Так тебе же Партизан выше написал - x64dbg/x32dbg с плагином ScyllaHide

Исходя из твоей задачи (помним про 200 миллисекунд), таймер может не подойти, потому что у него не гарантировано срабатывание точно по его истечению. Таймер гарантирует срабатывание не раньше заданного интервала, но не регламентирует точность. Смотри, как бы тебя не забанили за использование такой программы

Что это значит?

С точки зрения чистоты кода, у тебя сейчас поток выполняет две разные задачи - выставляет флаг и потом, в зависомости от этого флага, действует. В целом, для небольшого функционала можно и так оставить. В твоем случае, чтобы проц не долбился в сотку, можно добавить sleep на 5-10 милисекунд, мне кажется, это должно решить твою проблему. Но если совсем по фен-шую делать - можно вынести функционал отправки клавиш и проверки режима в отдельный поток с бесконечным циклом и задержкой. А по клавишам поток создавать и убивать. Тогда и флаг не понадобится )

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

Из того, что я прочитал, я увидел следующую картину - быстрое чтение и выполнение каких-либо действий нужно только тогда, когда mode включен. Если я правильно понимаю, вынесение кода ожидания горячих клавиш в отдельный поток не решит проблему стопроцентной загрузки процессора - тебе всё равно придется добавлять ожидание хотя бы 5 милисекунд (для твоего интервала в 200 милисекунд это не должно быть критично). По остальному - не видя код перед глазами довольно сложно искать пути оптимизации.

1. Идешь в хранилище исходников CheatEngine (сиречь репозиторий) 2. Находишь там раздел, где публикуются проблемы программы 3. Публикуешь туда описание ошибки, которая у тебя возникает и сценарий для ее воспроизведения 4. Ждешь, когда ошибку поправят.

HDC hdcColor = CreateCompatibleDC(compatibleDC.origDC); HDC hdcMask = CreateCompatibleDC(compatibleDC.origDC); HBITMAP prevColor = reinterpret_cast<HBITMAP>(GetCurrentObject(hdcColor, OBJ_BITMAP)); HBITMAP prevMask = reinterpret_cast<HBITMAP>(GetCurrentObject(hdcMask, OBJ_BITMAP)); HBITMAP color = CreateCompatibleBitmap(compatibleDC.origDC, 32, 32); HBITMAP mask = CreateCompatibleBitmap(compatibleDC.origDC, 32, 32); HICON icon1 = reinterpret_cast<HICON>(LoadImageW(WGW::hInstance, MAKEINTRESOURCE(_IDI_FRUT), IMAGE_ICON, 32, 32, 0)); SelectObject(hdcColor, color); SelectObject(hdcMask, mask); ICONINFO iconInfo{ 0 }; BITMAP bitmap{ 0 }; GetIconInfo(icon1, &iconInfo); GetObjectW(iconInfo.hbmMask, sizeof(bitmap), &bitmap); SelectObject(hdcColor, iconInfo.hbmMask); BitBlt(compatibleDC.origDC, 0, 0, bitmap.bmWidth, bitmap.bmHeight, hdcColor, 0, 0, SRCAND); SelectObject(hdcMask, iconInfo.hbmColor); BitBlt(compatibleDC.origDC, 0, 0, bitmap.bmWidth, bitmap.bmHeight, hdcMask, 0, 0, SRCINVERT); DrawIconEx(compatibleDC.origDC, 50, 0, icon1, 32, 32, NULL, NULL, DI_MASK | DI_IMAGE); HBITMAP prevColor = reinterpret_cast<HBITMAP>(GetCurrentObject(hdcColor, OBJ_BITMAP)); HBITMAP prevMask = reinterpret_cast<HBITMAP>(GetCurrentObject(hdcMask, OBJ_BITMAP)); Зачем это предварительное расшаркивание? SelectObject возвращает замещенный объект Дальше. Если мне не изменяет память, при создании GDI структур их нельзя вчистую нулями заполнять. У большинства из них есть поле dwSize, которое нужно заполнять, чтобы функции, использующие эти структуры, корректно отрабатывали. Но тут это не точно. Для загрузки иконок вроде как есть LoadIcon, заточенный специально под иконки Ну а артефакты говорят о том, что ты неправильно работаешь с маской. В случае с иконками, помнится, использовал режим SRCPAINT. Но это для старых иконок, где фон, по сути, был черным. По остальному - на выхах, если будет время, попробую освежить контекст в голове по рисованию с GDI. Но что-то ты явно с маской делаешь не так.

Отладчики тоже пишутся руками ) Потому, конечно же, никто не мешает тебе изучить тему их написания, и сделать что-то подобное с ограниченным, нужным только тебе функционалом. Другое дело, что вряд ли это стоит времязатрат. Скорее всего, действительно, желаемого можно достичь другим путем. Особенно, если учесть, что во многих играх есть антиотладочные приемы, а онлайн игры и вовсе разными способами препятствуют отладке.

А причем тут юникод? Вполне возможно, движок форума использует дефисы в качестве какого-то внутреннего разделителя для какой-либо токенизации. Я в дебри движка не залезал, не в курсе. Лень, потому что при следующем обновлении оно снова слетит - движок не лишен недостатков.

Значение может храниться в неявном виде. Такие значения нужно искать по принципу уменьшилось/увеличилось/не изменилось, а не как конкретные. Это очевидный путь проб, если с точным значением поиск не сработал. И да, ромов, как и игр - тысячи. Объяснять нюансы каждого из них - бред.

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

После обновления версии движка форума сломался плагин, подставляющий формы. Починим.

Когда вы, блин, уже лениться перестанете??? На нашем канале есть видео, неужели трудно пойти и посмотреть?

У меня в подписи есть ссылка на наш канал, там целый плейлист по взлому игр, и как минимум в нескольких видео есть работа с общими инструкциями

Извиняй, обсуждение взлома онлайн игр у нас доступно только для привилегированных пользователей. По теме могу посоветовать только одно - смотри по коду выше, откуда в r8 попадает адрес. Там, возможно, уже будет оффсет.

Эммм, ты о чём? Тут как раз видеоурок и есть.

Попробуй так:

Можно и главный, там всё равно есть цикл обработки сообщений виндовых, можно прям туда затолкать при желании. Но это уже вопрос личных предпочтений. Я предпочитаю отделять мух от котлет. Если планировщик в отдельном (не GUI потоке), это может вызвать определенные проблемы. В остальном - зависит от тебя. Если ты правильно накидаешь заданий, то почему бы и нет. Ничего сложного в этой задаче нет. Вот абсолютно. Сложность может быть только на этапе проектирования хранилища и сущностей заданий - тебе нужно четко понимать, какого рода задания ты будешь в него заталкивать. И тут, кстати, очень хорошо ложится паттерн абстрактной фабрики для порождения заданий. В сочетании с паттерном строителя для универсальности.

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

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

Не припомню, чтобы я эту задачку решал, если честно. Пришел в тему, потому что меня тут отметили. Задачку посмотрю по наличию времени, должно быть, интересная...

https://docs.microsoft.com/ru-ru/windows/win32/dlls/dllmain