Valhalla Legends Archive

Wow, that site is my new best friend.


Case ID_LEAVE
For X = 1 To Form1.ChannelList.ListItems.Count
  If frmMain.ChannelList.ListItems.Item(X).Text = Username Then
    frmMain.ChannelList.ListItems.Remove (frmMain.ChannelList.FindItem(Username).Index)
End If
Next X


One problem is you're using a 1 based counting system on a zero based index. Also, I don't see why you need to find the username again to remove it, the index x should contain it if it fulfills the IF condition. Also you should either convert everything to upper case or lower case to compare usernames.


Case ID_LEAVE
For X = 0 To Form1.ChannelList.ListItems.Count - 1
  If UCase(frmMain.ChannelList.ListItems.Item(X).Text) = UCase(Username) Then
    frmMain.ChannelList.ListItems.Remove (X)
    X = X - 1 'Compensate for the removed item
End If
Next X


My classes this semester:
CH 201 ANCIENT & MEDIEVAL CULTURE
CS 311 CHAL SOC ASP COMPUTING
CS 365 MATH OF COMP SCIENCE
CS 446 PRINC COMP OP SYST
MATH 182 CALCULUS II

Quote from: warz on January 19, 2005, 03:01 PM
What's with the Meh - (S-1-0-0) style names?

http://forum.valhallalegends.com/phpbbs/index.php?topic=10168.0

19

- Mark
- Yes
- College/Living away from home
-
- Family health problems, bad grades
- Getting a job in the computer gaming industry
-
- College is much more open, a lot more freedom and responsibility.

Update:
I've got the client encryption and decryption of world packets bypassed (with help from modem from BH). Since modem privated messaged me with the encryption bypass, I'm not sure how much he wants me to reveal (since this is his information). The decryption bypass is at 005AD7B8, change JE to JMP. The big thing though was the switch statement that used the received decrypted packet to do it's work. If anyone is really interested in the locations and packet format, send me a PM.

Try:


Print #1, Combo1.List(i-1)


I understand how it may appear that way, but this is only for creating my own server. I don't care at all how the client creates the server auth bytes, because my server will accept it no matter what. The problem is creating or bypassing the check on the bytes the server sends (if this were done on a legitimate server, it would disconnect the client). I use MSN Messenger exclusively if you would like to chat, my contact is: [email protected]

http://drivehappy.rgaming.net/WoWPatched.exe
That is for v1.1.1 Build 4062 (latest I know of)

It's the patched exe I use to bypass the first authentication.
The socket recv function for the game server is at: 005AD788

If you need the original: http://drivehappy.rgaming.net/WoW.exe

I don't believe this breaks any rules here, as it's only going to be used for writing a server, not running one.

Has anyone looked through wow.exe to get past the server authentication? I've bypassed the login server check and I'm able to get the client to connect to a hardcoded realmlist server I whipped up. Now, however, when trying to connect to a game server (from the realmlist) it does yet another authentication of the server. What I've gotten out of it so far is this:

Packet Log:
Server -> Client:
00 06 EC 01 4F 9A 4A EE   (format is always: 00 06 EC 01 xx xx xx xx)

Client -> Server:
00 xx ED 01, 00 00 aa aa 00 00 00 00 00 00 bb bb bb bb bb bb bb bb bb bb 00 cc cc cc cc dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd            (format: xx=packet size, aa aa = client version,  bb = account name, cc = 4 bytes - this have to do with auth?, dd = hash of data - not sure what)

Server -> Client:
xx xx xx xx 0C yy yy 07/08 00 00     (format: xx = server auth, yy = I'm not sure)
After the wssock recv function, the client appears to XOR the bytes with a lookup table upto and including 0C and subtracts the previous byte it did. The lookup table is created randomly each time the client connects to the login server, but is left the same if only you disconnect from the game server. The lookup table is located at 090BB678 in memory.

Client -> Server:
xx xx xx xx xx xx  (format, looks to be a client auth for the server. The first byte always appears to match the first byte the server sent. This leads me to believe the client also does the XOR operation on the lookup table and adds the next byte)


The problem I'm having is that I cannot find where the client compares the server auth bytes with what it should actually be. I would be OK with patching the client to get around it (as I had to do with the login server). I've got a quick little server written up in C# and I can tell you how to patch the client to get around the first auth key if anyone is willing to help. I've also posted this on Blizzhackers, but it appears many of the users there are more interested in playing w/o paying. I'm only interested in creating a server, not playing on it.

P.S. This would easily be seen where the logic flow goes on a legitmate server, however I don't have the game yet, so I'm unable to how the client responds to a correct server authentication packet.

Hopefully I didn't ramble too much about it and confuse anyone, it's just something that's been bothering me for the last few days.

EDIT: Clarification.

Output the Description variable and tell us what it describes; what you posted tells us nothing.

What does iUsrBFlags equal when it's supposed to SendChatCommand() ?
BTW, it's not called bitwise, rather bit masking.

When I try it Firefox uses less memory than IE6 (35MB v. 27MB). Minimized Firefox only uses ~1MB, IE ~2.5MB.

Isn't 2.0 technically in beta state though?

Quote from: NicoQwertyu on November 17, 2004, 03:13 PM

Quote from: MyndFyre on November 17, 2004, 03:03 PM

Quote from: NicoQwertyu on November 17, 2004, 01:37 PM
After stepping through it in a debugger: my code executes, jumps to the correct address, does what I want it to, hits a "retn 0", then ends up somewhere else where it, according to the debugger, has an "access violation when reading [FFFFFFFF]".  How can I fix whatever's going wrong? 

It's hitting a ret instruction?  Perhaps you need to use call rather than jmp in your code.

That wouldn't work for what I want it to do. And it should hit a ret, shouldn't it? The address I jump to is in the middle of a function.

That's probably your problem. When that function is called it pushes values onto the stack that correspond to parameters and the address at which it was called. Return I *believe* will revert EIP to the original address after which the call statement was made, any parameters should be popped off within the function. Again, I'm not 100% sure of the order. So when you jump inside the function and ret is reached it will try popping values off the stack that are incorrect. You should always have pairs of pushes and pops for the stack.