Attention

Okay. so you all read the above warning, and you STILL want to dupe? You're probably an idiot... but feel free to carry on if all sense of reason has abandoned you.

You want to dupe in a way that Blizzard couldn't possibly patch if they had all the time and resources in the world?

Well I'm not going to be as active in the D2 community in the coming months (family commitments and so forth) so here's a simple and easy way to do it as a parting gift.

What you will need:

1) 8 chars, call them C1-C8 for the time being. (More chars create more certainty)
2) A method for creating server-lag (this is optional, but timing is more imperative if this is not provided)
3) A method for causing a game-server crash.

First a little background:

When a character leaves a game, the game server saves all characters present in that game. This cannot and does not happen concurrently (all at once) ... it happens sequentially.

Assume for the sake of argument that there are 8 players in a game, and player 3 leaves... the game will first save player 3 (the leaving player) and will then save players 1 - 8 (1, 2, 4, 5, 6, 7, in order.

This method revolves around the idea of causing the game server to crash part-way through this save cycle, and thusly causing some of the characters in the game to save, and others to not save.

For best results, the method should be carried out as follows:

1) Players C1 - C7 all join a game in order, C7 should be holding the items to dupe and C2 - C6 should all have inventory + stash + cube full of 1x1 items. (this is to cause the processing overhead for saving each character to be maximized)

2) C8 joins a game on the same server.

3) C7 drops the items to be duped.

4) C1 picks them up.

5) The server-lag method is used to eat server-side processor cycles. Enough lag to crash the server or desynch it is NOT required at this point in time, just enough lag to cause a near-desynch and substantial action-delay.

6) C8 stands ready to perform the server crash on a pre-established automated trigger.

7) C1 leaves the game and C8 IMMEDIATELY performs the server crash. This should be done using a trigger, or even better using a clientless bot to send the relevant packets immediately C1 sends the game-leave packet.

Tada... if the server was lagged enough, and C2 - C6 have inventories sufficiently full of 1x1 junk, you have now duped. C1 will save and C7 will roll back.

Server-side observed symptoms of the use of this dupe method and derivative methods are a period of unusual lag, followed by a sudden server crash.

Most accidental rollback dupes happen via a process similar to this, and this method has been used by some fairly large item suppliers for some time now. It's pretty much unpatchable without a total reworking of several key elements of the game architecture... which isn't going to happen.

I'll leave the lag method and game crashing methods up to individual tastes ( I know several members of this forum have one or the other, if not both ) so that this doesn't cause mass havoc on bnet.

Have fun and be careful. This method constitutes a criminal action and could potentially be prosecuted as such.


WeeD wrote:
Very interesting
Quote:
C8 IMMEDIATELY performs the server crash. This should be done using a trigger, or even better using a clientless bot to send the relevant packets immediately

Can u explain how to perform server crash or server lag?


To cause server-crash:

Perform an action which provides incorrect parameters or correct parameters in an incorrect or unexpected way to either a packet-handler or a core code-function.

To cause server-lag:

Perform either a single action or multiple small actions which cause processor-time on the target machine to be used in a way which is detrimental to the performance of the game process on that machine.

Hope that helps.


PiratSS wrote:
looks like a modification to the lag dupe. Lots of work, But the return is good.


Totally different principal... both methods involve creating server lag at some point, but that's where the similarities end.

The return is excellent.

Once you have dupe-mules established (with x number of each rune + gems to transmute to higher) and you have a clientless bot capable of creating and coordinating multiple dupe games to a single server-IP, you can essentially turn each D2 server into the equivalent of an automated item-factory... producing large numbers of runes in a single run.

Achieving this level of coordination is extremely difficult however, and this kind of mass exploitation will probably remain in the realms of the large-scale suppliers who can afford to commission the coding of a bespoke system to handle it.


dark_teferi wrote:
How do you figure out the save order of a game?

Is it alphabetical?
Is it the first one to join---Last one to join?


Logically you'd have to assume that the list of players was stored either as an array or a linked/indexed list of some kind.

The most efficient way to carry out a save operation on the contents of that list would be to walk it from one end to the other and dump out the contents in the order they are encountered.

The most logical order to add them is the order in which the server becomes aware of them. Obviously they can be deleted from anywhere inside the list and so if people enter/leave mutiple times things can get complicated... but you wont/shouldnt need to go there.

That should answer your question, I think.


DeltaDreamer wrote:
To patch this easily, why couldn't they just code it to save characters randomly instead of in a sequence?

They made item and entities ids random instead of a sequence.

Is this just a 'theory' Evilcheese?

Because they might have already implemented this fix when they made item and entities ids random instead of a sequence.


Although entity IDs are now random... the order in which their data structures are stored server-side, and thus their order in the linked lists is still in spawn-order.

If that were not the case, the server would need to pre-allocate enough room to hold all possible entities that could ever spawn... which is somewhat impractical.

The way in which the client sees entities and the way in which the server deals with them internally are 2 totally different things. Changing the observed IDs is a matter of adding 2 or 3 lines of code to the existing entity-spawn function.... whereas placing them in a truly random order would be the work of several months and involve the development of an extremely (and needlessly) complex list management class.


Darawk wrote:
This is not something that is very hard to patch, seeing as they are now aware of this and will patch all of the bugs that crash their servers(and they will find out 99% of them very very quickly).

Myself, teferi, ling, tgif, and greg tested this on east. We tried it twice, with no sucess. I coded a module to crash the server upon reception of a 5c packet for player 1. I don't know if by the time you receive such a packet you have already saved though. If that is the case, then you will need to use some form of IPC(InterProcess Communication) to pull this dupe off, and crash the server before it even notifies the players in the game that someone has left.

This dupe is obviously theoretically sound, but I don't know how computationally feasible it is to actually catch the server in the middle of the save process. I mean, they're probably using some form of database software on separate servers from the game servers. So, they simply send out a packet to the dbase servers telling it what they want saved, thus not wasting time on write operations to files. It seems like this could be another wp dupe...but who knows?


If you aren't slowing the server down considerably (to nearly the point of crashing), then you're going to need almost instantaneous timing the likes of which can only be achieved, as you say, via some form of IPC or by running the whole process as a single application. (single clientless bot)

That this works is not in doubt, and while I don't have access to an automated system capable of carrying this out, I know someone who does... and since I was involved closely with its creation, I have a very good idea of its functionality.

As I said... I've told you how in the broadest sense possible, this is not a silver-platter dupe, nor is it one that is going to be carried out in five minutes by someone who just picked up hackit... or even someone experienced in the use of the tools for that matter.

This is a serious method that has made serious money for a large number of very serious people, and requires an appropriately serious amount of effort and coordination to achieve.

There's not a huge deal more I can say on this subject.

EDIT:

On the subject of patchability... yes it's true that this method can be patched by fixing all known server-crashes, but you have to remember that Blizzard have been "fixing all known server crashes" since the game was released, and still haven't succeeded in doing so.

This method has been in existence for an awfully long time... it goes way back into 1.09 since it is such an obvious and theoretically simple thing to carry out.

Cast your mind back... do you remember the huge speculation as to why large numbers of new bugged items were always released following a rollback release? Suggestions of importation with rollbacks?

Now you know.

There are more game-crashing methods in existence than even the most informed people (including myself) can possibly hope to know about.


DeltaDreamer wrote:
Evilcheese - Do you have any advice for someone that wishes to build an automated system capable of carrying this out?


Not really... other than if you're designing it specifically for this kind of task then there is a lot of information that you dont need to process, and so a lot of the in-game chatter from client-server that you can safely ignore.

If you need help on creating and maintaining a battle.net or realm connection, then there are few places better to go for information than clan vL ... I wont give out the bnet channel cuz I'll get shouted at for causing excess traffic, but a lot of the people there will give you help if you show some willing.