I got a Nexus4 the other day, but since it uses a micro sim whereas my old phone used a normal sim card, I had to get a replacement for it.
Much to my surpise, the only info I needed to provide, was my current phone number! No id card, no proof of ownership, no pin number, not even the old sim card I was replacing, .. nothing!
What's this proximus?! Social engineering courses for dummies?!
Tuesday, March 12, 2013
Monday, March 11, 2013
Portal Connection - update
Something I just noticed today when investigating an IMAP SSL connection issue (using openssl's s_client), is that the handshake packets looked quite similar to the SSL setup of the gw2 portal connection.
ie. what I originally had:
is actually:
ie. what I originally had:
0x14 = ack0x15 = server error0x16 = auth phase0x17 = game packet
is actually:
As shown in RFC5246 - The Transport Layer Security (TLS) Protocol, makes sense actually that they used a library for that instead of rolling their own TLS version.enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType;
Friday, March 8, 2013
Game connection
So last time I talked about the portal connection, now it's time to go over the security on the game connection.
The guildwars2 game connection is encrypted with RC4. Both the send and receive direction start from the same key.
The session key is randomly generated. The exchange of the session key is done using Diffie Hellman key exchange. The server's B value (gb mod p) is pre-computed and stored inside the game client, therefor isn't transmitted during the setup of the connection.
When the connection is established, the client will send a packet with version information and then send it's diffie hellman component to the server, ie. value A ( ga mod p). The value for g is fixed in all versions upto now and is always 4. The value p is changed on each new build of the game.
The actual session key is the computed diffie hellman shared secret xor'ed with the 20 bytes block the server sends at connection setup. However the RC4 initialization function uses a hash function on the key. I haven't been able to identify the hash function, so had to extract the one from the client to be able to initialize my RC4 routine. (search for "b3 98 b4 9f" and you'll find it)
After that, each byte send/received is just encrypted/decrypted with normal RC4.
As for the actual game packets. Every packet type has a predefined structure, which is handled by a MsgPack / Unpack function. Those functions use a table structure to define the types of fields. The actual msgtype numeric value for a packet can change between 2 revisions of the client, so hard coding those is a bad idea for anyone interested in writing an emulator. It is however fairly easy to extract the structure from the game client. While fooling around with it, I wrote a small program using libbfd to parse the executable and dump a header file with the structure of the packets, enabling me to decode a wireshark capture.
ie. example extract:
struct netFieldI serverMsgWvwCliObjectiveMgr_273[] = {
NETFIELD_MSGID(0x273, "serverMsgWvwCliObjectiveMgr_273"),
NETFIELD_BYTE(),
NETFIELD_END()
};
Since they still have that security issue I referred to a while ago, you don't need any hacks to decode the wireshark. I still haven't heard anything back from them, so I'll probably spill the beans about it one of these days.
Just to help anyone fooling around with it, here are the DH params for the current client (16974) :
const unsigned char p[] = {
0xe7, 0x6f, 0x21, 0x5a, 0x30, 0x4c, 0x56, 0x37, 0x83, 0x1b, 0x17, 0x9c, 0xde, 0x5d, 0xc7, 0x1e,
0x10, 0xec, 0xac, 0xbd, 0xd1, 0x96, 0x72, 0xe3, 0xd3, 0xcc, 0x73, 0x49, 0x0a, 0xfb, 0xb9, 0x97,
0x60, 0x49, 0x02, 0xe4, 0x96, 0xac, 0x4c, 0x8a, 0x39, 0xa7, 0xb2, 0xfa, 0xe4, 0x9d, 0x75, 0x98,
0xc6, 0x81, 0xd1, 0xa1, 0x28, 0x1a, 0x6a, 0x57, 0xb6, 0xf9, 0xa5, 0x1a, 0xf5, 0x11, 0x00, 0x89,
};
const unsigned char b[] = {
0x69, 0xa9, 0x48, 0xfe, 0x6b, 0xe4, 0x4e, 0xd4, 0xc3, 0x85, 0x8e, 0xdf, 0xc6, 0xc9, 0xd4, 0xd1,
0x82, 0x10, 0x9e, 0xce, 0x41, 0xcc, 0x34, 0x36, 0x9f, 0x13, 0xad, 0x37, 0x78, 0x05, 0x08, 0x59,
0xd5, 0x68, 0x2e, 0xe1, 0xf8, 0x34, 0xf3, 0x05, 0x9d, 0x12, 0x85, 0x85, 0x24, 0x7a, 0xa4, 0x69,
0xa9, 0x30, 0x98, 0xd4, 0x21, 0x22, 0xb6, 0xa0, 0x7c, 0x4f, 0xbf, 0x5e, 0x8d, 0x4b, 0x34, 0xe8,
};
g ofcourse is 4.
Another useful tip.. the protocol for this game connection is almost identical to how the GPLv3-licensed CyanWorlds.com Engine (Headspin/Plasma) functions. I'm actually fairly sure, they share a common origin, especially since some of the error messages and constant values of a certain template function are identical to this. The message pack/unpack is also similar, but that one isn't an exact copy.
The guildwars2 game connection is encrypted with RC4. Both the send and receive direction start from the same key.
The session key is randomly generated. The exchange of the session key is done using Diffie Hellman key exchange. The server's B value (gb mod p) is pre-computed and stored inside the game client, therefor isn't transmitted during the setup of the connection.
When the connection is established, the client will send a packet with version information and then send it's diffie hellman component to the server, ie. value A ( ga mod p). The value for g is fixed in all versions upto now and is always 4. The value p is changed on each new build of the game.
The actual session key is the computed diffie hellman shared secret xor'ed with the 20 bytes block the server sends at connection setup. However the RC4 initialization function uses a hash function on the key. I haven't been able to identify the hash function, so had to extract the one from the client to be able to initialize my RC4 routine. (search for "b3 98 b4 9f" and you'll find it)
After that, each byte send/received is just encrypted/decrypted with normal RC4.
As for the actual game packets. Every packet type has a predefined structure, which is handled by a MsgPack / Unpack function. Those functions use a table structure to define the types of fields. The actual msgtype numeric value for a packet can change between 2 revisions of the client, so hard coding those is a bad idea for anyone interested in writing an emulator. It is however fairly easy to extract the structure from the game client. While fooling around with it, I wrote a small program using libbfd to parse the executable and dump a header file with the structure of the packets, enabling me to decode a wireshark capture.
ie. example extract:
struct netFieldI serverMsgWvwCliObjectiveMgr_273[] = {
NETFIELD_MSGID(0x273, "serverMsgWvwCliObjectiveMgr_273"),
NETFIELD_BYTE(),
NETFIELD_END()
};
Since they still have that security issue I referred to a while ago, you don't need any hacks to decode the wireshark. I still haven't heard anything back from them, so I'll probably spill the beans about it one of these days.
Just to help anyone fooling around with it, here are the DH params for the current client (16974) :
const unsigned char p[] = {
0xe7, 0x6f, 0x21, 0x5a, 0x30, 0x4c, 0x56, 0x37, 0x83, 0x1b, 0x17, 0x9c, 0xde, 0x5d, 0xc7, 0x1e,
0x10, 0xec, 0xac, 0xbd, 0xd1, 0x96, 0x72, 0xe3, 0xd3, 0xcc, 0x73, 0x49, 0x0a, 0xfb, 0xb9, 0x97,
0x60, 0x49, 0x02, 0xe4, 0x96, 0xac, 0x4c, 0x8a, 0x39, 0xa7, 0xb2, 0xfa, 0xe4, 0x9d, 0x75, 0x98,
0xc6, 0x81, 0xd1, 0xa1, 0x28, 0x1a, 0x6a, 0x57, 0xb6, 0xf9, 0xa5, 0x1a, 0xf5, 0x11, 0x00, 0x89,
};
const unsigned char b[] = {
0x69, 0xa9, 0x48, 0xfe, 0x6b, 0xe4, 0x4e, 0xd4, 0xc3, 0x85, 0x8e, 0xdf, 0xc6, 0xc9, 0xd4, 0xd1,
0x82, 0x10, 0x9e, 0xce, 0x41, 0xcc, 0x34, 0x36, 0x9f, 0x13, 0xad, 0x37, 0x78, 0x05, 0x08, 0x59,
0xd5, 0x68, 0x2e, 0xe1, 0xf8, 0x34, 0xf3, 0x05, 0x9d, 0x12, 0x85, 0x85, 0x24, 0x7a, 0xa4, 0x69,
0xa9, 0x30, 0x98, 0xd4, 0x21, 0x22, 0xb6, 0xa0, 0x7c, 0x4f, 0xbf, 0x5e, 0x8d, 0x4b, 0x34, 0xe8,
};
g ofcourse is 4.
Another useful tip.. the protocol for this game connection is almost identical to how the GPLv3-licensed CyanWorlds.com Engine (Headspin/Plasma) functions. I'm actually fairly sure, they share a common origin, especially since some of the error messages and constant values of a certain template function are identical to this. The message pack/unpack is also similar, but that one isn't an exact copy.
Tuesday, March 5, 2013
Laptop repair
With the repair done on my motherboard, I figured I'd take a look at an old laptop I still had laying around. It's an old Acer Aspire 1510 which has an nvidia graphics chip. The problem with it, was that the display output was all garbled. It was possible to boot it, but when it went into graphics mode, it would usually lock up pretty fast.
This is something that happens to many laptops with nvidia chips. The issue, from what I understand, is that due to the way the chipset heats up, the forces on it cause the solder joints to fracture.
These are BGA (Ball Grid Array) chips, reworking those needs specialized equipment although you can find BGA rework equipment pretty cheap on sites like aliexpress. However for a one off on an old laptop, it would still be too much and I doubt it will be easy the first time you try to reball a BGA.
Luckily, there's a cheaper and much easier way!
Basically what you can do is remove the PCB with the GFX chip and just put it in a normal oven at 200 degrees Celcius for 10 minutes. This will cause the solder joints to reflow and fix the fractures. There's plenty of youtube videos demostrating the effect. So I figured I'd give it a shot... 10 minutes later my freshly baked laptop was resurrected!
This is something that happens to many laptops with nvidia chips. The issue, from what I understand, is that due to the way the chipset heats up, the forces on it cause the solder joints to fracture.
These are BGA (Ball Grid Array) chips, reworking those needs specialized equipment although you can find BGA rework equipment pretty cheap on sites like aliexpress. However for a one off on an old laptop, it would still be too much and I doubt it will be easy the first time you try to reball a BGA.
Luckily, there's a cheaper and much easier way!
Basically what you can do is remove the PCB with the GFX chip and just put it in a normal oven at 200 degrees Celcius for 10 minutes. This will cause the solder joints to reflow and fix the fractures. There's plenty of youtube videos demostrating the effect. So I figured I'd give it a shot... 10 minutes later my freshly baked laptop was resurrected!
Monday, March 4, 2013
Upgrade from hell
About two weeks ago, I decided to finally take the time to upgrade an old Ubuntu 10.04 on a home server. This ofcourse involves a couple of upgrades, since that release is too old to bump to the latest and greatest.
The first upgrade step went rather uneventful, albeit slow. However, my weekend plans were quickly interrupted when after booting the new release, the machine decided to insta power off after 2 minutes. *sigh*
Mind you, this machine did give the occasional warning about temperature issues before the upgrade, so my first reaction was to think too much dust had collected on the CPU cooler. I opened the machine and tried to clear the dirt that had settled between the cooler and the CPU heat sink.. however while doing that, I accidentally broke one of the fan supports.. doh!
This was starting to get annoying. Good thing I had some super glue lying around. Couple of minutes later, the support was firmly reattached and I could continue (though the fan wasn't 100% aligned, causing it to scratch the sides a bit, making a wonderful whining noise)
After this operation, I could boot the board again and it seemed to stay up. Just to be safe, I kept it running overnight before continuing my upgrade fiasco.
The next day, still no reboot issues. So I prepared to do the remaining upgrades. It didn't take long for new issues to pop up. One or two minutes after starting the update manager, the machine again went completely dead. However this time, I couldn't power on the machine anymore. The hardware had completely failed this time. Just my luck again...
Now it just so happens that I recently picked up my interest in electronics again. Therefor instead of throwing out the board, I had a look at what I could do or find about what was wrong.
First investigation showed that I could power it on if only the 20 pin ATX connector was attached, but when the 4 pin ATX connector was also connected, it refused to work for more than 1-2 seconds.
That 4-pin ATX connection supplies 12V to the VRM section of the motherboard. When looking closer, I noticed 2 capacitors which were bulging, which is usually a dead giveaway that they are damaged.
This looked promising...
I had some old CD and DVD audio player I wasn't using anymore, so used those to find some spare parts. Desoldered a couple of capacitors from them and put them in the motherboard. However, while turning the motherboard around a couple of times to see what I was doing, I accidentally also turned one of the caps around. Needless to say the repair didn't work. To add insult to injury, I also took the wrong cap for 1 of the replacements, picking a 6.3V in a place that had a 16V cap.
Some swearing ensued...
When I corrected the error, the board still didn't work (maybe it would have, if I didn't screw up the first fix).
Since working without a schematic is fairly hard, especially for a novice in electronics. I decided to just check on google if there was any info to be found for this motherboard (MSI 6728). To my surprise the service manual with a full schematic turned up. Nice!
Anyway in order to pinpoint the issue, I hooked up my lab power supply and put some juice on the 12V circuit. This immediately showed that there was a short circuit on that rail. When I turned up the amps, one of the MOSFETs quickly heated up, while the neighbouring ones which were for the other phases didn't. So I decided to desolder that MOSFET and check again.
With that one removed, the short on the rail was gone and the lab supply showed a steady 12V. To double check, I reconnected the original PSU, but nothing happened. It seemed the PSU had died due to the short, good thing I still had another PSU around and decided to try that one. This time the board booted again!
Next problem was actually finding a replacement part. I could only find the old part on mouser, but it was EOL and out of stock, but they did have a similar part (I made sure the rise and fall times were the same or better, since I figured that was important.. for details, google for multiphase buck converter). The part was only 60 euro cent, but of course shipping was a biatch, but I offset that by ordering some more goodies :-)
Few days later, the order arrived and a couple of minutes later, I was enjoying the fruits of my labor... my board was booting again! Victory!
The first upgrade step went rather uneventful, albeit slow. However, my weekend plans were quickly interrupted when after booting the new release, the machine decided to insta power off after 2 minutes. *sigh*
Mind you, this machine did give the occasional warning about temperature issues before the upgrade, so my first reaction was to think too much dust had collected on the CPU cooler. I opened the machine and tried to clear the dirt that had settled between the cooler and the CPU heat sink.. however while doing that, I accidentally broke one of the fan supports.. doh!
This was starting to get annoying. Good thing I had some super glue lying around. Couple of minutes later, the support was firmly reattached and I could continue (though the fan wasn't 100% aligned, causing it to scratch the sides a bit, making a wonderful whining noise)
After this operation, I could boot the board again and it seemed to stay up. Just to be safe, I kept it running overnight before continuing my upgrade fiasco.
The next day, still no reboot issues. So I prepared to do the remaining upgrades. It didn't take long for new issues to pop up. One or two minutes after starting the update manager, the machine again went completely dead. However this time, I couldn't power on the machine anymore. The hardware had completely failed this time. Just my luck again...
Now it just so happens that I recently picked up my interest in electronics again. Therefor instead of throwing out the board, I had a look at what I could do or find about what was wrong.
First investigation showed that I could power it on if only the 20 pin ATX connector was attached, but when the 4 pin ATX connector was also connected, it refused to work for more than 1-2 seconds.
That 4-pin ATX connection supplies 12V to the VRM section of the motherboard. When looking closer, I noticed 2 capacitors which were bulging, which is usually a dead giveaway that they are damaged.
This looked promising...
I had some old CD and DVD audio player I wasn't using anymore, so used those to find some spare parts. Desoldered a couple of capacitors from them and put them in the motherboard. However, while turning the motherboard around a couple of times to see what I was doing, I accidentally also turned one of the caps around. Needless to say the repair didn't work. To add insult to injury, I also took the wrong cap for 1 of the replacements, picking a 6.3V in a place that had a 16V cap.
Some swearing ensued...
When I corrected the error, the board still didn't work (maybe it would have, if I didn't screw up the first fix).
Since working without a schematic is fairly hard, especially for a novice in electronics. I decided to just check on google if there was any info to be found for this motherboard (MSI 6728). To my surprise the service manual with a full schematic turned up. Nice!
Anyway in order to pinpoint the issue, I hooked up my lab power supply and put some juice on the 12V circuit. This immediately showed that there was a short circuit on that rail. When I turned up the amps, one of the MOSFETs quickly heated up, while the neighbouring ones which were for the other phases didn't. So I decided to desolder that MOSFET and check again.
With that one removed, the short on the rail was gone and the lab supply showed a steady 12V. To double check, I reconnected the original PSU, but nothing happened. It seemed the PSU had died due to the short, good thing I still had another PSU around and decided to try that one. This time the board booted again!
Next problem was actually finding a replacement part. I could only find the old part on mouser, but it was EOL and out of stock, but they did have a similar part (I made sure the rise and fall times were the same or better, since I figured that was important.. for details, google for multiphase buck converter). The part was only 60 euro cent, but of course shipping was a biatch, but I offset that by ordering some more goodies :-)
Few days later, the order arrived and a couple of minutes later, I was enjoying the fruits of my labor... my board was booting again! Victory!
Friday, December 21, 2012
Portal connection
Portal connection
Time to dig into the specifics of Guild Wars 2's connection...
The portal connection starts off in clear text. The game client will connect, then send a /Sts/Connect command which will include information about the game client.
Example:
P /Sts/Connect STS/1.0
l:252
<Connect>
<ConnType>400</ConnType>
<Address>192.168.1.1</Address>
<ProductType>0</ProductType>
<ProductName>gw2</ProductName>
<AppIndex>1</AppIndex>
<Epoch>999999999</Epoch>
<Program>101</Program>
<Build>1002</Build>
<Process>9999</Process>
</Connect>
P /Auth/StartTls STS/1.0
s:1
l:11
This looks similar to how HTTP requests work. Th
Example:
STS/1.0 400 Success s:1R l:46
<Error server="1001" module="2" line="1518"/>
The 's:1R' here, refers to the original client request. The
The client will begin by sending a buffer starting with:
16 03 03 xx xx
The first byte indicates what kind of packet this is:
14 = ack
15 = server error
16 = auth phase
17 = game packet
The 2 last bytes are the size of the sub buffer that follows.
So looking at the first response the client sends:
16 03 03 00 4e
01 00 00 4a 03 03 xx xx xx ...
Shows a subbuffer of size 0x4e (78 bytes). The first byte is the type of the buffer. If you look closely, it's apparent this buffer is also split up (ie. 0x00 0x4a is yet another size indicator of a sub part). I'm going to skip on some details, if you fire up wireshark you can more easily look at what's there.
There's 1 part that is important in this 0x01 sub buffer and that is a client seed that will be used further on. We need to save 0x20 bytes starting at xx as indicated above.
Also important, is that these sub buffers are used in the HMAC calculation, so we need to keep a sha256 hash of them, excluding the 0x14 sub buffer for digest1.
In code:
if (packet[0] != 0x14)
digest1.process(packet);
digest2.process(packet);
16 03 03 00 34
So we already know 00 34 is the size of the sub buffer, which contains:
02 00 00 30 03 03 xx xx xx
For what follows now, it's useful to read RFC5054 paragraph 2.2. and have a look at the SRP demo page.
The server follows up with a new large packet:
16 03 03 01 14
0c 00 01 10
00 80 xx xx xx .....
00 01 02
08 yy yy yy yy yy yy yy yy
00 80 zz zz zz .....
N = xx xx xx ...
g = 2
s = yy yy yy yy yy yy yy yy
B = zz zz zz ...
16 03 03 00 04
0e 00 00 00
16 03 03 00 86
10 00 00 82
00 80 xx xx xx xx
with A = xx xx xx ...
If you look at the SRP demo page (SRP-6a), you can see how all these values fit together. However GuildWars 2 uses a slightly different way to calculate value x, the RFC version uses:
x = H(salt || H(username||':'||password))
whereas Guild Wars 2 uses:
Then converts this passhash buffer using htonl() and hashes it to form the password field to use in the calculation:passhash = H(lowercase(unicode_pass||unicode_login))
x = H(salt || H(lowercase(username)||':'||H(passhash)))
With all these values, we're able to calculate the shared key S.
The client will now activate encryption by sending the packet:
14 03 03 00 01 01
From now on, the buffers will be encrypted, however the shared key S isn't used as-is for the encryption. First a master key is generated from this and then a key expansion function is used to generate a send and a receive key.
But that's for another post...
Wednesday, December 12, 2012
Hmm it's been far too long since I posted something here...
So a while ago I got interested in seeing how game security was, more specifically how games these days protect people from snooping the traffic. But I was also interested in what counter measures are present to prevent or detect tampering, since bots/cheats are a big issue these days and can potentially ruin a game.
Since I was planning on playing Guild Wars 2 for a bit, I figured it would be a nice target to investigate. The investigation was done on the beta client somewhere in march so my memory is already a bit fuzzy on some details. I've waited this long to post about it, since I didn't want to help bot makers, but I doubt it still matters today. A quick search on google will show there's already plenty of hacks out there, so anything posted here won't make much of a difference.
First thing I noticed was how much information was present in the binary. My initial thought was that this was due to it being a beta client, hence probably contained more debug info. Unfortunately a quick look at a recent binary shows this not to be the case.. there's still lots of useful information present.
For example, even just issuing strings gw2.exe is quite revealing:
Even today's binary (16247) still shows all this detail. Anyone who has ever reversed code will understand how valuable this is during the reversing process.
The game was written in C++ with RTTI enabled, which is also a great source for information. (See Igor Skochinsky's post Recon 2012: Compiler Internals)
Anyway I'll explain the network protocols used by GuildWars 2 on here, which might help some people that are interested in writing a gw2 server emulator. I'll probably spread this over a couple of posts.
While reversing the client, I also discovered a security issue, which to this day is still present. Therefor I've notified ArenaNet today. I'll refrain from explaining the issue for some time, or until ArenaNet resolves the issue. Whichever comes first.
On to the nitty gritty now.
GuildWars 2 uses 2 ports for network communication:
- port 6600 : portal connection
- port 6112 : game server connection
Actually, ports 80 and 443 are also required, but those aren't involved in actual gameplay and it's pretty known which protocol is used on those :-)
The portal connection starts as a clear text protocol, but immediately issues an AUTH TLS command, which initiates a secured connection. The actual data protocol used on this port is XML based. The game uses RapidXML to do the XML parsing.
Example XML piece:
The encryption used on this connection is AES in CBC mode. With a separate session key for incoming and outgoing traffic. An HMAC digest hash is also used, again one for incoming and one for outgoing communications.
The key exchange between the client and server is done via SRP (RFC5054, Secure Remote Password). Since SRP uses Diffie-Hellman, it won't prevent proxying this connection, which would allow people interested in writing cheats to get access to the communication on an external machine, without having to tamper with the actual client binary.
However this doesn't matter much as the game binary I investigated contained no security checks.
The game goes through some key expansion functions to generate the AES & HMAC keys.
NOTE: this is not vulnerable to MITM attacks, as one needs to know the password to be able to proxy the connection.
The connection to the game servers is over an RC4 encrypted connection. Again Diffie-Hellman is used as a key exchange, but in this case the server side packet is precomputed and stored in the game client, ie. the result of ga mod p has been precalculated and is stored in the game binary. Each release uses a new set of keys, so there's no point in trying to find the server key a (would take too long anyway).
The same key is used for transmitting and receiving data, but both paths use a separate state.
From what I heard, this is the same as how it was in GuildWars 1.
The actual data protocol used is a binary protocol with variable sized packets. The client has a MsgPack/Unpack function to (de)serialize the data to/from a C structure.
Again this is similar to how GuildWars 1 worked.
This is a quick overview of how the communication works, I'll go into greater detail in a following post.
GuildWars 2
So a while ago I got interested in seeing how game security was, more specifically how games these days protect people from snooping the traffic. But I was also interested in what counter measures are present to prevent or detect tampering, since bots/cheats are a big issue these days and can potentially ruin a game.
Since I was planning on playing Guild Wars 2 for a bit, I figured it would be a nice target to investigate. The investigation was done on the beta client somewhere in march so my memory is already a bit fuzzy on some details. I've waited this long to post about it, since I didn't want to help bot makers, but I doubt it still matters today. A quick search on google will show there's already plenty of hacks out there, so anything posted here won't make much of a difference.
A First look
First thing I noticed was how much information was present in the binary. My initial thought was that this was due to it being a beta client, hence probably contained more debug info. Unfortunately a quick look at a recent binary shows this not to be the case.. there's still lots of useful information present.
For example, even just issuing strings gw2.exe is quite revealing:
!((m_view == VIEW_GAMEPLAY) && !CharClientContext()->GetControlledCharacter())
!iterator.IsValid()
DNot supported in this configuration!
..\..\..\Game\View\Headless\VhdContext.cpp
N@onRendered
..\..\..\Game\View\Default\VdfRender.cpp
metric < arrsize(m_metrics)
..\..\..\Game\View\Default\VdfLoad.cpp
m_state == STATE_LOAD_MANIFEST
m_state == STATE_MODELS_STREAM
m_mapId == mapId
m_state == STATE_LOAD_CONTENT || m_state == STATE_LOAD_MANIFEST || m_state == STATE_SERVER_WAIT
mapContentLoaded
mapDef != NULL
m_state == STATE_LOAD_CONTENT
m_state == STATE_SERVER_WAIT
m_state == STATE_MAP_STREAM
Even today's binary (16247) still shows all this detail. Anyone who has ever reversed code will understand how valuable this is during the reversing process.
The game was written in C++ with RTTI enabled, which is also a great source for information. (See Igor Skochinsky's post Recon 2012: Compiler Internals)
Anyway I'll explain the network protocols used by GuildWars 2 on here, which might help some people that are interested in writing a gw2 server emulator. I'll probably spread this over a couple of posts.
While reversing the client, I also discovered a security issue, which to this day is still present. Therefor I've notified ArenaNet today. I'll refrain from explaining the issue for some time, or until ArenaNet resolves the issue. Whichever comes first.
On to the nitty gritty now.
The connections
GuildWars 2 uses 2 ports for network communication:
- port 6600 : portal connection
- port 6112 : game server connection
Actually, ports 80 and 443 are also required, but those aren't involved in actual gameplay and it's pretty known which protocol is used on those :-)
Portal Connection
The portal connection starts as a clear text protocol, but immediately issues an AUTH TLS command, which initiates a secured connection. The actual data protocol used on this port is XML based. The game uses RapidXML to do the XML parsing.
Example XML piece:
<Reply>
<UserId>99999999-9999-9999-9999-999999999999</UserId>
<UserCenter>1</UserCenter>
<HasPhone>0</HasPhone>
</Reply>
The encryption used on this connection is AES in CBC mode. With a separate session key for incoming and outgoing traffic. An HMAC digest hash is also used, again one for incoming and one for outgoing communications.
The key exchange between the client and server is done via SRP (RFC5054, Secure Remote Password). Since SRP uses Diffie-Hellman, it won't prevent proxying this connection, which would allow people interested in writing cheats to get access to the communication on an external machine, without having to tamper with the actual client binary.
However this doesn't matter much as the game binary I investigated contained no security checks.
The game goes through some key expansion functions to generate the AES & HMAC keys.
NOTE: this is not vulnerable to MITM attacks, as one needs to know the password to be able to proxy the connection.
Game server connection
The connection to the game servers is over an RC4 encrypted connection. Again Diffie-Hellman is used as a key exchange, but in this case the server side packet is precomputed and stored in the game client, ie. the result of ga mod p has been precalculated and is stored in the game binary. Each release uses a new set of keys, so there's no point in trying to find the server key a (would take too long anyway).
The same key is used for transmitting and receiving data, but both paths use a separate state.
From what I heard, this is the same as how it was in GuildWars 1.
The actual data protocol used is a binary protocol with variable sized packets. The client has a MsgPack/Unpack function to (de)serialize the data to/from a C structure.
Again this is similar to how GuildWars 1 worked.
This is a quick overview of how the communication works, I'll go into greater detail in a following post.
Subscribe to:
Posts (Atom)