Silkroad Online Forums

Sigh, any new news on silkroad?? I don't know if you guys know but I farmed 85-100k and stopped on lvl 5x; I got about 50k left. So anyways...I've played this game called "Tantra Online" and it sucks. But they have a pretty innovative way to eliminate bots or botters. While grinding, they have this normal monster but it doesnt have aggro; and if you try to attack it, even though you have +11 sosun..etc, it doesnt hurt the monster. but 1-2 hits could kill you. Its like for ever mob you see this recognizable monster (looks like some super hero) you know not to hit it, but the other monsters around it. Did that make sense...?? Ah well theres my two cents.
LONG LIVE EPIC..lawl

ppl who make the bots will probably script the bot not to attack a certain mob... just like how bots don't attack "WOLF" or "MANGYANG" balls at all. Bot makers update alot more than JM it seems....

aznshadow wrote:ppl who make the bots will probably script the bot not to attack a certain mob... just like how bots don't attack "WOLF" or "MANGYANG" balls at all. Bot makers update alot more than JM it seems....

too true.

maybe they should make them random mobs that normal person would know not to attack but it has same model as the mobs around but its color red all around and when you click on it nothing changes the name is liek the mobs around eventually players would pick up not to attack red mobs

I'm sure the bot would be able to pick up the "different" packet from the special mob.

For these sorts of bot preventing measures, you can't rely on the bot taking a certain action for it to work, because bot programmers will quickly code the bots not to take that action. A better idea would be a system where if no action/the wrong was made by the bot then they would be booted/flagged/whatever. This way, the bot programmers not only have to code for the bot to take a new action, but to do it correctly. This would take a little longer for them to do, and if the system was regularly modified it would work best. But leaving any anti-bot strategy static for months is doomed to failure.

I still think the sro client and sro server need to use some form of public key authentication. The actual human player would not be involved, but the client and server software would each have their own private and public keys (AES keys, 256 bit maybe?). Then encrypt a small packet between the two servers, like digital signatures. The server can send an encrypted packet to the sro client, client must decrypt it, and encrypt a proper response back to the server.

The botter would have to be able to figure out both the encryption algorythm and the private keys used. Seems it should work.

Joymax could even change the keys weekly.

PR0METHEUS wrote:I still think the sro client and sro server need to use some form of public key authentication. The actual human player would not be involved, but the client and server software would each have their own private and public keys (AES keys, 256 bit maybe?). Then encrypt a small packet between the two servers, like digital signatures. The server can send an encrypted packet to the sro client, client must decrypt it, and encrypt a proper response back to the server.

The botter would have to be able to figure out both the encryption algorythm and the private keys used. Seems it should work.

Joymax could even change the keys weekly.

hmm. would be better to do that with C++. Is fast.

Waisha wrote:

PR0METHEUS wrote:I still think the sro client and sro server need to use some form of public key authentication. The actual human player would not be involved, but the client and server software would each have their own private and public keys (AES keys, 256 bit maybe?). Then encrypt a small packet between the two servers, like digital signatures. The server can send an encrypted packet to the sro client, client must decrypt it, and encrypt a proper response back to the server.

The botter would have to be able to figure out both the encryption algorythm and the private keys used. Seems it should work.

Joymax could even change the keys weekly.

hmm. would be better to do that with C++. Is fast.

C is even faster than C++. If any feature like that was done, it would be in whatever language the SRO client and server software are written in. I suppose the "bot-block-encryption" function could be written in C (or C++) regardless of what language the rest of the software is in. Just create a DLL and call it from SRO (is SRO written in Prolog? <--sarcasm)