Proxy to manipulate?

[abdula123]

FreeCap Homepage - Home can force a specific process to use a proxy, a program that does the same but better/easier is ProxyCap - A stable and reliable proxifier for Windows/Mac OS X but it's not free

+1

set up any "socksifier" (proxycap, sockscap, freecap, proxifier - there lot of them) to forward wow.exe connections via your proxy.

of course, you must implement SOCKS4 on it (its simple).

also you must separate connections to auth server (just forward, don't touch it) and to world server (do the bad things on it).

after CMSG_AUTH_SESSION you just freeze connection for some time, read seesion key from wow.exe process, create ARC4 instances, and then start do decryption/re-encryption of pkt headers thru your proxy.


OR

if your rly guru in windows sockets and have LOOOT of free time, you can write your own Layered Service Provider, that will filter wow.exe connection and do same things on it.




maybe this trick will stop working in 3.3.3, but now its works ok.

[SinnerG]

Well, isnt the issue that the protocol (encryption) changed ? Or does this only count for the 'realm list' part?

[BoogieManTM]

Well, isnt the issue that the protocol (encryption) changed ? Or does this only count for the 'realm list' part?

only authentication has changed extensively in the past few months. Which is why I recommend you bypass it completely and DO NOT even attempt to proxy it. There is no need.

[SinnerG]

So, if I remove my realm code, and just let my proxy sit in between the client<>'world server' things should still work without any change? (except that I actually need to get it to connect to my proxy )

[!@^^@!]

I'll admit that i lack knowledge about this subject but wouldn't you need either to time when you start proxying wow's network packages or filter the data?

[xdk]

only authentication has changed extensively in the past few months. Which is why I recommend you bypass it completely and DO NOT even attempt to proxy it. There is no need.

So, how can I forward only Realm server's connection and not AuthServer's connection ? ProxyCap/Proxifer etc doesn't have this feature.
Can I hook WinSock functions (using EasyHook) to force him to connect to my local realm proxy ?

[BoogieManTM]

So, how can I forward only Realm server's connection and not AuthServer's connection ? ProxyCap/Proxifer etc doesn't have this feature.
Can I hook WinSock functions (using EasyHook) to force him to connect to my local realm proxy ?

Sure, that's another way I never thought of. you can hook Winsock's Connect() function, looking for a connect that is headed towards a realm server (what you guys call world server), change the endpoint and voila! You're now proxying without any system-level modifications. Gotta let the proxy know somehow where it is supposed to be connecting to the other direction.. perhaps inject your own handshake packet?


ie, hook Connect()
Wait for call that looks like it's going to a realm server
intercept call to realm server
redirect to proxy
inject 'hello' packet to your proxy to instruct it on which realm it needs to connect to for you (I would also include encryption keys in this packet. which would allow for a totally remote proxy without much headache)

and then you're done! you're successfully proxying the realm connection only, which is the only thing majority of people would be remotely interested in.

[SinnerG]

^^

Used to do this:

- A VMWare'd Windows 7 (running as bridged aka own dynamic ip)
- A simple proxy instance (seen in screeny)

This is a connection to REAL wow server (not emulated) - FYI does not 'look' at the packages! (Just a POC for a proxy :P)

SimpleProxy is something I quickly made to do this thing ^^ (just an app that takes <local ip> <local port> <remote ip> <remote port> :P)

[SinnerG]

I'm in need of a favor.

Could anyone explain me the LARGE header for wow server > client packages.

I've looked both in pseuwow (wow client) + mangos code and all code there is either not working or the bitwise operations are not c# compatibe (I assume its the 2nd)

Wasted hours on this already. I do have it working for 'regular' headers :/

edit: For example take the following 5 decrypted bytes:

-
headerBytes Count = 5 System.Collections.Generic.List<byte>
[0] 195 byte
[1] 35 byte
[2] 63 byte
[3] 216 byte
[4] 226 byte

All code I tried either gave an incredible high 'size' OR an invalid one :/

Edit 2 : could it be that the 'session key' changes when entering a realm?

Edit 3 : until further edits, don't reply on this => I think I found it ... (GAAH hours wasted on this...) I added a 'peek' function to decrypt 1 byte, without ruining the decryption state, but I ruin it still later on ...

Edit 4 : Yup... It is working now (no 'big' packet yet though to see if that is working :/)

Some output:

UNHANDLED OPCODE RECEIVED: SMSG_TIME_SYNC_REQ
UNHANDLED OPCODE RECEIVED: CMSG_TIME_SYNC_RESP
Server > Client
UNHANDLED OPCODE RECEIVED: SMSG_MONSTER_MOVE
Server > Client
UNHANDLED OPCODE RECEIVED: SMSG_MONSTER_MOVE
UNHANDLED OPCODE RECEIVED: CMSG_PING
Server > Client
UNHANDLED OPCODE RECEIVED: SMSG_PONG
Server > Client
UNHANDLED OPCODE RECEIVED: SMSG_MONSTER_MOVE
Server > Client
UNHANDLED OPCODE RECEIVED: SMSG_MONSTER_MOVE
Server > Client
UNHANDLED OPCODE RECEIVED: SMSG_MONSTER_MOVE
Server > Client
UNHANDLED OPCODE RECEIVED: SMSG_MONSTER_MOVE
Server > Client
UNHANDLED OPCODE RECEIVED: SMSG_MONSTER_MOVE
Server > Client
UNHANDLED OPCODE RECEIVED: SMSG_MONSTER_MOVE

[SinnerG]

Here is a POC of Packet Injection

I said Hello, and I coded in an auto-reply (it injects the 'world' reply after the client' CMSG_MESSAGECHAT message)

Added server > client injection

http://yfrog.us/4rwow2010031009002261z (video)

I know the text aint clear so:

I move around a bit (cant fly) then I type 'Superman!' and I forge a message that I send to the wow client, it then thinks I'm allowed to fly and tada : fly 'hack' without any 'wow process' injection :P

FYI : Tested on a private server since wow offi servers are down atm (thats why I didnt bother 'cleaning' up my 'info' :P)

[SinnerG]

Err, could anyone be so kind to convert (*(((uint16*)&(x))+3)) to C# compatible code? :s

(where x is an ulong)

[Cypher]

Err, could anyone be so kind to convert (*(((uint16*)&(x))+3)) to C# compatible code? :s

(where x is an ulong)

Its not a difficult or complex expression, it just looks that way because of the way it's written.

Break it down into its 'parts' and convert it, its really not hard.

[SinnerG]

Well I think I got it...

Almost got a working 'object manager' that purely works on proxied data (ok you still need the session key ;p)

It works for most 'objects' except 'units' trigger an exception atm (looking into it...)

edit : meh keep fixing 'race' conditions... Lucky I had some data to compare so I knew it had a 'bit' to much data at a certain point

edit 2 : It is mostly working now though - now if I reverse the process I should be able to set the 'fly' bit once again :P

Some debug output (positions were fixed just then, thats why not all entries have a position :P)

Player: Position: 1 0 0 7,006492E-45
Player: Position: 0 0 0 0
Player: Errrz Position: 0 0 0 0
Player: Position: 0 0 0 0
Player: Position: 0 0 0 0
Unit: TODO Position: -629,7752 -4154,154 38,56937 0,4596916
Unit: TODO Position: -628,3361 -4284,025 42,10564 0,6844615
Player: Panzo Position: -658,518 -4251,67 38,718 3,660948
Player: Position: 0 0 0 0
Server > Client
Server > Client
UNHANDLED OPCODE RECEIVED: SMSG_MONSTER_MOVE
Server > Client
UNHANDLED OPCODE RECEIVED: SMSG_MONSTER_MOVE
Server > Client
UNHANDLED OPCODE RECEIVED: SMSG_MONSTER_MOVE

FYI: I'm not planning to do something with with what I do here. I'm just doing this for the coding XP (not planning to use it on my real account either - trials ftw!)

[SinnerG]

Hmm, it works, the object manager, except when I get a 'local' player update.

Anyone who has more info on the SMSG_UPDATE_OBJECT pack?

I must be reading something to much or to little (I can read the 'speed' values correctly though)

Either the movement reading is wrong, or the values reading (but I dont think the values reading differs from the regular player one, so I think its the movement reading)

'Praying' that an update with only 1 package occurs containing a player update.. Then I can debug (no luck so far)

edit: Hmm, didnt look at this yet => http://www.mmowned.com/forums/wow-me...crypt-lib.html <= Did all code myself, but let me take a look there.. Maybe I missed something :/

edit: goody! Thanks amadmonk for your code! I found out that I did have all the correct checks EXCEPT that my 'NOT LIVING' else was closed 2 late :P

[abdula123]

They're generated again using a polymorphic function which computes new in/out keys. The function changes with each module (which are distributed daily, multiple times) - so you need to read the context from Warden itself.

I load fresh warden module into memory, initalize it, as described in skillsecurity wiki
(in pyton with ctypes it not so hard - just need to understand, what happens under the hood)

when I feed it with current RC4 state (box1, i1, j1, box2, i2, j2, err - 520 bytes total) via GetRC4Data callback

after that I give it encrypted SEED packet, captured from stream and got encrypted SEED responce via SendPacket callback - exaclty same, as live warden sent to server.

after that I read new RC4 state with i1=0 and i2=0 (i.e not used for encryption) from warden's memory (from addr, there old state was written to).

but when I try to decrypt next warden pkt with this new RC4 state - I got nonsense result.

also when I give this pkt to module, it don't do any job - PacketHandler return 0, and no callbacks fired.

what I missed ?

Loading module AF203602B6E8414A835A10B4E3DC8EEC.raw
Allocated mem for module: 0x010b0000
Copying code sections to module.
Adjusting references to global variables...
Updating API library references...
Lib: KERNEL32.dll, offset: 0x00007000
   Function: GetConsoleMode, 	 0x7c81ac50
   Function: GetStdHandle, 	 0x7c812fd9
   Function: Sleep, 	 0x7c802446
HOOKED
   Function: GetModuleHandleA, 	 0x00f70fa4
   Function: TlsAlloc, 	 0x7c812e3f
   Function: TlsFree, 	 0x7c813777
   Function: TlsGetValue, 	 0x7c8097e0
   Function: TlsSetValue, 	 0x7c809c65
   Function: RaiseException, 	 0x7c812aa9
HOOKED
   Function: GetProcAddress, 	 0x00f70fdc
   Function: GetSystemInfo, 	 0x7c812df6
   Function: GetVersionExA, 	 0x7c812b7e
   Function: VirtualQuery, 	 0x7c80ba71
   Function: QueryDosDeviceA, 	 0x7c85d344
   Function: GetTickCount, 	 0x7c80934a
   Function: DuplicateHandle, 	 0x7c80de9e
   Function: CloseHandle, 	 0x7c809be7
   Function: FreeLibrary, 	 0x7c80ac7e
   Function: GetCurrentProcess, 	 0x7c80de95
HOOKED
   Function: LoadLibraryA, 	 0x00f70fc0
   Function: GetProcessHeap, 	 0x7c80ac61
   Function: HeapFree, 	 0x7c90ff2d
   Function: TerminateProcess, 	 0x7c801e1a
   Function: UnhandledExceptionFilter, 	 0x7c863fca
   Function: SetUnhandledExceptionFilter, 	 0x7c84495d
   Function: QueryPerformanceCounter, 	 0x7c80a4c7
   Function: GetCurrentThreadId, 	 0x7c8097d0
   Function: GetCurrentProcessId, 	 0x7c8099c0
   Function: GetSystemTimeAsFileTime, 	 0x7c8017e9
   Function: RtlUnwind, 	 0x7c92abc5
Lib: USER32.dll, offset: 0x0000707c
   Function: CharUpperBuffA, 	 0x7e36ae3f
   Function: CreateWindowExA, 	 0x7e37e4a9
   Function: ScrollWindowEx, 	 0x7e380187
   Initialize Function is mapped at 0x010b263d
 <-- GetModuleHandleA('kernel32.dll') = 0x7c800000
 <-- GetProcAddress(0x7c800000, 'AddVectoredExceptionHandler') = 0x7c936c2a
 <-- GetProcAddress(0x7c800000, 'RemoveVectoredExceptionHandler') = 0x7c936c96
 <-- AllocateMemory(2032)
 <-- AllocateMemory(60)
 <-- AllocateMemory(44)
 <-- LoadLibraryA('kernel32.dll') = 0x7c800000
HOOKED
 <-- GetProcAddress(0x7c800000, 'CreateToolhelp32Snapshot') = 0x00f70f88
 <-- GetProcAddress(0x7c800000, 'Module32First') = 0x7c8653a0
 <-- GetProcAddress(0x7c800000, 'Module32Next') = 0x7c865525
 <-- GetModuleHandleA('kernel32.dll') = 0x7c800000
 <-- GetProcAddress(0x7c800000, 'wine_get_unix_file_name') = 0x00000000
 <-- AllocateMemory(92)
Module Initialized, return 0x00cd2b60
GenerateRC4Keys = 0x17512352
Unload = 0x17523824
PacketHandler = 0x17512560
Tick = 0x17504864
 -> GenerateRC4Keys
 <-- GetRC4Data <warden.LP_c_ubyte object at 0x019089E0> 520
 -> PacketHandler
 <-- SendPacket(0x01908af8, 21)
(1, 17)
encrypted responce
0000: 52 58 2e be 97 dd fe dc ad a7 87 bc 1b ca ef 56  |  RX............V
0010: 7b fe 5c ce b6                                   |  {.\..

decrypted responce
0000: 04 0e 94 81 61 d0 b6 8b fb aa d5 60 eb a0 f1 8a  |  ....a......`....
0010: 73 d6 5c ad ad                                   |  s.\..

AFTER SEED -> HASH

serv pkt encrypted
0000: ac 03 4d 10 f6 d2 b7 b9 dc 96 5f 9f 75 ff f4 dc  |  ..M......._.u...
0010: 82 25 74 8c c0 c7 da 41 eb 7d 90 c0 3a 2a c0 74  |  .%t....A.}..:*.t
0020: 10 f4 d6 2f 6c 46 cb 71 5e ce 0b 22 bf b4 8b 56  |  .../lF.q^.."...V
0030: 35 1e 52 af 15 3f 4e 14 b7                       |  5R.?N.

serv pkt decrypted
0000: 69 b6 97 1c 52 8d 97 9a 70 c4 7f 5d f3 6e 6e df  |  i..R...p.].nn.
0010: a5 ff 96 72 bd f9 94 89 5c cc 18 e1 7d e8 dc d4  |  ...r....\..}...
0020: 42 eb c4 80 87 77 8b 86 c0 ea ff e0 82 dc 8b b5  |  B....w..........
0030: 40 42 6b ed b7 4b 4f 4e 80                       |  @Bk..KON.

 -> PacketHandler
(0, 0)

 <-- ReleaseMemory(0x00ca61d0)
 <-- ReleaseMemory(0x00c207a8)
 <-- ReleaseMemory(0x00aba020)
 <-- SetRC4Data <warden.LP_c_ubyte object at 0x00CFCBC0> 520
 <-- ReleaseMemory(0x00cd2b60)