Hidden Gamespy code leads to vulnerabilities in diffused games (BF1942, Halo, Dredd and more)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



#######################################################################

                             Luigi Auriemma

Application:  Gamespy SDK used for online cd-keys validation in third
              party code (hidden "security through obscurity" code)

Games/ver:    Battlefield 1942                     <= 1.6.19 and 1.6rc1
              ___________________________http://www.battlefield1942.com
              Contract Jack                                      <= 1.1
              ___________________________________http://nolf.sierra.com
              Gore                                       <= 1.48 (1.49)
              _________________________________http://gore.cryogame.com
              Haegemonia                                       <= 1.0.7
              ________________________________http://www.haegemonia.com
              Halo                                             <= 1.031
              _____________________http://www.microsoft.com/games/halo/
              Hidden & Dangerous 2                              <= 1.04
              ______________________http://www.hidden-and-dangerous.com
              IGI 2: Covert Strike                               <= 1.3
              _________________________________http://www.igi2-game.com
              Judge Dredd: Dredd vs. Death                      <= 1.01
              ______________________________http://www.dreddvsdeath.com
              Need For Speed Hot Pursuit 2                       <= 242
              ______________http://www.eagames.com/pccd/nfshp2/home.jsp
              Terminator 3: War of the Machines                     1.0
              _____________________________________http://www.t3war.com
              TRON 2.0                                         <= 1.042
              ____________________________________http://www.tron20.com
              probably also other games

Platforms:    Windows, Linux and MacOS

Bugs:         A] crash of games'servers
              B] privacy problems

Risk:         A] high
              B] very low

Exploitation: remote

Date:         24 Feb 2004

Author:       Luigi Auriemma
              e-mail: aluigi@altervista.org
              web:    http://aluigi.altervista.org


#######################################################################


1) Introduction
2) Bugs
3) Analysis of the hidden code
4) The Code
5) Fix
6) Conclusion


#######################################################################

===============
1) Introduction
===============


First I want to premise that these bugs have been discovered during a
bug research on a specific game and I knew about the implication of
Gamespy only some minutes later.
Yes Gamespy, the people who say to "welcome any and all help" and then
send me an useless Cease&Desist and DEFAME me and moreover my hobby,
the same people who say to "protect gamers rights and provide security"
and then leave RogerWilco and Gamespy3d vulnerables to highly critical
and pubblic old bugs (still now), the same "trusted people" who claim
"Gamers trust us" and at the same time insert hidden functions in third
party games.
http://aluigi.altervista.org/papers/castleoflies.txt

The code now object of this research is just the SDK that Gamespy
gives/sells to games developers to implement the online management and
validation of games cd-keys.
The worst thing of this SDK is that it uses simples "security through
obscurity" methods to hide informations to the same users who use these
vulnerable games (any existent type of demo, retail and dedicated
server) so this advisory will also clarify these shameful methods
avoiding that these users like me continue to be joked.

The bugs I want to analyze are essentially the following:

  A] security bug/programming error:   crash in the games servers
  B] security through obscurity bug:   possible privacy problems

Fortunally the developers have the source code of the bugged SDK so all
the people I have personally contacted a lot of weeks ago have had the
possibility to fix the first bug without problems.

Then some weeks ago Gamespy has also released a patched SDK to the
developers of the vulnerable games, in fact they have been contacted
just by one of the developers I have talked with... in fact as
everybody knows for me is impossible to directly contact Gamespy
because they are incapable to understand and manage my bugs
signalations.

However I have also provided some unofficial fixes for the games that
have no official patches at the moment or that are no more supported.


#######################################################################

=======
2) Bugs
=======


-------------------------
A] crash of games'servers
-------------------------

The problem is located in the instructions that copy the portion of the
received query packet delimited by backslashes (as \query\) into a new
buffer.
The vulnerable instructions are similar to the following:

  int size = strchr(buff + 1, '\\') - buff;
  if(size > 32) return;
  strncpy(querybuff, buff + 1, size);

"buff" is the decoded packet (look at next section) containing one of
the hidden Gamespy commands, "size" is a signed integer number that
contains the amount of bytes to copy and "querybuff" is the buffer that
will contain the query for comparison with the hidden commands.

In this code we can find 2 programming errors:

- the return value of strchr() is not checked so if it fails the
  Gamespy code continues to think that the address of the string
  returned is valid also if it is 0 (failed).
- "size" is managed as a signed integer (+/- sign) so when strchr()
  fails the function does a "0 - buff" operation (difference between
  the end and the beginning of the query) that results in a negative 32
  bit number.
  The problem happens when the function checks if "size" is major than
  32 because naturally this is a signed comparison and "size" has a
  negative sign.

The effect of the bug is an exception in the strncpy() function that
interrupts the server immediately.


-------------------
B] privacy problems
-------------------

As already said, the Gamespy code implements security through obscurity
techniques to avoid that the servers'administrators see or understand
the queries sent and received to their own systems (why? I don't know,
ask to Gamespy).
These queries however are nothing of "special" but can cause some
privacy problems to games servers and clients.
The following is the command that gives problems:

ison: used to know if in the target game server is playing an user with
      a specific cd-key

For example this command can be used to track a specific user if we
know his cd-key or its MD5 hash (hash sent to any game server where the
client joins).


#######################################################################

==============================
3) Analysis of the hidden code
==============================


The Gamespy cd-key SDK is a partially hidden function activated when
the game server receives a packet with a specific byte in it or must
validate a client's cd-key.
I'm just one of the users of some of the vulnerable games and I don't
accept that someone inserts hidden code in the games I buy or
administer (moreover if they are not the developers and I don't trust
in them) so this analysis will finally light on a part of this code,
the part that directly affects users.

The hidden function used to manage the "undocumented" queries is
activated when a packet starting with the char ';' (byte 0x3b) reaches
the query port of the game server of any user online.
The query port is just the same UDP port used to receive the
information queries as "basic", "info", "status", "rules" and all the
others.

The char ';' in reality is the char backslash (the same used at the
beginning of any normal query) "XORed" with the char 'g' of the string
"gamespy", in fact the packet that reaches the game server is simply
encoded using the XOR operator.
The following is an optimized C function that explains how works the
encoding/deconding operation:

void gamespyxor(u_char *string, int len) {
    u_char  gamespy[] = "gamespy",
            *gs;
    for(gs = gamespy; len; len--, gs++, string++) {
        if(!*gs) gs = gamespy;
        *string ^= *gs;
    }
}

After having decoded the data the hidden Gamespy function assembles the
supported 4 commands in memory for comparison with that received in the
packet. The method used for this operation is very simple and its only
purpose is to hide the available commands to who tries to open the game
executable with a disassembler or a hex editor.
The following is a real example showing how the 4 commands used in the
function are assembled:

:004422B7 B175                    mov cl, 75
:004422B9 B06F                    mov al, 6F
:004422BB 56                      push esi
:004422BC 8BF2                    mov esi, edx
:004422BE B26E                    mov dl, 6E
:004422C0 884C240C                mov byte[esp+0C], cl
:004422C4 884C2410                mov byte[esp+10], cl
:004422C8 884C2420                mov byte[esp+20], cl
:004422CC 884C2423                mov byte[esp+23], cl
:004422D0 33C9                    xor ecx, ecx
:004422D2 85F6                    test esi, esi
:004422D4 8844240D                mov byte[esp+0D], al
:004422D8 88442412                mov byte[esp+12], al
:004422DC 8844241A                mov byte[esp+1A], al
:004422E0 88442422                mov byte[esp+22], al
:004422E4 C644240E6B              mov byte[esp+0E], 6B
:004422E9 C644240F00              mov byte[esp+0F], 00
:004422EE 88542411                mov byte[esp+11], dl
:004422F2 C64424136B              mov byte[esp+13], 6B
:004422F7 C644241400              mov byte[esp+14], 00
:004422FC C644241869              mov byte[esp+18], 69
:00442301 C644241973              mov byte[esp+19], 73
:00442306 8854241B                mov byte[esp+1B], dl
:0044230A C644241C00              mov byte[esp+1C], 00
:0044230F C644242163              mov byte[esp+21], 63
:00442314 88542424                mov byte[esp+24], dl
:00442318 C644242574              mov byte[esp+25], 74
:0044231D C644242600              mov byte[esp+26], 00

The portion of code comes directly from the file BF1942_w32ded.exe of
Battlefield 1942 Win32 dedicated server 1.6.19 but this "hiding
technique" is the same used in all the other vulnerable games and
moreover also in all the Gamespy products (..."Gamers trust us"...).

The generated commands are exactly: "uok", "unok", "ison" and "ucount".
The first 2 commands in reality are replies sent by the Gamespy master
server to the games servers when they request the validation of a
cd-key using the "auth" query.

Instead the real interesting commands are "ison" and a bit "ucount"
that are used respectively to know if a specific cd-key is currently
used in the target game server and how many players in the server are
using cd-keys.
The following are some practical usage examples:

\uok\\cd\0123456789abcdef0123456789abcdef\skey\1\errmsg\Valid CD Key
\unok\\cd\0123456789abcdef0123456789abcdef\skey\1\errmsg\Invalid CD Key
\ison\skey\1\cd\0123456789abcdef0123456789abcdef
\ucount\

Where "skey" is an ID number used to track replies to a specific query
and "cd" is the cd-key hash.
The cd-key hash is simply the MD5 hash calculated by the client on his
original cd-key, it is sent by each client to the game server that uses
it to validate the client through the master server.

When the server has assembled the available commands in memory it
compares the received query with eachone of these 4 strings and then
sends the relative answer if needed.
The following are the possible answers for the commands "ison" and
"ucount":

\uon\\skey\1     the requested cd-key is used in the target server
\uoff\\skey\1    the requested cd-key is not used in the target server
\ucount\9        in the target server there are 9 players using cd-keys


#######################################################################

===========
4) The Code
===========


-------------------------
A] crash of games'servers
-------------------------

To test this bug is needed the simple sending of the char ';' to the
UDP query port of the vulnerable game server that is hosting the match
who will crash immediately, however I have written also an useful
proof-of-concept:

    http://aluigi.altervista.org/poc/gshboom.zip


-------------------
B] privacy problems
-------------------

The following is a tool to check the games that use the hidden Gamespy
code, it is able to send all the availables 4 commands (remember that
"uok" and "unok" aren't queries but replies so they cannot be used):

    http://aluigi.altervista.org/papers/gshinfo.zip

Then I have written also a simple packet analyzer for Windows to know
and decode on the fly all the UDP packets sent and received from the
Gamespy master server or by any other host choosen by the user:

    http://aluigi.altervista.org/papers/gshsniff.zip

The latest tool instead is a logger used to log all and only the
encoded commands sent and received on a specific UDP query port:

    http://aluigi.altervista.org/papers/gshlog.zip


#######################################################################

======
5) Fix
======


----------------
Official patches
----------------

As already said, some weeks ago Gamespy has released an updated SDK
that should fix the vulnerability so virtually all the vulnerable games
that I didn't know were vulnerables have or will have a fix soon.

However ALL the developers of the vulnerable games I knew vulnerables
and I have personally checked have been quickly alerted with multiple
mails for one month.

The following is the patches'situation in the moment I'm writing:

 Battlefield 1942.....................FIXED only Linux DS 1.6RC2.
     I was in contact with Dice about the bug but after the Linux
     dedicated server patch I lost any contact with them (no replies)
     so I don't know the current status of the fixes for the retail and
     the win32 dedicated server
 Contract Jack........................NOT, seems no more supported
 Gore.................................NOT, MYFIX
 Haegemonia...........................NOT, seems to use a modified
     SDK so cannot be crashed with the classic attack but contains the
     vulnerable instructions
 Halo.................................FIXED in 1.04
 Hidden & Dangerous 2.................NOT, MYFIX DS only
 IGI 2: Covert Strike.................NOT, MYFIX DS only
 Judge Dredd: Dredd vs. Death.........NOT
 Need For Speed Hot Pursuit 2.........NOT
 Terminator 3: War of the Machines....FIX is coming, however it is not
     vulnerable to the classic attack explained in the previous section
 TRON 2.0.............................NOT, seems no more supported


--------
My fixes
--------

Fortunally patching the bug is very very simple so I have written some
manual patches (need hex editor) that fully patch the problem in almost
all the unpatched games:

Game                          file               offset    old  patch
----------------------------------------------------------------------
BF1942 win32 DS 1.6.19        BF1942_w32ded.exe  00042370  7f   77
Gore 1.48 and 1.49            gore.exe           000B86F2  7f   77
Hidden & Dangerous 2 1.04 DS  HD2DS.exe          003498CA  7f   77
Igi2 1.3 dedicated server     igi2.exe           001C937A  7f   77

  All the other games or retail versions use encrypted executables for
  their lame and useless CD protections and I don't and I can't support
  them with my fixes.
  This is another confirmation that CD protections are a limit for real
  users and in this case also for people who wanna fix their
  "no-more-supported" games:
  http://aluigi.altervista.org/patches/nocd.txt

Explanation of my fix
---------------------
My fix simply converts a JG (signed comparison) in a JA (UNsigned).
Practically when strchr() fails it returns a 0, then the Gamespy
function does a "0 - buff" to find how big is the query and then checks
if the result is major than 32.
BUT this comparison is signed (+/-) so the result of "0 - buff" in
reality is minor than 32 and the comparison fails.
My fix so does simply an UNsigned comparison so "0 - buff" is major
than 32 and the malicious query is successfully rejected.


#######################################################################

=============
6) Conclusion
=============


Trust should be gained with real facts and not with lies and secrets.


#######################################################################


--- 
Luigi Auriemma
http://aluigi.altervista.org


[Index of Archives]     [Linux Security]     [Netfilter]     [PHP]     [Yosemite News]     [Linux Kernel]

  Powered by Linux