Difference between revisions of "Heap Scanning"
Imathrowback (talk | contribs) |
Imathrowback (talk | contribs) |
||
| Line 13: | Line 13: | ||
| − | HotAllocators | + | == HotAllocators == |
HotAllocators use the Win32 function VirtualAlloc to create memory. | HotAllocators use the Win32 function VirtualAlloc to create memory. | ||
| Line 21: | Line 21: | ||
The general purpose allocator is named "HoTAllocator" (where HoT stands for "Heroes of Telara" the original name of RIFT). The specialized Allocators use names like "Gamebryo" or "Audio" to indicate their purpose. | The general purpose allocator is named "HoTAllocator" (where HoT stands for "Heroes of Telara" the original name of RIFT). The specialized Allocators use names like "Gamebryo" or "Audio" to indicate their purpose. | ||
| − | Linked List | + | == Linked List == |
| − | Allocators are created and inserted into a global linked list. The first allocator is always "HotAllocator". | + | Allocators are created and inserted into a global linked list. The first allocator is always "HotAllocator". You can find the this allocator by finding the string "HoTAllocator" and then doing a search for use of that string. That will give you the Heap Allocator object that will contain references to the next and last in the linked list. |
| − | + | == Allocator heap memory == | |
| − | Allocator heap memory | ||
When an allocator is first created it creates a memory entry that is 0x1E0 in size. This is the Heap header block and contains links to further heap blocks, sizes of heaps and other information. | When an allocator is first created it creates a memory entry that is 0x1E0 in size. This is the Heap header block and contains links to further heap blocks, sizes of heaps and other information. | ||
| Line 35: | Line 34: | ||
Memory allocations are rounded to the next 8 bytes. | Memory allocations are rounded to the next 8 bytes. | ||
| − | Heap footer | + | == Heap footer == |
The heap footer is a structure that defines where a block of memory starts and how big it is. It also contains a pointer to the next heap memory block (and footer) if this footer is full. | The heap footer is a structure that defines where a block of memory starts and how big it is. It also contains a pointer to the next heap memory block (and footer) if this footer is full. | ||
| − | Deleted blocks | + | == Deleted blocks == |
It is unknown how blocks are tagged as deleted. | It is unknown how blocks are tagged as deleted. | ||
| − | Memory Entries | + | == Memory Entries == |
| + | |||
| + | Each memory entry is specific to it's purpose. There is no way specific way to determine what the memory block represents apart from guessing based on the size of the allocation and the allocator that is used. For example, every ClientEntity block for example is always the same size and uses the same Heap Allocator "ClientEntity". | ||
| + | |||
| + | == Property System == | ||
| + | |||
| + | RIFT uses a "property system" to add properties to objects. This is how links between ClientRenderable and it's model are gathered. | ||
| + | |||
| + | == ClientRenderable == | ||
| + | |||
| + | Client renderable blocks contain rotation, scale, position and links to Gamebryo. The always (as of writing) take up 1416 bytes of memory. | ||
| + | |||
| + | == ClientEntity == | ||
| − | + | Contains details about the entities, including TEMPLATEID (as per the items.xml file from RIFT CDN) | |
Revision as of 22:14, 18 December 2018
Heap Scanning is the process of reading the details within RIFT memory space.
The particulars of actually capturing the memory are not covered here, only discussion of the "HoT" allocator.
RIFT uses two main methods to allocate memory.
1. Heaps 2. HotAllocators
The Heap is the standard C malloc heap. Generally this is only used by 3rd party libraries or other small functions.
The HotAllocator is a special allocator that manages it's own heap, also known as a "Tagged" heap.
Contents
[hide]HotAllocators
HotAllocators use the Win32 function VirtualAlloc to create memory.
RIFT creates two different types of Allocators, "General Purpose" and "Specialized".
The general purpose allocator is named "HoTAllocator" (where HoT stands for "Heroes of Telara" the original name of RIFT). The specialized Allocators use names like "Gamebryo" or "Audio" to indicate their purpose.
Linked List
Allocators are created and inserted into a global linked list. The first allocator is always "HotAllocator". You can find the this allocator by finding the string "HoTAllocator" and then doing a search for use of that string. That will give you the Heap Allocator object that will contain references to the next and last in the linked list.
Allocator heap memory
When an allocator is first created it creates a memory entry that is 0x1E0 in size. This is the Heap header block and contains links to further heap blocks, sizes of heaps and other information.
The memory block is filled by the allocator with memory entries. When the block is full, a new memory block is allocated and a pointer stored in the heap header to a "heap footer".
Memory allocations are rounded to the next 8 bytes.
The heap footer is a structure that defines where a block of memory starts and how big it is. It also contains a pointer to the next heap memory block (and footer) if this footer is full.
Deleted blocks
It is unknown how blocks are tagged as deleted.
Memory Entries
Each memory entry is specific to it's purpose. There is no way specific way to determine what the memory block represents apart from guessing based on the size of the allocation and the allocator that is used. For example, every ClientEntity block for example is always the same size and uses the same Heap Allocator "ClientEntity".
Property System
RIFT uses a "property system" to add properties to objects. This is how links between ClientRenderable and it's model are gathered.
ClientRenderable
Client renderable blocks contain rotation, scale, position and links to Gamebryo. The always (as of writing) take up 1416 bytes of memory.
ClientEntity
Contains details about the entities, including TEMPLATEID (as per the items.xml file from RIFT CDN)
