New Certificate for SoftSled

Mar 25, 2008 at 4:26 PM
Ok, I was able to come up with a certificate that closely resembles the XBox 360 cert. Below is the command I used in openssl. I know the uuid is wrong but not sure that the host will care. I will try and get the cert and private key into the project. Now we just need to figure out how to code the encryption/decryption stuff.

openssl req -x509 -newkey rsa:1024 -sha1 -config softsled.cnf -outform DER -set_serial 0x125ab07aef0001 -days 7305 -out softsled.cer

Here is the config file that I referenced...

default_bits = 1024
default_keyfile = softsled.key
default_days = 7200

distinguishedname = reqdistinguished_name
#attributes = req_attributes
prompt = no
output_password = softsled
x509extensions = v3ca

#C = GB
#ST = Test State or Province
#L = Test Locality
#O = Organization Name
#OU = Organizational Unit Name
CN = SoftSled
#emailAddress = test@email.address

# req_attributes
#challengePassword = A challenge password

keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = clientAuth,
subjectAltName = URI:uuid:20000000-0000-0000-0200-00125AB07AEF

Mar 25, 2008 at 5:00 PM
Probably best practice to insert the correct uuid anyway. Wouldn't be very hard, simply maintain a reference config file which has %UUID% for the UUID and simply open it, replace the UUID with the Guid generated one and write it to a different location which you subsequently pass to OpenSSSL.
Mar 25, 2008 at 5:26 PM
The first issue we need to tackle is to understand what's happening here in the first MSTA proc call:

"public void TrustAgreementService_Exchange(System.String HostID, System.String HostCertificate, System.Byte IterationsRequired, System.String HostConfirmAuthenticator, out System.String DeviceID, out System.String DeviceCertificate, out System.String DeviceConfirmAuthenticator)"

Obviously we need to first store the host certificate in a private field. After that I don't really know what to do. Sanmile says that the base64 encoded HostConfirmAuthenticator is encrypted with the host cert and we need to decrypt it and encrypt it with our own certificate. Is the private key sent with our certificate? If not how can the host know that we've encrypted it properly with our cert public key?

Mar 25, 2008 at 6:41 PM
Edited Mar 25, 2008 at 6:56 PM
This is similar at the SHA digest value

Mar 25, 2008 at 6:53 PM
Edited Mar 25, 2008 at 6:56 PM
6.2.1 SHA-1
The SHA-1 algorithm SHA-1 takes no explicit parameters. An example of an SHA-1 DigestAlg element is:

<DigestMethod Algorithm=""/>

A SHA-1 digest is a 160-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 20-octet octet stream. For example, the DigestValue element for the message digest:

A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D

from Appendix A of the SHA-1 standard would be:


Mar 25, 2008 at 7:01 PM
Excellent research :)

Sorry if I'm not following properly but what exactly do we respond with as the DeviceConfirmAuthenticator? What is going to be the DigestValue?

Mar 25, 2008 at 7:10 PM
the SHA1 digest value is only a method for validating the integrity of the xml message
Mar 25, 2008 at 7:18 PM
Ah I see, so we can safely respond with "qZk+NkcGgWq6PiVxeFDCbJzQ2J0=" and MC should accept it.
Mar 25, 2008 at 7:20 PM
We should now move our concern over to the second server post and response. Did you say that HostValidateAuthenticator is encrypted with the device cert and then DeviceValidateAuthenticator should be the decrypted value encrypted with the host cert?
Mar 25, 2008 at 7:22 PM
this value is build with the private key and certificate signature
the validation is made by inputing the signature and the public key the result is valide sing or invalide sing

this is the reason why SoftSled need her own certificate. because the device response was made with the private key and the cert signature, the MCE valide the message with the private key

the mcx deveice valide the server message with the public key... then the server send public key .. device validate the hash value by insering the signature and the public certificate. 2 response possible valide digest is valide or not.

Mar 25, 2008 at 7:24 PM
The MC not accept the digest if the result the validation signature return invalide sing.
this is the documentation on the digest validation
Mar 25, 2008 at 7:26 PM
It seems that you've got a good grasp on the situation. Do you think you would have time trying to implement this in code?
Mar 25, 2008 at 10:06 PM
this is the sample for sha1 algo

SHA-1 hashes
SHA1("The quick brown fox jumps over the lazy dog")
= 2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12
Even a small change in the message will, with overwhelming probability, result in a completely different hash due to the avalanche effect. For example, changing dog to cog:

SHA1("The quick brown fox jumps over the lazy cog")
= de9f2c7f d25e1b3a fad3e85a 0bd17d9b 100db4b3
The hash of the zero-length message is:

= da39a3ee 5e6b4b0d 3255bfef 95601890 afd80709
Mar 25, 2008 at 10:08 PM
Pseudocode for the SHA-1 algorithm follows:

Note: All variables are unsigned 32 bits and wrap modulo 232 when calculating

Initialize variables:
h0 = 0x67452301
h1 = 0xEFCDAB89
h2 = 0x98BADCFE
h3 = 0x10325476
h4 = 0xC3D2E1F0

append the bit '1' to the message
append k bits '0', where k is the minimum number ≥ 0 such that the resulting message
length (in bits) is congruent to 448 (mod 512)
append length of message (before pre-processing), in bits, as 64-bit big-endian integer

Process the message in successive 512-bit chunks:
break message into 512-bit chunks
for each chunk
break chunk into sixteen 32-bit big-endian words wi, 0 <= i <= 15

Extend the sixteen 32-bit words into eighty 32-bit words:
for i from 16 to 79
wi = (wi-3 xor wi-8 xor wi-14 xor wi-16) leftrotate 1

Initialize hash value for this chunk:
a = h0
b = h1
c = h2
d = h3
e = h4

Main loop:
for i from 0 to 79
if 0 ≤ i ≤ 19 then
f = (b and c) or ((not b) and d)
k = 0x5A827999
else if 20 ≤ i ≤ 39
f = b xor c xor d
k = 0x6ED9EBA1
else if 40 ≤ i ≤ 59
f = (b and c) or (b and d) or (c and d)
k = 0x8F1BBCDC
else if 60 ≤ i ≤ 79
f = b xor c xor d
k = 0xCA62C1D6

temp = (a leftrotate 5) + f + e + k + wi
e = d
d = c
c = b leftrotate 30
b = a
a = temp

Add this chunk's hash to result so far:
h0 = h0 + a
h1 = h1 + b
h2 = h2 + c
h3 = h3 + d
h4 = h4 + e

Produce the final hash value (big-endian):
digest = hash = h0 append h1 append h2 append h3 append h4
Instead of the formulation from the original FIPS PUB 180-1 shown, the following equivalent expressions may be used to compute f in the main loop above:

(0 ≤ i ≤ 19): f = d xor (b and (c xor d)) (alternative 1)
(0 ≤ i ≤ 19): f = (b and c) xor ((not b) and d) (alternative 2)

(40 ≤ i ≤ 59): f = (b and c) or (d and (b or c)) (alternative 1)
(40 ≤ i ≤ 59): f = (b and c) or (d and (b xor c)) (alternative 2)
(40 ≤ i ≤ 59): f = (b and c) + (d and (b xor c)) (alternative 3)
(40 ≤ i ≤ 59): f = (b and c) xor (b and d) xor (c and d) (alternative 4)
Mar 25, 2008 at 10:10 PM
For more info about the hash algo SHA-1
Mar 25, 2008 at 10:47 PM
this function produce a Sha1 base64 text

ConvertToOwnerAuth Method of the Win32_Tpm Class

The ConvertToOwnerAuth method of the Win32_Tpm class translates a user-provided passphrase input into a 20-byte owner authorization that can be used to interact with the TPM. Methods such as TakeOwnership and ResetAuthLockOut require the resulting owner authorization value.

The conversion process follows the specifications from the Trusted Computing Group.


uint32 ConvertToOwnerAuth(
in string OwnerPassPhrase,
out string OwnerAuth

A string to convert to an owner authorization value. The string can contain any number of alphanumeric characters.

A string derived from the OwnerPassPhrase parameter. This value is a 20-byte binary value encoded to a 28-byte base64 null-terminated string.

Return Value
All TPM errors as well as errors specific to TPM Base Services can be returned.

The following tables lists some of the common return codes.

Return code/value Description
The method was successful.

A Unicode UTF-16LE encoded string is converted to the 20-byte TPM owner authorization value by taking the SHA-1 hash of the string's binary representation. The null termination of the Unicode string is not included in the hash. No salt is used in the SHA-1 hash.

For example, to convert the TPM owner passphrase "1Sample" to a TPM owner authorization value, the SHA-1 hash is taken from the following byte stream:

0x31 0x00 0x53 0x00 0x61 0x00 0x6D 0x00 0x70 0x00 0x6C 0x00 0x65 0x00

To convert a zero-length passphrase to an owner authorization value, the SHA-1 hash is taken of the NULL byte stream.

Client Requires Windows Vista.
Server Requires Windows Server 2008.
MOF Declared in Win32_tpm.mof.

DLL Requires Win32_tpm.dll.

Namespace Defined in \\.\root\CIMv2\Security\MicrosoftTpm.
Mar 25, 2008 at 11:07 PM
.NET Framework 2.0 provides the necessary classes to work with certs, and the various crypto algorithms. I am confident we can crack this. I will go back through Sanmilie's posts to make sure I understand what's happening with the MSTA stuff. Basically, it sounds like it involves
1. Security exchange of certificate and/or public key
2. Host/Device verifying that they can decrypt some data encrypted with the other's private key
3. Using digital signature (message digest) to verify that the messages sent to/from is unaltered.

[editorial: if you think about it, this is a lot of needless garbage just to pass username/password to logon
to the host and 'protect' CableCard DRM....]
Mar 25, 2008 at 11:20 PM
Edited Mar 25, 2008 at 11:27 PM
Excellent stuff, I'll leave all of that with you then! :P

I've sent a message to the tufour dev to see if he has any information on the RDP Virtual Channel Protocol. Another thing we should look into once we have a basic RDP connection up and running is the possibility of implementating the "remote renderer" which allows MCML applications to be rendered natively on the MCX. Though that would come much much later. I would be content with simply a RDP'd ehshell and video/audio working :)

One thing we need to do once we've got the Crypto stuff worked out (thanks!) is to do a /major/ structure and clean-up of the code. Start building a proper shell to handle the communication in a pleasing manner etc. I'm planning (presumptious I know...) on running it on a silent small factor Dell for a sparebedroom.
Mar 26, 2008 at 7:41 PM
ok this have 2 effect 1 the license validation and 'protect' the cable DRM
during the rdp connection mcrmgr.exe valide the device certificate and the deveice UUID if this condition was not respected the RDP session close.
The MCX pairing procedure is realy important for that project.

you can create a dump file from the remode session and open it with IDA for more information about ehshell.exe and mcrmgr.exe
Mar 26, 2008 at 8:26 PM
I have one idea for tring to discouvert wath part of message was use in the sha1 digest validation.
if the ehshell is run with artached debuger. it possible to tract the sha1 function call. i think the ehshell.exe use the frameworks 2 crypo api for this job.. the best way for discouvring the procedure is taging a break point the send function from winsock2

and escalading the function call for discouvert what is the part of message is use to create the sha1 validation.
the messagte was easy to discouvert because this is a xml type.

If any one have time for trying to intercept the message creation from the server.

Presently, it's conference time for my until end june my time is very limited.

2 important think
1 trying to capture the packet before the send.. escalading the function call for trying to discouvert sha1 call function
2 interception the sha1 call function for discouvring the original value frome the sha digest.

Mar 26, 2008 at 9:18 PM
Thanks for the additional information.

Ehshell.exe doesn't handle the processinng of the key exchange directly. Mcx2prov.exe (C:\windows\ehome\mcx2prov.exe) is an RPC server which does the heavy lifting in regards to the processing of the key exchange. The benefit of that is there is a running instance of mcx2prov.exe maintained during the VMC setup.

From your discovery that mcrmgr.exe validates the device cert and the device UUID we need to dynamically build up the device cert as currently the static device cert is hardcoded with a UUID. It shouldn't be too hard if we bundled the bin directory of OpenSSL and simply call it every time to create the tailored certificate. How do you think mcrmgr.exe checks the device cert? Over the Virtual Channel? We need to understand what's actually being sent over the VC. I wonder if it's possible to create an intercepting process which will open-up the named virtual channel and dump what's being exchanged. For that to work we would need to determine the name of the virtual channel which the mcx and the host use.
Mar 27, 2008 at 4:12 PM
I thought the UUID was the same for each type of device. Like all 360s would have one UUID and all Linksys extenders would have a UUID. I guess this doesn't really make sense since what if you had more than one 360 hooked up to a host. So you are right we are going to have to change the cert on the fly. Not sure but there might be a way to set the subject alt name in code.

I think I have found some example code on encrypting/decrypting stuff with public and private keys. I haven't tried to actually use it yet but hopefully soon here. I know the code needs a major rework. The stuff I put out there so far has just been for getting things to work. Feel free to change stuff around as you see fit.

Mar 27, 2008 at 5:31 PM
Edited Mar 27, 2008 at 5:43 PM
Yeah the UUID is unique and thus we probably need to create the cert on the fly. I think the .NET cert classes are all read only meaning we will probably need to resort to using OpenSSL. I'll look into it but I would perfer if we didn't have to.

We can't really start properly implementing the Crypto stuff until we work out SHA1 digiest DeviceConfirmAuthenticator message. We wouldn't be able to even determine if MC is accepting the encrypted values validation checks if the digest message is incorrect as it would simply bomb-out with "failed to exchange certificates". We need to ideally write a rough spec of what we think is going on as currently we have posted messages scattered around everywhere of conflicting beliefs of what is happening. Crypto stuff is really not my area of expertise, is there anyone who would be willing to write a rough doc on what's happening? Sanmile would be ideal if he's listening! :P Once we get a more partly complete implementation I'll do some re-structuring.

btw, isn't Codeplex so awfully slow when navigating, posting or editing forum messages?
Mar 27, 2008 at 5:39 PM
Edited Mar 27, 2008 at 5:40 PM
Actually for now we could just agree on the UUID for the SoftSledclient . The disadvantage would be that for now you couldn't run two Softsled clients on the network but would be a nice quick option until we get a better full implementation.
Mar 27, 2008 at 6:26 PM
I thought this was a good read and I believe this will help with the decoding and encoding. Although this seems a lot harder than it should be.

Mar 28, 2008 at 2:56 AM
Ok, is true the softleds without a regenerative methode for certificat and uuid limite to only one connection per MediaCenter but presently is not very important at this time.

i try to find more information about the sha1 digest validation.
presently ony one way is possible disassembly of the message send procedure to find the real stream use for making the sha1 validation. Normaly is only the field value without xml but i'am not 100% sure.

the procedure for finding this is simple but need long time and little bit of assembly knowlege.
1. download the debug symbol for vista mce
2. use IDA as debuger go to the winsock2 module and set a break point at the send function. any way use for sending a socket message all advence function glue the old send function. THe send message is only a unsigned char buffer.
3. open the call stack when you detect first server post. simply by viewing data in memory easy the xml message is a plain text.
4. go up in the stack and retry untl you see the message without the sha1 digest value.
5. try to determine the adresse of sha1 call if the app use the system function yu can detect more easly the adresse but if is a custom implantation the adresse was more dificul to to find.
6. The Sha1 function as only one parameter the buffer use for calculating the finger print it is also a unsiged char buffer.

this isn't a easy way the procedure need a long time. microsoft is very good in code offuscation. during this procedure you can see a lot of jmp and call to a not nessely usefull function. is nessaire to map the function with a non generic name. More than 1 prolog and epologe can be use normaly use for initialising the variable stack.. i estimate the time for discouvring the procedure to 20 to 40 hour. A additional 10h for validating by test the data use in the sha1 digest message.


Mar 28, 2008 at 3:07 AM
Presently 3 bug is need to solve.

1 the sha1 digest message validation to complete the certificate exchange.
2. making the rdp connection and connectiong a good virtual channel for video streaming function exchange.
3. find a way to use a stream player to connect the stream send via the virtal channel.

In the first time is not important where the rendering is performe only connecting the stream is important.

Step for the victory

1 making a key exchange.
2. Connecting rdp
3. create virtaul channel for receving the mce command. ex. stream url
4. initialising the stream.
5. decoding the stream and play it outside the rdp
6. find a method for rendering the stream inside the mce rdp.

Mar 28, 2008 at 3:25 AM
Jason the projet is reverse engineer Vista Media Center extenders !!

by default reverse engineer isn't easy because no clue was provided by the mcx creator or mce creator.
Presently the best free tools for doing a reverse engineer is IDA and the vista debug symbol.

the xbox360 is hard to decode. and the linksys was also a little device without debug port.
presently no firmware update was avalable in linksys website. the best chance is on the xbox mcx prog for trying to gatter more direct information. but the xbox360 not use the intel processor.

the projet have a great success chance because the key exchange was initiate by mce. is easy to trying to reverse the start procedure of key exchange and validating all step by try and error.

the most harder part was the media stream connection because i haven't the expertise in media rendering. and because the initial commande is retreve via a rdp session.

virtual channel in the rdp session work as a file... you can read and write similar a file. this is a named pipe for rdp. this is not a dificult part but the name of the pipe is important in the same way the virtual mapping can by use .

but some more try is need for detecting the good methode and the good name for the virtual channel.