Как найти offset cheat engine

This is not a support channel. It's a social chat room for goofing around.

		UnKnoWnCheaTs — Multiplayer Game Hacking and Cheats Anti-Cheat Software & Programming General Programming and Reversing
[Tutorial] Finding Offsets Using Cheat Engine


	Save

Authenticator Code

Reply

Thread Tools

Finding Offsets Using Cheat Engine

Old
14th January 2017, 07:25 PM

#1

computation

1337 H4x0!2

Join Date: Jan 2016

Posts: 144

Reputation: 2724

Rep Power: 183

Finding Offsets Using Cheat Engine

Hello everyone. Many people have trouble finding offsets in games and understanding what an offset is (talking to beginners here not you leet haxors). So I want to make an over kill tutorial to clear any confusions on offsets and a simple way to find them. This tutorial is aimed at the very beginner who is just looking to get into hacking but doesn’t know the basics of offsets and is having trouble starting off. This tutorial is not designed to target internal or external game hacking specifically but general(and simple) memory concepts. You should have an understanding of programming (I will be using C++ in the short code examples) or else this will be useless.

What Is An Offset?
So you might be thinking what is an offset or you might have used an offset to hack a game but not known what it is doing (sad life if so). To understand how to use offsets and find them we must understand what an offset is so we will look at a simple example. Lets take a look at a very simple structI will provide.

Code:

struct player {
int health;
int ammo;
float x;
float y;
float z;
};

So here we have a struct. Now when we create a variable of a struct in memory a very awesome and simple thing happens. Every member in the struct gets created in memory back to back to back. Meaning our z coordinate is always the same distance to the beginning of the struct. The struct might start at a different memory address every time you run an application BUT the members in the struct are always the same distance away relative to each other. ammo will always come after health and nothing is declared in between them and so on and so forth. So what is an offset. An offset is just how far away something is (in bytes) relative to something else. In game hacking when we say offset we are often referring about offset from the start of our player (if we are talking about our player of course). Lets look at the struct but lets comment in the offsets that each member is.

Code:

struct player {
	int health;		//0x0
	int ammo;		//0x4
	float x;		//0x8
	float y;		//0xC
	float z;		//0x10
};

how do we know what the offsets are though? Well think about this for a second. If all of these members are in a struct, they will be allocated in memory right next to each other. If you know how many bytes each data type is we can do some simple addition. The first member in the struct is where the struct starts. So health is offset 0 bytes from the start of the struct because it is the start. And the next member is 4 bytes away from that (since health takes 4 bytes because its an int) so it is said to be offset 4 bytes. As long as you know the data type you can simply add how many bytes it is away from your reverence point (which is the start of the struct for us also called the start of local player). So an offset is just the number of bytes away from a reference point and in this case that’s the start of player. This is extremely simple but many «programmers» who make hacks use offsets but don’t understand what it actually is.

Pointer To Local Player And Local Player
To understand why offsets are use full we have to take a look at the bigger picture and how we get to a spot in memory where our offset will be useful. When hacking games we usually have a pointer to local player usually denoted as pLocalPlayer and that address points to local player. Then from there we have offsets to the things we want to access such as ammo. Lets look at a picture of this to give you a visual of how all that stuff works.

We know the address of pointer to local player or pLocalPlayer. That address is 0x509B74(this could be anything we use this for reference). If we find out what that address points to it will always point to local player or localPlayer. localPlayer is a dynamic address so it will change every time we start the game and that’s why we need a way to find it every time we start the game.. Once we know where our localPlayer address is we know how to get to health, ammo, x, y, and z. We just add the number of bytes it is offset to localPlayer! Pretty simple. Now it is important to note that usually the player struct or class is way bigger and can contain thousands of variables so this is just extremely simplified so you can understand the concept of what all this means. I am not going to show how to find pointer to local player today but I might come back in a fill in how to do that if people want. For now lets focus on finding the offsets. The whole purpose of all the stuff mentioned above is in order to make a hack we need some way of getting to variables in memory every time. It would be ridicules if had to change the memory addresses in our application every time we started the game. That would defeat the purpose.

Finding Offsets
So lets open up assault cube for this example. I am going to give you the address of pointer to local player since I did not explain how to find that. The address is 0x509B74 that points to local player (it’s the same as the one i used in the picture but the player struct in assualt cube is different so don’t mix that up). Attach cheat cheat engine to assault cube. Now lets get to local player. Go to add address manually in the bottom right of cheat engine. check pointer then add 0x509B74 (since the address of pointer to local player).

Now if we hit okay we now have what localPlayer is. Remember if you close the game and reopen it the address will change since its not static but dynamic.

I renamed the description to pLocalPlayer so I can remember what it is. Under where it says address there is a memory address. That is what pLocalPlayer points to and that is localPlayer. So now we know what address localPlayer is lets find some offsets. There are several ways to do this and I will show you one simple way. We will want to find the dynamic address of what ever offset we want to get. So lets look at ammo and get that offset. You will want to set scan type to exact value and value type to 4 bytes and the value is 20. Since we did not fire and our ammo reads 20.

Now we want to hit scan and thousands of results will show up. To limit that down shoot a couple bullets and then under value change it to how many bullets you have left and hit next scan. This will throw out all the addresses that don’t have that value meaning it will limit down the possibilities. Keep doing this until you only have a couple addresses. On my second try I got 2 addresses.

you can double click on the address to bring them down to our address table. Now double click on one of the addresses values and change it to what ever you would like. If it changes the value of your ammo in game then you found the dynamic address of your ammo and you can shoot and test this out.
Now lets think about this logically. If the members of a struct or class is always declared in memory together and in the same order we can find an offset. Now if we know some address that it starts at (localPlayer in this case) and we know an address of one of the members in the struct such as our ammo, then we could subtract localPlayer address from ammo address and it would leave us with how many bytes away that member is in the struct from the start of the struct! Its just taking two numbers and finding how far apart they are. So here are the addresses I have for local Player and Ammo

If we take ammo address which is 0xE7A4E0 and subtract localPlayer from it which is 0xE7A390 we get 0x150. That means that the ammo address is 150 bytes away from the start of localPlayer and since ammo is part of the player struct in assault cube the offset will always stay the same even if we restart the game since how structs and classes and things are declared in memory. Now if you did this your addresses would be different but you would get the same offset once doing the math. Now you can go and find any other address and do the same. Go try finding your health, x, y, z coordinates and any other thing you want. Remember that there are other methods of scanning in cheat engine. You probably won’t use exact value for your x, y, and z coordinate cause you don’t know them and also coordinates are usually floats so under type you would change 4 bytes (an int) to float.

The Bigger Picture
This stuff isn’t hard! If you do some research about how things are allocated in memory and you use your brain you can figure stuff out easily. Just by knowing subtraction and how a struct is allocated in memory we found an offset. Its very simple. If you have any doubts about memory make an application and look at it in cheat engine to clear your confusion. Also why do all of this if you can go to a forum post with all the addresses? Well because knowing how to get things in memory strengthens your understanding and you won’t always have a post with information you need so start learning how to do things yourself! Good luck on the beginners starting out I hope this helped in some way or another.

Last edited by aixxe; 14th January 2017 at 07:31 PM.
Reason: fix image links

computation is offline

Old
14th January 2017, 07:27 PM

#2

WasserEsser

Site Administrator

Join Date: Jun 2013

Posts: 4,818

Reputation: 122812

Rep Power: 413

Recognitions

Donator

(43)

Gratuity

(4)

File Analyzer

Contest Winner

(1)

Points: 236,129, Level: 59

Level up: 20%, 257,871 Points needed

Activity: 42.9%

Last Achievements

Award-Showcase

@computation Use the direct links to the images. (Rightclick on the image and copy the direct link)

__________________

WasserEsser is online now

Old
14th January 2017, 07:48 PM

#3

computation

1337 H4x0!2

Threadstarter

Join Date: Jan 2016

Posts: 144

Reputation: 2724

Rep Power: 183

Quote:

Originally Posted by WasserEsser

@computation Use the direct links to the images. (Rightclick on the image and copy the direct link)

Sorry about that. Thanks for the fix!

computation is offline

Old
15th January 2017, 03:51 AM

#4

Slayer

Master Contributor

Join Date: Jan 2016

Location: USA

Posts: 1,297

Reputation: 17363

Rep Power: 209

Recognitions

Former Staff

Donator

(2)

Points: 37,008, Level: 29

Level up: 29%, 1,792 Points needed

Activity: 2.1%

Last Achievements

Looks neat, but definitely add or update this and touch on finding pointers. Very important skills. Otherwise, this was simple and neat, great explanation!

Kudos,

~Slayer1250~

__________________

Quote:

Originally Posted by Synraw

Don’t blame me, blame the japanese. Nuke them once and they fight back with a weapon far more dangerous

Quote:

Originally Posted by gorkx

Bluntly: WHAT FUCK IS YOU PEOPLES GOD DAMN PROPBLEM? you are the most disterbingly egotistical little-endian bags ever! This isn’t…don farmer going ooff to risk jail time to further chaos,and market theory. this is a gots damn video game motherfuckers. jesus fucking christ.

Slayer is offline

Old
24th January 2017, 02:21 PM

#5

vergil250493

n00bie

Join Date: Aug 2014

Posts: 12

Reputation: -37

Rep Power: 0

Points: 6,013, Level: 8

Level up: 56%, 487 Points needed

Activity: 2.3%

Last Achievements

Thanks for the tutorial to beginners ! you could also add on how to find pointers

vergil250493 is offline

Old
25th January 2017, 02:19 AM

#6

computation

1337 H4x0!2

Threadstarter

Join Date: Jan 2016

Posts: 144

Reputation: 2724

Rep Power: 183

Quote:

Originally Posted by vergil250493

Thanks for the tutorial to beginners ! you could also add on how to find pointers

thanks. there is so much on finding pointers that I feel it is not worth the time to say what can easily be found with a quick search.

computation is offline

Old
15th March 2017, 03:14 AM

#7

ccurtis20

h4x0!2

Join Date: Jan 2013

Posts: 104

Reputation: 955

Rep Power: 254

Thanks for the tutorial/info. +Rep

ccurtis20 is offline

Old
3rd December 2017, 02:14 PM

#8

wtffwtf

Junior Member

Join Date: Jun 2017

Posts: 53

Reputation: 162

Rep Power: 145

Points: 4,738, Level: 7

Level up: 27%, 662 Points needed

Activity: 8.6%

Last Achievements

How do you find the address of sth that is not changeable (not like the ammo or health) easily? I want to find the address of unlocking all guns for example, how is this possible?

wtffwtf is offline

Old
6th December 2017, 03:43 PM

#9

Lawlessvictory

n00bie

Join Date: Dec 2017

Posts: 22

Reputation: 23

Rep Power: 134

Points: 1,061, Level: 2

Level up: 33%, 339 Points needed

Activity: 1.3%

Last Achievements

Thanks for taking the time to write this, things like this help a lot.
Now I have a much clearer explanation of what offsets are.

Lawlessvictory is offline

Old
17th January 2018, 01:12 AM

#10

chubbyH

n00bie

Join Date: Jan 2018

Posts: 1

Reputation: 10

Rep Power: 131

Thinks for sharing

chubbyH is offline

Old
7th February 2018, 04:28 PM

#11

hieu832

n00bie

Join Date: Jan 2018

Location: HA NOI

Posts: 9

Reputation: 10

Rep Power: 131

Points: 2,131, Level: 4

Level up: 5%, 669 Points needed

Activity: 1.8%

Last Achievements

you can tutorial video plz.

hieu832 is offline

Old
8th February 2018, 11:47 AM

#12

jahaha

A God

Join Date: Jul 2007

Posts: 171

Reputation: 858

Rep Power: 388

Points: 15,227, Level: 16

Level up: 17%, 1,173 Points needed

Activity: 4.8%

Last Achievements

Quote:

Originally Posted by hieu832

you can tutorial video plz.

There’s many videos on this already, just open up youtube and search.

Good guide btw. +rep

jahaha is offline

Old
9th February 2018, 08:21 AM

#13

tsunaweak

n00bie

Join Date: Feb 2018

Posts: 8

Reputation: 10

Rep Power: 130

very helpful thank you so much ^_^

tsunaweak is offline

Old
15th February 2018, 09:43 AM

#14

Phnmz

Senior Member

Join Date: Feb 2015

Posts: 78

Reputation: 132

Rep Power: 202

Points: 5,101, Level: 7

Level up: 67%, 299 Points needed

Activity: 2.3%

Last Achievements

Good explanation, still need to know how to find pointers, and it would be about time someone explain how to do this on a game that has a simple anti-cheat at least, cause once you learn that from Assault Cube and try another game, you’re pretty much fucked as a beginner. (including myself)

Phnmz is offline

Reply

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Tutorial] Cheat Engine — Finding Base Address w/ Pointer Scan	xenocidewiki	Programming for Beginners	16	26th June 2019 05:06 AM
[Question] Finding offsets using IDA.	Articxslack	DayZ SA	7	22nd July 2016 09:51 AM
[Help] Cheat Engine not finding Rsc	nrodway11	ARMA 3	3	27th March 2015 04:12 AM
[Discuss] Is Finding Transformation Pointer Possible With Cheat Engine?	Falchon	DayZ SA	1	22nd May 2014 08:52 AM
Help with using OllyDBG finding adresses and offsets	traplol2	ARMA 2	9	11th August 2012 10:13 AM

Что такое Оффсеты? Как найти и обновить?

Что такое Оффсеты?
Оффсет (Offset) — на простом языке, это смещение адреса в памяти . Например, в ячейке памяти есть игрок, по адресу 0x5100 (или любому другому), соответственно что этот объект содержит несколько ячеек данных: количество HP, процент брони, местоположение — координаты нахождения на карте, а также и другую информацию.

Как их найти и произвести обновление?
Вероятно вы зададитесь вопросом, как их найти и извлечь? Постараемся немного объяснить, на примере одновременно популярной и простой в этом плане игре Counter Strike: Global Offensive. Игровой движок Source имеет есть так называемые глобальные значения «Networked Variables» или же Netvar, сокращенный вариант. По сути, это обширные таблицы для каждого типа объекта . За известный адрес игрока, возьмем 0x5100, переносим игровой client.dll и загружаем в IDA- интерактивный дизассемблер. После открываем список строк через комбинацию клавиш Shitf + F12, в открывшимся окне и делаем поиск по строке , вписываем «Health» в переводе Здоровье (Игрока), после этого появится целый список с результатами.

На изображении выше, в после String есть много префиксов, но нужен именно тот, который имеет в начале «m_» — это член класса, в полном названии member. Для примера возьмем m_iHealth, который имеет следующий код:

class CBasePlayer < pad; pad; pad; int m_iHealth; // 0xFC >

int — integer «целое число»;
float — число с плавающей запятой;
etc — оператор.

Как пользоваться IDA PRO. Как найти оффсеты в любой игре

Два раза кликаем по любому из столбиков, и перед глазами появляется очередная таблица:

Этими действиями, удалось найти Оффсет, который равен значению — 0xFC. Но на этом еще не все, осталось еще одно незаконченное действие, чтобы узнать внутренние значение, нужно выполнить код ниже, применяем его, так как тип данных integer:

void * player = getentity(. ); int health = *(int*)((DWRD)player + 0xFC); print( health );

10.08.2021
6 641
5

Источник: cheats.lol

Поиск поинтеов и оффсетов

7. Открываем, калькулятор и настраиваем «Вид -> Инженерный», потом выбираем Hex.

8. Возвращаемся к Cheat Engine и копируем значение поля «Address».

9. Возвращаемся к калькулятору и вставляем значение сюда. После этого вычисляем (-) 500.

10. Получившийся результат копируем на поле»Address» и нажимаем OK

11. В Address list смотрим и видим, добавилось новое значение. Нажимаем ПКМ и выбираем»Pointer scan for this address».

12. Появиться окно. В настройках ставим Max level на 1 и галочку на»Improve pointerscan with gathered heap data» потом жмем OK и ожидаем окончание загрузки.

13. Должно, появится что-то вроде PointBlank.i3exec+123123123, на него 2 раза кликнем и закрываем окно.

14. В Address listнажимаем на новое значение ПКМ и выбираем»Change -> Address». В окне поле «Address of pointer» это Pointer.

15. Около него должен быть поле»Offset (Hex)» копируем данное поле и вставляем на калькулятор и сложим (+) на 500. Получившийся результат это оффсет.

Чтобы искать новый оффсет и не проделывать все пункты сначала:

16. Нажимаем на «Add address manually»,ставим галочку на «Pointer» и в поле «Address of pointer» пишем наш Pointer (например: PointBlank.i3exec+123123123). Нажимаем Ок.

17. В Address list нажимаем на новое значение ПКМ и выбираем «Change -> Address». Над полей «Address of pointer» есть текст вида «This pointer points to address 123123123» здесь «123123123» адрес, с которого будем искать другие оффсеты.

18. Выполняем пункт с 1-9. НО (!) вместо того чтобы вычислят (-) 500, мы будем, вычислят значение которое нашли недавно. Получившийся результат это — ОффСет.

2-ой способ я выложуtxt файлом т.к там очень много писать..прочитав,вы всё поймёте…

Источник: www.rf-cheats.ru

Источник

Эти загадочные указатели
Теоретическая часть для понимания сути процесса

Как доподлинно известно, адрес в оперативной памяти — некий условный шестнадцатеричный идентификатор (а еще проще — обычное число) для взаимодействия программы с реальной физической памятью. По конкретному адресу всегда расположен ровно 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.
m02_0

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

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

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

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

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

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

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

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

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

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

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

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

m15_0

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

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

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

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

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

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

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

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

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

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

Источник

Всем привет. Я пишу ботов для MMORPG Guild Wars. Занимаюсь этим год — полтора. Все это не слишком сложно, потому что существует такой скрипт как GWA2.au3, данный скрипт был написан не мной, он находится в публичном доступе, каждый может его скачать и заниматься бытописанием для Guild Wars. В данном скрипте прописаны многие пути расположения тех или иных значений, такие как количество здоровья, координаты персонажа, место нахождение и тд, все это можно определить используя ту или иную функцию. Но увы всех функций не достаточно что бы писать новых ботов. Ниже приведу пример, нескольких функций.

; Пример первой функции
Func GetPartySize()
   Local $lOffset[5] = [0, 0x18, 0x4C, 0x64, 0x24]
   Local $lPartyPtr = MemoryReadPtr($mBasePointer, $lOffset)
   Local $lReturn = MemoryRead($lPartyPtr[0], 'long') ; henchmen   
   Return $lReturn
EndFunc   ;==>GetPartySize

; Пример первой 2 функции
Func GetMissionStartDelay()
	Local $lOffset = [0, 0x18, 0x44, 0x9C, 0]
	Return MemoryReadPtr($mBasePointer, $lOffset)[1]
EndFunc

Первая функция определяет количество персонажей в команде. Второй определяет статус команды (лидер команды, начата ли миссия и тд.)
Ниже MemoryReadPtr и MemoryRead.

;~ Description: Internal use only.
Func MemoryReadPtr($aAddress, $aOffset, $aType = 'dword')
	Local $lPointerCount = UBound($aOffset) - 2
	Local $lBuffer = DllStructCreate('dword')

	For $i = 0 To $lPointerCount
		$aAddress += $aOffset[$i]
		DllCall($mKernelHandle, 'int', 'ReadProcessMemory', 'int', $mGWProcHandle, 'int', $aAddress, 'ptr', DllStructGetPtr($lBuffer), 'int', DllStructGetSize($lBuffer), 'int', '')
		$aAddress = DllStructGetData($lBuffer, 1)
		If $aAddress == 0 Then
			Local $lData[2] = [0, 0]
			Return $lData
		EndIf
	Next

	$aAddress += $aOffset[$lPointerCount + 1]
	$lBuffer = DllStructCreate($aType)
	DllCall($mKernelHandle, 'int', 'ReadProcessMemory', 'int', $mGWProcHandle, 'int', $aAddress, 'ptr', DllStructGetPtr($lBuffer), 'int', DllStructGetSize($lBuffer), 'int', '')
	Local $lData[2] = [$aAddress, DllStructGetData($lBuffer, 1)]
	Return $lData
EndFunc   ;==>MemoryReadPtr

;~ Description: Internal use only.
Func MemoryRead($aAddress, $aType = 'dword')
	Local $lBuffer = DllStructCreate($aType)
	DllCall($mKernelHandle, 'int', 'ReadProcessMemory', 'int', $mGWProcHandle, 'int', $aAddress, 'ptr', DllStructGetPtr($lBuffer), 'int', DllStructGetSize($lBuffer), 'int', '')
	Return DllStructGetData($lBuffer, 1)
EndFunc   ;==>MemoryRead

Соответственно вопрос таков. Как я могу найти такие значения как $lOffset[5] = [0, 0x18, 0x4C, 0x64, 0x24] (первый пример) и $lOffset = [0, 0x18, 0x44, 0x9C, 0] (второе значение)???
Эти значения уже найдены, но я хочу их найти самостоятельно, что бы потом я так же смог найти другие, которые отсутствуют в скрипте. Я понимаю что для это мне нужно использовать OllyDbg или Cheat Engine. Так же у меня есть инструмент для получения отправленных и полученных пакетов из сервера до шифрования. Фото ниже.

То есть это ряд мне выдает программа, которая получила пакет от сервера. Вторая функция GetMissionStartDelay() возвращает тоже значение. 0x100 Integer => …..
Я попытался сравнить $lOffset и hex ряд на фото, к сожаления сходств я не нашел. Пытался найти этот hex ряд с помощью OllyDgb и тоже без результатной. Буду рад получить любые советы для решения данного вопроса.
И да, сам GWA2.au3 выложу ниже.

Источник

Что такое Оффсеты? Как найти и обновить?

Поиск поинтеов и оффсетов

Не пропустите также: