• You've discovered RedGuides, an EverQuest multi-boxing and scripting community 🧙‍♀️⚙️. We want you to play several EQ characters at once, come join us and say hello! 👋

  • A TLP without truebox has thawed (Very Vanilla ready)
    Frostreaver

Packet Obfuscation

Arlyh is better, but it's in mq2, we'll have keep adding back, cause MQ isn't going add anything back into the compile.

Here's mine for plugin
 
Last edited by a moderator:
I couldn't find anything. I spent a few hours with a debugger looking at all of the variables near the functions at CObfuscator__doit and 0x004BAD00. There are multiple variables that contain the same value near 0x004BAD00 which are decremented by one, and incremented by one again in the obfuscation function. The word is that there is a variable somewhere that contains the number of packets that should be exchanged, but it's difficult to tell how exactly that number is determined. I have a number of ideas, the simplest being to use the function at 0x004BAD00 to send packets instead of the one at 0x004B6620. This has the added benefit of packet obfuscation being transparent. I haven't tried this approach.
 
Hmm, would it be possible to find out where the packets originally start getting put together by the client and hook through that, giving the client the info that it would normally get from another area? If you did it this way, then it might be possible that you wouldn't have to rewrite/reverse engineer the whole obfuscation/encryption code.
 
0x004A7D10 is the interface between the UI and the function that sends packets. The obfuscation code doesn't need to be rewritten, we already have a fix for that. There's word out that there may be up to three separate counters that give information on the number of legitimate packets that should have been passed between the client and server. I haven't found it and I don't know of anyone else that has. So that's what we want to look for. If it exists, it has to be somewhere between the two functions I mentioned in this post.
 
Ok buddy got his working 3 nights ago I tested out with ghost kills 3 nights ago I cleared all of anguish with a 75 monk and still account active. Working on doing some warps today when he gets off and trying a couple things the time isnt 48 min its 30 and he has it so it searches cause supposeable the packets are changing the location line of the id of the packet. I donno he sending me the source and I will post it when he gets in at work. Hopefully this be the fix. But I know it will work so far. We see who gets this if it works i will be posting the .DLL for users. Source will remain mine.
 
Ok Well my monk hasnt been banned buddies has been but he also bought his monk to test and he did all of anguish no problem and went into open zones and was killing via ghost and was suspended today. So hrm...
I am going to try anguish 1 more time when lockout done and see if that as long as isnt open zone issue but I dont know he thinks that they are able to see id's and they have a duel system check for certain packet id.
He breaking down everything today and we see what changes per my banning with my monk that I bought to test with and the new monk that works. And his monk that he bought and was banned. So hopefully will give some insite here.
 
These monks you bought? Possible they were already flagged for hacking? How many peeps would do their best to unload an acct. if they knew odds were high they would be banned? just a thought.
 
Aye That is also another thing but these monks we got were pretty gimp but yeah thats another option buddy though has been scanning and saving copy of every packet and running it through some variable finder. to see if there any kind of common occurance. But you are absolutely right. =) hence why i been working on another monk but pling is a pain so i am going to try to ghost smaller adventures and missions to see if works.
 
Here is the packet for ya. Nomal packets send:

PHP: 
85 A5 01 40 3A 5B 11 58 00 00 00 00 00 00 00 13  ...@:[.X........
D9 AF BF 00 00 90 7C 7E CF 33 C2 00 00 00 00 39  ......|~.3.....9
05 91 7C 00 00 00 00 58 E6 3D 40 82 C8           ..|....X.=@..
to IP address :
Rich (BB code): 
199.108.9.157:1376

Then the third party tracer packet every 3 min:
PHP: 
00 06 1E 88
to ip address :
Rich (BB code): 
199.108.3.4:9875


When MQ loaded : there 2 changes then normal packet sending
PHP: 
03 5A 78 9C 63 61 10 95 6B 3F C4 C0 29 61 B9  ..Zx.ca..k?..)a.
C8 A8 EE BC F1 21 E1 9B EB F7 DF 57 7A ED C0 28  .....!.....Wz..(
7A EF 93 16 4C E0 41 F1 1B 07 C6 C6 7B 9F 51 04  z...L.A.....{.Q.
98 5E DD FB 02 17 B8 0D D2 12 75 FF 1B 5C E0 69  .^........u..\.i
EB 0B 07 C6 63 F7 BF C3 05 58 B6 3F 71 60 34 7A  ....c....X.?q`4z
F0 03 2E F0 FF F6 7D 07 C6 F9 0F 7E C2 05 7C C4  ......}....~..|.
6F 39 30 72 3F FC 05 17 D8 B2 E7 B2 03 63 F9 C3  o90r?........c..
DF 70 81 C8 B7 67 1C 18 9F 3C FC 03 17 10 E0 39  .p...g...<.....9
E6 C0 18 F0 E8 AF 56 1D 00 5A 74 69 54 7D B2     ......V..ZtiT}.
to IP address:
Rich (BB code): 
199.108.3.4:9875
Also when mq2 loaded this IP address comes out also.. to send to :
with this code:
PHP: 
51 4E 47 20 34 30 0D 0A                          QNG 40..

IP Address:
Rich (BB code): 
207.46.106.72:1863

So variables are changing agian... those that know what time talking bout can PM me plus packets are 20bytes bigger to 40bytes.
 
Well I'm not unloading my MQ2. I can live without the active hacks, I barely use them anyway... but if they want to ban me for running automation scripts, have at it. I got other stuff I can be doing. :D
 
I have been lvling my bard since mq9.0 went live mind you I'm not active hacking. I fixed nowarpfh.mac into nohackfh.mac and I have not had one problem yet. Plus I have been putting other toons in the missoin with LoD so they get there lvls to.
 
207.46.106.72:1863

Belongs to Microsoft it's part of the auto updates and WGA server group.

I doubt it has anything to do with soe at all
 
Using a tipping point protocol analyzer i found no packets hitting any of these ip's using 6 different computers and 6 different accounts Furthermore putting a deny rule in the firewall for these ip address's didn't result in a single hit or even impact the ability to play.
 
I'm not sure that you're on the right track. It might be possible that what you're seeing is a coincidence. I'm not sure whether a packet counter exists or not, I have no evidence to suspect that one does after a couple of weeks of examination, but I can't rule out the possibility either. I do know that a better way to send packets exists. If Sony is going to ban people based on the number of packets sent or received, they have to be both accurate and precise when they determine those numbers. There must be a way to verify that a packet was sent and made it to its destination for a packet counter to be both accurate and precise, and this must happen in a low level function or it must be connected to a low level function. Basically, what I'm trying to say is that the program must increase any sort of packet counter after the actual data within the packet is determined and there must exist a function that generates this data. So the simple, safe solution is to utilize a function that generates this data. It is also true that a function that generates this data most likely does not determine whether or not the packet was successful in reaching its destination, because of the nature of modular programming. So there is most likely a function or series of functions between the data generation function and the packet sending function that handles the logistics of converting pseudo human readable programming (op codes and data most likely have discernible, logical meanings to Sony programmers, as opposed to the jumble of cryptic characters we see and have to decode) to something more suitable for transmission. So the beginning of the chain of functions after the data generation function is a pretty good candidate to look at for a way to send our packets and mimic the process of sending legitimate packets.

I also think that it may be possible that those who are able to figure this information out on their own to want to limit the spread of this information to limit retaliation from Sony. It may be wise to read between the lines on this one.

I'm by no means an expert on this, and I could very well be wrong, however I've been warping, zoning, ghosting, and running around pretty fast since a few days after the 20070420 patch, and I haven't been banned. The code recently posted by Omiime and me are a step in the right direction, but it's unnecessary because it's analogous to reinventing the wheel. Everquest can already do it for us.
 
Southernman 40, that's right damn it!!!!! Beat them all down for trying to contribute. Under NO circumstances should anyone attempt to foster and/or nurture the interests and/or attempts of those that are trying to learn and contribute. STRIKE them all down and stifle their desire to learn and help. Publically humilate them by pissing on their head and tell them they are idiots for sharing their thoughts and ideas.

It would be WAY to inappropriate to address misinformation in a professional and considerate mannor. BURN them at the stake. Under NO circumstances, should you EVER share any of your superior knowledge with them so that they might see how their ideas are flawed.
 
I'm saying I don't see a counter. There probably is something there, because when I first used the code I originally posted, I was getting seemingly random disconnects that disappeared when I stopped using plugins that utilize packets. The disconnects disappeared again when I applied the logic I was talking about a few posts back. If anyone wants to test it all out, disassemble the client, search for an opcode being pushed on to the stack (something like "push 5CF3h") and look for a path that leads to 0x4B6620. If there's a packet counter it's probably somewhere in that area, and I'd reason that if you start sending packets before the programming hits that packet counter, your packet would be counted as legitimate. I'm not posting source because I don't know if I'm right. I can't see a packet counter, so it's nothing more than an educated guess, and I'd feel bad if a bunch of people get banned in a few weeks because of something I released.
 
Releasing something for limited use for testing purposes only (which obviously needs to be stated) isn't necessarily out of the question. As long as you're pretty explicit about only having folks test it with throw-away accounts, and the RG leadership signs off on it, it could be done.

With that said, I'm sure anything released for testing by the general populace probably has been already tested on a limited basis by the developers. All I can say is, keep up the good work... I don't know the kind of back-and-forth that is going on with trying to figure this stuff out, but I certainly hope all the interested parties are talking with each other so work isn't duplicated too much.
 
Arlyh said:
I'm saying I don't see a counter. There probably is something there, because when I first used the code I originally posted, I was getting seemingly random disconnects that disappeared when I stopped using plugins that utilize packets. The disconnects disappeared again when I applied the logic I was talking about a few posts back. If anyone wants to test it all out, disassemble the client, search for an opcode being pushed on to the stack (something like "push 5CF3h") and look for a path that leads to 0x4B6620. If there's a packet counter it's probably somewhere in that area, and I'd reason that if you start sending packets before the programming hits that packet counter, your packet would be counted as legitimate. I'm not posting source because I don't know if I'm right. I can't see a packet counter, so it's nothing more than an educated guess, and I'd feel bad if a bunch of people get banned in a few weeks because of something I released.
Click to expand...
First of all, if you have a plugin that you'd like people to test, I'd be more than happy to test it for you. I get accounts banned all the time anyhow :)
Second, I followed the example you have there, but also I can't find a counter anywhere either. I did find something that I had a question on, what exactly does the exe mean by "teardown" when I find it again I'll post the exact offset where its found.

Edit: Found it.
.text:004B66BB push offset aConnectionStat ; "Connection status %d/%x [%s,%s] before teardown."
 
Without looking too deep in to it, it looks like that function gets called when a packet fails to send and determines what the error was. It probably outputs that information to a log. Teardown probably refers to erasing data about the current failed connection before it makes a new one.
 
The stuff Arlyh and I post is correct. And will get correct opcode.

I have few new test accounts that were giving to me. I've done over 50 million warps over week, using the plugin I posted. Warping is 'as safe as it ever was'

Ghosting(blocking packets) and/or adding extra packets are another thing. If you check exe there are around 40-50 place you will find where functions are called for 'counter'. Arlyh and I talked about this week or more ago on Redguides IRC. Also Dkaa talked about and had alogthm mapped out couple days after the patch.

I don't know it all, or figure it out totally, but basically. Every time packet from client is sent, it does subtract and bunch other crap(couple functions, not sure why they just didn't use same one, but oh well) every once in while (either it's timed or not, I never looked) it sends this packet to server.

Then server, who was counting packets sent to it, in that time frame, to number inside one sent. And if they match, all is fine. IF they don't. It logs it. And whenever sony decides to check this log, you are suspend/banned.
(some have claimed it's auto, but I think thats bs, cause I did testing, wasn't banned till three days later.)

So you either need to do like dkaa did and figure that out, or cheat, and figure how change packetchecker to correct number before it's sent (which I think is easier way)
 
Last edited by a moderator:
ok, here's an idea. Could the "packet counter" just be an internal counter with a packet sent from the server to the client saying how many packets have been recieved? If so, it should be quite easy to detour the incoming packet and change the # of packets recieved into the correct #.
 
[...]

Question for Omiime...how did you determine that the "Ghosting" was the issue? When I tested your plugin with one of my accounts I used all commands except the monk ones, including both warp functions and ghosting. Just curious, thats all.

Also, I would have to agree with you Omiime about the logs being checked manually. If SOE had a parser running that logged whenever the packets sent/received did not match, would it not be more efficient for them to have it set up to automatically suspend the account as well? My theory is that they random run data logs from various zones and basically calculate to make sure it all matches up…if it doesn’t..bam..you’re suspended.

Now,
siddin said:
Edit: Found it.
.text:004B66BB push offset aConnectionStat ; "Connection status %d/%x [%s,%s] before teardown."
Click to expand...
I find this interesting…
Just bare with me here because I could be way off base. Some of you, I’m sure, will know what I mean, others will probably laugh till you piss your pants. I play using a DSL connection and a mediocre computer (laptop) at best. Most of the time my connection is stable…sometimes, it’s laggy as hell. In those times I could run thirty steps and jump right back to where I started running. I’m sure we’ve all seen those individuals in overly populated (like POK) zones jumping back and forth..two steps forward one step back..yadda yadda yadda. Anyways, what I’m getting at is if this is reading a connection stat failure, i.e. lag, and resending the packet information, would it not be possible to utilize this to our advantage?
 
Last edited by a moderator:
You must log in or register to reply here.
Packet Obfuscation
Next unread thread 🦁

Users who are viewing this thread

Total: 1 (members: 0, guests: 1)
Back
Top
Cart

Cart

Total -