connection packet q3 engine based games

Holy · **Joined:** 29 Dec 2008 00:52 **Posts:** 5

I was wondering whether it would be possible to modifie the ip send within the connection packet of q3 engine based games.

Code:

\g_password\none\cl_guid\xxx\cl_punkbuster\1\cl_anonymous\0\snaps\20\rate\32000\name\player\cl_wwwDownload\1\protocol\84\qport\18535\challenge\1928440079\ip\192.168.178.27:27961

(Enemy Territory 2.60b)

Using the sudppipe plug-in doesn't work at all, it simply drops the modified \ip\ part and places the real one again.

Also, the connection packet for omni-bots looks quite different to the "real" one.

Code:

\name\[BOT]Chan\rate\25000\snaps\20\ip\localhost\cl_guid\OMNIBOT0200000000000000000000000

They don't seem to have to get a challenge, send the protocol etc.
Would it be possible to trick a normal client into sending such a connection packet instead of the other?

aluigi · **Posted:** 05 Oct 2009 21:03

the \ip\ field is automatically set by the server to the real ip of the client:
- if the field is already specified by the client it gets modified
- if the field is not there (normal behaviour) the server adds it, this one was the cause of the good old unban bug

anyway if you want to "play" with the connect packet sent by your client some time ago I wrote a plugin for sudppipe which does exactly this, modifying pre-existent fields or adding them if they were not sent by the client:
http://aluigi.org/testz/q3conmod_sudp.zip

anyway without the challenge value the client can't join the server, that's the security protection of the quake3 engine versus spoofing attacks.

aluigi · **Posted:** 11 Oct 2009 12:07

Holy why you deleted your post?
I have saved it here:
---

Holy wrote:

Quote:

I think its time to clear up some confusion.
First of all, this isn't a genuine spoof in the true sense of the word, the actual .IP used for communication to the client remains the same. The engine (that is, etded) only provides the IP one time only, right when vmMain() is called with GAME_CLIENT_CONNECT. The engine gets the IP from the socket and saves it in the engine-stored userinfo string for future reference by the mod.

As you know, the client can change the userinfo string when you change your name for example. A simple hook can be crafted that directly sends the userinfo cmd to the server. In fact, this is nothing more then sending this:

xxxxuserinfo "name\myname\ip\myspoofed-ip"

and in fact you wouldn't need a hook at all to pull this one off, a single perl script (one that issues rcon commands for etadminmod for example) could be modified to send this data to the server outside of the game itself.

Earlier versions of ET (<2.56) did not check for extraneous \ip fields in the userinfo string, so if the user added one, it would simply overwrite the server-provided ip value, resulting in a true spoof (mod-wise).

Since 2.60 this has been fixed, the engine now deletes all \ip fields from incomming userinfo string. However, and this is what the exploit is all about, it doesn't delete what comes after it.

If the userinfo string looks like "\name\mee\\ip\ip\ip\void" the server makes it into "\name\meee\void" as you can see an erreneous fieldname 'void' is introduced, which disrupts mod's trap_getInfoValueForKey function.

If the \ip\void is placed correctly, this will actually result in an empty guid value and an empty IP value, which will cause all the trouble later on.

reference

---
and this is my reply:
the original ET 2.60b (aka without mods) is not affected.

nothing results in an empty nickname there, tested with q3conmod_sudp:
-L "\ip\void"
-L "\ip\\"
-L "name mee\\ip\ip\ip\void" // technically senseless because flips parameters with values
-L "name mee\ip\ip\ip\void"
and others

Holy · **Joined:** 29 Dec 2008 00:52 **Posts:** 5

The deletion was rather an accident. :/
^^
In the text I've quoted, doesn't he talk about a new userinfo? I mean changing the userinfo when already connected to the server? (like through the name change). Not sure if that makes a difference, just a thought.

aluigi · **Posted:** 11 Oct 2009 13:54

the problem is that doesn't exist the out-game command "userinfo" to test with a "perl script".

"userinfo" is an in-game command and so it's not possible to send a simple packet to process it otherwise if it was possible was enough to use a "udpsz -p 27961 -f packet.dat SERVER 27960 -1" to test it.

even with q3fill the problem doesn't happen, the difference is that q3fill uses only the "connect" packet so the "SV_UserinfoChanged" function is called in that occasion without the possibility that a subsequent "userinfo" changes the info provided in "connect" (like could happen with a normal client and q3conmod).
and even modifying the executable of the game replacing any "rate", "snaps", "cl_wwwdownload" and some other fields with "ip" doesn't change the effect.

I'm not saying that the problem doesn't exist, I mean only that the problem doesn't exist in the plain ET 2.60b or if there is a way to test the bug it's for sure not the one described there and not one of all the tests I have performed (don't remain other things to test).

so it's only bug of that etpub mod.

Holy · **Joined:** 29 Dec 2008 00:52 **Posts:** 5

Hey, thanks for the replie!

I got another question concerning the q3conmod plugin. Would it be possible to set the protocol\xxx\qport\xxx\challenge\xxx part at the begining of the connect packet to make a successfull login with the server, even if the following parts exceed the maximum length?

If I modifie the packet to send a cl_anonymous 111... and so on, just until the max_info_string bytes exceeded, the server never actually reads the ..\challenge\.. part resulting in a "No or Bad challenge for this address" error for my client. Now if I'd put that at the beginning of my packet "\protocol\xx\qport\xxx\challenge\xxx\cl_anonymous\111..." would the server accept the connection? (regarding the No or Bad challenge error)

aluigi · **Posted:** 19 Oct 2009 11:17

no, q3conmod replaces the original parameters (so keeping their positions) or places them at the end if they didn't exist.

challenge, qport and protocol are ever at the beginning of the packet, so you could try to change one the 4th parameter.
for example in quake3 the 4th is cl_guid followed by name, rate, snaps, model and so on

Luigi Auriemma

connection packet q3 engine based games