Как найти статический адрес cheat engine

Как доподлинно известно, адрес в оперативной памяти — некий условный шестнадцатеричный идентификатор (а еще проще — обычное число) для взаимодействия программы с реальной физической памятью. По конкретному адресу всегда расположен ровно 1 байт информации. При этом значение любой переменной в программе хранится по какому-то адресу, даже у переменной, для которой выделено больше 1 байта. Например, если по адресу 0CC9B840 хранится переменная в 2 байта со значением в 10000, то в памяти по адресу 0CC9B840 будет храниться 10h, а по адресу 0CC9B841 будет храниться 27h (10000 в hex-кодировке будет выглядеть как 1027 с учетом обратного порядка чередования байтов). Но для программы важен именно начальный адрес всего блока из 2 байтов. Просто программа знает, что нужно использовать последовательно 2 байта информации, начиная с байта по искомому адресу — соответствующий тип переменной использовался разъеботчиком при написании исходного кода.

Каждый кулхацкер сталкивается с тем, что ранее найденный адрес со значением здоровья, патронов или выпусков журнала «Горячие попки ванамингосов» после перезапуска игры, уровня, а то и вовсе ВНЕЗАПНО становится нерабочим — теперь в нем хранится какое-то другое значение или вообще мусор (так называемый garbage — данные, на которые больше нет никаких ссылок). И нужно, превозмогая боль и страх, со штангенциркулем искать новый вожделенный адрес. Происходит сие непотребство из-за так называемого динамического распределения памяти — механизма создания и хранения программами данных в оперативной памяти непосредственно в процессе работы самой программы (называется «в рантайме»). Нужно игре выделить какой-то диапазон адресного пространства под свои данные? Да пожалуйста. Во время своей работы игра жонглирует данными постоянно, выделяя и освобождая память по необходимости. Создался новый враг? Отлично, под его данные выделено N байт. Враг получил передозировку киберсвинца в организьме и больше он нам и нахуй не нужон, враг ваш? Память, ранее выделенную под него, можно освободить и сделать доступной для записи каких-то иных данных, например, для спавна другого врага.

И, собственно, из-за этого блядского цирка с пересозданием объектов и происходит переезд данных на новые адреса в памяти, например, при переходе на новый уровень — игре нужно заново создать уровень и наполнить его объектами. При этом игре лишь нужно знать, с какого адреса будут начинаться данные нового уровня (увязать все это взаимодействие — задача компилятора, программист и в страшном сне заниматься этим не захочет), а относительно этого адреса игра будет пользоваться так называемыми указателями (pointers) на адреса — ссылками на начальные адреса вновь создаваемых объектов согласно принятой иерархии или на адреса, по которым располагаются конкретные значения.
Исходя из сказанного, можно сделать следующие выводы:
1. Память однородна. Ячейка памяти может хранить как исполняемый код, так и какие-то данные.
2. Если данные хранятся непосредственно по какому-то адресу в памяти, доступ к ним осуществляется напрямую при обращении к этому адресу.
3. По какому-то адресу в памяти можно разместить не конечные данные, а указатель — ссылку на какой-то другой адрес, где хранятся нужные данные.
4. Если указатель ссылается на другой указатель, то такой указатель будет называться многоуровневым. Времена одноуровневых указателей давно в прошлом, поэтому 99% нужных нам указателей будут многоуровневыми.

Тут надо сделать маленькое лирическое отступление о причинах возникновения такого порядка вещей. Всему виной повсеместное использование ООП — объектно-ориентированного программирования. Такой подход позволяет оперировать объектами игры как с некими абстрактными структурами данных, и хранить однотипные данные не в обособленных переменных, а в заранее определенном формате. Например, при создании нового объекта типа пони можно последовательно хранить имя пони, тип пони (обычная поня, пегас, единорог, аликорн и т.д.), цвет пони в кодировке RGB, тип кьютимарка (отличительный знак на ляжке — пояснение для жалких унтерменшей, не смотревших прогрессивные мультики про поней). Таким образом, когда будет создан новый объект типа пони, информация о нем будет заранее определенным образом упорядочена при описании структуры или класса объекта.

На абстрактном языке погромирования это может выглядеть следующим образом:

struct Pony
{
char name[10]; // 10 байт под имя
short type; // 2 байта под тип пони
byte color[3]; // 3 байта под цвет
byte cutiemark; // 1 байт под тип кьютимарка
}

Возможность создавать такие однотипные структуры данных позволяет экономить сотни времени, наделяя объекты общими данными и методами работы с ними.

Теперь представим, что мы как-то адекватно хотим описать в коде игры возможность пегасов летать. Создадим некую структуру данных и назовем ее PonyType. Пусть другие типы, кроме пегасов, нас сейчас не волнуют, и мы просто хотим в один байт уместить информацию о возможности или невозможности пони летать.
Для этого объявим в этой структуре логическую переменную canFly типа bool, которая может принимать значения true либо false, занимая при этом ровно 1 байт. Также добавим еще 1 байт под запас энергии для полета.

struct PonyType
{
bool canFly;
byte energy;
}

А теперь начинается интеграционная дружбомагия. В исходную структуру типа Pony поместим указатель на структуру типа PonyType:

struct Pony
{
char name[10];
PonyType* type; // тот самый указатель на тип в виде звездочки *
byte color[3];
byte cutiemark;
}

Таким образом, при создании нового объекта типа Pony информация о возможности летать и запасе энергии будет передаваться через указатель на структуру PonyType. Чсх, в памяти это будет занимать те же самые 2 байта, как если бы использовали ранее применявшийся целочисленный тип short.

Для программиста, который занимается разработкой структуры типа Pony, теперь не имеет значения, что там внедряет другой программист, занимающийся разработкой структуры PonyType. При правильной организации кода игры любые изменения в структуре PonyType никак не отразятся на работоспособности структуры Pony. Собственно, ради этого все и затевалось. Конечно, на таком простом примере сложно ощутить все преимущества ООП, но мейнстримом он стал не за красивые глаза.
И теперь уже совсем нетрудно построить некоторую цепочку указателей, начиная от создания мира.
Остальные данные структур не отображены для экономии пространства:

// структура лучезарного эквестрийского мира с множеством локаций
struct Equestria
{
.. // какие-то другие данные
City* city[36]; // для выделения памяти под 36 объектов типа City
}

// структура уютненького Понивилля с множеством поняшек
struct City
{
..
Pony* pony[100]; // для выделения памяти под 100 объектов типа Pony
}

// структура няшечки Рейнбоу и любой другой пони
struct Pony
{
..
PonyType* type; // для выделения памяти под 1 объект типа PonyType
}

// структура типа пони
struct PonyType
{
..
byte energy; // для выделения 1 байта памяти под значение энергии
}

Таким образом, например, при перезапуске игры нужно вновь создать объект типа Equestria, записав его начало по новому адресу, а дальше последовательно будет выделена память под 36 объектов типа City, для каждого и которых будет последовательно выделено место под 100 объектов типа Pony, в каждом из которых, в свою очередь, будет выделено место под 1 объект типа PonyType.
Адресация во всех этой махине зависит полностью от одного адреса — адреса начала объекта типа Equestria. И если нас интересует конечный адрес количества энергии на полет конкретной пони, то он каждый раз будет новый. Но с точки зрения игры все остается по прежнему:
→ Она знает начальный адрес, по которому прописался исполняемый код игры.
→ От него она отсчитывает известное количество байт, занимаемое исполняемым кодом и не относящимися к генерации уровня данными, и там начинает записывать данные, уже относящиеся к генерации уровня — то есть создает объект типа Equestria.
→ Далее по системе указателей она доходит до конечного пункта — количества энергии у конкретной пони — и использует его.

На слове последовательно я акцентирую внимание по той причине, что по нашей схеме будет использовано сквозное заполнение адресного пространства оперативной памяти: сначала будут созданы какие-то исходные данные объекта типа Equestria, затем создан первый объект типа City и все объекты типа Pony, затем второй объект типа City и все объекты типа Pony и так далее.

Собственно, зная адрес начала объекта типа Equestria и последовательность смещений до энергии конкретной пони, мы всегда может восстановить искомый адрес энергии. Задача поиска рабочего адреса энергии возлагается на рабочий указатель.
В рассматриваемом случае буквально получается, что объект типа Equestria создается по адресу, по которому была записана в оперативную память сама игра (ее исполняемый файл Game.exe) плюс некоторое смещение 10EF0C, необходимое игре для записи своего исполняемого кода и каких-то иных данных.
Относительно адреса объекта типа Equestria на значение C0 смещено расположение конкретного объекта типа City, относительно которого на значение FAD8 смещено расположение конкретного объекта типа Pony, относительно которого на значение 02FF смещено расположение конкретного объекта типа PonyType, относительно которого на значение 01 смещено расположение искомого значения энергии.
Обладая этой информацией, мы почти всегда однозначно можем определить истинный адрес искомого значения энергии.

И все это благолепие справедливо, конечно же, в том случае, если нужный нам город и нужная нам поня создаются первыми (вторыми, десятыми, главное — стабильность положения относительно начала) во всем массиве объектов (что часто бывает, поскольку именно относящиеся к игроку данные загружаются первыми). Также нужно уточнить, что адрес объекта типа Equestria может и не быть статическим (то есть неизменным от загрузки к загрузке — в нашем случае это Game.exe + 10EF0C), если не предопределен конечный объем данных перед его загрузкой. В этом случае адрес начала ключевого объекта должен быть найден способами, не входящими в данный гайд (через поиск так называемых сигнатур — уникальных последовательностей байтов). О сигнатурах мы тоже когда-то обязательно поговорим.

Резюмируя затянувшуюся вводную часть, подчеркну, что никакой мистики тут нет. С точки зрения кулхацкерства указатель — всего лишь ссылка на начальный адрес объекта внутри адресного пространства другого объекта либо непосредственно на адрес, по которому расположены требуемые данные.
Для успешного кулхацкерства достаточно знать, как вся система примерно работает в целом, а также владеть автоматизированными средствами поиска и ручными методами контроля правильности указателей.
К этому и приступим.

Автоматический поиск указателей
Практическая часть для формирования навыков

Если речь идет не об эрпогэ, где достаточно один раз взломать значение каких-нибудь скиллпоинтов, а затем тупо вкачать героя на полный фарш, поиск указателей является обязательной процедурой. Играя в шутер или РТС, хочется всегда иметь под рукой возможность поковырять ресурсы, здоровье или боезапас, не утруждая себя подчас утомительной процедурой поиска нового адреса. Да и в пошаговой эрпогэ каждый бой искать количество очков действия, если их всего два, а то и одно — нахуй так жыдь?
Но на помощь кулхацкерам приходят средства автоматизации СЕ, благодаря которым поиск рабочих указателей является ничуть не более сложной процедурой, чем стандартный поиск адреса.

Процесс поиска предлагаю рассмотреть на примере первой Мафии. Если при взгляде на главное меню у тебя заиграла в голове та самая музыка, а сердце защемило тоской по былому — я тебя понимаю!

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

Итак, значение найдено. Действующий адрес 16В4744С.

Жмакаем правой кнопкой по адресу и выбираем пункт Pointer scan for this address.

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

Далее СЕ попросит указать расположение файла результатов сканирования указателей в формате PTR.

После появится окно прогресса сканирования.

И завершится все феерическим количеством найденных указателей (результаты уже сохранены в файл 111.PTR). Предлагаю внимательно изучить результаты.
Сверху слева в выпадающем списке указан формат представления данных по конечному адресу, на который ссылается указатель. В нашем случае это 4 байта целочисленное. Конечный адрес указан в крайнем правом столбце Points to.
Сверху по центру указано общее количество найденных указателей: 26769689. 26 мульёнов — шутка ли?
В крайнем левом столбце Base Address указывается базовый статический адрес, относительно которого выстраивается многоуровневый указатель.
В столбцах Offset 0 – Offset 6 указывается смещение на каждом уровне многоуровневого указателя.

Если перенести даблкликом найденный указатель в рабочее поле СЕ и даблкликом же в поле Address открыть окно редактирования Change address, можно будет детально изучить всю структуру добавленного указателя. В рабочем поле указатель помечается префиксом P->.
В окне Change address снизу по центру указаны по порядку все уровни указателя, начиная со статического базового адреса. Справа приводится результат по каждому смещению. Результат по предыдущему вычислению становится исходным адресом для следующего уровня.

Если говорить совсем в открытую, уже сейчас, несмотря на дикое количество результатов, с ними можно работать. Но мы из вредности проведем еще один цикл поиска и отсева. Главное правило при отсеве указателей заключается в максимальном смещении всего адресного пространства, выделяемого под игру. Чаще всего, правда, достаточно игру просто перезапустить, но можно и поизъёбствываться, запустив перед загрузкой игры пару «тяжелых» приложений.
Но мы ограничимся перезапуском самой игры и загрузкой другого уровня. Окно СЕ с результатами поиска указателей по старому адресу остается открытым.

В открытом окне СЕ снова выбираем процесс игры. Проводим поиск нужного адреса. Готово.
В окне поиска указателей можно обратить внимание на то, что ранее найденные указатели, отображенные в данный момент на экране, уже не ссылаются на нужный адрес в памяти игры.

Теперь достаточно скопировать новый найденный адрес (даблклик по полю Address откроет окно редактирования), затем в окне поиска указателей нужно выбрать пункт меню Pointer scanner > Rescan memory — Removes pointers not pointing to the right address.

В появившемся окне нужно проконтролировать корректность введенного адреса и отметить чекбоксик Only filter out invalid pointers.
После установки чекбоксика изменение адреса и типа отсева станет недоступно.

Снова СЕ предложит нам сохранить результаты отсева указателей в файле PTR. Я рекомендую каждый этап сохранять в отдельной файле, ибо в случае каких-то проблем можно будет без труда загрузить предыдущие результаты. Из окна результатов сканирования Pointer scan это можно сделать через пункт меню File > Open.

Результатом предыдущего этапа являются 3кк указателей, что почти на порядок меньше, чем при первом поиске.

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

И четвертый цикл отсева произведем не по результатам поиска нового адреса, а по результатам сравнения в текущей сессии значений по адресам, на которые ссылаются найденные указатели. В этом случае нужно изменить тип отсева на Value to find, указать тип значения 4 байта целочисленное и снять чекбоксик Only filter out invalid pointers.

Как видно из количества отсеянных указателей на третьем и четвертом этапах, эти этапы можно было смело пропустить.
И вот здесь кулхацкер задаст себе резонный вопрос: как же работать с тремя миллионами (Карл!) найденных указателей? На помощь пытливому уму придет логика и здравый смысл:
1. Нужно проанализировать базовые адреса в колонке Base Address. Всякие мутные ddl-ки и прочие модули нам вряд ли подойдут. Нужен исполняемый файл или, на крайний случай, какая-то базовая библиотека. В случае с Мафией ориентироваться на Game.exe более чем разумно.
2. Если после очередного отсева есть указатели, ссылающиеся на адрес с некорректным значением (при условии правильно указанного типа значения — целочисленного или с плавающей точкой!), то такие указатели нам явно не подходят.
3. Чем меньше уровней в многоуровневом указателе, тем надежнее будет его использование. Иногда, конечно, и двухуровневые указатели могут отваливаться, но желательно стремиться к меньшему числу уровней.
И именно на этом этапе анализа достаточно кликнуть по заголовку столбца Offset 6, чтобы указатели были рассортированы по количеству уровней.

Теперь нужно легко и непринужденно даблкликом накидать скопом в рабочее поле СЕ указатели второго-пятого уровня различными базовыми адресами и первыми смещениями. В нашем примере очевидно, что Game.exe + 00246D4C является, скорее всего, тем самым правильным базовым адресом, но вот иерархия уровней указателей может не обязательно говорить в пользу меньшего количества уровней. Строго говоря, для точного ответа необходим ручной анализ структур данных, но это уже более комплексный вопрос. Поэтому надо накидать в рабочее поле штук по пять указателей каждого уровня и получить в итоге целую батарею предварительных результатов. В рабочем поле они все выглядят одинаково, но при редактировании можно будет увидеть всю структуру уровней каждого указателя.

Торжественный момент! Настало время проверить работоспособность найденных указателей.
Как всегда перезапускаем игру и загружаем другой уровень.

Выбираем в открытом окне СЕ процесс игры и — вуаля. Все найденные указатели являются рабочими. Удалять их из экономии пространства я пока не советую, ибо в разных условиях какие-то могут отвалиться и перестать работать, но в целом всё получилось. Можно объединить все указатели в группу в рабочем поле СЕ, выделив их и выбрав в контекстном меню по правой кнопке мыши Add to new group, озаглавив группу и выбрав уверенное No в вопросе «Do you want «address» version?». В настройках группы Group config в контекстном меню можно выбрать Hide children when deactivated и сворачивать всю группу пробелом или кликом по чекбоксу заморозки значения в левой части строки. Табличку можно сохранять и жить припеваючи.

Анализ дампа в окрестностях найденного адреса показал, что за 4 байта до нашего адреса хранится тип оружия, а через 4 байта после — общее количество патронов к данному оружию.

Что же нам теперь, повторять эту возню с поиском указателей еще и на эти адреса? Разумеется, нет.
Достаточно скопировать рабочем поле какой-нибудь корректный указатель с помощью Ctrl + C или пункта контекстного меню Copy, после чего вставить его здесь же по Ctrl + V (Paste).
Откроется небольшое окно, позволяющее указать требуемое смещение.

Альтернативный вариант заключается в копировании всего указателя без изменений и последующего редактирования копии в общем порядке.

Вот и все. Получается уютненькая табличка, которой можно пользоваться в том числе и тогда, когда оружия на миссию вообще не выдают, а покувыркаться с Сарочкой очень хочется — достаточно выставить тип оружия на 10 (томми-ган) и досыпать патронов, не забывая выкинуть его и поднять для корректной обработки появления оружия в руках у персонажа.

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

This is a method to find a desired static pointer address through the desired value you want changed that is extremely simple and straight forward and is what I use to find static addresses fast. I will in layman’s terms one step at a time explain how to use this method.

Update edit: You could also just right click your desired value and do a pointer scan right away and keep it open and close the game and then open the game and reattach cheat engine then click pointer scanner at the top of its menu and click rescan for your value in that list (make sure to set the right value type and correct value you want to search for) the problem with this method is its quick and dirty and less thorough for the addresses you get.

Overview: You will find a value (health, etc.) then use the pointer map generate tool and then pointer scan tool to then compare two maps for the same desired value to find the static address for your desired value.

Step 0: Open cheat engine and attach to desired process.

Step 1: Search for your first desired value (health, ammo, etc.)

Step 2: Generate pointer map A for found value (right click value to find generate)

Step 3: (KEEP CHEAT ENGINE OPEN) Restart program/game and attach to process then find value B (same desired value as in step 1 but it will have a different address)

Step 4: Generate pointer map B for the new address of the desired value.

Step 5: Open pointer scanner (right click address>pointer scan for this address)

Step 6: Click the box for «Use saved pointermap» and browse to your A map (from step 1)

Step 7: Click the box for «Compare results with other saved pointermap(s)»

Step 8: Add the the second value address you found in step four into compare text box (After selecting the box in step 7, click it to open file explorer)

Step 9: Start Scan (With whatever settings you need I usually leave it default but go crazy if ya want lol see what works)

Once it gets the results KEEP YOUR SCAN LIST OPEN AND CHEAT ENGINE OPEN

Step 10: Restart program/game (MAKE SURE TO REATTACH TO PROGRAM/GAME)

Step 11: Find the static pointer(s) that remain in the scan list that change with each restart of the program/game to correctly point to the desired value, anything that reads — or is blank are fake/incorrect addresses.

Whatever is left in the scan list that correctly points to your value is what you want to use for your cheats. This is your static address(s) (most likely if they stayed true through the restart).

Enjoy and keep learning! Hacking is a journay man.

«The only true wisdom is in knowing you know nothing.» ~Socrates

«It does not matter how slowly you go as long as you do not stop» ~Confucius