Sniffer/SEQ UDP protection: can you add?

[lostinspace]

After all that effort in non-detectable sniffer programs (hook dlls, kernel driver etc...) , sending plain EQ key over UDP seems still like easiest way for SOE to detect us.

So I posted before question if someone can add simple XOR key that we will use on both sides ( SEQ and keysniffer) to encrypt key that we send over UDP. Since best way is not to ask, but to make it, I decided to make such feature.

It would be nice if someone can include this in next normal SEQ version, so I dont need to change files every time :) Also, I have no idea how people who change SEQ code post it, but here it is:



seqdef.xml [line 2536] in 'options for Key loading from file'

above: </section>
add:
<property name="KeyXor">
<int value="0" />
<comment>Value that received key over UDP will be XORed with</comment>
</property>
<property name="KeyOffset">
<int value="0" />
<comment>starting position of 8-byte key within UDP packet</comment>
</property>


main.h [line 128] in struct ShowEQParams

under: uint16_t keyport;
add: uint32_t keyxor;
add: uint16_t keyoffset;


main.cpp [line 323] in main()

under: showeq_params->keyport = pSEQPrefs->getPrefInt("KeyPort",section, 10000);
add: showeq_params->keyxor = pSEQPrefs->getPrefInt("KeyXor", section, 0);
add: showeq_params->keyoffset = pSEQPrefs->getPrefInt("KeyOffset", section, 0);



packet.cpp [line 1021] in decodePacket()

old:
keyStruct* keypacket = (keyStruct *) (packet.getUDPPayload());
m_decode->theKey(keypacket->key);

new:
if (packet.payloadLength()< (8+ showeq_params->keyoffset)) return;
keyStruct* keypacket = (keyStruct *) (packet.getUDPPayload() + showeq_params->keyoffset );
m_decode->theKey(keypacket->key ^ showeq_params->keyxor );





With this default option, all existing keyreaders that send UDP packets to SEQ will continue to work , since default KeyXor=0. Change that value in seqdef.xml into something, and in your keyreader use that same value to xor key that you send.


*EDIT* added support for KeyOffset. If used, you need to place 8-byte key at that offset in packet that you generate in keysniffer. Also packet datalengthh can be arbitrary, as long as its larger than 8 + KeyOffset. I suggest random length for every packet.

[LordCrush]

/cheer lostinspace - point 8 on my todo list solved :D

Thank you !!

What do you think about adding an offset value so that we can hide the XORed key in a Datapacket of random length

e.g.



seqdef.xml [line 2536] in 'options for Key loading from file'

above: </section>
add:
<property name="KeyXor">
<int value="0" />
<property name="KeyOffset">
<int value="0" />
<comment>Value that received key over UDP will be XORed with and the offset the key starts in data.</comment>
</property>


code should be following later ... have my man pages not at work :p

[lostinspace]

LordCrush, offset is very good idea since without it, there is one option for SOE to detect key packets even if XORed:

- they sniff every small UDP packet, XOR first 8 bytes with current key and store IP/port/result in memory
- if next time they get UDP packet for same IP/port, when current key is different (other zone), and if that packed XORed with current key AGAIN produce same result as before - then they will be reasonably sure that data in those packets was EQ key XORed with same value

I already posted in some previous post that solution to that would be KeyOffset. But since this was my first attempt to change anything in SEQ code, just adding XOR key was easy first step :)

[lostinspace]

Added support for KeyOffset, edited first post :)

[suseuser7341]

I would rather use some highlevel protocol and hide the key in the regular spam windows keeps flooding your network with. Aka netbios broadcasts.
However I am not convinced that there is any reason for this at all, because the only place to intercept the udp packet is hooking up the udp call of windows. Thinking of different versions, performance etc, I doubt they start to waste time here.

[lostinspace]

There is obviously regular documented way to put network card in promiscuity mode and to capture packets.

Programs like NetXray ( ShifferPro), and even that sniffer program that comes with win2000 use it normally. No need to 'hook to UDP call in windows' - you just insert your own driver in IP protocol chain.

Also, above change to SEQ ( and one that i made in my keyreader) is easier to implement than flooding net broadcasts or higher level protocols. And with both Offset and Xor value it is unbreakable for SOE.

So, it is simple, it is efficient, and will make me feel secure enough to use UDP packets and stop using file/samba. Its up to you if you need to use it though :)

[fee]

I like the idea of setting an offset to find the key at a random point in the UDP payload. This feature should have been there from day 1, i'll make sure to get this added shortly.

However, I see no compelling reason to support key XORing, it is only serves as bloat. In real world terms, anything we can do they can detect. In practical terms, SOE will not be packet sniffing on your EQ client to look for a random packet containing the key. It is simply not going to happen.

Fee

[lostinspace]

Well, adding offset is in same part of code as adding XOR - its already there in code i posted. And if someone dont want to use it, default xorkey is 0 , so no need to change anything keysniffer codes.


And while I also do not think that SOE will sniff packets, that possibility always exists. If it is easy to protect against that, I do not see why we shouldnt do it.

[LordCrush]

Fee,

i would like the XOR-Code in seq, too ... if you want to make it optional just let us use a #define,

i will add the code with diff every time when i get a new seq, but that means i will often have to add that manually, cause the source file changed.

/wave Fee

and lostinspace - thank you for the coding ... my coding skills never were very high 80..100 ;) and they are a bit rusty (did not use a compiler for over 10 years :D )

[throx]

There's so much network traffic from any computer that analysing it to determine if an arbitrary packet contains a key is incredibly difficult. However, the unlikely nature of the exact key turning up as part of several packets does make the xor concept a worthwhile endeavour (in my opinion). It's far easier to capture packets and see if there's always an outbound packet with the key in it just after you zone than it is to xor arbitrary packets together to test for a simple xor-encrypted outbound packet.

[PD_Dingo]

another posibility could be to send the key in more than one UDP packet, but then there is even more excessive ways to hide the key:

you could also SSH it, PGP it, ROT it, RLE it, Enigma :D it ...

or just zlib compress the data stream from the sniffer, since it would be pretty damn 'near' impossible to break into it if the stream would be already established before eqclient was started,

in the end they can just go hire 10 more anal retentive employees for $800 a month each and have them scrounge the internet for sniffers, add simple 1-2kb of code that will check for each of the sniffers found and ld the player with the sniffer to death, why even bother and try to ban the accounts, it much easier and faster just to make sniffers more nuisance than they are worth. in the end, average joe user will rather stop using sniffers than wait for days for another version/hack that will avoid their detection for few hours, because the same way our joe user gets his 'fix' they can get it too, so the population that uses sniffers will shrink that way to maybe 5-10% of what it is right now, and only people left still using them are the ones that can write their own and don't distribute it.

i can think of atleast 4 different ways how to break sniffers and seq both on regular basis without having to shut down all the eq servers every time to update the stuff, but why give verant any ideas right ? :p

personally i don't think that encryption of any kind would do the trick they can just simply watch the outgoing traffic from the time the player starts zoning until 3-4 seconds afterwards and look for patterns. they don't have to know exactly what is in the packets.

the only better way would be to have program running on another machine that would sniff the traffic and do exactly what eqclient does, since there are people like the guys who work on hackersquest who know how exactly the data are put together by the server it wouldn't be impossible, but even that way can be eliminated.

in the end all depends on how far verant and you guys are willing to go to prevent the other one from breaking into their datastream.

verant just could add overhead map/gps thing like every other rpg game has and would take interest in seq down another notch.

Dingo.

[devnul]

that's definitely true

many people get easily disoriented especially in dungeons, not everyone has excellent spatial awareness

i know a lot of people who set it up mainly so their girlfriends/wives could play and not get disoriented and then lost

seq makes EQ playable for a lot of people, especially women who probably did not cut their teeth in 3d virtual environments as many boys did and thus are not nearly as at home in them

without this functionality they would lose a lot of players

it was very hard to get my wife interested in EQ until I set up SEQ, she always got lost and turned around, disoriented and then fail to heal someone in time and they'd die and she'd feel really bad

with SEQ she always 'knows where she is' and even solo's sometimes

she's certainly not 'farming rare spawns' rofl, she's just trying not to get lost from the group

no question in my mind she'd stop playing without SEQ.. tho I might continue :rolleyes:

but then again.. now that I know she can share this with me we might just find another game that we could play together

so anyway, ultimately.. risk of banning holds no fear for me, if they managed to stop SEQ totally, it's more important to me that my wife share my gaming fun with me than any specific game.. we'd find somethign else

dn

[LordCrush]

/nod devnul