Thoughts on a proxy-based bot-making API?

[unknownone]

Ok, I've had an idea for some time to make a proxy that beginners can code with, and isn't a hell of a mess like qoproxy and derivatives are. The idea I've come up with is a library where all networking code, packet serialization, login, authentication etc is hidden from the coder in a static lib or DLL. This also has other advantages, such as sharing code for bots, and not having to update your own bots if TQ decide to mess something up, you'd just need an updated version of the API.

The API will expose an event driven OOP interface that really anyone with some knowledge of C++ should be able to use. Each received packet will trigger it's own event, and the packet all have their own classes with meaningful names and properties.
I've designed it to be as simple as possible while hiding everything so people can't break their own bots. You need no knowledge of networking because it's all done for you. Project is currently named blacknull, but it's open for change.

Anyway, as an example of what a bot will look like, here's a 5 minute thing I made. It's basically an auto messager that'll reply to anyone with a custom message when they whisper you in game. You'd activate the bot by typing "/autoreply I'm currently afk", and deactivate it with "/noreply". The code below is very simple, if you don't understand it, start learning C++ perhaps before you ask any questions.

/* auto_reply_bot.cpp
 This is the primary code file you'll be editing to fit in your packet events and sending packets.
*/

#include "auto_reply_bot.hpp"

#include <string>

namespace auto_reply_bot
{
    std::string* auto_reply; //var to hold our auto reply message
    bool auto_reply_on=false;

    client_packet_event::client_packet_event()
    {
        // the register_event() function is required to overide the internal handle for these packets.
        // you must register each packet you use for code to work, everything else will be forwarded by the api.
        register_event(CHAT_PACKET);
    }

    void client_packet_event::on_chat_packet(chat_packet* chat)
    {
        if (chat->is_command()) // is_command() returns true if the chat message begins with "/"
        {
            if (strcmp((const char*)chat->strip_command(),"autoreply")) // strip_command() returns the string that follows a "/"
            {
                auto_reply = chat->strip_args();  // strip_args() returns the rest of message after the command.
                auto_reply_on = true;
            }
            if (strcmp((const char*)chat->strip_command(),"noreply"))
            {
                auto_reply_on = false;
            }
        }
        else send_to_server((packet*)chat);
    }


    server_packet_event::server_packet_event()
    {
        register_event(CHAT_PACKET);
    }

    void server_packet_event::on_chat_packet(chat_packet* chat)
    {
        if (auto_reply_on)
        {
            if (chat->chat_type()==WHISPER)
            {
                chat_packet reply;
                reply.msg_from(my_hero->name);
                reply.send_to(chat->msg_from());
                reply.chat_type(WHISPER);
                reply.message(auto_reply);

                send_to_server((packet*)&reply);
            }
        }
        send_to_client((packet*)chat);
    }
}

/* auto_reply_bot.hpp
 Header file for the bot, you can add to this, but needn't worry about
 what is already written here, it will be auto-generated from a template.
*/

#include <blacknull.hpp>

namespace auto_reply_bot
{
    using namespace blacknull;

    class client_packet_event : public packet_event
    {
        public:
            client_packet_event();
            virtual ~client_packet_event();
        private:
            void on_chat_packet(chat_packet*);
            void on_hero_info_packet(hero_info_packet*);
            void on_create_character_packet(create_character_packet*);
            //.. on_other_packets_etc(...)
            //... Will contain a full list of client packets eventually

    };

    class server_packet_event : public packet_event
    {
        public:
            server_packet_event();
            virtual ~server_packet_event();
        private:
            void on_chat_packet(chat_packet*);
            void on_spawn_packet(spawn_packet*);
            //.. Will also contain a completed list

    };
}

Once you have all your logic in place, starting up the bot is simple. You need to pass the packet event classes above to it so the API knows about your newly coded methods. This will be an auto generated start file for your bots, but you're free to edit it if you want.

/* main.cpp
 Auto generated file to start up the basic proxy.
*/

#include <blacknull.hpp>
#include "auto_reply_bot.hpp"

using namespace blacknull;
using namespace auto_reply_bot;

int main(int argc, char* argv[])
{
    proxy_config* config = new proxy_config();
    config->local_auth_ip("127.0.0.1");   //This is uneccessary since localhost is the default in the api
    config->local_game_ip("127.0.0.1");   //Just to demonstrate other IPs can be used instead.

    packet_event* client_events = new server_packet_event();
    packet_event* server_events = new client_packet_event();

    proxy* co_proxy = new proxy(config, client_events, server_events);
    co_proxy->run();
}

Ok, so that code alone is for demonstration and useless without the blacknull API , but eventually it should work when the API is complete. There's already code in place, the packet encryption is no problem at all. Infact, most of the work is documenting it. I'd say it's about 50% complete anyway, but before I finish things off, I'm interested in some feedback. Particularly, will anyone use it? What would you change to make it easier to use? Are there any specific features you think it should contain? At the moment this is only working for a single client, but the plan is to handle many. In that case, I'm after opinions on how best to handle that, will you want to create your own packet_event classes for each seperate bot, or would you prefer to handle seperate clients by checking the hero_id on incoming packets, or do you have another idea?

Anyway, please take some time to look over the above code and gimme your comments if you're interested. I won't guarantee I'll finish this until I get some feedback. There's another coder who has worked on it so far, but not sure if he is interested in doing more.


On a side-note, I have a simple binary-packet-editor that uses blacknull, it's almost ready for release but a few bugs need fixing. The UI is somwhat based on behelit's CoProxy, and it has practically the same functionality. It's cross platform as it's using wxWidgets, and blacknull is designed to be portable too.

[nTL3fTy]

Haha, seems like everyone's server has a problem with Egyptians except mine.

Nice idea and looking forward to updates.

[Some-Guy]

It's a very nice idea, however it's similar to what Bone-You tried to accomplish with XProxy, in that case no one showed enough interest to put any effort in to it. The difference obviously being that this time there are no working public releases like v3nom

The syntax seems fairly simple as long as the functions are fully documented which I'm sure they would be.

Although personally I would prefer working with the raw packet data the method you are using would make it easier on the users with no past experience of (coding/editing/anything but using) proxies.

<3 packet editor.

P.S did I mention we all love you lots? well I did now.

[Real~Death]

I'd love a working packet sender. behelit's crack/Coproxy is my favorite CO program(been using coproxy for years befor he released updated crack),without being able to play with packet the game is a lot less fun,thats one of the reasons i quit playing a few months ago.

C++ is more advanced then 95%+ of the ppl here,My self included.crack/sacob got me real intreased in programing and made me learn VB,So this will do the same and get me to learn C++.

Im starting on the leason's from the link you posted tomorrow.Cant wait for a update on this,and more info on how it's going to work

[raptordin]

This is a lovely thing. I am a programing noob so I can't help much but as for Ideas I will add my 2 cents.

1- Not AimBot Please.
2- Autoloot & AutoHunt.
3- AutoDC on Blauers or Blu, red, BlackName and GM's.
4- Reduce the teleportation speed so it will not be so obvious for onlookers.
5- AutoDC on HP (So bot will not Die).
6- Show Names of Players on top left of screen (Like Cotobo).
7- Show Quality Items on Top Right of Screen (Like Cotobo) (You should be able to chose which quality Items).
8- AutoPath finding based on preset cordinates (Could be configured in a separate INI File).

9- Again, Please No AimBot.

p.s. Started reading on C++ and if I can I will try to help (Full Time Job and a wife is very time consuming).

[Some-Guy]

Originally Posted by raptordin

This is a lovely thing. I am a programing noob so I can't help much but as for Ideas I will add my 2 cents.

1- Not AimBot Please.
2- Autoloot & AutoHunt.
3- AutoDC on Blauers or Blu, red, BlackName and GM's.
4- Reduce the teleportation speed so it will not be so obvious for onlookers.
5- AutoDC on HP (So bot will not Die).
6- Show Names of Players on top left of screen (Like Cotobo).
7- Show Quality Items on Top Right of Screen (Like Cotobo) (You should be able to chose which quality Items).
8- AutoPath finding based on preset cordinates (Could be configured in a separate INI File).

9- Again, Please No AimBot.

p.s. Started reading on C++ and if I can I will try to help (Full Time Job and a wife is very time consuming).

Clearly you mis-interpreted or just didn't read what was said. The idea of this is that unknownone provides the framework and then other users develop modules for it, so depending on which packets the framework allows you to take data from it would be entirely possible for an aimbot module to be released and I expect it would be.

Also on point for you would be referring to v3nom, the teleport there was only client side, others saw you jump.

[raptordin]

Originally Posted by Some-Guy

Clearly you mis-interpreted or just didn't read what was said. The idea of this is that unknownone provides the framework and then other users develop modules for it, so depending on which packets the framework allows you to take data from it would be entirely possible for an aimbot module to be released and I expect it would be.

Also on point for you would be referring to v3nom, the teleport there was only client side, others saw you jump.

Thanks for the clarification. My bad.

as for the 2nd point, I have tested all proxies starting from QO the original, they all show you as Jumping extremely fast and Jumping in place for a split second.
For any one who knows anything, it is clear you are auto looting/Hunting.

I presume if it was on a shorter cycle, it could be less evident.



Thanks again for clarifying point One.

[unknownone]

Originally Posted by Some-Guy

IThe syntax seems fairly simple as long as the functions are fully documented which I'm sure they would be.

Although personally I would prefer working with the raw packet data the method you are using would make it easier on the users with no past experience of (coding/editing/anything but using) proxies.

I'm not sure why anyone, even well experienced programmers would prefer to work with raw packet data. I've compiled a list of all the packets and every field to save you time doing it yourself, and without having to worry about serializing them, particularly the ones that aren't fixed size. All the memory allocation and deallocatoin is done internally. I'll document all the packets, and you'll even have access to the code for some of it. Here's an example of what one looks like.
If you really must insist on wasting time though, you'll be able to override the on_packet_received() method in the packet_event class, and do everything manually.

#ifndef LOGIN_PACKET_HPP
#define LOGIN_PACKET_HPP

#include "base_packet.hpp"
#include "packets.hpp"
#include "../crypto/password_encryption.hpp"

class login_packet : public packet
{
    public:
        login_packet() : packet(LOGIN_PACKET, 52);
        virtual ~login_packet() {};

        void username(std::string username)
        {
            write<const char*>(username.c_str(), 4, 16);
        }
        std::string username(void)
        {
            return = read<const char*>(4);
        }
        void password(std::string password)
        {
            write<const char*>(password_crypto.encrypt(password.c_str(),16), 20, 16);
        }
        std::string password(void)
        {
            return password_crypto.decrypt(read<const char*>(20)),16);
        }
        void server(std::string server)
        {
            write<const char*>(server.c_str(), 36, 16);
        }
        std::string server(void)
        {
            return read<const char*>(36);
        }
    protected:
    private:
};

#endif // LOGIN_PACKET_HPP

You have a valid point with XProxy, but I'm hoping to make this a bit more simplistic with a clear documentation, yet still very powerful. Rather than trying to combat the latest encryptions yourself, it'd be easier to just use an API that does it for you. It's not just for beginners either, well experienced programmers would find advantage in using this API, because it'll save them time and effort. And as already mentioned, if TQ mess something up, it'll take a small community effort to fix every bot in one go.

If you still have a reason why you'd prefer to make your own bot other than for the learning experience, I'd like to hear it. I don't see where you'd go wrong here though. Performance is better than C# or Java could ever hope for. It's cross platform out of the box, so if you wanna run the proxy off a server, no problems. And it'll be updated asap whenever needed. I'll pass the whole project to someone else if I can no longer keep up with it.

[Some-Guy]

Originally Posted by unknownone

It's not just for beginners either, well experienced programmers would find advantage in using this API, because it'll save them time and effort. And as already mentioned, if TQ mess something up, it'll take a small community effort to fix every bot in one go.

Of course a c++ release would also run a lot smoother than the vb6 source releases that have been seen here before and without having to worry about the messy code of QOProxy, so also a plus.

Originally Posted by unknownone

If you still have a reason why you'd prefer to make your own bot other than for the learning experience, I'd like to hear it. I don't see where you'd go wrong here though. Performance is better than C# or Java could ever hope for. It's cross platform out of the box, so if you wanna run the proxy off a server, no problems. And it'll be updated asap whenever needed. I'll pass the whole project to someone else if I can no longer keep up with it.

I didn't mean I'd rather start from scratch, was just curious whether the option to work with raw packet data would be included, always nice to see how things are working behind the pretty front end from time to time and it's just how I was used to working on my previous projects.


Anyway, as I said in my first post I think it's a great idea and hope it goes well.

[Real~Death]

just wanted to say thanks unknownone for coming back and helping out the CO ppl here on epvp again.Your a board legend

[trash]

I'll be suprised if the gods of epvpers dont want this to go to the underground, seems to me they like to keep anything usefull/good away from the unworthy masses.

[tanelipe]

UG doesn't have "all" the goodies it's more of talk there. :P

What you describe would be the Level 2-3 (Does level 2 still exist?)

P.S I don't remember CID Proxy being released for underground members only? Or it could just be my memory doing tricks.

[Some-Guy]

Underground is more of a place where we are able to discuss the methods behind programs in order to better them, it has no effect on whether people decide to release their tools to the public or not. If someone wants to release a program it will be released, if it was stopped here it would likely be posted elsewhere. But I doubt very much it would be stopped here (even if it was completely open-source, look at QOProxy).

[trash]

ok i stand corrected, I guess its just the way it looks from the outside seeing a few posts in other threads taken from underground containing great useful info then you look at the CO2 Main Discussions / Questions or CO2 Exploits, Hacks & Tools sections and you mainly have people wanting or outdated info/tools maybe its just me being a cone head ima stop hijacking this thread and shush.

peace all.

[Real~Death]

Originally Posted by tanelipe

What you describe would be the Level 2-3 (Does level 2 still exist?)

nope no more lvl 2/3, A1 told me the UG was like a test to see if anything good would come from a private user group(non public),If so lowfry might revive it

Originally Posted by trash

ok i stand corrected, I guess its just the way it looks from the outside seeing a few posts in other threads taken from underground containing great useful info then you look at the CO2 Main Discussions / Questions or CO2 Exploits, Hacks & Tools sections and you mainly have people wanting or outdated info/tools maybe its just me being a cone head ima stop hijacking this thread and shush.

peace all.

there is a lack of trust in the UG when queen leaked the first UG only crack to another site(she got banned),it created a problem,There isnt anything there that isnt already public,but give ppl a place to ask questions -experienced user's helping outher experienced
users-

anyway we are geting off track in this thread,this is about blacknull and spoon proxy