
                              The Spy Game
            Interception, freud and impersonation as an approach to
                     a server-based Registration scheme
                                   By
                                   Gij
            -------------------------------------------------------

Note: This article is not meant to give you a crack for gamespy,
      The serial number is left out on purpose.
      If your looking for a crack, this is not the article for you.

Keywords: Local API hooking, Server-Based protection, Server code, UDP.

Introduction
------------

More and more online-oriented programs are beginning to use Servers to
authenticate registration, Battle.net is one example, GameSpy is another.
Gamespy 2.01, my target for this article, has a major weekness in it's 
protection scheme. the weakness lies in the fact that the contacted server 
does not supply any real functionality to the program, it only replies to 
the question "is this e-mail address present in your database?", the main 
function of gamespy is not dependent in any way on the registration server.
GameSpy contacts servers and receives lists of online Game servers, then 
contacts these servers to determine Lag, hops, and other relevant information 
regarding them.

GameSpy's server checks can be patched in the normal way, but that's not an
option in ( other ) programs that are heavily protected by checksum checks,
And more importantly, doing it the old-fashioned way doesn't help me learn
anything.

so i thought of a new approach.

Tools
-----

1) Packet sniffer: I use PacketBoy from NDG software.
2) Winsock API monitor: I used SocketSpy.
3) Winsock SDK And Docs, For Reference And coding Help.
4) Lcc-Win32, free windows C compiler, needed to compile and link the code.
5) NASM, because it's finger-licking good. needed to assemble the code.
6) Netcat is a very handy thing to have around when debugging and coding
   network stuff.
7) Usual Tools: Winice,Hiew,Dumppe.

Note: you should be familiar with winsock, TCP/IP ( UDP/IP ), and have
      some knowledge of windows c coding.


Description of Target's Behaviour
---------------------------------

When a serial is entered in the registration box, gamespy first contacts
the registration server, sends it the entered E-mail, and expects a reply
stating weather that E-mail is in the registration database or not.
If the reply is "no", The registration process stops at this point.
if the reply is "yes", the entered serial is checked for validity.

I will not deal with the serial calculation, nothing interesting i can think
to do with it at this point.

Looking at the log From the Winsock API Monitor, The Flow of Winsock calls is
loosely as follows:

Socket (SOCK_DGRAM)
Bind
Connect 204.182.161.94:25635
send "IREG|entered@e-mail.addr.com"
recv ( receives "00 30" for "Address not authorized" )
closesocket

( some calls are missing, they are not relevant right now )


Note this things:
1) the Socket is UDP
2) the address contacted it 204.181.161.94
   ( This Resolves to spy.planetquake.com )
3) the reply sent by the server.

Once a socket is connected to an address is stays connected to it until the
connection is broken. all data sent to the socket will be sent to the other
server already connected.


The Approach
------------

To defeat the check, i will redirect the socket connection from 204.181.161.94
to 127.0.0.1, and code a local server to emulate the response sent by the
real server to allow any e-mail address to be used for registration.

From A coding Standpoint this translate into the following pseudo-code:

 Start_local_server();

 Hook_Connect_API();

 On_Connect_Call {
	if ( requested_server_connect == registration_Server ) {
		change requested address to 127.0.0.1;
		call connect with new params;
	}
	else {
		call connect with supplied parameters.
	}

 }



The Local server
----------------

As I mentioned before, GameSpy used UDP as it's underlaying protocol, That's
important when writing the local server.

I included the Full C source for the local server, nothing fancy, it just
waits for a command packet in the form "Command|Args", and then checks to see
if the command is an authorization request "IREG|entered@e-mail.com", and then
sends a 2 digit sequence which qualifies as a "E-mail Valid" response.

There are probably more commands used by GameSpy When connecting to the registartion
server, these are not supported since they are not relevant.



Hooking The Connect Winsock API
-------------------------------

The IAT
-------

Every 32bit proccess in windows runs in it's own address space, seprated from
others. in order for a proccess to use function in a dll, they have to be mapped
onto the process's address space. 
In order for the code to be able to call the functions of the various DLL's,
a jump table is built, this is neccesery because the DLL might be mapped at
a diffrent address every time the program is run.
This table is called the IAT, look it up in the PE spec under 
"Import Address Table", it's basicly just a list of DWORDS containing the 
addresses of every imported function, and that address is called instead of 
directly calling the DLL address. The IAT is located in the .rdata section of 
the PE exe.
Stone's article explains this, i suggest you do yourself some good and read it.
 

Looking for Hookers
-------------------

Hooking the API Turned out to be the tricky part.
The method i used is IAT Hooking, so the hook is local to Gamespy, all other
applications continue calling the normal API as usual.
This approach was taken from Stone's glorious Article "In Memory Patching,
Three approaches".

However the described methods of injecting the replacement code into the
program weren't used, since a regular WriteProcessMemory does the trick quite
nicely.

The code serves as the best explanation of the procedure, but here's what the
code roughly does:

1) loop through task list using ToolHelp32 API's ( i like toolhelp ),
   looking for an entry for gamespy.

2) reads in the original IAT entry for WSOCK32!Connect, using a hardcoded
   address. The old IAT entry is written at the end of the .rdata (IAT) section,
   at a hardcoded address, plenty of room for it.

3) The WSOCK32!Connect replacement code is appended to the program code, again,
   there is more then enough room for it.

4) the IAT entry is replaced with the address of the injected code.

5) when the new replacement code is called, the params are checked and modified
   if neccesery and the old function address is called at it's new storage
   location.

6) the local server is launched.


Looks like this is quite a virii-inspired piece of code.


How to Use it
-------------

Run gamespy, then run gij_gsin.exe to hook the Connect call. then run 
gij_lgs.exe to start up the server.
try and register it with a serial, as far as the Server-check is concerned, 
any E-mail Address you enter is Valid.


Greetz
------

Stone: An obscene amount of the code and methodology is derived from his
       articles and code.

       Remember, He IS God.

+RCG:  For That Elusive Article on API Hooking Using VXD's, an approach which I
       didn't use in this case, But was interesting just the same.



Reaching me
-----------

#cracking4newbies on EFNET is where i normally IRC.
you can e-mail me: gij <at> iname.com .


"If a protection is reversed,
              but there's no one there to use it,
                                does it make a sound?"

	Gij.
+                                                                              -
