ProjectX V5 (Aka. Codename CandyConquer) - 5517 Source

03/06/2020 20:35 Relic#76
Quote:
Originally Posted by Virus7799 View Post
First of all I'd like to say great source, I've been learning a lot going through it.

I'm running into two problems with player booths.

1. When a booth is active and you're selling one item, disconnecting the client and logging back in will show two of the same item you were just selling in your inventory. Debugging shows that the Inventory.Count=1 though.

2. When another player buys an item from booth, the seller booth window doesn't remove the item unless you close and reopen booth window. Solved. Wasn't passing the ClientId in packet.

I've looked at other sources and can't seem to figure out why this is happening. I know this isn't much to go on but maybe I'm overlooking something or not sending the right packet. Any help would be greatly appreciated.
For anyone running into the same problem, the issue was that player owned items were generating a unique ClientId upon login. So I'm assuming the client sees the original and the "duplicate" because they have different ClientIds even though only 1 exists in the database.

Setting the item.ClientId to DbOwnerItem.Id for player owned items fixes this issue. I can elaborate further if anyone is interested.

Additional Question:

I see you're assigning a unique ClientId for players on login via the IdentityGenerator class. Is there any benefit to doing this as opposed to just using the unique Id column from the player table?
03/08/2020 00:07 Spirited#77
Quote:
Originally Posted by Virus7799 View Post
For anyone running into the same problem, the issue was that player owned items were generating a unique ClientId upon login. So I'm assuming the client sees the original and the "duplicate" because they have different ClientIds even though only 1 exists in the database.

Setting the item.ClientId to DbOwnerItem.Id for player owned items fixes this issue. I can elaborate further if anyone is interested.

Additional Question:

I see you're assigning a unique ClientId for players on login via the IdentityGenerator class. Is there any benefit to doing this as opposed to just using the unique Id column from the player table?
Looks like it's just another way for securing [Only registered and activated users can see links. Click Here To Register...], which is a vulnerability in most other private server sources. The problem with just having the client id (or an incremented number which is what most other servers do) in the packet is that it's predictable. By replacing that field with another client id, you can login as anyone. I exploited this a few years back to login as the server owner of Arista (was challenged to do so after disclosing the exploit with him):

[Only registered and activated users can see links. Click Here To Register...]

It looks like Candy Conquer uses the database to store a 32-bit token based on the current time and a 32-bit generated client id. In my own source, I generate a cryptographically secure random unsigned 64-bit token on the account server, send that token in MsgConnectEx to replace the client id and authentication token, and send the token with the client's connection details to the game server using RPC. Both accomplish the same thing though: securing login. Though, there is an extremely small chance for a race condition in Candy Conquer where you could steal a login session from someone if you know the algorithm.
03/08/2020 16:34 Super Aids#78
Quote:
Originally Posted by Spirited View Post
Looks like it's just another way for securing [Only registered and activated users can see links. Click Here To Register...], which is a vulnerability in most other private server sources. The problem with just having the client id (or an incremented number which is what most other servers do) in the packet is that it's predictable. By replacing that field with another client id, you can login as anyone. I exploited this a few years back to login as the server owner of Arista (was challenged to do so after disclosing the exploit with him):

[Only registered and activated users can see links. Click Here To Register...]

It looks like Candy Conquer uses the database to store a 32-bit token based on the current time and a 32-bit generated client id. In my own source, I generate a cryptographically secure random unsigned 64-bit token on the account server, send that token in MsgConnectEx to replace the client id and authentication token, and send the token with the client's connection details to the game server using RPC. Both accomplish the same thing though: securing login. Though, there is an extremely small chance for a race condition in Candy Conquer where you could steal a login session from someone if you know the algorithm.
Yeah, in all honesty didn't bother doing much else because it's a pserver and not something where it really counts.

It's kinda old at this point too.

A lot of servers also don't verify that the one sending an id is the one who has said id.

So in some servers you can just change the id to whatever and do whatever on that player since the id is never verified against the connected client lmao.
03/10/2020 06:36 Relic#79
Thanks for taking a look guys.

The race condition you're talking about would be highly unlikely no? The attacker would have to guess the generated number and the exact time the request was sent.

I noticed in your (Spirited) Comet source, you use the CharacterId from the database as a unique client id for any game server interactions.

My next question is, after the whole auth flow, is there any benefit in having the CharacterId/ClientId set to that randomly generated value? Or can I simply use the id from the db?

Since the value never changes, it seems like a slight inconvenience for a potential attacker if you generate a random ClientId every time a player logs in.
03/10/2020 12:16 pintinho12#80
Quote:
Originally Posted by Virus7799 View Post
Since the value never changes, it seems like a slight inconvenience for a potential attacker if you generate a random ClientId every time a player logs in.
Nope, because when the player login the server will assign the random ID for the user, and then the DB Identity will be used only for internal or database assignment. The client will see the fake ID and will send requests in it, but the server has the relation between Fake ID and Identity.
03/10/2020 18:44 Super Aids#81
Quote:
Originally Posted by Virus7799 View Post
Thanks for taking a look guys.

The race condition you're talking about would be highly unlikely no? The attacker would have to guess the generated number and the exact time the request was sent.

I noticed in your (Spirited) Comet source, you use the CharacterId from the database as a unique client id for any game server interactions.

My next question is, after the whole auth flow, is there any benefit in having the CharacterId/ClientId set to that randomly generated value? Or can I simply use the id from the db?

Since the value never changes, it seems like a slight inconvenience for a potential attacker if you generate a random ClientId every time a player logs in.
There is a benefit if you have multiple servers where they interact with each other because the chance of IDs clashing when randomly generated is smaller than if you just took them from a database (If said servers has two different databases) - of course that is void if the ids are not incremental.

Other than that there is no benefit other than preventing users from just invoking calls as other users but generally that is avoided if you handle packets correctly since you just have to check the client id of the packet against the client id of the connected client server side.

In particular there is no real benefit for a co server. I doubt there are even anyone active anymore that has an interest in server hacking either.
08/13/2020 19:21 gian1227#82
Quote:
Originally Posted by Spirited View Post
No. Nobody can help you because you told us nothing. That leads me to believe that you didn't google whatever error you got either, and that you're going to create even more spam than you're making now. But go ahead, post the error you're having and maybe we can help you.
Hi. Im a player for a 5517 server. My problem is this will show up after i click start game.

"Failed to start settings.exe"
"Failed to load the game"

Please help me
08/14/2020 01:19 pintinho12#83
Quote:
Originally Posted by gian1227 View Post
Hi. Im a player for a 5517 server. My problem is this will show up after i click start game.

"Failed to start settings.exe"
"Failed to load the game"

Please help me
good information
09/03/2020 09:36 nitrofreak06#84
Solved my issue on the login. -Feelsbadman. Made me feel dumb xD
04/08/2022 12:02 sayedlove1#85
:lul:
04/30/2022 03:46 wmgm183#86
The MSSQL database and the source are not on the same server, how to modify the database address
03/05/2023 09:38 BarcodeReader#87
Here is a small fix to make arena work, took me a while to figure out why arena didn't seem to work:

1. Open ArenaActionPacketController and change

Code:
if (player.Battle != null)
To:

Code:
if (player.Battle != null && packet.Dialog != Enums.ArenaDialog.AcceptGiveUp)
Otherwise the match won't start.

Everything else seems to work with it.
10/11/2023 11:43 توام#88
Ty