TV2 DRM

[Mulder3]

Can someone comment on my (very)summarized description(and probably wrong) of the DRM used in tv2 that i posted here: http://www.t-hack.com/forum/index.php?topic=565.0

Also, i would like to know how the "x300t client<->server xml communication dump" dump available in the wiki as made.

I noticed that "x-tv2-auth-svrMsgNonce" appears to be some kind of sequence number witch is incremented by 1 in each soap call(probably to avoid replay attacks???)

About the "x-tv2-auth-ticket" :They appear to be the same in every soap call(on the same session) are they a encrypted AES key to decrypt the soap call??? (probably base64 encoded and encrypted with RSA???)

Thanks.

[Hoernchen]

My interpretation of the drm/encryption stuff is about the same. The dump was made by modifying a tv2clientce.exe to dump the data
The AES key for the xml communication is included in the first rsa encrypted answer from the server, this key does not change (or it does change, but only after a loong time), the only thing that does change is the IV which is the first 16 bytes of each base64 encoded xml data blob.

[Mulder3]

My interpretation of the drm/encryption stuff is about the same. The dump was made by modifying a tv2clientce.exe to dump the data
The AES key for the xml communication is included in the first rsa encrypted answer from the server, this key does not change (or it does change, but only after a loong time), the only thing that does change is the IV which is the first 16 bytes of each base64 encoded xml data blob.

So, if i understood right, the xml soap request/response is base64 encoded prior to encryption, and the first 16bytes in the base64 blob used as IV in the AES encryption process, why? I doesn't make sense...They could directly encrypt the xml, why the base64 step? base64 will increase the blob's length... WBXML(binary xml) should be used instead of base64 in that step... Microsoft never ceases to impress me...

[Hoernchen]

Wrapping tons of binary data into xml is one of the reasons why the box needs ages to boot...

[Mulder3]

Wrapping tons of binary data into xml is one of the reasons why the box needs ages to boot...

I totally agree with you, the main benefit of using xml serialization is being human-readable, given the fact that they made a good job preventing that, what's the point of using xml? Specially if they like to embed blobs in the middle of a xml document? They should have used some kind of binary protocol... The same thing about using SOAP for web-services? Everybody is using REST and JSON these days for Web-Services... And i don't even comment the fact that they use RDP protocol for some interactive services...   

[Hoernchen]

Afaik the best part of the whole xml mess is the epg, which is compressed, so the incredibly powerful 300mhz cpu has to parse and decompress ~1MB of binary data wrapped into xml data and then parse the decompressed data again. Unfortunately the rdp stuff is somewhat tamper resistant because it's complicated...

[Mulder3]

Afaik the best part of the whole xml mess is the epg, which is compressed, so the incredibly powerful 300mhz cpu has to parse and decompress ~1MB of binary data wrapped into xml data and then parse the decompressed data again. Unfortunately the rdp stuff is somewhat tamper resistant because it's complicated...

I don't understand what you mean by rdp stuff beeing complicated, RDP does what i does(i.e. the same that remote desktop on windows does, witch is showing a remote screen) If you use wireshark to get one of the rdp servers hostname, you can connect using the normal remote desktop client in windows... They use RDP to show the interface for activating/deactivating channels(witch is just a normal windows program running on a a normal winserver2003 terminal server session, the client in the box just maps the remote button presses to pc keyboard events) since the native mediaroom does not have that capability.

About the AES key used to decrypt/encypt the xml communication, we could dump it to some field on the UI(i.e. the about page) Then it should be easy the write a Wireshark protocol dissector to decrypt the xml instead of relying on a modified tv2client to dump the xml. It will facilitate the reversing for all of us
If someone can provide me a wireshark log and the corresponding AES key for the captured session, i can try to write the dissector....
(I can't capture it myself because i'm still trying to find someone with the necessary soldering skills to enable jtag pin on the SMP)

PS-they use the 31313 port for RDP instead of the usual 3389(at least in my Portuguese provider)

[asgard]

I don't understand what you mean by rdp stuff beeing complicated, RDP does what i does(i.e. the same that remote desktop on windows does, witch is showing a remote screen) If you use wireshark to get one of the rdp servers hostname, you can connect using the normal remote desktop client in windows... They use RDP to show the interface for activating/deactivating channels(witch is just a normal windows program running on a a normal winserver2003 terminal server session, the client in the box just maps the remote button presses to pc keyboard events) since the native mediaroom does not have that capability.

Do you found the password for logging in into the RDP? or is it a sessionbased one?

[Mulder3]

I don't understand what you mean by rdp stuff beeing complicated, RDP does what i does(i.e. the same that remote desktop on windows does, witch is showing a remote screen) If you use wireshark to get one of the rdp servers hostname, you can connect using the normal remote desktop client in windows... They use RDP to show the interface for activating/deactivating channels(witch is just a normal windows program running on a a normal winserver2003 terminal server session, the client in the box just maps the remote button presses to pc keyboard events) since the native mediaroom does not have that capability.

Do you found the password for logging in into the RDP? or is it a sessionbased one?

I didn't found the password used but is shouldn't be to hard to find, a couple years ago i *hacked* a Win2k terminal server box, using arp poisoning and some proggie i don't recall the name that faked a RDP server and logged the password to file, so when one of the win2k users logged in the machine, they were actually logging in my fake rdp server. I will try this trick tomorrow or so, In this particular case i don't even need to use arp poisoning, i can simply configure my router to redirect my provider's rdp server IP to my pc. 

However, in my opinion the password is fixed(or per. provider) or per. box, it's very unlikely that they use a session-based one, because that would imply a modified LSASS(Local Security Authority) or some modifications on Active Directory/Kerberos auth. or other core changes in windows server core components, i really doubt that they dared to mess with windows internals... If they did that(witch i really doubt) then, it's like killing an ant with a nuclear bomb...

[zfeet]

There's TSgrinder for brute forcing Terminal Server and RDP passwords. I shouldn't think it would be difficult to use Ettercap or possibly Cain to crack the password.

Edit: Looks like Cain would be the easiest to do the job.

http://www.oxid.it/cain.html

[Hoernchen]

A rdp session password can be requested and will then be delivered as part of the encrypted xml communication - the complicated part is the extra security, even a valid password is not enough to log in, "someone" has already tried this *cough*. A wireshark dissector is rather useless, because like I already said, the key is inside the rsa encrypted first server response, and it's different each time.

[zfeet]

Have you tried ssl-mitm attacks? I know at least my box actually seems to verify the certificate. There's also the method using sslsniff, Microsoft being very vulnerable to that kind of attack.

http://www.thoughtcrime.org/software/sslsniff/

[Hoernchen]

ssl ?!

[Mulder3]

A rdp session password can be requested and will then be delivered as part of the encrypted xml communication - the complicated part is the extra security, even a valid password is not enough to log in, "someone" has already tried this *cough*.

I haven't look into xml rdp request yet, however from my past experience with windows server terminal services, i'm guessing there two types of RDP authentication here, the first is the standard windows login username/password, witch, by the facts that i already described, it must be a fixed/per provider/per box username/combination, after the windows login session is established, then terminal services in single-application mode(i don't expect they were dumb enough to give a full windows interactive session)  delivers to the box the iptv-specific application, and that application authentication can be a session based one delivered via xml... but that has nothing to do with RDP auth... I am talking about RDP/Windows server stdandard auth.... Of course if you pass the first authentication(the windows one) that is useless without passing the second... but it's a start... 

A wireshark dissector is rather useless, because like I already said, the key is inside the rsa encrypted first server response, and it's different each time.

I know it's different every session, that's why i said that when tv2 decrypts the first rsa sent by the server, the key could be written to some field in the UI by a modified tv2... So if anyone want to sniff something in the xml,then it would be possible to do "live sniffing" with wireshark instead of relying on a modified tv2client to dump xml files to hard disk...(of course the first step will be to get the key from that field in the UI and insert it on Wireshark, on every capture session, since the key changes in every session)
Or tv2client doesn't even have access to key, and the decryption in done inside the XPU??

[Hoernchen]

The rdp username/password is not fixed, that's what is included in the xml data, it looks like this:

Code: [Select]

<GetTerminalServerCredentialsPerApp3Response xmlns="http://www.microsoft.com/tv2/server/tsmonitor">
<GetTerminalServerCredentialsPerApp3Result>Succeed</GetTerminalServerCredentialsPerApp3Result>
<loginCredentials serverName="a.server.T-ONLINE.DE" domainName="TSSF01008" username="rdpsessionuser004" password="Adbe9d0d2-f1cb-48cb-a394-24bb7d2c38b9z" sessionId="5" port="3389" Token="1021cd1d-f894-4681-b4a3-63fcc35719d5" />
</GetTerminalServerCredentialsPerApp3Response> - The token id seems to be needed to connect.
The aes key can be captured, i watched it and the corresponding IVs with the help of http://www.t-hack.com/forum/index.php?topic=293.0 and http://www.t-hack.com/forum/index.php?topic=278.0 about a year ago, but a modified tv2clientce would be much easier