Had the idea to write some words about the technical background of exploits, so here's my point of view.

Nearly all exploits are based on the simple fact, that DDO does not have a transactional database management system (DBMS).
Of course i can't prove this fact, but i worked a very long time in software architecture, specialized in distributed DBMS systems and had to fight similar bugs (exploits).

I don't know what these guys are using, but it's surely not a SQL based system, it smells like a homebred OODBMS for object persistence, which means you have to code every single query, no easy scripts for fixes or reports.
Further there are also no relation based structures, i'm sure the whole system is a hardcoded OOP hell without any second thought on a multi-tier architecture.

To the core:
A database transaction is generally atomic. That means, it is either done completely, or it is not done.
To move an item from the bag to the shared bank you will have to modify two places (let's call them tables for simplicity) in the storage system.
In table A (the bag) one record (the item) will be deleted, in table B (the shared bank) one record (the item) will be inserted.
In a healthy DBMS you just start a transaction, do what ever is needed, fire a commit if all is ok and both tables are changed.
If your connection will break between the operations, the DBMS will do an automatic rollback, no table is changed.
Notice something? All exploits based on DC'ing interrupt the coded operations and leave one table in inconsistent state.

The newest changes in DDO paint a disgusting picture about the DDO codebase.
The devs have started to fix the exploits in the client ("exclusive windows").
This is terrible, since this will leave the DDO server system buggy and massacre the user interface to the annoyance of all players.
This is terrible, since it proves that noone at turbine is brave or skilled enough to change the server code.
This is terrible, since it leaves the system wide open for a "man in the middle" attack.
This is terrible, the ultimate exploit tool just needs to capture and modify/resend messages from the client to the server.

Be creative 

And now for the Turbine readers:
There is one simple solution to fix the given "move item" security hole:
Remove the clientbased code sequences and implement a server based new function MoveItem(item, fromContainer, toContainer). No need to touch your barely running system, just an additional function.
And now search for a developer brave and skilled enough to change your network api and remove the retarded exclusive window shit.

SweetKitten wrote on Jun 12^th, 2014 at 4:34am:

I saw someone flying straight up into the air today in Meridia. That was after he duped ingredients. 

OneUpGamer wrote on Jun 12^th, 2014 at 10:09am:

Not quite.

Any of the exploits that were fixed by having x close when y opens can be reproduced by simulating the required interaction with x, while y is open. This assumes that the fix is entirely client side.

i.e. If an exploit requires putting something in the bank, you can still send the necessary request to put it in the bank, without the bank UI open. This wouldn't work if the server keeps a state of whether the bank is open or not, appropriately flips the state when other things happen, and doesn't allow bank interaction while the state if off. That is very unlikely, however.

disappointment

wascally wabbit wrote on Jun 12^th, 2014 at 2:54pm:


Orangutans and chimpanzees, yes.  But not this filthy stupid gorillas, marmosets or tamarins.  Those things are awful.

Flav wrote on Jun 12^th, 2014 at 11:22am:


He said Transactional, not Relational.

But yeah, if you have transactions available and don't use them, you can get this with any database.

But part of the problem is scale. Once upon a time, DDO had more than 20,000 players, and holding transactions open across the 15 seconds of the whole action instead of twice across 1 second halves of the action would have really added up. It would have made disk churning that sounds like a sausage grinder.

Fortunately, Turbine has solved that problem. With our current populations, full transactions should be easily within the capabilities of modern hardware.

Flav wrote on Jun 12^th, 2014 at 5:44pm:


?

The exploits have nothing to do with data storage and everything to do with the protocol, thats why it matters if you move an item to the SB before of after you use it.

ps: yay boobies

sweetkitten....

SweetKitten wrote on Jun 12^th, 2014 at 4:34am:


Hey Sweetkitten.
Just curious, I've not heard this word used in this context before?  Is this a software development term, or did you just mean binary?

Ah, thanks for explaining.
Was not familiar with the term.

thanks bro.

mystafyi wrote on Jun 14^th, 2014 at 11:06am:

hmmm