Recently I was able to look at the 64bit version of Windows 7 and check the MsvpPasswordValidate within the ms1_0.dll to see if it is possible to NOP the TRUE/FALSE RtlCompareMemory function when we compare hashes in memory.
It is actually much simpler then the Win7 SP1 32bit version of the library, with so much less objects in IDA-view it was very easy to find the function and replace it with NOP.
So in my demonstration Im using IDA-pro (for 64bit DLLs) and a patch utility called ida_patcher.c (download it from IDA and compile using Visual Studio Express 2010) to diff the results against the msv1_0.dll
So we search for the function MsvpPasswordValidate within the msv1_0.dll and check the following section in the IDA-view
Looks simple right ? So next we need to highlight the jnz loc_7FF735183A4
and switch to hex view so that we can see the part which we can patch like so:
Next we patch the highlited hex strings with NOP so instead of 0F 85 7C 80 00 00 we will have 90 90 90 90 90 90
Then we produce a DIFF file with our changes which we can then patch using the ida_patcher.exe
So the final command would be > ida_patcher.exe -i msv1_0.dll -p msv1_0.dll.patch
The resulting msv1_0.dll (which we have copied from the C:\windows\system32 to another location right ?) can be used to authenticate with any password against Win7 64 SP1. For the tests sake I’ve just replaced the original msv1_0.dll with the patched one and i can login with any password imaginable. Nothing groundbreaking, but still could be used as a nice magic trick to amuse kids in your local IT class.
Astr0baby's not so random thoughts _____ rand() % 100; 
I tried to NOP one RtlCompareMemory() call, but it seems that it didn’t have any effect on the authentication. Mine is a 32bit DLL for Windows 7. Can you explain the systematic debugging of msv1_0.dll a little bit? Instead of trying to do it blindly, I want to know the formal method behind such system level debugging.
Hi Sherlock,
for Win7 SP1 32bit please have a look here
https://astr0baby.wordpress.com/2011/09/20/unlocking-windows-7-sp1-locked-screen-remotely/ The trick is finding the correct location with RtlCompareMemory, there are many calls within the MsvpPasswordValidate so please look at the article to find the correct location, once changed, you can generate a diff using the idapatcher program and patch the binary yourself. Good luck !
Hi Astr0baby!
It`s really work. But i have some problem with admin account. On the computer is a domain user and the administrator, the process came to a domain user, but not for the administrator. The Administrator account is disabled in the settings of the Group Policy Object. Maybe there is a way around this block like this with the dll? I would be very grateful for any help.
If your pc is on a Domain, unplug the Ethernet cable and you can use the dll trick. Do not plug in the cable because the user account will get locked against the Active Directory. By default all AD accounts are cached on the PC in case the network connection drops so after you patch the dll you can login to the system under any account that is cached there.
I unplug the Ethernet the cable and still dll trick works only for domain user. The only thing that comes to mind is a lock Group Policy Object. What else could be the reason of such metamorphoses?
Do I understand that the local adminstrator account is locked and you need admin privileges on the box? If this is the case maybe just copy over cmd.exe to c:\windows\system32\ultiman.exe …. http://www.howtogeek.com/106333/how-to-reset-your-forgotten-domain-admin-password-on-server-2008-r2/
Yes, you understood correctly. Method to link helped me. Administrator account is not enabled, but I created a new user with admin rights. Thank you for your help, you have a very useful blog!