Old Resource List struct is invalid... I think

[R3D23R0]

This used to work. I'm trying to pull up resource id's and names with it and it's not performing as it used to. Am I missing something?

Oh, and I'm using

Global $vBaseAdress = IniRead($SOFTWARE_CONFIG, $cfg_address_key, $cfg_vBaseAdress, "13067820")

$vpointer1 = _MemoryRead($vBaseAddress, $vOpen)
$vpointer2 = _MemoryRead($vpointer1, $vOpen) + 0x8
$vpointer3 = _MemoryRead($vpointer2, $vOpen) + 0x28
$pointer = _MemoryRead($vpointer3, $vOpen) + 0x18

for $i=0 to 768
Local $item_base1 = _MemoryRead($pointer, $vOpen) + $i*4
Local $item_base = _MemoryRead($item_base1, $vOpen) + 0x4

Local $ITEM_NAME1 = _MemoryRead($item_base, $vOpen) + 0x164
Local $ITEM_NAME = _MemoryRead($item_name1, 'wchar[30]') ;Item-Name

Originally Posted by asgborges

hmm ok.. we agreed with some points and your lists is same as mine...
but, let me explain how can i see this:

Players list (sequential):
Player-Struct = base_ptr + 0x8 + 0x20 + 0x90 + index*4
Player-Count = base_ptr + 0x8 + 0x20 + 0x14
Player-ID = Player-Struct + 44C
Player-Name = Player-Struct + 5F0 + 0

NPC/MOB list (sequential):
NPC-Struct = base_ptr + 0x8 + 0x24 + 0x50 + index*4
NPC-Count = base_ptr + 0x8 + 0x24 + 0x14
NPC-ID = Player-Struct + 11C
NPC-Name = Player-Struct + 23c + 0

Resource list (sequential):
Resource-Struct = base_ptr + 0x8 + 0x28 + 0x18 + index*4 + 4
Resource-Count = base_ptr + 0x8 + 0x28 + 0x14
Resource-ID = base_ptr + 0x8 + 0x28 + 0x18 + index*4 + 8
Resource-Name = Resource-Struct + 164 + 0

the Resource-Struct have an aditional +4 offset to make the correct sequential pointers. (simple as you can see)

i hope its help!!

Edit: Screw this, they can change at every new patch. I've got a better idea.

[Interest07]

here i made a video for you on how to get the offsets for the item stuff



with the transcript if it was too hard to read:

 Spoiler

00:00
This video will show how to figure out the offsets / addresses we need for exploring the item lists in PWI. We'll be using Cheat Engine and ReClass. Basics for offset finding are assumed to be known.
00:10
Start by dropping a couple of items on the floor; don't want to start looking for 0 or 1 as they're way too common in memory and will return too many results, making the rest of the process slower.
00:20
Continue picking up and narrowing down the list of addresses until we have only a few results left.
00:35
Try both remaining results and see if we can figure out what's accessing this memory. The first result was a dud as it remains at 0 even after dropping an item and naturally doesn't result in any accesses.
1:15
More luck with the other value. Try and go for the opcode containing registers such as esi and ecx when looking for offsets. ebp and esp are generally not of interest to us.
1:25
The offset for item count would appear to be 0x14, now let's dig further back to see if we can get the chain of offsets from the base. We follow the usual pattern; search for the suspected address in memory, then check what pointers hold that address until we get to the base.
2:00
Quite a lot of useless results we keep getting. This could get boring quickly, we'll have to see if we can do something clever to speed things up here...
2:18
This result appears promising at first glance, but notice how these opcodes only got accessed once, even though they're supposed to lead us to a list of all items in the world... you'd expect them to be used more often.
2:28
It would also appear that they are stored in some sort of list (see the eax as indices) which can make things more annoying to track. Look at the rest of the results first.
2:44
Now we're getting somewhere... these are getting accessed many times a second. Since we're pretty bored of looking for offsets by now, let's see if we can find something useful in the opcode that can speed up this process a bit.
3:12
Bah, the address comes from a local variable (notice the esp register), that's not going to be much use for us. Let's see what else we can find.
3:42
Well hello, this seems promising...
3:52
Oh indeed... leads us all the way back to a very familiar address (you should always figure out the base address first and be on the lookout for this baby).
4:02
A nice chain of offsets... base + 0x1C + 0x18 + 0x24... + the original 0x14 we found earlier. Let's try this out...
4:22
Just in case this didn't look like the base address to you... When you see something such as [Elementclient.exe + XXXXX] you should read it as 0x400000 + XXXXX
5:02
And tadaaaa, it works! We finished the first part of our quest.
5:17
Now it's time to explore some structures in ReClass. Once you have established a chain of offsets towards some structures, it is much easier to simply explore the memory around them to see if you can recognise anything useful. It will allow you to gain much more intel in a short amount of time than when you search value by value in Cheat Engine.
5:29
Attach ReClass to the process you want to explore.
5:39
We are starting from scratch, so add a new class and enter our base address in there. Add new classes along the chain we uncovered previously until we reach our item count.
6:35
Verify that this is indeed correct... Then time to find the actual list with all the nodes that point to the items. A pointer to the list is generally very close to the count variable, which is why we looked for that value first.
6:56
As luck would have it, it is indeed the first pointer after the itemCount. A big list of null pointers we will have to traverse to find our lucky node.
7:06
We already know that each node will have a pointer to a next node as first value and a pointer to an item object as second value. So we simply explore the pointer at 0x4 to see if we can recognise anything in our item struct.
7:16
We will definitely want the location of our item... so lets see if we can find three floats close together (every object in the game has this pattern, probably inherited from some base ingame object).
7:30
We will also want to recognise the item... since we dropped Herb Yuanxiao with itemTypeId = 19240, we are looking for 0x4B28, which always comes paired with its uniqueId, most likely the value before it.
8:14
Next let's look for the name of the item, which always makes things easier when debugging than just the id. Just trying out some pointers to see where we can find it.
8:24
As stated before, we are exploring the structure, so just educated guesses on what we can find, it's fast enough to just try out a few pointers to see what happens. You never know what you might find.
8:34
This was quite interesting... some sort of image / resource file belonging to this item. Never know when that might come in handy. Oh and hello, it's the name of our item!
8:44
In a similar way you can explore other structures to see what you can find. Using a combination of tools you can use different angles of approach to finding what you need within the client.

[R3D23R0]

Wow, thanks for the tutorial, Interest! I'm still having some trouble making my code pull the text name for the mats from the correct address... I have the address where the name of the herb/resource is located, but wchar and text and char just won't pluck the hex/ascii code from memory. The only thing it pulls are chinese characters when I use wchar.

I don't know if this will show up right or not:

Don't ask me how one herb can have two names in memory. i.e. nectar 3095

2014-02-06 18:15:48 : 11 ID: 3095 name: ⵸ᎳĀ㽭쿰ᜮ
2014-02-06 18:15:48 : 12 ID: 3095 name: ⵸Ꮃ
2014-02-06 18:15:48 : 13 ID: 3098 name: ㏰ᎳĀ-
2014-02-06 18:15:48 : 14 ID: 3098 name: ㏰ᎳĀ-
2014-02-06 18:15:49 : 15 ID: 3103 name: 㺸Ꮃ-
2014-02-06 18:15:49 : 16 ID: 3103 name: 㺸ᎳĀ-
2014-02-06 18:15:49 : 17 ID: 3536 name: 䔰Ꮃ-
2014-02-06 18:15:49 : 18 ID: 3536 name: 䔰Ꮃ-

Idea: why not create an ini (yes it's more work) with all the ids and just pull the name from that. Actually...could just put in the id's I want to grab, forget the rest if I don't want them. Better yet, an ini for each mining region.