-
Постов
1 635 -
Зарегистрирован
-
Посещение
-
Победитель дней
55
Тип контента
Профили
Форумы
Загрузки
Блоги
Весь контент keng
-
Так. Во-первых, WriteByteArray используется скорее для перезаписи кода, т.к. как раз тут удобнее всего использовать массив байт. В твоем случае, как мне кажется, проще было бы использовать WriteInt или WriteFloat. Во-вторых, твоей программе может не хватать прав для корректной работы, так что если ты запускаешь ее из Visual Studio, то запускай всю Visual Studio от имени администратора. Если просто готовый ехе-файл, то так же - от администратора. Попробуй проверить это в первую очередь, т.к. это самое простое и быстрое возможное решение.
-
Какую версию библиотеки ты используешь? Я нашел метод "CheckProcess", который стоит вызвать сразу после инициализации (после строки new VAMemory). "Prj1" при этом - это название процесса или что-то другое?
-
Привет! Код принято оборачивать в тэг "code" и сверху - в "spoiler". Как ты пробовал решать проблему?
-
С этого нужно было начинать.
-
ЩИТО? Ты засовываешь dll в процесс. У процесса есть process id. У процесса может быть окно(а). У каждого есть handle. При этом, если графика в процессе рисуется через Direct3D, то она может проинициализироваться только один раз. Это первое. Второе - у каждого окна есть как минимум класс и заголовок, которые можно найти. При всем при этом у игр в 99% случаев окно только одно, так что я не понимаю, в чем проблема. Находишь process id из dll, по process id находишь handle окна, сообщаешь его обратно dll, готово. [GetCurrentProcessId] ; Получаем идентификатор текущего процесса [EnumWindows] ; Получаем список всех окон [GetWindowThreadProcessId] ; Если идентификатор процесса окна совпадает с тем, что мы нашли ранее, то это нужный нам window handle Готово! Не очень красиво, но винда не предоставляет адекватных механизмов для подобных извращений. P.S.: В чем проблема посидеть часик и поразмышлять или просто погуглить?
-
В папке установки СЕ лежит файл справки CheatEngine.chm, в нем есть раздел MemoryViewer->Script Engine, и там куча всего интересного, в т.ч. и описание функции createHotkey. Я сначала было подумал, что этой функции в документации нет.
-
Вариантов много, в любом случае. Мне было бы проще заранее выяснить hwnd и уже в dll передавать.
-
CreateToolhelp32Shapshot и вперед, бегать по списку и искать по имени модуля. Дальше уже по ProcessID вытащить.
-
Привет! Я бы пошел другим путем - предположив, что юниты явно хранятся в каких-нибудь коллекциях (например, в массивах), я нашел бы характеристики одного юнита (текущее здоровье, к примеру), затем - массив, в котором хранится тип этого юнита и все эти юниты соответственно, а затем - функцию, которая создает новые юниты этого типа и записывает их в массив. В этой функции явно будут читаться минимальные и максимальные значения всех параметров в зависимости от типа создаваемого юнита. Твой пост я чуток подправил - исходный код принято запихивать под соответствующий тэг и под спойлер, потому что кода бывает много и не очень удобно читать эти простыни.
-
Еще можно психануть и в dll unload код закрытия формочки и потока поместить.
-
Ребята, а вы ведь понимаете, что на этой сцене основное мерило - это время? То есть прав (и является автором) тот, кто первым (раньше всех) выложил трейнер или таблицу. Смысл заморачиваться, если все равно это ничего не изменит, а трейнер в любом случае взломают? Вон, тот же Lingon свои трейнеры аж Themida-й обвешивал - толку то, все равно его раскрыли.
-
Закрываю.
-
Очень советую читать официальную документацию в таких случаях. Fasm - не то, что многоразрядный (32/64), он еще и кросс-платформенный. И все прекрасно работает.
-
В целом - все верно.
-
Кто писал? Где?
-
Аргументы пихаются в стек при помощи команды PUSH, так что в твоей функции как минимум один параметр. Можно так же посмотреть изнутри самой функции, поставив брейкпоинт на самое ее начало. В этом случае на стеке будут лежать все аргументы + адрес возврата, так как функции нужно знать, куда потом вернуть управление. Каждый аргумент занимает по 4 байта (или по 8, если ОС 64-разрядная).
-
@Dino, если без сторонних библиотек, то можно воспользоваться банально автоассемблером - он в LuaEngine вполне доступен.
-
У меня, к сожалению, не получится, т.к. компьютер староват, но принцип достаточно простой - в СЕ в "MemoryView" нужно найти адрес, где хранится интересующая строка, далее ПКМ на первом ее символе и "Data Breakpoint" -> "Break on Access", а дальше - надеяться, что это сработает. Второй вариант - искать неизвестное значение. PS: Убедительно прошу не тащить на форум политику, т.к. форум этот посвящен совершенно иной тематике. Я уважаю ст. 29, но все-таки.
-
Отлаживать таким образом - очень экзотическое занятие. Логика в том, что строчка текста возможно (!) используется где-то в игровом движке (например, в логах) и при вызове ответственного за функцию игрового кода движок обратится к этой строке - то есть ему нужно будет его прочитать. Следовательно, можно поставить брейкпоинт на чтение и надеяться на успех, но есть куда более простые методы - от банального поиска неизвестного значения очень трудно спрятаться.
-
Строго говоря, это больше программирование, чем чисто взлом. Почитай, для начала, про GDI, а заодно найди у меня на Youtube-канале (или в блоге) урок про ESP-хак.
-
Привет! Нет абсолютно никакой разницы, пока у языка есть прямой доступ к WinAPI или внешним библиотекам. Следовательно, хоть DX\OGL, хоть Vulkan, хоть GDI - да пожалуйста, можно.
-
Открывай любым текстовым редактором и внимательно вчитывайся.
-
DB говорит, что расширения Lua работают только для х32 и только в виде бинарника. Бинарник лично у меня собрать под Windows не получилось. Чем, кстати, тебе побитовый сдвиг поможет?
-
Или [вот]. А [вот] исходник хамелеона из [этой] статьи. SHA коммита - 789beea9c1fd675549c6b3c61d72d816e4d617ae.