Answer to How PWI is exploited

Quote:

Originally Posted by Shareen There seems to be a comment missing for the line: 0xA8, 0x00, 0x50, 0x39 ;) Just in case you happen to know what it is, it differs from value in my packet dumps and I can't map it to any known values.

I'm afraid I haven't updated my catshop bot in ages, not sure what that was supposed to be lol. I just copy pasted it from my code that I dug up. If it's important I'll have a look at it.

Apart from being properly documented, It's only important if it changes between packets or between different users using this code.

Your pasted code doesn't change the afore mentioned packet section (more precisely this part: 0xA8, 0x00, 0x50, 0x39).

I don't care about, for example, 0x00, 0x00, 0x00, 0x00, even though it's also undocumented, simply because it's always the same value. Change user or number of packets (or number of items in packet, or quantity), value remains the same. It may be unknown, but it's also irrelevant to the use (at least up to the point of normal, intended usage of the packet).

Back to the unknown 0xA8, 0x00, 0x50, 0x39 part, it's not related to items being sold, for if it was, it would be a part of item struct at the end of packet.
If it works consistently for you, after several relogins AND with different characters, it would also seem it's not related to any character or shop data.

For additional info, I add my sample (same endian as yours):
0xB2, 0x00, 0xC8, 0x99

This was obtained on one purchase with one character on one shop. I will get more samples, from different shops using different characters, for comparison.


Edit:
I've checked value at my end after restarting the game and it's still the same.
Managed to track it to player struct, now I need confirmation from you Interest.

Please check the following offsets on your end:
PartOne = [[Base + 0x34] + 0x08 ( 2 bytes)
PartTwo = [[Base + 0x34] + 0x0A ( 2 bytes)

They should be:
PartOne = 0x39, 0x50 (reverse endian from network packets)
PartTwo = 0x00, 0xA8 (reverse endian from network packets)

Put together like shown below (and network packet endian), they should form your value:
PartTwo, PartOne = 0xA8, 0x00, 0x50, 0x39

Alternative offsets are also:
PartOne = [[Base + 0x34] + 0x7B4 (2 bytes)
PartTwo = [[Base + 0x34] + 0x7B6 (2 bytes)

If you could please confirm or deny this, it would help.

Thanks.

Quote:

Originally Posted by Shareen Apart from being properly documented, It's only important if it changes between packets or between different users using this code. Your pasted code doesn't change the afore mentioned packet section (more precisely this part: 0xA8, 0x00, 0x50, 0x39). I don't care about, for example, 0x00, 0x00, 0x00, 0x00, even though it's also undocumented, simply because it's always the same value. Change user or number of packets (or number of items in packet, or quantity), value remains the same. It may be unknown, but it's also irrelevant to the use (at least up to the point of normal, intended usage of the packet). Back to the unknown 0xA8, 0x00, 0x50, 0x39 part, it's not related to items being sold, for if it was, it would be a part of item struct at the end of packet. If it works consistently for you, after several relogins AND with different characters, it would also seem it's not related to any character or shop data. For additional info, I add my sample (same endian as yours): 0xB2, 0x00, 0xC8, 0x99 This was obtained on one purchase with one character on one shop. I will get more samples, from different shops using different characters, for comparison.

Yeah, i have used it consistently for several months on different characters, from different accounts. It may have changed since I last used it of course, as it has been at least about half a year since I last used my shop bot.

It's prolly something like the id of the catshop, the catshop session id, or something similar. Which isn't necessary for the server to process it since you are already in 'dialogue' with that particular cat.
At least that would be my (uneducated) guess

Traced back a little through Olly - No idea what they are, but it seems to be two shorts that come from [[playerBase]+0x08] and [[playerBase]+0x0A] :)

Btw... we've kind of hijacked a completely unrelated thread lol. Might be worth moving this convo to the [Only registered and activated users can see links. Click Here To Register...] ;)

Edit: D'oh - Just saw I got ninja'd xD

Yeah, seems I edited just as Interest was writting his reply.

But no matter, thanks dumbfck, you've supplied the needed confirmation.

Well, thanks for that :)

Just need to know what they actually mean now :D

edit: well 'need' is the wrong word there, rather curious though :p

Just to finalize this discussion, I'd like to point out something else to watch for using this packet: ShopIndex

You are viewing the shop window and "Items Offered" as they called it, meaning items you can sell to shop are on the right side in their own 'group'.

Tendency would be to thus use index 0 for first item in first row, but that however isn't the case.

ShopIndex is calculated using ALL the items shop deals with, those for sale as well as those for purchase, while skipping empty slots.

Thus, in selling to cat shop, item that is located first in first row and with total items on sale being, let's say 12, ShopIndex would be: (12+1)-1. -1 is for zero indexing.

See image below to avoid confusion.

Quote:

Originally Posted by Shareen Just to finalize this discussion, I'd like to point out something else to watch for using this packet: ShopIndex You are viewing the shop window and "Items Offered" as they called it, meaning items you can sell to shop are on the right side in their own 'group'. Tendency would be to thus use index 0 for first item in first row, but that however isn't the case. ShopIndex is calculated using ALL the items shop deals with, those for sale as well as those for purchase, while skipping empty slots. Thus, in selling to cat shop, item that is located first in first row and with total items on sale being, let's say 12, ShopIndex would be: (12+1)-1. -1 is for zero indexing. See image below to avoid confusion.

oh yeah, and something to pay attention to:
say originally a shop sets up with item X at slot 0 and item Y at slot 1.
Someone buys all of item X, now moving item Y to slot 0. When sending the packet you will still need to send shopIndex 1.

Quote:

Originally Posted by Interest07 oh yeah, and something to pay attention to: say originally a shop sets up with item X at slot 0 and item Y at slot 1. Someone buys all of item X, now moving item Y to slot 0. When sending the packet you will still need to send shopIndex 1.

Oooh nasty... So for item Y which was in slot 1, but now in slot 0, you need to send 1? That's dangerous xD. Is this only if you don't close the shop interface? If that's always the case then those item slot IDs are pretty worthless as far as sending packets go?

Quote:

Originally Posted by dumbfck Oooh nasty... So for item Y which was in slot 1, but now in slot 0, you need to send 1? That's dangerous xD. Is this only if you don't close the shop interface? If that's always the case then those item slot IDs are pretty worthless as far as sending packets go?

Nahh, that value can be found still :D I forget where exactly though

not working anymore =/ done everything but seems that it got fixed.... can anyone explain that ?

Quote:

Originally Posted by lars911 not working anymore =/ done everything but seems that it got fixed.... can anyone explain that ?

Considering how incredibly easy to fix this is, and how public this knowledge is, I'd assume that yes it would be fixed by now :rolleyes:

damn :( maybe i dident create a right proxy web ? or it just got fixed

It got fixed.

Wow, this could have worked though. I tested it and succeeded to obtain a perfect stone (50 DQpoints) through a manual post. Other item_id's from the 1st post were not working, so I guess it's fixed. Cool hack and at least I learned a lot from it.