I've been inspired.

With all this me being active for around 5 posts.. I'm going to devote some time this weekend to programming some shiz and maybe releasing what I do. I guarantee it will never be finished however.

Feel free to peer in on me. My current join.me link is below.

My Current Join Me:

https://secure.join.me/609-284-641

The Github Repo:

https://github.com/ScriptProdigy/nF

Btw, its a zOMG client

I'll be keeping an eye out for you.

The Unintelligible wrote:

I'll be keeping an eye out for you.

Not sure how I want to organize the packet handling class.. This is really difficult to decide upon, considering there are like 30 packets send/received before you ever show up on the map. In my old class I had the startup hard coded. Which worked 75% of the time but broke sometimes and you had to restart it. Bit of a pain, don't like it hard coded either.

EDIT::

Also, I don't want to send any packets directly from the main class, it's nasty. I want the main class to be super easy to do things so I can change that fairly quickly and have a very different zOMG bot. Yah know?

My head feels weird today, so I may sound a bit off but here's my take.

I'd go with a simple black box abstraction model where all the internal work is hidden in classes or some form of abstraction and only the main logic/program flow is exposed. It's actually a pretty common style, especially in OO languages.

But for the packets specifically set up a packet stack to where different packets are handled individually (i.e. if [packet 6] do stuff, elif [packet 9] do stuff, etc). That's the cleanest way to manage/organize packets that I can think of any way.

Your setup has to be pretty cohesive to write something like this immaculately.

Yea, my current hierarchy is:

main -> GZL (GaiaZomgLib)
GZL -> GSI
GZL -> PacketHandler

where, packethandler will handle the packets, gsi handles gsi, and gzl is the middle man between main and the rest of everything.

Should open source it. Speaking of which, I'm following you and the Logicalgamers account on Github.

https://github.com/Protozoid/

The Unintelligible wrote:

Should open source it. Speaking of which, I'm following you and the Logicalgamers account on Github.

https://github.com/Protozoid/

I'll make the git repo tomorrow and push it.

Well, that response was certainly fast. But yeah, will look out for it.

I'll bet my house nothing eventuates from this.

Artificial wrote:

I'll bet my house nothing eventuates from this.

MattSmith wrote:

I guarantee it will never be finished however.

It never fails. It never fails..

To be fair, I read the title, had a quick peruse of the thread to understand its context, and came to my conclusion.

Artificial wrote:

I'll bet my house nothing eventuates from this.

MattSmith wrote:

I guarantee it will never be finished however.

This. Haha, I guaranteed it will never be finished. But I need something clean to impress people so who knows. Maybe I will finish this. Lol, what the fuck am I saying..

Sounds cool, can't wait for the source, so I can actually understand some of this shit

EDIT: Your joinme is down

Flareboy323 wrote:

Sounds cool, can't wait for the source, so I can actually understand some of this shit

EDIT: Your joinme is down

Yea I know, I was setting up the git repo and pushing the initial commit to github. Check now

This is sort of what I want, how easy it should be.

        ####

        ## This is what I want to be able to do. This friggin' easy.

        ####

        self.GZL.startup()

        while(True):

            Pos = self.GZL.get_position()

            Sel_Mob = self.GZL.get_nearest_monster(Pos)

            self.GZL.attack(Sel_Mob)

Another quick update:

I think I'm going to write a sniffer that will decode the zOMG packets automatically so I don't have to decrypt them manually anymore.. I'll do it in C# because intercepting packets should be easy in this, decoding may be difficult but we shall find out!

MattSmith wrote:

Another quick update:

I think I'm going to write a sniffer that will decode the zOMG packets automatically so I don't have to decrypt them manually anymore.. I'll do it in C# because intercepting packets should be easy in this, decoding may be difficult but we shall find out!

Overkill. Try building a testing unit instead. Preferably in Python as a class or something. A sniffer would be pointlessly unnecessary in this case.

Something like so:

## Recover packets from established socket with allocated buffer



sock = testing.connect(server, ip)

testing.sniff(sock, 1024)

I may write it up and give you a push request. This is given I have the time though.

Edit: There might be a few advantages to using an external sniffer. It just seems redundant to me. Whatever you decide to go with I guess.

The Unintelligible wrote:

Overkill. Try building a testing unit instead. Preferably in Python as a class or something. A sniffer would be pointlessly unnecessary in this case.

Something like so:

## Recover packets from established socket with allocated buffer



sock = testing.connect(server, ip)

testing.sniff(sock, 1024)

I may write it up and give you a push request. This is given I have the time though.

I have it mostly written already, just have to implement decoding the data.

Eh, can't find a lib for amf so I'm going to just save the packets to a file then write the decrypting in python.

MattSmith wrote:

I have it mostly written already, just have to implement decoding the data.

Should be pretty easy henceforth then. Comparatively that's the simple part (setting up the interceptor and such is usually considered the "hard" part).

Wonder how you're going to top WPE/Wireshark's intuitiveness, though.

MattSmith wrote:

Eh, can't find a lib for amf so I'm going to just save the packets to a file then write the decrypting in python.

Good idea. Faster than writing an entire dedicated sniffer for sure.

Taking a break, got to get some school work done. Wireshark is pissin' me off so I'll deal with stuff laters.

Man, it would be awesome if you could give me a runthrough of all this stuff or something, I've always wanted to make flash bots, but have never been able to

Flareboy323 wrote:

Man, it would be awesome if you could give me a runthrough of all this stuff or something, I've always wanted to make flash bots, but have never been able to

They aren't flash bots lol. They're clients for games. Flash things usually just involve variable editing or some means of manipulating Flash.

Making clients take a bit of knowledge of client & server/TCP/networking/sockets/etc. No one can just instill the ability to make bots/clients into you. It's something that takes time and practice.

The Unintelligible wrote:

They aren't flash bots lol. They're clients for games. Flash things usually just involve variable editing or some means of manipulating Flash.

Making clients take a bit of knowledge of client & server/TCP/networking/sockets/etc. No one can just instill the ability to make bots/clients into you. It's something that takes time and practice.

Well I know that, but when I say "Flash bot" I mean everything from bot, to trainer, to client. And I know, but if I just see some source and get into it, learning and experimenting with the rest becomes easy, and only takes time instead of 100% concentration on it.

Back at it again, not sure how long I'll be on but I'll be on at least for a few.

@Flare - It's not really a trainer or anything. You can consider it a client that has been made from reverse engineering the original one. Just figuring out how they handle their packet structure and you are golden.

Alrighty so, I think I've figured out how I'm going to handle incoming packets and such. EVENTS! Yes, I know python doesn't natively support events but because python is so fucking incredible, 26 lines of code will implement the same exact event structure of C#.

http://www.valuedlessons.com/2008/04/events-in-python.html

Anyways, events should allow me to make it nice and clean! Especially the startup packets!

MattSmith wrote:

Back at it again, not sure how long I'll be on but I'll be on at least for a few.

@Flare - It's not really a trainer or anything. You can consider it a client that has been made from reverse engineering the original one. Just figuring out how they handle their packet structure and you are golden.

I have no idea how to find out how they handle packets o-o but anyways, what will said client do?

Events? That's usually for GUIs or widgets (i.e. ON_CLOSE). I mean, they could probably be applied elsewhere but as far as practicality and usefulness goes, I'm not sure how far you'll go.

I guess we'll just have to find out.

The Unintelligible wrote:

Events? That's usually for GUIs or widgets (i.e. ON_CLOSE). I mean, they could probably be applied elsewhere but as far as practicality and usefulness goes, I'm not sure how far you'll go.

I guess we'll just have to find out.

If you take a look at gaia's zOMG client, it's all handled with events as well. And the more I thought about it, its a good idea.