Thoughts on a proxy-based bot-making API?

Nice idea though I'm guessing the only thing to ever be made for this will be an aimbot xD

Quote:

Originally Posted by MushyPeas Nice idea though I'm guessing the only thing to ever be made for this will be an aimbot xD

na, auto hunt? followers? auto loot:mofo:.... aimbots :rtfm:

Well, I think you know my opinion on this kind of thing... TQ is kinda actively watching CO these days so I prefer this kind of thing not being released to extend the longevity of existing programs. True, it will happen eventually, but I don't see any reason to make it happen sooner. :p

I think it's "over-confident" to think that TQ's next encryption updates would be equally easy to reverse. I know you can do it, but what about the rest of us? :)

I'd rather see a public pserver api released (that takes care of the login, monitoring connections, etc.) and calls into user functions to implement server logic. TQ is less likely to react to that and if the only motive for releasing a proxy is for educational purposes I'd think people would learn more from writing a pserver versus a proxy.

Quote:

Originally Posted by flowerpot! I'd rather see a public pserver api released (that takes care of the login, monitoring connections, etc.) and calls into user functions to implement server logic. TQ is less likely to react to that and if the only motive for releasing a proxy is for educational purposes I'd think people would learn more from writing a pserver versus a proxy.

Pservers are garbage and a waste of time(sorry... personal opnion)
I dont think TQ will be all that bothered(atleast not enough to change anything)by working proxy,with 2 "public" proxys (cid and this one) they can keep an eye on things,Relesing the whole algo for the enc would be different (more private proxys and what not)
When most ppl figure out they have to program to use this proxy they will lose intrest,leaving it for the small but faithfull comunity that actualy want to learn programing and packets.


any update on this unknown?

Quote:

Originally Posted by Real~Death Pservers are garbage and a waste of time(sorry... personal opnion) I dont think TQ will be all that bothered(atleast not enough to change anything)by working proxy,with 2 "public" proxys (cid and this one) they can keep an eye on things,Relesing the whole algo for the enc would be different (more private proxys and what not) When most ppl figure out they have to program to use this proxy they will lose intrest,leaving it for the small but faithfull comunity that actualy want to learn programing and packets. any update on this unknown?

How come Pservers are garbage?
Even if it's just an opinion I know you must have based that on something.

I don't see how the number of public proxies would matter, if people want to aimbot / cheat they will do so regardless of what the proxy is called, so there won't be any less proxy users just because there are fewer proxies.

On the programming part, I'm sure someone will be releasing working code for an aimbot and such as soon as this thing is released, which I think is the purpose of this project, the "community" working together on adding functionality.

Most of the current PServers are garbage. There's not really any that are complete, most of them are built the same few C# code bases which are badly written and hard to maintain. I don't really think releasing server code helps at all though, because you end up with a dozen servers that have 50 players each, rather than one with a big community that's worth playing on.

I'd considered what flowerpot suggested, about releasing an API for a server, but I just don't find it practical. Everyone want's their own method for handling networking in a server. If the choice was just left up to me, there'd be people who'd disagree with my choices. I'm not in favor of IOCP, poll etc, becuase I try to keep my code portable. In the end, people will prefer the easier-to-code C# crap that's around already anyway. If anyone would be interested in coding a server in C++ and needs help they can PM me.

I consider your P.O.V about the API flowerpot, although I don't play the game and neither does bgreen. I'll be releasing this at home first anyway and see what people there think, but I'm in agreement with RD. TQ aren't gonna change anything, it took em 3 years to do this. If they do, it can be cracked again. Yeah, I'm probably overconfident, but I'm not particularly bothered if it's more difficult to do next time, I enjoy the challenge.

If it's the aimbot potential people are concerned about, I can always apply an internal packet filter to the API that would prevent any being made. I think that'd leave more room for creativity in botting rather than just the old crap we've already seen. I'll wait for more opinions on that before it happens anyway. Probably pointless bothering if CIDProxy is released.

Anyway, the status now is: The auto_reply_bot from my initial post is no longer useless. It's built and working, but the API kinda crashes once in a while, I'll fix that soon though (when I find what's causing it). Atm it still only handles 1 bot (although you can proxy an unlimited number of clients and it'll just forward all the data). I'm in the process of adding multi-bot support. The way I'll be doing it is, you'll create a new client_event/server_event class & instance for each bot, and use conquer_proxy.add_proxy(client_event, server_event, "account_name");. This will mean you can run multiple different bots for diff characters in the same application. If people stick to the templates I provide then it'll be really easy to plug in someone else's bot to your own applications.

Is the bot-check in it,or does the client itself have to reply?

Quote:

Originally Posted by Real~Death Is the bot-check in it,or does the client itself have to reply?

After going clientless again then ^^ btw, how far did you get with sacob in the end?

ps Sorry for going off topic here, I think whilst / if this is the only working proxy release a filter to prevent fb/ss packets going out would be reasonable, though I'm not really fussy....everyone would afterall have the same advantages.

Quote:

Originally Posted by Some-Guy After going clientless again then ^^ btw, how far did you get with sacob in the end? ps Sorry for going off topic here, I think whilst / if this is the only working proxy release a filter to prevent fb/ss packets going out would be reasonable, though I'm not really fussy....everyone would afterall have the same advantages.

I was thinking if the BC is in this then just keeping up with spawn/items/XP might not be too hard,specialy with the way unknown is talking about(keeping the packets structures sorted as more of data like?),then using somthing like Cid used for TG without a client open(wassent it just blocking a packet?) should work.

I figured out alot with sacob but also had problems with some easy stuff either way I can take what I leared there and make this so much easier to understand(focus more on learning/understanding C++ because I already know packets)

as for aimbot dossent that requier xor'ing along with a few outher things(sorry deleted/lost all my CO data/text/notes a few months ago to confirm) as it is a skill?I dont thing anyone who would understand how to do it would release it public,And a follow command is just as deadly and just need Co-ord's,and cid will have that shit anyway so I dont see a need to realy block it within the proxy it self,but thats just my thoughts


I cant wait this sounds fun

Quote:

Originally Posted by Real~Death as for aimbot dossent that requier xor'ing along with a few outher things(sorry lost all my CO data a few months ago to confirm) as it is a skill?I dont thing anyone who would understand how to do it would release it public,And a follow command is just as deadly and just need Co-ord's,and cid will have that shit anyway so I dont see a need to realy block it within the proxy it self,but thats just my thoughts

Yes skill packet encryption requires more work, however if the api is intended to make packets easy to understand that will likely be handled by the api (to allow magic based bots etc). Also people like caff and xtreme would be able to easilly build an aimbot using this even if they don't end up releasing cidproxy again.

Yeah follow kill is almost as bad, I say almost because at least it is possible to notice they are doing so and take a quick vid...whether anything gets done about that is another thing.

Anyway, maybe an anti-pk mode...when proxy is activated sends packet to switch to capture, and does not allow switching to pk (blocks packet) however that makes it almost useless to some people.

My view is generally that anything which makes pking unfair is bad however if other people choose to create or use them then it doesn't bother me too much.

I think a small effort to prevent aim bots would be good, at least make it a little more difficult, especially if the skill packet is easilly dealt with by the api.

Quote:

Originally Posted by Some-Guy ps Sorry for going off topic here, I think whilst / if this is the only working proxy release a filter to prevent fb/ss packets going out would be reasonable, though I'm not really fussy....everyone would afterall have the same advantages.

Correct me if I have the wrong idea, but wouldnt that be a stupid idea if you are filtering and preventing fb/ss packets going out of the proxy?! Then, if you were to use the proxy for...say auto-chat (and then want to go pk someone without having to close conquer and re-config the client to use itself, not the proxy) how would you then be able to pk someone without the use of an aimbot...but also without the use of a skill :eek:

I hope that makes sense xD

~:Hiyoal:~

Maybe what he ment to is, disable the custom building of ss/fb in the proxy. (aka don't allow to edit the X, Y etc.) This would still allow the proxy send the packet to server.

Thats what I was thinking when Unknown said it, but I got a bit confused when it came out for the second time... :eek:

Unknown said it so I assumed Guy meant something different :o

Neways,
#OnTopic

~:Hiyoal:~

Quote:

Originally Posted by unknownone I'd considered what flowerpot suggested, about releasing an API for a server, but I just don't find it practical. Everyone want's their own method for handling networking in a server. If the choice was just left up to me, there'd be people who'd disagree with my choices. I'm not in favor of IOCP, poll etc, becuase I try to keep my code portable. In the end, people will prefer the easier-to-code C# crap that's around already anyway. If anyone would be interested in coding a server in C++ and needs help they can PM me.

Use boost ASIO for the network code; it's portable. My pserver runs fine on Linux and Windows but I wouldn't really call it a pserver. More like a playground for me to test my bots.

Quote:

I consider your P.O.V about the API flowerpot, although I don't play the game and neither does bgreen. I'll be releasing this at home first anyway and see what people there think, but I'm in agreement with RD. TQ aren't gonna change anything, it took em 3 years to do this. If they do, it can be cracked again. Yeah, I'm probably overconfident, but I'm not particularly bothered if it's more difficult to do next time, I enjoy the challenge.

Wasn't Green working on a pserver too? I vaguely remember him sending me some SS on msn of his progress. Releasing a proxy and having TQ make updates would slow down progress if he wants his pserver to work with the latest patches. I know I'd rather not keep two installations of CO on my computer and so if the pserver didn't work with the latest patch I wouldn't bother.

BTW, by home do you mean PB? :)

Quote:

If it's the aimbot potential people are concerned about, I can always apply an internal packet filter to the API that would prevent any being made. I think that'd leave more room for creativity in botting rather than just the old crap we've already seen. I'll wait for more opinions on that before it happens anyway. Probably pointless bothering if CIDProxy is released.

Dan told me he wouldn't release an aimbot.. at least at first. Maybe things have changed. If you had the proxy never send FB/SS packets that would be good. Pure leveler proxy.

Nice idea, but plz compile the program to *.exe file