Question about OTCV8 Client (Modules removal)

[archer32]

Hi, just a quick question if somebody wouldn't mind answering

If I use OTCV8 and remove some modules like bot, actionbars, etc.. how can I make it so nobody can add those back into the game manually? It seems to be what can happen?

I want to just have like a clean older 8.6 style, not with all these extra bells and whistles.. but I like the function of like auto-updater and things like that... is there anything I am missing about this?

I like simple, slower paced RPG.. with the current OTCV8 to many buttons is just meh overwhelming to me... but I want everybody to be on the same page, and not being able to add extra things like actionbars or bot, battle window (if it was removed for example)

Thanks for input!
Have a blessed day

 

[Gesior.pl]

If I use OTCV8 and remove some modules like bot, actionbars, etc.. how can I make it so nobody can add those back into the game manually? It seems to be what can happen?

When you release your version of OTClient, there are multiple possibilities for players to add something:

• just edit OTC files and add missing modules
• connect using clean version of OTC - if you add some changes in your OTC, to block other clients (ex. edit RSA key), they can try to copy these changes into their client to make it able to login
• write external bot and inject it into OTC

So you got to block these 2 scenarios. You cannot allow anyone to modify your files and you cannot allow anyone to use your files in his client - do not allow to mix clean OTC files with your files.

Obvious solution is to encrypt client ( Updated, encryption and compression (https://github.com/OTCv8/otclientv8/wiki/Updated,-encryption-and-compression) ), but there are 3 problems with basic OTCv8 encryption (all OTCv8 use same encryption password, which is defined inside OTCv8 .exe):

• anyone can take file from your encrypted OTC and put it in his encrypted OTC - mix files to connect with his OTC
• anyone can take file from his encrypted OTC and put it in your encrypted OTC - mix files to add module to your OTC
• by default OTCv8 .exe - even one that you will compile on your own - contains --encrypt function, so if you change in C++ 'password' used to encrypt files (to make your files incompatible with official version of OTCv8), someone can still take clean OTCv8 files, run your .exe with --encrypt parameter and it will encrypt his files using your secret password, so he can mix his and your files, like in 2 examples above

To get basic protection, you got to do 3-4 things:

• edit password used for encryption in OTCv8
• prepare 2 .exe versions, one for you to encrypt client files you release (with --encrypt), one for players (without --encrypt)
• modify RSA and some bytes in client-server communication protocol, to make it impossible to connect using clean OTC
• [in case you want to remove bot module] you must edit C++ code that makes bot folder not encrypted

If someone can break it, he can also create simple OTC bot .exe to attack/use spells/heal etc., so no matter what else you do with your client, they will use modified client by injecting own bot C++/C# code into it.

 

[Unknown Soldier]

When you release your version of OTClient, there are multiple possibilities for players to add something:

• just edit OTC files and add missing modules
• connect using clean version of OTC - if you add some changes in your OTC, to block other clients (ex. edit RSA key), they can try to copy these changes into their client to make it able to login
• write external bot and inject it into OTC

So you got to block these 2 scenarios. You cannot allow anyone to modify your files and you cannot allow anyone to use your files in his client - do not allow to mix clean OTC files with your files.

Obvious solution is to encrypt client ( Updated, encryption and compression (https://github.com/OTCv8/otclientv8/wiki/Updated,-encryption-and-compression) ), but there are 3 problems with basic OTCv8 encryption (all OTCv8 use same encryption password, which is defined inside OTCv8 .exe):

• anyone can take file from your encrypted OTC and put it in his encrypted OTC - mix files to connect with his OTC
• anyone can take file from his encrypted OTC and put it in your encrypted OTC - mix files to add module to your OTC
• by default OTCv8 .exe - even one that you will compile on your own - contains --encrypt function, so if you change in C++ 'password' used to encrypt files (to make your files incompatible with official version of OTCv8), someone can still take clean OTCv8 files, run your .exe with --encrypt parameter and it will encrypt his files using your secret password, so he can mix his and your files, like in 2 examples above

To get basic protection, you got to do 3-4 things:

• edit password used for encryption in OTCv8
• prepare 2 .exe versions, one for you to encrypt client files you release (with --encrypt), one for players (without --encrypt)
• modify RSA and some bytes in client-server communication protocol, to make it impossible to connect using clean OTC
• [in case you want to remove bot module] you must edit C++ code that makes bot folder not encrypted

If someone can break it, he can also create simple OTC bot .exe to attack/use spells/heal etc., so no matter what else you do with your client, they will use modified client by injecting own bot C++/C# code into it.

I think that's not exactly what he meant, he seems to want to make it impossible to just drag and drop bot module into his OTC directory, as it is possible even with encrypted client. So having encrypted client with not encrypted bot module is going to make the bot work. Basically even a kid can do this, so just removing bot folder and encrypting will not protect him from injecting bot into his OTC.

 

[Gesior.pl]

so just removing bot folder and encrypting will not protect him from injecting bot into his OTC.

Yes. That's why I posted that you have to modify OTCv8 C++ code to make it does not skip 'bot' folder while encrypting/decrypting.
I forgot to mention, that special version of .exe 'for players' should not allow any not encrypted .lua/.otmod/.otui files. By default OTCv8 reads encrypted and not encrypted files (you can mix them), by checking, if they start with ENC3 and if they do, it tries to decrypt them.

I also forgot that I released OTCv8 with bot removed and blocked a month ago

Client without bot and with VS project to build special safe .exe for players by gesior · Pull Request #102 · OTCv8/otcv8-dev

Client without bot and with VS project to build special safe .exe for players. VS project has 2 new build targets: OpenGL_admin DirectX_admin Only .exe build with "admin" can run with u...

github.com

When you ( @Unknown Soldier ) posted your answer about blocking "bot" module, I though "I made it for someone and he allowed me to release code".

 

[Tbol]

Yes. That's why I posted that you have to modify OTCv8 C++ code to make it does not skip 'bot' folder while encrypting/decrypting.
I forgot to mention, that special version of .exe 'for players' should not allow any not encrypted .lua/.otmod/.otui files. By default OTCv8 reads encrypted and not encrypted files (you can mix them), by checking, if they start with ENC3 and if they do, it tries to decrypt them.

I also forgot that I released OTCv8 with bot removed and blocked a month ago

Client without bot and with VS project to build special safe .exe for players by gesior · Pull Request #102 · OTCv8/otcv8-dev

Client without bot and with VS project to build special safe .exe for players. VS project has 2 new build targets: OpenGL_admin DirectX_admin Only .exe build with "admin" can run with u...

github.com

great release