ProjectX V5 (Aka. Codename CandyConquer) - 5517 Source

[Relic]

Originally Posted by Virus7799

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?

[Spirited]

Originally Posted by Virus7799

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 , 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):



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.

[Super Aids]

Originally Posted by Spirited

Looks like it's just another way for securing , 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):



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.

[Relic]

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.

[pintinho12]

Originally Posted by Virus7799

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.

[Super Aids]

Originally Posted by Virus7799

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.

[gian1227]

Originally Posted by Spirited

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

[pintinho12]

Originally Posted by gian1227

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

[nitrofreak06]

Solved my issue on the login. -Feelsbadman. Made me feel dumb xD

[sayedlove1]

[wmgm183]

The MSSQL database and the source are not on the same server, how to modify the database address

[BarcodeReader]

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

if (player.Battle != null)

To:

if (player.Battle != null && packet.Dialog != Enums.ArenaDialog.AcceptGiveUp)

Otherwise the match won't start.

Everything else seems to work with it.

[توام]

Ty