Topic: Hacking - ?
James,
You ok if I were to do some exploit testing on the new server code? (are we running the new server or old + new client?). The goal would be testing to report/fix.
Re: Hacking - ?
It's still the old server right now. I haven't had time to work on the new server, though I did write about 50-75% of one in 2020.
I expect I'll be using the old server for some time now. There's lots to do on the new client still left to do -- many months of fixing bugs -- before I even consider any new features, much less work on the new server.
Just out of curiosity, what sort of testing do you mean?
Re: Hacking - ?
I had a very thorough response written ... but the damn forum timed me out and I lost it all... I will summarize:
Race Conditions, Signed type overflows, client data validation as some examples with my favorite tactic to create a proxy that the client connects to... which connects to the server and handles all the fun stuff. I will play around when the new server comes out...
I had an explanation referencing all the cool old memories like back in the day when you added in the logoff delay when you were in combat.. and we would dupe all the stat elixirs by killing the player JUST as they logged off so the items would drop, but the server never removed it from the players inventory... oh the good memories.
Angeldust,
Re: Hacking - ?
Apparently the forum timeout was 5 minutes. I too encountered this all the time.
What a great default.
I've changed it to 3 hours.
Re: Hacking - ?
When you do get to the server - I'd be open to offer you suggestion's on defensive programming and ways to make the server more resistant to accidental exploits through progrmatic errors, and race conditions from multi-thread read/writes. One of the easiest things to do is consolidate ALL items into one table to avoid unnecessary INSERT when moving items from one table to another as outlined below:
ObjectId, OwnerId, Location, data, data2, data3, data4
The objectId would be the key for the table prevent duplicate entries natively by design - the ObjectID would be a thread safe IDFactory (server wide) and can be used for many things, but specifically, AccountID, CharacterID, MailID, etc.
Then you'd have your tables for Accounts, Characters, Mail, etc ... which with the reference to the Unique ID and loaded at server run time into memory - and written to the table as needed (items would Save instantly, always... as an example... but characters/exp gains could save on an timer thread such as every 5 minutes to reduce I/O Load).
When working with the "Inventory Table":
ObjectId, OwnerId, Location, data, data2, data3, data4
All instantiated items would exist in this table where the OwnerID would be where the item resides:
OwnerID = CharacterID for character Inventory
OwnerID = MailID for character mail - the Mail Table would reference its Character ID as to who owns it.
OwnerID = AccountID for Account Based storage... this would allow you create account based storage for moving items between characters on an account - shared storage..
OwnerID = GuideID for Guide Based storage...
OwnerID = MonsterID for pets... this would allow you to store pets with items on them still 
(solves that problem for you).
The benefit of this system, is that instead of DELETE and INSERTS you are doing simple UPDATES - so now you can't force a dupe through any type of race condition or logic error... because the object will only ever exist ONCE and get its reference in the database updated when traded / dropped / stored
At this point, the only thing you'd have to worry about is stackables - because the objectID would need to be recreated when splitting stacks - making them potentially still dupable.. but there are ways to track this and prevent it as well.
The location property would be a reference for loading and accessibility...
0 = Ground
1 = Inventory
2 = Account
4 = Mail
8 = Guild
16 = Pet
.... etc