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.
Results 1 to 31 of 31
Thread: I've been inspired.
- 13 Oct. 2012 01:56am #1
I've been inspired.
- 13 Oct. 2012 02:15am #2
Feel free to peer in on me. My current join.me link is below.
My Current Join Me:
Code:https://secure.join.me/609-284-641
Code:https://github.com/ScriptProdigy/nF
- 13 Oct. 2012 02:48am #3
- 13 Oct. 2012 03:05am #4
I'll be keeping an eye out for you.
- 13 Oct. 2012 03:11am #5
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?
- 13 Oct. 2012 03:29am #6
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.
- 13 Oct. 2012 03:42am #7
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.
- 13 Oct. 2012 04:58am #8
Should open source it. Speaking of which, I'm following you and the Logicalgamers account on Github.
https://github.com/Protozoid/
- 13 Oct. 2012 04:59am #9
- 13 Oct. 2012 05:01am #10
Well, that response was certainly fast. But yeah, will look out for it.
- 13 Oct. 2012 06:44am #11
I'll bet my house nothing eventuates from this.
- 13 Oct. 2012 06:50am #12
- 13 Oct. 2012 06:57am #13
To be fair, I read the title, had a quick peruse of the thread to understand its context, and came to my conclusion.
- 13 Oct. 2012 03:32pm #14
- 13 Oct. 2012 03:39pm #15
- Join Date
- Apr. 2010
- Location
- When freedom is outlawed only outlaws will be free
- Posts
- 5,113
- Reputation
- 195
- LCash
- 15.00
Sounds cool, can't wait for the source, so I can actually understand some of this shit
EDIT: Your joinme is down
- 13 Oct. 2012 03:48pm #16
- 13 Oct. 2012 03:58pm #17
This is sort of what I want, how easy it should be.
Code:#### ## 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)
- 13 Oct. 2012 04:08pm #18
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!
- 13 Oct. 2012 04:45pm #19
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:
Code:## Recover packets from established socket with allocated buffer sock = testing.connect(server, ip) testing.sniff(sock, 1024)
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.Last edited by The Unintelligible; 13 Oct. 2012 at 04:57pm.
- 13 Oct. 2012 04:52pm #20
- 13 Oct. 2012 05:04pm #21
- 13 Oct. 2012 05:06pm #22
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.
Good idea. Faster than writing an entire dedicated sniffer for sure.
- 13 Oct. 2012 05:38pm #23
- 13 Oct. 2012 06:20pm #24
- Join Date
- Apr. 2010
- Location
- When freedom is outlawed only outlaws will be free
- Posts
- 5,113
- Reputation
- 195
- LCash
- 335.00
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
- 13 Oct. 2012 06:27pm #25
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.
- 13 Oct. 2012 08:08pm #26
- Join Date
- Apr. 2010
- Location
- When freedom is outlawed only outlaws will be free
- Posts
- 5,113
- Reputation
- 195
- LCash
- 547.00
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.
- 14 Oct. 2012 03:17am #27
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.
- 14 Oct. 2012 04:34pm #28
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#.
Code:http://www.valuedlessons.com/2008/04/events-in-python.html
- 14 Oct. 2012 05:06pm #29
- Join Date
- Apr. 2010
- Location
- When freedom is outlawed only outlaws will be free
- Posts
- 5,113
- Reputation
- 195
- LCash
- 209.00
- 14 Oct. 2012 05:06pm #30
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.
- 14 Oct. 2012 05:44pm #31