Can anyone share these new versions of termsrv.dll? I'm on Win 7, and I can't extract it from msu files (obviously it's a cab archive, but files are encrypted).
Alright, I already have termsrv build 6.3.9600.17095 in my collection. I'm now working on it, the new release of RDP Wrapper will come soon. Thanks.
This replacement is confusing me. Hex signature is placed at 0x5CCE7 (in IDA : 0x180000C00 + 0x5CCE7 = 0x18005D8E7) Changed part is 7F07 -> 9090. Code: .text:000000018005D8E3 ; START OF FUNCTION CHUNK FOR ?StartWaiting@COpsMonitorBase@@UEAAJK@Z .text:000000018005D8E3 .text:000000018005D8E3 loc_18005D8E3: ; CODE XREF: COpsMonitorBase::StartWaiting(ulong)+5Cj .text:000000018005D8E3 call cs:__imp_GetLastError .text:000000018005D8E9 test eax, eax .text:000000018005D8EB jg short loc_18005D8F4 << nop .text:000000018005D8ED mov ebx, eax .text:000000018005D8EF jmp loc_18001937A .text:000000018005D8F4 ; --------------------------------------------------------------------------- I doubt this is the right replacement. The function COpsMonitorBase::StartWaiting has no relation to licensing / policy. If we take a look at this opcode replacement, it seems to be right, because here is an opcodes of CEnforcementCore::GetInstanceOfTSLicense function. Let's look into code, it's a really right change: Code: .text:000000018008181F ; START OF FUNCTION CHUNK FOR ?GetInstanceOfTSLicense@CEnforcementCore@@UEAAJAEAU_GUID@@PEAPEAVITSLicense@@@Z.text:000000018008181F .text:000000018008181F loc_18008181F: ; CODE XREF: CEnforcementCore::GetInstanceOfTSLicense(_GUID &,ITSLicense * *)+45j .text:000000018008181F cmp [rsp+48h+arg_18], 0 .text:0000000180081824 jz loc_180031DEF << nop + jmp .text:000000018008182A lea rdx, aCenforcemen_18 ; "CEnforcementCore::GetInstanceOfTSLicens"... .text:0000000180081831 mov ecx, 8 .text:0000000180081836 mov ebx, 80070005h .text:000000018008183B call ?_DbgPrintMessage@@YAXHPEBDZZ ; _DbgPrintMessage(int,char const *,...) .text:0000000180081840 jmp short loc_18008185E .text:0000000180081840 ; END OF FUNCTION CHUNK FOR ?GetInstanceOfTSLicense@CEnforcementCore@@UEAAJAEAU_GUID@@PEAPEAVITSLicense@@@Z So, finally I think maybe it's a kind of some error / typo. And I can offer an alternative solution for this opcode replacement: Code: .text:00000001800B9143 loc_1800B9143: ; CODE XREF: CEnforcementCore::GetInstanceOfTSLicense(_GUID &,ITSLicense * *)+30j .text:00000001800B9143 lea rdx, [rsp+48h+arg_18] .text:00000001800B9148 mov rcx, rsi .text:00000001800B914B call ?IsLicenseTypeLocalOnly@CSLQuery@@SAJAEAU_GUID@@PEAH@Z ; CSLQuery::IsLicenseTypeLocalOnly(_GUID &,int *) .text:00000001800B9150 test eax, eax .text:00000001800B9152 js short loc_1800B9173 .text:00000001800B9154 cmp [rsp+48h+arg_18], 0 .text:00000001800B9159 jz short loc_1800B9173 << jmp .text:00000001800B915B lea rdx, aCenforcemen_18 ; "CEnforcementCore::GetInstanceOfTSLicens"... .text:00000001800B9162 mov ecx, 8 ; char * .text:00000001800B9167 mov ebx, 80070005h .text:00000001800B916C call ?_DbgPrintMessage@@YAXHPEBDZZ ; _DbgPrintMessage(int,char const *,...) .text:00000001800B9171 jmp short loc_1800B91B4 .text:00000001800B9173 ; --------------------------------------------------------------------------- So, replace 837C2468007418 with 837C246800EB18. It's for 6.3.9600.17095 version x64. But... I know this replacement is unsuitable for Windows 8.1, because here is no Home Premium edition. But this knowledge will really help to enable RDP on Basic / Core edition (also the few functions are required to be intercepted).
And this... I think it's a really typo. wrong: B80001000089813806000090 right: B80001000089813C06000090 because of 39813C060000.
binarymaster, best of luck with your RDP Wrapper project. Let's hope that things change next year with Win9. It's a new regime now, so maybe they'll have only two editions of Windows: one for consumers and one for enterprises. They would both have RD host. We can dream. The wrapper project aside (I'm now talking about editions that support RD host), and the full acknowledgement that I haven't a clue about assembler code, are you suggesting that we try out this new replacement string (you lost me a little bit when you said it's unsuitable)? I did wonder earlier on about the one you also suspected, though my flimsy reason was that it looked so different than what we did with the original 8.1 termsrv. Yours looks very similar so makes more sense to me on that superficial level, and, of course, you provided more solid reasoning. I'll definitely try it. This one confuses me. Why do you think it's a typo? Because of where it is (39813C0600000F849E310500)? It well could be, but note that its location in the last termsrv was (39813C0600000F841B700000), so was it wrong then too? It's been working for months. Perhaps you spotted something in the disassembly that led you to this? Thanks!
Hi, First of all... i'm a big fan of multiple cuncurrent rdp session in windows 7!!! I use it for my HTPC. I would love to upgrade to win 8.1 but i holding back, since last time i tried windows 8.1 with a patch for termsrv i happen to loose audio on the console every time i sign in with another user using RDP. I am aware of the sound settings in RDP client, and i choose to play on remote computer, but sound always dissapers, and i'm only able to getting it back after a reboot. It's not an issue in windows 7. So as of now, i'm running tests on Windows server 2012R2 with everything stock, and multiple rdp works out of the box, and there is no audio issue. I hope you can come up with a fix for this audio issue on win8/win8.1. //TjaLfE
That is really strange. I have a 8.1 HTPC and connect to it remotely using an RDP client with the latest patches and it works great. I have sound in the client set to "Do not play".
If we use this code replacement, the termsrv will ignore LocalOnly policy (it checked in CEnforcementCore::GetInstanceOfTSLicense function). Because of the policy LocalOnly = 1 on Home Premium editions, the new RDP sessions will be disconnected. Windows 8 and 8.1 have Basic/Core and Single Language editions, which is similar to Windows 7 Home Basic by policy values. But it has no Home Premium like edition. And so, if we apply this code replacement to Windows 8.1 Core, or Pro, apparently nothing will change. The Listener session on Basic editions is disabled by AllowRemoteConnections policy. In the next release of RDP Wrapper I've implemented an interception for CSLQuery::Initialize function, so the Listener will work. But actually, on Basic edition the LocalOnly policy is same (equal to 1), so this code replacement will be helpful. I've researched other patches for other versions of termsrv, and maybe I'm wrong. I will recheck it...
Well, I've researched an ARMv7 termsrv version too (which is for Windows RT), but I have a very little experience in ARM assembler binaries. Also here is my post #22 about it: httр://forum.xda-developers.com/showthread.php?t=2093525&page=3
Thanks, but not what I meant, was only looking to learn that cdb.exe trick from their jailbreak and apply it to a normal windows process, nothing to do with ARMv7. If anyone can explain to me how to hook a process from CDB.exe on a normal windows machine, I am all ears.
@bjf2000 I've downloaded patched files from your post: httр://forums.mydigitallife.net/threads/47610-How-to-crack-the-quot-termsrv-dll-quot-in-windows-8-1/page22?p=929478&viewfull=1#post929478 And I'm confused with differences between x86 and x64 patch. I attached an image. Look at conditions and "this" offsets. Possibly something is wrong, but I don't know x86 or x64. x86: 804h and 800h -> 804h and 800h x64: 638h and 63Ch -> 638h and 638h ? image: httр://i.imgur.com/8bfXJFs.png
I've not dealt with CDB.exe, so I don't know Maybe I will look it later. I think it's not enough to patch the memory... Interception/hooking is very important part.
For the x86 one, which works in my tests, all I did was follow the same search strings established with the original 8.1 x86 last year, since they're conveniently all still around (unlike x64's). I see that you're comparing it with the x64 one, but that's something you'd have to ask the original patcher about (several pages back in the thread now). OK, so back on the x64 one, specifically the 2nd of the 3 changes (ignoring the 3C06 one for now), if 090085C07F078BD8/090085C090908BD8 aren't right and what you suggested (837C2468007418/837C246800EB18) aren't either, what should it be? All I'm looking to do is get the proper strings for Pro/Enterprise. I should emphasize that it seems to be working as originally patched, but if it's not exactly right we should get that established. BTW, none of the above relates to 8.1 Core, that's a separate discussion.
Today I've seen patches for Vista And I encountered the same difference between x86 and x64 patch. Maybe it's right, or this typo was from the time of Windows Vista So, we hardly know about it. The replacement (837C2468007418/837C246800EB18) is related to Core edition, but can't be used without interception of other functions. Pro/Enterprise editions doesn't require this change. I read somewhere about this... but don't know how to fix it. As a workaround, try to execute in command prompt: net start AudioSrv
Sorry to keep asking questions, but I think it's good to clarify this: when you say Pro/Enterprise don't require this, are you saying that the 090085C07F078BD8/090085C090908BD8 change should stay or that it's not necessary?