NOTE: This is very hard to use if the timing is not perfect.
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, 8) 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 maximised)
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.
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.
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.
To figure out the save order of the game 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.
If you arent 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 dont 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.
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 havent 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.
curtisouy of evilcheese.