I'm wondering if it is still the case that the affix values are not transmitted explicitly but instead the seed value for these. If yes, is the seed value still 32 bits long?

Yes and yes.

While the exact formulas for generating the attribute values changed slightly several times during the beta, the basic premise has remained the same.

The seed determines the values of all the attributes (which are determined by the affixes). The seed is also used the generate any variable values on the base item: armor value, min/max damage offset, and block % (for shields).

Note that if you packet scan the GameServer packets, you will see the attribute values come across when an item is loaded / generated. So depending on what you are trying to do, you don't need to reverse the seed code.

However, when using the AuctionHouse, it uses the bnet protobuff encoding for items which only contains the affixes and the seed.

Thank you. I was actually looking for decoding the affixes. The puzzle part I missed was the re-seeding.

I am not sure if you heard about the hack that lets you know the affixes on unID'ed items. Someone wrote a program to show you the affixes given a string that you could cut and paste from chat while browsing the AH. As it turns out, that string also contained to affix, so you could completely determine the item stats.

Blizzard's fail in this regard is epic. Once again, they failed to adhere to what I call:
Rule # 1 of Client/Server Programming: Never trust the Client.

Really sucks that the buying and selling of unID'ed items is dead. I was making a lot of Gold doing so, and I didn't even know about this hack until it was all over the forums.

I did know that you could determine the number of affixes since that came across in the GameServer packets. When an item is identified, the values for the attributes come across as well, but for unIDed, the affixes are all generic "unknown prefix" and "unknown suffix".

Little did I think about the fact that this info would be available through the AH packets. I didn't really think about it since you can't sell those items. And I assumed they would follow the same rules as the Game Server packets and not show the affixes. As it turns out, AH item packets are encoded very differently than GameServer packets (which I already knew), and this became the weakness.

Wouldn't your AH project have turned up something about this back in the beta?

Yes, this is why I was asking. At first I didn't know about the full method that lets you rearrange the string and read out the actual attribute values in-game. So I started to write code that would decode the stat values for me. I couldn't get it working because I missed the step where the PRG is re-seeded, so I started to doubt things.


I'm right there with you. It's unbelievable. Twelve years ago, when I started messing with D2, I noticed that there was WAY to much data being sent when you gamble for items. So yeah, a few hours later I found out that they send the full item information to the client... free uniques! Already back then I was surprised how a large team of professional game developers could overlook something so trivial. You kind of expect that words gets around after a decade of online gaming (and cheating). Don't ever send any bit of information that is not supposed to be public anyway... it is beyond me how they could fail at this. Given that, I'm not sure what other surprises will show up. If anything, it shows that it is worth looking (hello duplicate loot packages).

I knew I could decode AH item packets. And given that GameServer packets didn't have the affixes (it showed them as "Unknown Prefix" and "Unknown Suffix"), I didn't bother to check assuming Blizzard wouldn't be that stupid.

Also, keep in mind that during the Beta that was 0 trading in unID'ed items. That's something that sprung up in the past month.

The final thing to keep in mind is that the AH packets are sent over the Bnet link which is encrypted, while the GameServer packets re sent in the clear. So in order to parse those packets, you need some kind of DLL injection like protowatch, or another mechanism to read them. Of course, the unID hack relied on Blizzard's idiocy of item links containing the affixes (and seed) for unID'ed items.

Not adhering to Rule #1 is a catastrophic mistake. And what's even scarier is the fact that some of the few safeguards that are in place now didn't even get coded until late in the Beta.

Consider the fact that in the early Beta item generation data was in the client MPQs (all the Treasure Class data up to Skeleton King was there), you could Map Hack since the server sent full map info, you could dupe in a number of ways, etc. This goes to show you that the design didn't put a high priority on anti-cheating. All of this only came after the fact which is really scary.