Tuesday, August 13, 2013
It's no IDA, yet?
Tuesday, July 23, 2013
Central Heating - ROM Dump
I had been meaning to try and dump the ROM image of the main cpu of my central heating, but wanted to wait doing that until the weather was a bit better, afterall I didn't want to blow up the chip in the middle of winter.
I actually didn't expect it was going to be possible to dump it, since most devices have a fuse which you can blow to prevent reading out the image, but it was worth the shot.
So took the CPU to work today, since I have access to a universal chip flasher here. To my surprise, the thing read out the chip without problems! So I now have a dump which I can start to reverse. The processor is an ST62T25, unfortunately I don't have a disassembler for that chip, so that will be the next step, writing one.
I actually didn't expect it was going to be possible to dump it, since most devices have a fuse which you can blow to prevent reading out the image, but it was worth the shot.
So took the CPU to work today, since I have access to a universal chip flasher here. To my surprise, the thing read out the chip without problems! So I now have a dump which I can start to reverse. The processor is an ST62T25, unfortunately I don't have a disassembler for that chip, so that will be the next step, writing one.
Saturday, July 20, 2013
Riglol
So a while back, people discovered the Rigol DS2xxx scope firmware contained a developer key to activate all the extra features. This attracted attention from a couple of people to examine the firmware in more detail.
The firmware was reversed by cybernet. He found that the license check was based on ECDSA. The Elliptic Curve implementation was from MIRACL. He then wrote a tool that took the serial number and options + license key and ran the same verification steps to show if the license was correct or not.
This piqued my interest, so I got involved. Read up on Elliptic Curves and gathered the necessary tools. One of the first paths I tried was to check if they were as stupid as Sony, ie. instead of using a random number, they always used the same value, which was how the PS3 security was broken.
Reason why I wanted to check this, was that the MIRACL library only contains a pseudo random number generator, which is seeded by asking the users for a 9 digit seed. If Rigol was lazy, they might have used the same value each time... worth checking out.
However, for this I needed 2 valid license codes, which was a problem...
So I forgot about that and started looking to trying to solve the elliptic curve discrete logarithm problem. I didn't expect to get very far, I mean.. what would be the chance of Rigol screwing up their Elliptic Curve implementation? Right?!
Well it seems the odds were in my favour :-)
After entering all the curve params in a ECDLP Solver, I was greeted with the private key value in less than a second!!
Now here's the weird thing... the values they used are suspiciously similar to a crackme on the net.
To double check my finding, I used the ecsign from the MIRACL SDK to generate a new signature for a fake serial number. Converted the signature values to the license code format, then ran it through cybernet's tool to see if the license was accepted. The last line of the output says it all:
Anyway it was a fun challenge and I learned quite a lot about Elliptic Curves from it.
The firmware was reversed by cybernet. He found that the license check was based on ECDSA. The Elliptic Curve implementation was from MIRACL. He then wrote a tool that took the serial number and options + license key and ran the same verification steps to show if the license was correct or not.
This piqued my interest, so I got involved. Read up on Elliptic Curves and gathered the necessary tools. One of the first paths I tried was to check if they were as stupid as Sony, ie. instead of using a random number, they always used the same value, which was how the PS3 security was broken.
Reason why I wanted to check this, was that the MIRACL library only contains a pseudo random number generator, which is seeded by asking the users for a 9 digit seed. If Rigol was lazy, they might have used the same value each time... worth checking out.
However, for this I needed 2 valid license codes, which was a problem...
So I forgot about that and started looking to trying to solve the elliptic curve discrete logarithm problem. I didn't expect to get very far, I mean.. what would be the chance of Rigol screwing up their Elliptic Curve implementation? Right?!
Well it seems the odds were in my favour :-)
After entering all the curve params in a ECDLP Solver, I was greeted with the private key value in less than a second!!
Now here's the weird thing... the values they used are suspiciously similar to a crackme on the net.
To double check my finding, I used the ecsign from the MIRACL SDK to generate a new signature for a fake serial number. Converted the signature values to the license code format, then ran it through cybernet's tool to see if the license was accepted. The last line of the output says it all:
License Key is VALID
Anyway it was a fun challenge and I learned quite a lot about Elliptic Curves from it.
Tuesday, July 16, 2013
Central Heating - Decoding
After staring some time at the logic capture of my central heating, I was able to decode the way data is encoded by the unit.
The smallest unit in the capture is 6.80ms. It takes 4 units to make up 1 bit/symbol, not exactly a high speed bus. There are 3 different patterns that show up in the cap:
MARK MARK SPACE SPACE
MARK SPACE SPACE SPACE
MARK SPACE MARK SPACE
The transmission has 56 of these patterns, followed by a silence period. This means that each transmission totals 7 bytes. I used the arduino to decode this sequence and output the result on the serial. The MARK SPACE MARK SPACE pattern is decoded as a set bit, while the other 2 decode to a 0 bit. I have no clue as to why there's 2 patterns to indicated a zero, ie. MARK MARK SPACE SPACE and a MARK SPACE SPACE SPACE, maybe it has something to do with providing the remote unit enough power to load up it's internal capacitor, since that unit is completely powered from the 2 wire bus.
I found that to debug the timing of the code, it's quite useful to use an extra IO pin on the arduino, hooked up the the 2nd channel of the oscilloscope and then toggling the line when something goes wrong. By displaying both the CV signal and the debug channel signal on the scope, it was quite easy to see where the code lost track of the signal.
After some fiddling, this is what I got out of the signal:
The communication gives 4 sets of 7 bytes, then repeats. Now it was time to play with the heating and see which values changed...
The smallest unit in the capture is 6.80ms. It takes 4 units to make up 1 bit/symbol, not exactly a high speed bus. There are 3 different patterns that show up in the cap:
MARK MARK SPACE SPACE
MARK SPACE SPACE SPACE
MARK SPACE MARK SPACE
The transmission has 56 of these patterns, followed by a silence period. This means that each transmission totals 7 bytes. I used the arduino to decode this sequence and output the result on the serial. The MARK SPACE MARK SPACE pattern is decoded as a set bit, while the other 2 decode to a 0 bit. I have no clue as to why there's 2 patterns to indicated a zero, ie. MARK MARK SPACE SPACE and a MARK SPACE SPACE SPACE, maybe it has something to do with providing the remote unit enough power to load up it's internal capacitor, since that unit is completely powered from the 2 wire bus.
I found that to debug the timing of the code, it's quite useful to use an extra IO pin on the arduino, hooked up the the 2nd channel of the oscilloscope and then toggling the line when something goes wrong. By displaying both the CV signal and the debug channel signal on the scope, it was quite easy to see where the code lost track of the signal.
After some fiddling, this is what I got out of the signal:
26 66 74 24 02 7B 0A 0010_0110 0110_0110 0111_0100 0010_0100 0000_0010 0111_1011 0000_1010
60 66 75 FF FF 00 20 0110_0000 0110_0110 0111_0101 1111_1111 1111_1111 0000_0000 0010_0000
26 06 77 FF FF 00 20 0010_0110 0000_0110 0111_0111 1111_1111 1111_1111 0000_0000 0010_0000
60 FF 76 25 02 78 0A 0110_0000 1111_1111 0111_0110 0010_0101 0000_0010 0111_1000 0000_1010
The communication gives 4 sets of 7 bytes, then repeats. Now it was time to play with the heating and see which values changed...
Monday, July 15, 2013
DAoC - The middle man
We've already seen that the key generation isn't up to par, neither is the actual way how the RC4 encryption is used... but there's an even bigger issue. The game is susceptible to a man-in-the-middle attack (MITM).
The game client has no way of knowing if the traffic it receives is indeed coming from the official servers. Games like Guild Wars2 use Diffie-Hellman to exchange the encryption key, but they have the server part baked into the client binary. Therefor in a game like that, you can't impersonate the server without changing the client binary (unless they leak their server binary ofcourse *wink*).
Now, in Mythic's defense, the DAoC client does use RSA to transmit the RC4 session key to the server, which means a man in the middle attacker won't be able to decrypt this packet and sniff the encryption key (unless you found a solution for the factoring problem).
So... where's the problem then?
The issue is with the initial connection setup. The client connects to the server and sends a packet with it's info. The server then responds with the following packet:
0000: 22 01 31 01 0a 03
Which tells the client what version the server is running, but more importantly, tells the client to switch to encrypted communication mode. Yes, there's actually 2 modes the client can work in! Encrypted and non-encrypted mode.
This opens the possibility for a MITM attack. If we proxy the data between the client and the server and change the 01 into 00, we can trick the client to work in non-encrypted mode. To the server, we respond with an RSA encrypted RC4 key, which the proxy creates itself. From then on, it's just passing traffic while encrypting/decrypting the data between the 2.
Another big problem is that the communication protocol doesn't use anything like SRP to prevent people from sniffing and reusing the password. Therefor, the attacker will be able to grab the login and plain text password from the intercepted session.
As a proof of concept, I wrote a small proxy that did just that. It ran on a linux machine in between the client and the server and used the transparent proxying (TPROXY) feature of the linux kernel to redirect the traffic to the proxy program. Worked like a charm.
The game client has no way of knowing if the traffic it receives is indeed coming from the official servers. Games like Guild Wars2 use Diffie-Hellman to exchange the encryption key, but they have the server part baked into the client binary. Therefor in a game like that, you can't impersonate the server without changing the client binary (unless they leak their server binary ofcourse *wink*).
Now, in Mythic's defense, the DAoC client does use RSA to transmit the RC4 session key to the server, which means a man in the middle attacker won't be able to decrypt this packet and sniff the encryption key (unless you found a solution for the factoring problem).
So... where's the problem then?
The issue is with the initial connection setup. The client connects to the server and sends a packet with it's info. The server then responds with the following packet:
0000: 22 01 31 01 0a 03
Which tells the client what version the server is running, but more importantly, tells the client to switch to encrypted communication mode. Yes, there's actually 2 modes the client can work in! Encrypted and non-encrypted mode.
This opens the possibility for a MITM attack. If we proxy the data between the client and the server and change the 01 into 00, we can trick the client to work in non-encrypted mode. To the server, we respond with an RSA encrypted RC4 key, which the proxy creates itself. From then on, it's just passing traffic while encrypting/decrypting the data between the 2.
Another big problem is that the communication protocol doesn't use anything like SRP to prevent people from sniffing and reusing the password. Therefor, the attacker will be able to grab the login and plain text password from the intercepted session.
As a proof of concept, I wrote a small proxy that did just that. It ran on a linux machine in between the client and the server and used the transparent proxying (TPROXY) feature of the linux kernel to redirect the traffic to the proxy program. Worked like a charm.
Friday, May 24, 2013
DAoC Random function
As I mentioned before, the generation of the RC4 key in this game can easily be instrumented to generate the secret we want.
The pseudo code to generate the RC4 key looks something like this:
They are also feeding back the input into the RC4 state, by incrementing the j variable by the unencrypted input byte.
Another issue with just using the rdtsc instruction to generate random data, is that this instruction can be made priviledged by setting the TSD flag in CR4, ie. cause a system trap to occur when executed in userspace / ring3, which means there's full control over what this RC4 key generator produces without even having to alter the game binary or redirecting system APIs. Example code to do something like this, can be easily found, ie. here.
The pseudo code to generate the RC4 key looks something like this:
repeat 0x40 timesThis block is then RSA encrypted and exchanged with the server. From then on, all packets get encrypted with this RC4 key. One interesting thing also, is that the game doesn't use RC4 as a continuous stream cipher, instead each packet resets the RC4 cipher to the initial state. This stems from the fact that the game can use UDP for communication and therefor needs to handle the case where packetloss occurs, which would desync the state, but it also makes this less secure. I'm not an expert in cryptography, but I'm sure this enables some interesting crypto attacks to decipher the content. From what I've read, the first few bytes of RC4 are already less random than they should be, which is why it's suggested to advance the RC4 state a couple of bytes before actually using it on your data, which this game doesn't do. Couple that with knowledge of some of the payloads' fixed bytes and I'm sure a real cryptographer can decipher a stream without much effort. Now there's 1 thing they did to try and counter some of this. Instead of starting the packet encrypt from the first byte of the packet, they start it from the middle of the packet, which helps a bit with the known byte value issue.
use rdtsc to generate 1 byte
verify the resulting byte isn't 0
sleep 1
They are also feeding back the input into the RC4 state, by incrementing the j variable by the unencrypted input byte.
Another issue with just using the rdtsc instruction to generate random data, is that this instruction can be made priviledged by setting the TSD flag in CR4, ie. cause a system trap to occur when executed in userspace / ring3, which means there's full control over what this RC4 key generator produces without even having to alter the game binary or redirecting system APIs. Example code to do something like this, can be easily found, ie. here.
Tuesday, April 16, 2013
DAoC vulnerability update
So I got a mail back from the janitor at Mythic regarding my vulnerability report:
Oh boy... what can I say... FAIL!
Hello Karl,
Thank you for contacting Dark Age of Camelot Support.
With regard to your appeal, Ticket#: [XXXXX], we cannot field feedback or suggestions regarding how the game may be altered or improved. However, your opinions and thoughts are always valued!
To appropriately submit your suggestions and feedback regarding game content, mechanics, or design, please go to http://darkageofcamelot.com/contact. On this page, you will find a form which will allow you to submit your suggestions and opinions directly to our development team.
This email address is only for issues of a billing or technical nature, and not issues related to feedback or concerns regarding elements of the game.
Thank you for playing Dark Age of Camelot!
XXXX
Oh boy... what can I say... FAIL!
Monday, April 15, 2013
Hacking the central heating
The central heating I have installed in my home (Integra Zero F29e) doesn't have any network functionality or possibility to interface with a computer. It's using a 2 wire thermostat as a control. The thermostat is powered from the 2 wires it uses to communicate with the central unit.
As I was interested in a computer interface, I set out to investigate what my options were. After some googling around, I got up to speed on the types of interfaces that exist for these kinds of devices. It seems there are 2 major interfaces. One is called Ebus and the other OpenTherm. Both of these have been dissected by hobbyists and therefor there are devices / schematics available to make an interface.
When I started this endevour, I only had a multimeter available. Measuring the 2 wires, it gave a voltage around 20-24v, which led me to believe it was an Ebus interface. So I put something together to convert the data on the bus to TTL levels, since Ebus is just 9600bps serial communication. However, it didn't quite work out.
While researching all this stuff, I figured an oscilloscope would come in handy and since these days you can pick up a digital oscilloscope pretty cheap, I went ahead and ordered a cheap Rigol DS1052e. Once I had the scope, it quickly became apparent that this system wasn't Ebus based.
As I was already on a shopping spree, I also got myself an Open Workbench Logic Sniffer and some arduino's.
I figured it would be simpler to bypass the bus driving circuit, so I had a look at the PCB of the central unit. The PCB was quite simple, it's nothing more than a couple of relays controlled by a microprocessor, in this case an ST62T25.
Here the scope came in handy to check the pins on the MCU, which helped me to figure out which pins were used for the transmission and reception of data. With this knowledge, I could hook up the logic sniffer on those pins and get a dump of the data transmission. Here's how it looked:
For anyone with the same device, the data of the MCU pins are available from the topside of the PCB at points J1 (green wire) and J10 (white wire), the black wire is just a ground point.
With the logic dump available, my next step was to try and decode it. Which I'll explain in another post.
As I was interested in a computer interface, I set out to investigate what my options were. After some googling around, I got up to speed on the types of interfaces that exist for these kinds of devices. It seems there are 2 major interfaces. One is called Ebus and the other OpenTherm. Both of these have been dissected by hobbyists and therefor there are devices / schematics available to make an interface.
When I started this endevour, I only had a multimeter available. Measuring the 2 wires, it gave a voltage around 20-24v, which led me to believe it was an Ebus interface. So I put something together to convert the data on the bus to TTL levels, since Ebus is just 9600bps serial communication. However, it didn't quite work out.
While researching all this stuff, I figured an oscilloscope would come in handy and since these days you can pick up a digital oscilloscope pretty cheap, I went ahead and ordered a cheap Rigol DS1052e. Once I had the scope, it quickly became apparent that this system wasn't Ebus based.
As I was already on a shopping spree, I also got myself an Open Workbench Logic Sniffer and some arduino's.
I figured it would be simpler to bypass the bus driving circuit, so I had a look at the PCB of the central unit. The PCB was quite simple, it's nothing more than a couple of relays controlled by a microprocessor, in this case an ST62T25.
Here the scope came in handy to check the pins on the MCU, which helped me to figure out which pins were used for the transmission and reception of data. With this knowledge, I could hook up the logic sniffer on those pins and get a dump of the data transmission. Here's how it looked:
For anyone with the same device, the data of the MCU pins are available from the topside of the PCB at points J1 (green wire) and J10 (white wire), the black wire is just a ground point.
With the logic dump available, my next step was to try and decode it. Which I'll explain in another post.
Saturday, April 13, 2013
Blast from the past
Since I've been talking about game security the last couple of posts. I figured I revisit an old target I once investigated.
Many many moons ago I blogged about getting Dark Age of Camelot to run in wine. While reversing that game, I also had a look at how the actual game connection works, because that's something that always interests me, ie. the security aspect of it. In this case, there was an extra reason to have a look, since at one time early on in the game's life, a security issue was found and reported to them:
So fast forward 10 years, you'd think it would be pretty secure by now... unfortunately it appears it's still flawed in some way. The thing is, even after all these years, the game is still susceptible to a man-in-the-middle attack. It's perfectly possible to intercept / proxy a connection from the game without needing any details / account info from the player.
So how does the game connection work?
The communication is rather straight forward. There's only 1 connection maintained between the client and the server. The game supports both UDP or TCP for it's game session. This probably stems from the old days where most players actually used a dialup connection, where you don't want TCP retransmissions to cause issues.
Most of the game packets are known. There has been an emulator around for quite some time now and since it's open source, anyone can have a glimpse at how it all works.
The connection is encrypted with RC4. It generates a random session key which gets exchanged via RSA encryption. The generation of the RC4 key could also be improved, since how it currently is done, makes it extremely easy to intercept by using some virtualization techniques. This has as effect that one can get the game to generate the key you want, without having to make any patches to the game client, which is imho not a good thing.
But worse is the fact that this all doesn't matter, due to another vulnerability. But before explaining that one, I'll see if there's still anyone in charge of the game code (most players of the game, seem to think the janitor is the only guy left in the building.. so we'll see how it goes)
Anyway, let's hope the old Mythic gang @ City State Entertainment will have a better security track record if their Kickstarter project, Camelot Unchained, funds!
Many many moons ago I blogged about getting Dark Age of Camelot to run in wine. While reversing that game, I also had a look at how the actual game connection works, because that's something that always interests me, ie. the security aspect of it. In this case, there was an extra reason to have a look, since at one time early on in the game's life, a security issue was found and reported to them:
CVE-2004-1855
Dark Age of Camelot before 1.68 live patch does not sign the RSA public key, which could allow remote malicious servers to gain sensitive information via a man-in-the-middle attack.
A more detailed description is available at:
http://capnbry.net/daoc/advisory20031211/daoc-billinginfo-exploit.html
So fast forward 10 years, you'd think it would be pretty secure by now... unfortunately it appears it's still flawed in some way. The thing is, even after all these years, the game is still susceptible to a man-in-the-middle attack. It's perfectly possible to intercept / proxy a connection from the game without needing any details / account info from the player.
So how does the game connection work?
The communication is rather straight forward. There's only 1 connection maintained between the client and the server. The game supports both UDP or TCP for it's game session. This probably stems from the old days where most players actually used a dialup connection, where you don't want TCP retransmissions to cause issues.
Most of the game packets are known. There has been an emulator around for quite some time now and since it's open source, anyone can have a glimpse at how it all works.
The connection is encrypted with RC4. It generates a random session key which gets exchanged via RSA encryption. The generation of the RC4 key could also be improved, since how it currently is done, makes it extremely easy to intercept by using some virtualization techniques. This has as effect that one can get the game to generate the key you want, without having to make any patches to the game client, which is imho not a good thing.
But worse is the fact that this all doesn't matter, due to another vulnerability. But before explaining that one, I'll see if there's still anyone in charge of the game code (most players of the game, seem to think the janitor is the only guy left in the building.. so we'll see how it goes)
Anyway, let's hope the old Mythic gang @ City State Entertainment will have a better security track record if their Kickstarter project, Camelot Unchained, funds!
Fixed!
So I was finally contact by ArenaNet regarding the issue I mentioned. It seems my original mail regarding the issue I posted about, was unfortunately lost in cyberspace. So they never read my report.
Anyway, I must say I was pleasantly surprised by the way they handled it. Respect!
Anyway, I must say I was pleasantly surprised by the way they handled it. Respect!
Thursday, April 11, 2013
Fixed?!
"We've updated the game for routine maintenance only. No content changes were included. ~RB2"
-- https://twitter.com/GuildWars2/status/322082110334697472
It seems the GwSrv and AuthSrv libraries aren't on the CDN. I wonder if they finally fixed their leak?! Sad that mailing them didn't work, but posting about it got the job done... The old files however are still present.
-- https://twitter.com/GuildWars2/status/322082110334697472
It seems the GwSrv and AuthSrv libraries aren't on the CDN. I wonder if they finally fixed their leak?! Sad that mailing them didn't work, but posting about it got the job done... The old files however are still present.
Thursday, March 28, 2013
Give a man a fish...
I guess ArenaNet has had time enough to react and fix their broken security, so it's
time to explain what exactly they messed up.
As I showed in a previous post, the game connection uses diffie hellman to negotiate the RC4 session key but stores the server's side pre-calculated in the client.
So how in hell did I calculate the server's secret?! ie. For the current release (17368) where do I get this from:
const unsigned char p[] = {
0xa1, 0xc5, 0x67, 0x7b, 0x95, 0xef, 0x74, 0x12, 0xcf, 0x58, 0xab, 0xef, 0xb0, 0x60, 0x9e, 0xa7,
0xab, 0x6c, 0x15, 0x3c, 0x6d, 0xf0, 0x24, 0xac, 0x0d, 0x02, 0x26, 0x66, 0xd1, 0x65, 0x28, 0x53,
0x29, 0xc7, 0xb4, 0xc4, 0x7b, 0xdd, 0xbc, 0x4c, 0x8d, 0xab, 0x7d, 0x6a, 0x7e, 0x26, 0xd7, 0x3c,
0x62, 0xe5, 0x66, 0x5f, 0x38, 0x9f, 0x49, 0x44, 0x6b, 0x18, 0x74, 0x9c, 0x43, 0x7a, 0xf4, 0x17,
};
const unsigned char b[] = {
0x8e, 0xe7, 0x79, 0xf0, 0x00, 0x0d, 0x31, 0xc9, 0xda, 0x45, 0x77, 0x44, 0xd3, 0x47, 0x0a, 0x26,
0x8d, 0x7e, 0xe3, 0x03, 0x02, 0x55, 0x6b, 0x0d, 0x88, 0xc7, 0x65, 0x32, 0x29, 0xbe, 0x1d, 0x71,
0x9f, 0x49, 0x00, 0xf9, 0x65, 0x97, 0xe6, 0x05, 0xda, 0x3b, 0x8f, 0xc0, 0xc7, 0x0b, 0x3a, 0x49,
0xe3, 0xfa, 0x6e, 0x2e, 0x27, 0x54, 0xab, 0x13, 0xae, 0xf5, 0x54, 0x61, 0x29, 0x4f, 0x37, 0x35,
};
To explain it.. we have to look at how the game does it's updates.
ArenaNet is using a content delivery network to distribute game updates. At startup, the game patcher will query an URL on the CDN which contains information about what the current live version is.
This information is at:
http://assetcdn.101.ArenaNetworks.com/latest/101
Now, if you try to access this with your browser, you'll get an authentication error. To pass the authentication check, a header called 'authCookie' has to be passed. Older clients had this header clearly visible in the executable, ie:
$ strings gw2.exe.524178 |grep md5=|cut -c1-
authCookie=access=/latest/*!/manifest/program/*!/program/*~md5=4e51ad868f87201ad93e428ff30c6691
In newer clients it's build through printf style formatting, so it's a bit more effort to get it:
$ strings gw2.exe.570713 |grep md5=|cut -c1-
authCookie=access=/latest/*!/manifest/program/*!/program/*~md5=%s
However, the md5 value is always the same (haven't verified this on the latest clients anymore), so you can just use this value.
$ curl http://assetcdn.101.ArenaNetworks.com/latest/101 -b 'authCookie=access=/latest/*!/manifest/program/*!/program/*~md5=4e51ad868f87201ad93e428ff30c6691'
17368 570713 22680128 570709 5108
This tells us the latest release is 17368, has a fileid of 570713 on the CDN and is 22Mb in size. Equipped with this information, we can download the latest gw2 executable:
$ curl http://assetcdn.101.ArenaNetworks.com/program/101/1/0/570713 -b 'authCookie=access=/latest/*!/manifest/program/*!/program/*~md5=4e51ad868f87201ad93e428ff30c6691' -o gw2.exe
Easy enough...
An update contains much more than just the gw2 executable, there's also patches for the data files and other stuff.
And this is where ArenaNet made a gigantic mistake in my opinion. If you take the previous link and increment the filenumber by one, you get something VERY interesting! For some unknown reason, the actual server code and authentication code is also on the CDN and it's even accessible to everyone that wants a copy!!
If you take fileid 570714 and run it through objdump, you will see it's actually called GwSrv.dll and fileid 570715 is called AuthSrv.dll
Imagine my surprise when I discovered this. By that time, I had already reversed the encryption protocols used on both connections, so it didn't help me for that part, but I also knew one of those 2 DLLs would need access to the server side secret and after some investigating, it was clear the key was contained inside the DLL itself (it could aswell have been loaded from an external file).
Equipped with that info, I wrote a small tool using libbfd which looks for the keys and just dumps them. I later verified they were in fact correct.
To this day, I'm still gobsmacked that a company can make such an error. Makes you wonder how they store all the credit card information of people!
The GwSrv.dll will be particularly interesting for people trying to write an emulator, but it's also nice to get an idea of how their backend is setup.
ie.
$ strings GwSrv.dll |grep -P '^[A-Z].*Srv$'
FileSrv
BuildSrv
DllSrv
AuthSrv
GwSrv
DbSqlSrv
DbCacheSrv
StreamSrv
SiteSrv
DistSrv
AcctHttpSrv
AcctMailSrv
CrashDumpSrv
EventLogSrv
LogQuerySrv
BeaconSrv
CrashSrv
UTournSrv
ConfigSrv
DbNameSrv
BugMailSrv
LogImportSrv
CensusSrv
DummyCliSrv
DbNameTestSrv
DbSrv
RankSrv
FileIdChkSrv
IpBlockSrv
PitchingSrv
ConfigSrv
ObsCtrlSrv
GuildSrv
ReplicationSrv
AssetSrv
EconDataSrv
EconSrv
ClientErrorLogSrv
TournSrv
EmptySrv
PlayerlessSrv
BrokerSrv
ExchangeSrv
GemStoreSrv
TradeSrv
CharUserDataSrv
PortalSrv
HealthSrv
ClientErrorSrv
MetricsSrv
ItemSearchSrv
ItemDataSrv
RestoreSrv
ListTaskSrv
TournSearchSrv
ContentSrv
Pity they didn't put them all on the CDN ;-)
Tuesday, March 12, 2013
Proximus fail!
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?!
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?!
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!
Subscribe to:
Posts (Atom)