Request for Information: Warcraft 3 Gaming Protocol Documentation

[Puzzle]

There is a much easier way to do this: patch game.dll with 6804000080 at address 6F00996C to 6800000000. Any hex editor will work. All this does is create a null value in the third paramater of SetSecurityInfo() which makes sure the api doesnt do anything that can block you.

Edit: My apologies. This address has been changed in 1.20B and I will update the newer address and values ASAP.

[Warrior]

How do I compile this?

MASM.

[UserLoser]

Same reasons why there's no public Starcraft game bots out there

Define "game bots"?

I have about 4 (public) source codes to STAR/SEXP/W2BN Winbots. Which in a way could be modified to just idle in games etc..

Game bots, as in, actually in a game where it's connected to a host and other peers.  WinBots are nothing close to an actual game bot, you're mistaken, sorry.

[PaiD]

Yea i got it compiled now, thx. Now for some reason. I can only view packets that I sent to bnet or the host of the game. I cant see what bnet responds with or with what the host sent me. Anyone know why?

[Puzzle]

Reinstall with x32 so that you can use Ethereal.

[Skywing]

Or you could just do the easy thing and enable SeDebugPrivilege in your patching program.  Alternatively, you could just rewrite the DACL for the process the same way that War3 does it - it's running under the same user as you and owned by you, so this will always be possible.

[PaiD]

Ok I just read up on the SeDebugPrivilege API and it says that Admins have it on allrdy (from what I can tell), If so.... I should have it on

Edit: Oh Ok. I have the privilege to load it, but i need to call the api and give it the war3.exe process ID, it sounds like to me. Correct?

Edit: Also will this let me see the recieved packets from Bnet and the Game Host?

[Skywing]

Ok I just read up on the SeDebugPrivilege API and it says that Admins have it on allrdy (from what I can tell), If so.... I should have it on

Edit: Oh Ok. I have the privilege to load it, but i need to call the api and give it the war3.exe process ID, it sounds like to me. Correct?

Edit: Also will this let me see the recieved packets from Bnet and the Game Host?

If you are running as an administrator or a user with that privilege, then you can use AdjustTokenPrivileges to enable the privilege for the process token.  While the privilege is enabled, all access checks to OpenProcess and OpenThread are disabled, so Blizzard's modifications of the process security descriptor will have no effect on your program.

A different, slightly more complicated solution is to open the process for WRITE_DAC access (will always succeed because you are the owner of the process) and rewrite the DACL to not deny the rights you are interested in.  This is slightly better in that it doesn't require you to be an administrator in order to function.

[Joe[x86]]

How do I compile this?

You don't compile, you assemble. =). I'm not sure which assembler that was written for, as I only work with NASM, but I can tell you that it's not NASM code.

It's ASM, I think.

You never cease to make me chuckle.

[Warrior]

I already said it's MASM code.

[topaz]

i hate you joe

[Joe[x86]]

i hate you joe

I hate you too, loser.

[PaiD]

looking over how DACL works. I dont see how they could have blocked the admin (who sould have all rights) to not see the process from WPE Pro. How does this work?

[Joe[x86]]

looking over how DACL works. I dont see how they could have blocked the admin (who sould have all rights) to not see the process from WPE Pro. How does this work?

Theoretically, admin should have all privlidges. But, you aren't using Linux, so don't expect it to work in practice. =)

[Kp]

looking over how DACL works. I dont see how they could have blocked the admin (who sould have all rights) to not see the process from WPE Pro. How does this work?

Theoretically, admin should have all privlidges. But, you aren't using Linux, so don't expect it to work in practice. =)

Actually, it's possible on both Linux and Windows for an administrator to end up with reduced privileges via a rootkit.  On Windows, it's common for administrators to have the option of certain privileges (such as SeDebugPrivilege), but not actually have the privilege enabled until he requests it.  On Linux, it's quite possible to build a modified kernel (such as a GRsecurity kernel) where root (and all other users) have reduced privileges.