xs4all:With my Dll, is media center crashing as soon as it starts or only when trying to tune an H.264 channel?
Only when you select any SD or HD tv channel.
xs4all:Absolutely not. That's why we need to add more validation code that decides when to modify the year bits. asm495 did a great work by finding that the 5D loop (the loop that regenerate the code that compare the year to 2008) is called twice when using regsvr32. However, it's very much possible that Media Center uses that same loop for other code generation. To know it for sure, we will have to debug Media Center and find out when the loop is called.With my Dll, is media center crashing as soon as it starts or only when trying to tune an H.264 channel?
God d.mn great big corporate machine, we do it our way, regardless of what U think or say...
Do we care.. no we don´t, we will grease you up, so that you´ll want Windows 7 soooooo bad.... mooooohahahaaahaaa.... get ready to be redeemed once again by our all caring loving father, Microsoft.
Oh yes we have an office in Ireland dedicated to all our European children, we will take good care of you all..
We are the itch you can´t scratch...
I just realized something disturbing, I can´t live without my mediacenter and I will be buying Windows 7 too...
.... I´m stuck in this hell and I can´t get out.... But do I really want to leave anyway....
asm495: I don't think the problem is with this at all though. I think there is something else going on when decoding needs to happen - maybe another date check there.
xs4all: asm495: I don't think the problem is with this at all though. I think there is something else going on when decoding needs to happen - maybe another date check there.Is that results from debugging media center?
No evidence to back that up other than the fact that we've bypassed the date check now and that the error only occurs when playing back content. I'll try and see if there is any way I can attach to Media Center with a debugger just to quickly see where the error is happening. If there is another date check (which is what I suspect is happening considering I can't think what else would fail) then with any luck it will be based around the same code process and will be fairly easy to fix.
I've noticed that the .dll's you uploaded have a modified date of 18/09/2008
Would it be worth tring the the following;
Setting the clock back and resaving the dll at the original date that MS did it?
Just an idea? maybe the .dll also checks when the file was created?
D
Just having a quick scan through the code again to see if I could spot anything in IDA Pro. The only thing I could see was...
.text:63A0B897 ; =============== S U B R O U T I N E =======================================.text:63A0B897.text:63A0B897.text:63A0B897 sub_63A0B897 proc near ; CODE XREF: sub_63A0BA3C+15p.text:63A0B897.text:63A0B897 SystemTime= _SYSTEMTIME ptr -414h.text:63A0B897 ValueName= byte ptr -404h.text:63A0B897 Dst= byte ptr -403h.text:63A0B897 var_4= dword ptr -4.text:63A0B897.text:63A0B897 sub esp, 414h.text:63A0B89D mov eax, dword_63AE0928.text:63A0B8A2 xor eax, esp.text:63A0B8A4 mov [esp+414h+var_4], eax.text:63A0B8AB push esi.text:63A0B8AC push edi.text:63A0B8AD push 3FFh ; Size.text:63A0B8B2 lea eax, [esp+420h+Dst].text:63A0B8B6 push 0 ; Val.text:63A0B8B8 push eax ; Dst.text:63A0B8B9 mov edi, ecx.text:63A0B8BB mov [esp+428h+ValueName], 0.text:63A0B8C0 call memset.text:63A0B8C5 add esp, 0Ch.text:63A0B8C8 lea ecx, [esp+41Ch+SystemTime].text:63A0B8CC push ecx ; lpSystemTime.text:63A0B8CD call ds:GetLocalTime.text:63A0B8D3 movzx esi, [esp+41Ch+SystemTime.wYear].text:63A0B8D8 movzx edx, [esp+41Ch+SystemTime.wMonth].text:63A0B8DD imul esi, 64h.text:63A0B8E0 movzx eax, [esp+41Ch+SystemTime.wDay].text:63A0B8E5 add esi, edx.text:63A0B8E7 imul esi, 64h.text:63A0B8EA push 400h.text:63A0B8EF lea ecx, [esp+420h+ValueName].text:63A0B8F3 push ecx.text:63A0B8F4 add esi, eax.text:63A0B8F6 push 3.text:63A0B8F8 xor esi, 73B998h.text:63A0B8FE call sub_63A0BAA7.text:63A0B903 add esp, 0Ch.text:63A0B906 push 0 ; int.text:63A0B908 lea edx, [esp+420h+ValueName].text:63A0B90C push edx ; lpValueName.text:63A0B90D mov ecx, edi.text:63A0B90F call sub_63A0B504.text:63A0B914 cmp eax, esi.text:63A0B916 jnz short loc_63A0B970.text:63A0B918 push 400h.text:63A0B91D lea eax, [esp+420h+ValueName].text:63A0B921 push eax.text:63A0B922 push 4.text:63A0B924 call sub_63A0BAA7.text:63A0B929 mov ecx, dword_63AEFD74.text:63A0B92F add esp, 0Ch.text:63A0B932 push ecx ; int.text:63A0B933 lea edx, [esp+420h+ValueName].text:63A0B937 push edx ; lpValueName.text:63A0B938 mov ecx, edi.text:63A0B93A call sub_63A0B504.text:63A0B93F mov dword_63AEFD74, eax.text:63A0B944 push 400h.text:63A0B949 lea eax, [esp+420h+ValueName].text:63A0B94D push eax.text:63A0B94E push 5.text:63A0B950 call sub_63A0BAA7.text:63A0B955 mov ecx, dword_63AEFD78.text:63A0B95B add esp, 0Ch.text:63A0B95E push ecx ; int.text:63A0B95F lea edx, [esp+420h+ValueName].text:63A0B963 push edx ; lpValueName.text:63A0B964 mov ecx, edi.text:63A0B966 call sub_63A0B504.text:63A0B96B mov dword_63AEFD78, eax.text:63A0B970.text:63A0B970 loc_63A0B970: ; CODE XREF: sub_63A0B897+7Fj.text:63A0B970 mov ecx, [esp+41Ch+var_4].text:63A0B977 pop edi.text:63A0B978 pop esi.text:63A0B979 xor ecx, esp.text:63A0B97B call sub_6399E9D5.text:63A0B980 add esp, 414h.text:63A0B986 retn.text:63A0B986 sub_63A0B897 endp
The time part seems a bit suspicious. Don't remember seeing this when going through before.
Edit: Just reading through and this is definitely doing a date comparison. It takes the current year, multiplies by 100 (64h) then adds the current month before multiplying by 100 (64h) again. Before adding on the day. This is then compared against EAX which seems to be set in this subroutine:
.text:63A0B504 ; =============== S U B R O U T I N E =======================================.text:63A0B504.text:63A0B504.text:63A0B504 ; int __stdcall sub_63A0B504(LPCSTR lpValueName, int).text:63A0B504 sub_63A0B504 proc near ; CODE XREF: sub_63A0B897+78p.text:63A0B504 ; sub_63A0B897+A3p ....text:63A0B504.text:63A0B504 hKey= dword ptr -410h.text:63A0B504 Data= byte ptr -40Ch.text:63A0B504 cbData= dword ptr -408h.text:63A0B504 SubKey= byte ptr -404h.text:63A0B504 Dst= byte ptr -403h.text:63A0B504 var_4= dword ptr -4.text:63A0B504 lpValueName= dword ptr 4.text:63A0B504 arg_4= dword ptr 8.text:63A0B504.text:63A0B504 sub esp, 410h.text:63A0B50A mov eax, dword_63AE0928.text:63A0B50F xor eax, esp.text:63A0B511 mov [esp+410h+var_4], eax.text:63A0B518 push esi.text:63A0B519 mov esi, [esp+414h+lpValueName].text:63A0B520 push 3FFh ; Size.text:63A0B525 lea eax, [esp+418h+Dst].text:63A0B529 push 0 ; Val.text:63A0B52B push eax ; Dst.text:63A0B52C mov [esp+420h+hKey], 0.text:63A0B534 mov dword ptr [esp+420h+Data], 0.text:63A0B53C mov [esp+420h+cbData], 4.text:63A0B544 mov [esp+420h+SubKey], 0.text:63A0B549 call memset.text:63A0B54E push 400h.text:63A0B553 lea ecx, [esp+424h+SubKey].text:63A0B557 push ecx.text:63A0B558 push 2.text:63A0B55A call sub_63A0BAA7.text:63A0B55F add esp, 18h.text:63A0B562 lea edx, [esp+414h+hKey].text:63A0B566 push edx ; phkResult.text:63A0B567 push 1 ; samDesired.text:63A0B569 push 0 ; ulOptions.text:63A0B56B lea eax, [esp+420h+SubKey].text:63A0B56F push eax ; lpSubKey.text:63A0B570 push 80000002h ; hKey.text:63A0B575 call ds:RegOpenKeyExA.text:63A0B57B test eax, eax.text:63A0B57D jnz short loc_63A0B59B.text:63A0B57F lea ecx, [esp+414h+cbData].text:63A0B583 push ecx ; lpcbData.text:63A0B584 lea edx, [esp+418h+Data].text:63A0B588 push edx ; lpData.text:63A0B589 push eax ; lpType.text:63A0B58A push eax ; lpReserved.text:63A0B58B mov eax, [esp+424h+hKey].text:63A0B58F push esi ; lpValueName.text:63A0B590 push eax ; hKey.text:63A0B591 call ds:RegQueryValueExA.text:63A0B597 test eax, eax.text:63A0B599 jz short loc_63A0B5C9.text:63A0B59B.text:63A0B59B loc_63A0B59B: ; CODE XREF: sub_63A0B504+79j.text:63A0B59B mov eax, [esp+414h+hKey].text:63A0B59F test eax, eax.text:63A0B5A1 jz short loc_63A0B5AA.text:63A0B5A3 push eax ; hKey.text:63A0B5A4 call ds:RegCloseKey.text:63A0B5AA.text:63A0B5AA loc_63A0B5AA: ; CODE XREF: sub_63A0B504+9Dj.text:63A0B5AA mov eax, [esp+414h+arg_4].text:63A0B5B1 pop esi.text:63A0B5B2 mov ecx, [esp+410h+var_4].text:63A0B5B9 xor ecx, esp.text:63A0B5BB call sub_6399E9D5.text:63A0B5C0 add esp, 410h.text:63A0B5C6 retn 8
Food for thought...
Also it seems to XOR the date it creates with 73B998h
So for today's date (18/09/2008) you originally end up with a number of 20080918 (1326916h) and XORing produces... 21090446 (141D08Eh)
Why it does this, I do not know.
I cannot seem to debug this code as it is not reached during the regsvr32 process. This makes me believe that this is something that we've not taken into account.
Another routine also gets called:
.text:63A0BAA7 ; =============== S U B R O U T I N E =======================================.text:63A0BAA7.text:63A0BAA7.text:63A0BAA7 sub_63A0BAA7 proc near ; CODE XREF: sub_63A0B504+56p.text:63A0BAA7 ; sub_63A0B5E5+E5p ....text:63A0BAA7.text:63A0BAA7 arg_0= dword ptr 4.text:63A0BAA7 arg_8= dword ptr 0Ch.text:63A0BAA7.text:63A0BAA7 mov edx, [esp+arg_0].text:63A0BAAB xor ecx, ecx.text:63A0BAAD xor eax, eax.text:63A0BAAF.text:63A0BAAF loc_63A0BAAF: ; CODE XREF: sub_63A0BAA7+1Dj.text:63A0BAAF cmp dword_63AE2010[eax], edx.text:63A0BAB5 jz short loc_63A0BAC7.text:63A0BAB7 add eax, 84h.text:63A0BABC add ecx, 1.text:63A0BABF cmp eax, 183Ch.text:63A0BAC4 jb short loc_63A0BAAF.text:63A0BAC6.text:63A0BAC6 locret_63A0BAC6: ; CODE XREF: sub_63A0BAA7+44j.text:63A0BAC6 retn.text:63A0BAC7 ; ---------------------------------------------------------------------------.text:63A0BAC7.text:63A0BAC7 loc_63A0BAC7: ; CODE XREF: sub_63A0BAA7+Ej.text:63A0BAC7 imul ecx, 84h.text:63A0BACD lea edx, a4[ecx] ; "©\r¦4ÀÌ".text:63A0BAD3 mov eax, edx.text:63A0BAD5 push esi.text:63A0BAD6 lea esi, [eax+1].text:63A0BAD9.text:63A0BAD9 loc_63A0BAD9: ; CODE XREF: sub_63A0BAA7+39j.text:63A0BAD9 mov cl, [eax].text:63A0BADB add eax, 1.text:63A0BADE test cl, cl.text:63A0BAE0 jnz short loc_63A0BAD9.text:63A0BAE2 mov ecx, [esp+4+arg_8].text:63A0BAE6 sub eax, esi.text:63A0BAE8 cmp eax, ecx.text:63A0BAEA pop esi.text:63A0BAEB jnb short locret_63A0BAC6.text:63A0BAED mov [esp+arg_8], ecx.text:63A0BAF1 mov [esp+arg_0], edx.text:63A0BAF5 jmp sub_63A0BA5A.text:63A0BAF5 sub_63A0BAA7 endp
I'll take another look tomorrow.
asm495: Also it seems to XOR the date it creates with 73B998h So for today's date (18/09/2008) you originally end up with a number of 20080918 (1326916h) and XORing produces... 21090446 (141D08Eh) Why it does this, I do not know. I cannot seem to debug this code as it is not reached during the regsvr32 process. This makes me believe that this is something that we've not taken into account. Another routine also gets called: .text:63A0BAA7 ; =============== S U B R O U T I N E =======================================.text:63A0BAA7.text:63A0BAA7.text:63A0BAA7 sub_63A0BAA7 proc near ; CODE XREF: sub_63A0B504+56p.text:63A0BAA7 ; sub_63A0B5E5+E5p ....text:63A0BAA7.text:63A0BAA7 arg_0= dword ptr 4.text:63A0BAA7 arg_8= dword ptr 0Ch.text:63A0BAA7.text:63A0BAA7 mov edx, [esp+arg_0].text:63A0BAAB xor ecx, ecx.text:63A0BAAD xor eax, eax.text:63A0BAAF.text:63A0BAAF loc_63A0BAAF: ; CODE XREF: sub_63A0BAA7+1Dj.text:63A0BAAF cmp dword_63AE2010[eax], edx.text:63A0BAB5 jz short loc_63A0BAC7.text:63A0BAB7 add eax, 84h.text:63A0BABC add ecx, 1.text:63A0BABF cmp eax, 183Ch.text:63A0BAC4 jb short loc_63A0BAAF.text:63A0BAC6.text:63A0BAC6 locret_63A0BAC6: ; CODE XREF: sub_63A0BAA7+44j.text:63A0BAC6 retn.text:63A0BAC7 ; ---------------------------------------------------------------------------.text:63A0BAC7.text:63A0BAC7 loc_63A0BAC7: ; CODE XREF: sub_63A0BAA7+Ej.text:63A0BAC7 imul ecx, 84h.text:63A0BACD lea edx, a4[ecx] ; "©\r¦4ÀÌ".text:63A0BAD3 mov eax, edx.text:63A0BAD5 push esi.text:63A0BAD6 lea esi, [eax+1].text:63A0BAD9.text:63A0BAD9 loc_63A0BAD9: ; CODE XREF: sub_63A0BAA7+39j.text:63A0BAD9 mov cl, [eax].text:63A0BADB add eax, 1.text:63A0BADE test cl, cl.text:63A0BAE0 jnz short loc_63A0BAD9.text:63A0BAE2 mov ecx, [esp+4+arg_8].text:63A0BAE6 sub eax, esi.text:63A0BAE8 cmp eax, ecx.text:63A0BAEA pop esi.text:63A0BAEB jnb short locret_63A0BAC6.text:63A0BAED mov [esp+arg_8], ecx.text:63A0BAF1 mov [esp+arg_0], edx.text:63A0BAF5 jmp sub_63A0BA5A.text:63A0BAF5 sub_63A0BAA7 endp I'll take another look tomorrow.
xs4all:That could be it.Here is a version that does not crash on my SD (I still have no H.264 WTV to test with). With the beta-expired version, I used to get a message about an expired codec. That message is now gone for me using that dll.http://rapidshare.com/files/146479578/MSDTVVDEC.zip.html
OMG it works! Amazing job asm495 and xs4all, you made alot of European VMC users happy :).
I added a mirror to my FTP.
>> Download <<