software security management

[go for it]

well to be as short as possible, i was looking for the best ways to protect your products ex. proxies or anything using subscriptions system

of what i know that most of bot proxies out there (ex. coai/chrome/cog) if not all are a second level proxies where the proxy client you get is useless for reversing purposes , and that it just connect to the main proxy server that does all the magic then gives you the final packets that you need to process to the server/client (i could be so wrong but that's what i've heard) , how true is that and could you please give me more details ?

is there a better way of getting that done? aka giving users a proxy client that won't worth reversing also having the control of everything on a main server but still using there proxy clients of dealing with server/game client ?

[Korvacs]

The ideal solution I suppose would be to distribute what I can best describe as a gateway client. Simply the client/clientless account connects to the gateway which then forwards to a cloud service which contains all the logic. The gateway client is then merely informed of changes.

In a practical sense this is the equivalent to using a pile driver to attach 2 pieces of paper in the place of a staple, and the cost of setting up the cloud based service is likely to be far beyond the profitability of the bot in the short term. Problem being that rather than the client's computer doing the processing the cloud servers would be doing it, so you would need a fair few servers to handle the bots.

On the other hand since you would most likely be handling alot of clients at the same time you could design the service to work in bulk, using parallel processing techniques and design which would therefore be more efficient perhaps than your typical bot, so with the right design you may be able to strike a good enough balance to make the thing profitable.

I wont go into detail on CoAI, the only bot that I am really familiar with (though even then I'm not upto date), but your not that far from the truth.

[go for it]

Originally Posted by Korvacs

The ideal solution I suppose would be to distribute what I can best describe as a gateway client. Simply the client/clientless account connects to the gateway which then forwards to a cloud service which contains all the logic. The gateway client is then merely informed of changes.

In a practical sense this is the equivalent to using a pile driver to attach 2 pieces of paper in the place of a staple, and the cost of setting up the cloud based service is likely to be far beyond the profitability of the bot in the short term. Problem being that rather than the client's computer doing the processing the cloud servers would be doing it, so you would need a fair few servers to handle the bots.

On the other hand since you would most likely be handling alot of clients at the same time you could design the service to work in bulk, using parallel processing techniques and design which would therefore be more efficient perhaps than your typical bot, so with the right design you may be able to strike a good enough balance to make the thing profitable.

I wont go into detail on CoAI, the only bot that I am really familiar with (though even then I'm not upto date), but your not that far from the truth.

pretty much what i knew was from CoAI as i've had there reflected client codes and yeah there wasn't much there, so that's how i figured that out, im thankful for the explanation and that's what i actually was trying to achieve
few gateways handling the auth system, having instances for each bot client having instances for clients, whenever a bot client try to do something it send this information for gateways (the gateways do the auth) and forward that to the main server, the main server compose/edit packets and send it back to gateways then back to the bot client to send it to tq servers
but i've always thought it's kinda stupid as packets going forward and backward by the gateways also the main server would have thousands of instances running
that's why i think it may not be as efficient as i want but this is the kind of details i want, maybe you can verify what i just said without revealing anything about coai (yup i would love to get some help at this subject but i don't want to get you troubles)

[CptSky]

Originally Posted by go for it

[...]the main server would have thousands of instances running [...]

What is a server of a MMORPG ? It handles thousands of clients For big projects, it might not scale well. For a bot, the main server will barely do something similar to the real server, except it will be a AI server. The logic isn't too complex.

Forwarding packets isn't a big issue, except in term of latency. But, if you're clientless, the lag won't be an issue. and if not, I doubt the latency created will be so big if the overall design is performant. The gateway should barely retransmit packets without any in-deepth analyses... In local, the ping is of few ms.

[go for it]

Originally Posted by CptSky

What is a server of a MMORPG ? It handles thousands of clients For big projects, it might not scale well. For a bot, the main server will barely do something similar to the real server, except it will be a AI server. The logic isn't too complex.

Forwarding packets isn't a big issue, except in term of latency. But, if you're clientless, the lag won't be an issue. and if not, I doubt the latency created will be so big if the overall design is performant. The gateway should barely retransmit packets without any in-deepth analyses... In local, the ping is of few ms.

which means that maybe a 100$ dedi will be suitable for this?, yes comparing to tq yes this will barely do something (as i won't forward every single packet, ill still do some simple filtering logic at the proxy client)