Pro4Never's project tracking thread of ultimate goodness

[jokerboy123]

this cool when u wil releasing it=D?

[pro4never]

Originally Posted by jokerboy123

this cool when u wil releasing it=D?

Definitely not releasing the proxy source but depending on how much i decide to finish up on it I may have a friend host it for me and let a few people use it for testing.

I'd estimate that for basic testing (IF I decide to do that and get hosting) then maybe a week or two minimum? Friend of mine was gonna test it in a few min just to see what I can get working.


So things to be done in the next day or two:

Auto Skill casting (Xp skills mostly)
Bot Attack types split based on activated skill (Fs/Cyclone/Sm)
Magic Attacks (archer bot, etc)
Path System (Sql based using default and custom paths)
Speed Hack
Aimbot
POSSIBLY Met Dove locator (would be easier if I had a character who wasn't a total noob to test with lol)

[© Haydz]

Originally Posted by pro4never

-Check monster mesh so that bad things aren't being hit (guards, patrols, etc)

Admiring the work so far, just going to point this out, I think it's easier to check the UID than the mesh to determine what type of spawn the entity's are, I usually do.

if (UID < 1000000) = Monster else Player

and then just check if the name contains "Guard" if I want to have guards/patrols as a particular type. Seems a bit easier than checking the mesh.

Well done though.

[pro4never]

Yah I already have UID being used to determine if it's a monster or not (if not fatal strike can't hit it so obviously you REALLY want to be careful with what you're adding to your monster dict).

I did the mesh check cause it's quick and simple for my current uses but you're right. Name may be better in the long run. Actually I think my packet reader for name may be messed.. probably was starting at the wrong offset. never went back and fixed it yet.


More Updates:

Handled Entity Update Packet
This means the proxy now knows your hp, mana, level, exp, stamina, xpbar pct and everything else. Makes alot more easy to code.

Handled Auto xp start
When Xp bar is full it now casts your xp skill of choice.
Also resets the datetime for the bot actions so that it's not trying to screw around with attacks/jump mid activation.

Handled auto switching between bot types:
When fatal strike is activated it switches to that bot type, when it runs out it switches back to standard botting.

<edit>
Handled Item Floor
Removal on loot and on disappear
Adding on drop (from players/mobs)
Going to test auto loot functionality next up then combine it with the hunting bot so that they do not interfere.
</edit>

Just working on updating a few more packet offsets then maybe I can FINALLY do some real work on looting and path finding...

[fireTQ]

looks very nice i wish i have all this skills you have to work faster on my own proxy :P , but Ian said im not that good thought :| , will i guess then if i got some problems in mine you would help right ? , so nice for you and good luck to finish it looks like a pretty good one , good luck .

hard work get you what you want
peace ,

oh forgot to thank you alot about your help in my theard and my question .

Originally Posted by Eliminationn

<update>
I found an old 5228 Proxy I have.

oh thanks alot man that would help alot for me

[pro4never]

So this was the initial attempt at superman xp skills. It works quite nicely.

Mini Progress: (My C# trial expired so fighting with getting new version cause old one refuses to uninstall)

AutoXp Use:
Based on your character class it selects Superman/cyclone/fatal strike for auto casting (changeable obviously)

Auto Activate XpSpeed:
In this video I was doing it manually but I simply added that to my auto activation code

Re-wrote bot system Completely:
Checks are so much better now. Not had a chance to test so I'm sure it needs revamping still.

Auto looting:
Not tested but I wrote all the code and it appears to be perfect.


The way I wrote it is that if there is any rare items in range it will temporarily boost your jump/attack delays, wait for a bit (till any existing attacks may be over) and then jumps to rare item and loots it and then sets the speeds back to what they were previously. Should result in NO conflicts between attacking and looting codes.

Dmap checks and speed checks are much more streamlined now (my old code was getting hella messy)

The new bot code is infinitely more modular and organized meaning adding/changing things will be easier.

Planned how to run my clientside GUI to control the bot.

I'm planning on having it be completely separate from any proxy functions but rather have it log into the proxy using your character username/password and if that client is already connected to the proxy then you will then be able to change it's variables and view it's info through the Client side gui. Not sure if that's how others are using it but it SHOULD mean that

A: No one can simply crack the proxy because all proxy functions are SERVER SIDE

B: No muss and fuss with re-writing everything

C: Can literally add anything I want to the GUI without any problems. Just write up my own packets for communication between the server and GUI. Should allow for things to be changed really easy.

Ok: decent amount done today

Monster death handled better (yes... shockingly using Server>client attack packets to remove monsters from the world didn't occur to me sooner lol...)

MUCH better monster targeting handling.

Re-wrote attack code is much less buggy now (now that I've actually been able to test it lol)

Auto loot is working flawlessly. No dc even in xp mode (haven't been dc'd in forever when using it so yah... considering it flawless now :P)

Status update packet is vastly improved including Xp countdown to remove xp status properly (so no more running at xp skill speed when it's already expired. YAY FOR NOT DCING!)

Fixed character coords on login... dunno wtf I was thinking before but I never checked it meaning you had to move before botting or w/e because it would cause problems.

Botting works with multiple users on the proxy at once (yahh... using return statements when you are doing a foreach loop through clients = BAD!!)

Some other random fixes, stabilization and other shit...


QUESTION:

I'm having a big problem with other users logging onto the proxy. I can run multiple characters just fine myself but whenever my friend tries to use the proxy, the second they jump via the auto hunt they get dc'd (seriously, ONE jump)

I can bot their character fine (so it's not some screwed up char ID or something) and they can use the jump packet (tested w/ cmd) but it still does the same thing. I tried boosting the delays between jumps incase it was some odd ping issue but it's still happening.

Any advice from the pr0 proxy makers out there?

Also how the fuck am I supposed to be handling the character status things? In any server source (or even tannels proxy source) I've seen, things such as Superman or w/e are checked such as 0x60000. What I'm receiving is more like 0x40... and from what tiny bit I looked into, it's not being removed or anything later (when the effect stops) so wtf do I do with these values?

Ooh and also: I noticed in some other proxies that for fatal strike they are causing the monsters to be blacknamed/flashing. Is that something so that you can boost the attack speed/reduce the dcing or what exactly are you doing there?

I'm thinking it might be something along those lines as even in xp mode for fatal strike I get dc'd if my jumps are going past 700/750 ms each (I'm considering fatal strike a jump seeing as there is no need to jump to mob and THEN attack.. that's just dumb and gets you dc'd uber fast)

[_tao4229_]

Originally Posted by pro4never

Ok: decent amount done today

Monster death handled better (yes... shockingly using Server>client attack packets to remove monsters from the world didn't occur to me sooner lol...)

MUCH better monster targeting handling.

Re-wrote attack code is much less buggy now (now that I've actually been able to test it lol)

Auto loot is working flawlessly. No dc even in xp mode (haven't been dc'd in forever when using it so yah... considering it flawless now :P)

Status update packet is vastly improved including Xp countdown to remove xp status properly (so no more running at xp skill speed when it's already expired. YAY FOR NOT DCING!)

Fixed character coords on login... dunno wtf I was thinking before but I never checked it meaning you had to move before botting or w/e because it would cause problems.

Botting works with multiple users on the proxy at once (yahh... using return statements when you are doing a foreach loop through clients = BAD!!)

Some other random fixes, stabilization and other shit...


QUESTION:

I'm having a big problem with other users logging onto the proxy. I can run multiple characters just fine myself but whenever my friend tries to use the proxy, the second they jump via the auto hunt they get dc'd (seriously, ONE jump) . . .


I can bot their character fine (so it's not some screwed up char ID or something) and they can use the jump packet (tested w/ cmd) but it still does the same thing. I tried boosting the delays between jumps incase it was some odd ping issue but it's still happening.

Any advice from the pr0 proxy makers out there?

Also how the fuck am I supposed to be handling the character status things? In any server source (or even tannels proxy source) I've seen, things such as Superman or w/e are checked such as 0x60000. What I'm receiving is more like 0x40... and from what tiny bit I looked into, it's not being removed or anything later (when the effect stops) so wtf do I do with these values?

Ooh and also: I noticed in some other proxies that for fatal strike they are causing the monsters to be blacknamed/flashing. Is that something so that you can boost the attack speed/reduce the dcing or what exactly are you doing there?

I'm thinking it might be something along those lines as even in xp mode for fatal strike I get dc'd if my jumps are going past 700/750 ms each (I'm considering fatal strike a jump seeing as there is no need to jump to mob and THEN attack.. that's just dumb and gets you dc'd uber fast)

This is because you're producing an "artificial" timestamp thats based off your computer. The timestamp you're producing is the time (in ms) since your computer has booted. This is conflicting with the timestamps TQed stored of when they've jumped previously (they store it in an attempt to stop speedhackers, which it's detecting your users as).

In order to "remedy" this problem, you need to have the end user send you a timestamp of their PC, and then spoof it from there on out, or replace all of their actual legit packets with your own timestamps (I don't know if you'd need to change the ping timestamp, but that could cause some crazy pings showing up on their client side).

[pro4never]

Ahh that makes sense actually.

So would that mean if i created a 'fake' time stamp i could jump as fast as i wanted server side? (Eg, boost the user's stamp by 700 ms each action).

I'm thinking that maybe i can just pull a time stamp from one of their legit packets and store a stamp per character... or is that just a dumb way of doing it?


Thanks so much for the help.


<edit>

Ok so I'm PART way there with time stamps (I think I need to over-write the incoming ones as well... cause this is getting silly)


My test method (very, very basic) was to set time stamp = 0 on character login, then when receiving general data packet, if the time stamp for that character is 0, set it to the incoming time stamp.

Then in my main bot thread I simply run a foreach loop through connected clients and += their time stamp with the speed of the bot thread (for testing purposes I increased the speed of it so that it runs every 5 ms)

It works in that other players using it can make a few jumps/kills no problems but in the long run it's not a stable method for use.

I'll write a Push version of my function to over-write packets being sent from the client and server and over-write the existing time stamp (I assume that's all it is, another packet being sent from the client or server using a different time stamp that then causes the client to dc)

Anyone in the know: That will work? or am I simply fooling myself here? I'd rather not go and find the time stamp offset for every imaginable incoming/outgoing packet and read-overwrite it if it's not even going to make much/any difference lol.

Also if I boost the time stamp will that then let me run my speed hack properly? (Eg: boost the time stamp by 750 each jump and then send it more often even when not in xp mode?)

In theory it all makes sense but never having done this stuff before, I'd appreciate some advice.


Ooh and I did a TINY bit more on the client (reads input fields, connects to the proxy server and the proxy server receives the connection/sends a packet.

Just need to run server side verification of data and manage the GUI side thread for managing incoming/outgoing packets. After that should be easssyy.







Finally finished up some needed features i was putting off.

TimeStamp: push:
packets being sent and received have their time stamp modified by the proxy (so far i did general data and attack. Is there others that should be done to avoid dcing from messed time stamps?)

Paths:
sql based server path system. This will store default paths people can chose from or they can create/save/load their own eventualy through the gui. Db stores the path id, map, points and path description. They are loaded on server start.

Modified my no mobs in range jump to go towards active point. If within range of point, it will cycle to the next point (or point 0 if at last one). Note, jumps are still random + dmap checker so it doesn't follow an exact route (good imo)

So! This brings me to some minor news that i'm sure no one will find shocking.

Proxy is advancing very quickly so i MAY need a few testers soon. Proxy will be up for very short bits of time in which people can logon and test features/report bugs. It's NOT intended as a fully functional bot yet lol.

Lemme know in the thread if you'd be willing to lend a hand in testing sometime.

Also; i WILL need some help in the long run (the gui, recording paths, building website/databases, etc). No huge packet knowledge is required but you should know what you're doing lol (artists would be awesome cause i fail hardcore at graphics). Pm me or reply if you think the project looks interesting.


Yay for progress!
pro4never



<edit>

So time stamp is still a bit wonky.

For now what I'm doing is over-writing outgoing timestamps using a timestamp from the proxy... it's working for now and others are botting just fine but in the long run that will need to be changed.

REQUEST
Any advice on the best way to do a PROPER time stamp system? (So that I can run speedhack and such without running into issues)

I just need to modify outgoing TimeStamps correct? or will that run into problems?

Path system is sorta... ok... it works in that it keeps you within a certain area and it hunts much more efficiently but it needs tweaking so that you go more directly to the next point.


Ninja hunt speed is still slow. I assume this is due to timestamps? What's the best way to run ninja hunting at a decent speed? as it is right now I can't use fatal strike any faster than ~700 ms.... which is strange cause I could have sworn my speed was faster than that before.

What I'm doing right now for fatal strike is

If mob inrange && last attack was more than jump speed ago

send attack packet/set char coords to mob x/y (shifted for mob direction)

So past that I SHOULD just need to boost time stamp and that will let me attack faster? or am I just confusing myself here?

[princeofpain]

You actually don't need speed hack to get to monsters fast with fatal strike, you can simply send the attack packet and fs will warp you to the monster.

I have my proxy set to 80 ms delay between attacks (that's without all the calculations overhead included) and its fairly stable.

For pathfinding, the A* algorithm is working wonders for me, it can navigate its way through grotto in a few ms.

"Timestamp pushing" is a really interesting idea, it might be a way around that limit they put on fatalstrike. You wanna collaborate with me on msn? Send me ur msn via PM haha.

Oh btw, the way I'm speeding doesn't require time stamps.

[pro4never]

Originally Posted by princeofpain

You actually don't need speed hack to get to monsters fast with fatal strike, you can simply send the attack packet and fs will warp you to the monster.

I have my proxy set to 80 ms delay between attacks (that's without all the calculations overhead included) and its fairly stable.

For pathfinding, the A* algorithm is working wonders for me, it can navigate its way through grotto in a few ms.

"Timestamp pushing" is a really interesting idea, it might be a way around that limit they put on fatalstrike. You wanna collaborate with me on msn? Send me ur msn via PM haha.

Oh btw, the way I'm speeding doesn't require time stamps.

Yah i'm simply sending the attack packet during fatal strike, nothing else... for some reason though, with the last attack script i wrote it would dc if i went past like 700 ms on attacks..


Ii'll be using a* eventually i'm sure but my current system is independent of method. It consists of db stored list of points which are then loaded into the server as a dictionary (path id and points). the first pt is selected from the path, if no mobs are i range if finds a random coord closer to the target pt and jums there. If within 12 range it cycles through to another pt. The only thing that needs changing is the coords to get there. I'm sure i'll use a*... that's down the road though.


Normal timestamp pushing is working fully for me.. boosting it does not seem to be.

As it exists, i overwrite every user's timestamp for client>server general data, attack and walk using my own computer's time.. artificially boosting it does not seem to work in my tests but i didn't do much yet. Pm me your msn and i'll try to add you next time i have nnet (phone atm). This project is semi on hold because i just got a job and am rather busy irl. I'm sure i'll get back onto it soon though.

[DeathByMoogles]

It deeply saddens me that I do not currently possess the knowledge to contribute anything to p4n or clint.

pro, I'm thinking that I'll go with c++ for my proxy (mostly because the dll imports are easier), Is this the right choice?

Also, what's the first thing I need to do coding wise?
I pretty sure I need to do something with winsock to redirect the connection to 127.0.0.1 but not totally sure, and If that is INFACT the case, then what do i need to do to achieve that? (I'm sorry to bug you, It would help if i had any coding experience with c++, but its all vb.net, which is loosely related to c# which would make it seem like c# would be the better choice but i have always had problems with people opening my projects made in vb.net due to lack of the right .dll's which i could never seem to remedy and therefor by extension it is forseeable that I might have the exact same problem with c#)

If you don't understand all that, I'm sorry im a spontaneous writer and a lot of times my ideas and thoughts trickle together in no discernable fashion whatsoever.

Sincerely
,Prodigy.

[pro4never]

Originally Posted by DeathByMoogles

It deeply saddens me that I do not currently possess the knowledge to contribute anything to p4n or clint.

pro, I'm thinking that I'll go with c++ for my proxy (mostly because the dll imports are easier), Is this the right choice?

Also, what's the first thing I need to do coding wise?
I pretty sure I need to do something with winsock to redirect the connection to 127.0.0.1 but not totally sure, and If that is INFACT the case, then what do i need to do to achieve that? (I'm sorry to bug you, It would help if i had any coding experience with c++, but its all vb.net, which is loosely related to c# which would make it seem like c# would be the better choice but i have always had problems with people opening my projects made in vb.net due to lack of the right .dll's which i could never seem to remedy and therefor by extension it is forseeable that I might have the exact same problem with c#)

If you don't understand all that, I'm sorry im a spontaneous writer and a lot of times my ideas and thoughts trickle together in no discernable fashion whatsoever.

Sincerely
,Prodigy.

Ok well I can't really be of much use when it comes to C++ as I've completely avoided it as of right now. To be honest it intimidates me... I tend to find something I like and stick with it... It being C#, I've used it enough that I'm comfortable working with it so I really have no real desire to switch right now. I'm sure I will eventually if I keep moving on to harder stuff.

The very simplest thing I'd suggest doing as a 'way to learn' would to be create 2 very simple programs. a client and a server. This way you can experiment with creating connections, sending packets, receiving packets and some basic stuff on threading (depending on if you are using sync or async sockets... which tbh I stick to simple ones because I understand them)


It's VERY simple to do in C#, if you decide to I'd suggest taking a look at a old coemu login server (they are very basic and all they really do is listen on a port and then create a new client thread/handle a few packets).

All you really need to do is specify your socket type (stream, tcp, etc), specify a port and then bind to the ipe (basically blocks off the port). Then create a thread that listens for new connections every x milliseconds. If a client connects then create a new client thread to handle it (that way you have it listening for packets every x ms and also gives you the ability to send packets back and such easily.

NOTE: Using this method for sockets means you are creating a thread per client! (Plus your overhead). This will work perfectly fine for limited users but if you are wanting to create something that allows for many hundreds/thousands of users to connect at the same time... then use async which does not require its own thread. For learning purposes or small numbers of users (i'd say under 100 or so?) then this should work just fine.


In my old 'learning' proxy (I basically just finished up login sequence and some basic encryption), I simply accept the connection, then connect to the tq game server and create a "auth thread' for that client which would listen for info from the client (Client<>proxy side) and would connect to tq auth servers (Proxy<>Tq Auth Server side). That way you can send and receive data from both sides.


That's your FIRST step. After that you need to worry about encryption, handling the login packets, CHANGING the one that's returned to the client (because it contains the game server ip/port assuming it's a successful log). By changing this you re-direct the connection back to the proxy to start on the game server side of things... which functions quite similarly except is more complicated because you need your DHKey exchange, blowfish, LOTS more packets and of course your botting features/scripts.



That being said... there is TONS of information posted in the sticky in this section. If you have any specific questions I'd recommend asking there rather than my thread.






------------------------------------



Project(s) update:


I've gotten a job and been super busy irl. That + no net at home and having been slightly burned out from my last revamp means proxy has basically been on hold... I could see it advancing again some time soon though.


As for the 5280+ custom pserver source... I haven't really done much there either although yesterday I got bored and started on a custom login server for it (which is laughable seeing as I had no net so couldn't log any packets... so basically right now it's just some socket connections and a few cs files)... that being said the fact that I started doing something on it at all probably means next time I'm bored I'll smack myself and do some real work on it.

[HolyMaker66]

Grats on your job, and you made alot of progress, can't wait for your proxy to be done.

[pro4never]

Well proxy still exists but I'm not exactly using it anymore. Some packet logging and that's about it lol.

The good news is... HELLMOUTH IS RETURNING!


We are working on a custom 5290+ source from the ground up. This is going to take some time but should allow us to do some really cool stuff.

Follow us on twitter for progress updates:


Subscribe to us on youtube for media updates:


Visit the project tracking thread on epvp for all sorts of links, chat, goodies and updates!

[Die Schnittstelle]

If you stopped this project I may close here.