430 replies to this topic

[Wonko the Sane]

Yep , for the record is the 33C090 that won't exist on both 32 and 64 bit .dll's.

Checking just once (before the choice between 32 bit and 64 bit) for the 33C090 (i.e. independently from the bit width of the OS) would be an even more "wide" check (i.e. more "secure").

I.e. if already 33C090 doesn't exist (and it won't ) 33C0900F85 also won't exist.



Wonko

[steve6375]

If anyone has win8 release version (either 32 or 64bit) I am happy to suggest a patch if they can private email me the dll, but they will have to test it as I don't have a spare system for x64 at the moment!

[Wonko the Sane]

If anyone has a Windows 8 64 bit edition a patch to be tested has been ALREADY posted on the board, on post #63:

http://reboot.pro/to...sword/?p=173442

 

"release version", "preview version" "the one that my aunt gave to me version", "technet version", "the version I downloaded from somewhere" and the like are MEANINGLESS.

 

We (that means Wonko the Sane and Holmes.Sherlock, i.e. the guys that originally had the idea and put together the half @§§ed grub4dos batch BEFORE Steve6375 took the development of PassPass in his hands)  would like to have the EXACT (§@ç#ing) .dll version (and adding to it filesize and MD5 would also be nice) instead.

 

 

Wonko

[steve6375]

I have put your 64-bit win8 patch and my 32-bit Win8 patch into my E2B PassPass version which can be downloaded from the E2B Tutorial 72a page (PassPass.zip is at the bottom of the page - it will only work in E2B).

 

The 32-bit patch has been tested on Release Preview 32-bit only and works (but no idea if it works on full RTM Win 8 32-bit)! The pattern match I use may be rather 'fussy'!

The 64-bit patch was tested on Server 2012 64-bit Beta and seemed to patch and unpatch ok, but my VM now seems to hang on the Win8 boot up rotating circles - so I don't know if I broke it with some previous patches or just my VM is flaky!

[Wonko the Sane]

"my" 64 bit patch for Windows 8 works also on "the one that my aunt gave to me version" and on "the version I downloaded from somewhere", most probably.

 

It should also work on Server 2012 "no, not that one, the other one with that KB integrated, no, not that KB the other, older one version".

 

I know of someone who has a cousin whose mother in law is willing to test "your" 32 bit patch on "windows 8 housewife edition".

 

Wonko

[pscEx]

I do not know whether this hint can help:

 

In the Ice-Age, when I worked with DOS and NT4, I several times did also patches of binary files.

Here I did not only search for a pattern, but when necessary I also gave a range where the pattern should be found.

 

Peter

[Wonko the Sane]

I do not know whether this hint can help:

 

In the Ice-Age, when I worked with DOS and NT4, I several times did also patches of binary files.

Here I did not only search for a pattern, but when necessary I also gave a range where the pattern should be found.

 

Peter

Sure it helps.

 

It is always good when someone shares his/her experience.

 

My only "real" experience with machine code dates back to the good ol' times of the Z80 processor, when we built our bytes one by one, bit by bit, by hand. (.... and we liked it. )

 

For completely different reasons, I am now fighting a bit with the i386 assembler (Nasm) and in the end I am resorting (due to the particular *needs* of this other little project) to go through "pure" assembly, and it is a nightmare to re-learn the old tricks of the trade (and adapt them to the stupid PE format), but it's anyway "fun" .

 

However, in this particular thingy here the idea is (was) to find "general" ways, the idea to limit to not only a range but also to a number of occurrencies had actually crossed our minds but a few rudimentary tests proved that this approach was either "too narrow" or unneeded because the "generic" patch worked allright.

 

It is good how everyone is preoccupied about this patch and patching approach (which - limited to the 32 bit - has been used unknowingly since some 5 years by - I presume - a few thousands peeps) to botch forever a Windows install, it means that members of the forum do care about other people OS's integrity.

 

Wonko

[maximus57]

In short I must report success with r11 on both installations. That fixed it.

 

I must now report what could be considered catastophic failure. After the successful patch of the previously non-working OS with version r11, unpatching it left it with a different MD5 and patching it again does not work (still requires password). So it just pooched my dll, although it still logs in with the proper password. The good news it that was a testing system, of which I don't care about. I did not make a copy of the dll before I started because I didn't really care. I DID make a copy of the dll for the system that was reported working as I care about that a bit more, but that doesn't do me any good to recover my test system to a point where I can try again from scratch like it was.

 

+1 for any sort of warning / backup system.

 

Edit:

I do have a backup, but is this the correct MD5 for the origianal? I might have patched and unpatched once with original passpass before making the backup.

version: 6.1.7600.16385

b2a020adf96ab10ef3ef269849a726c8 *system32 msv1_0.dll

 

BTW this is the MD5 after the last unpatch:

ef12b8385aa2849999008a977918f96b

Edited by maximus57, 13 June 2013 - 11:08 PM.

[Holmes.Sherlock]

I must now report what could be considered catastophic failure. After the successful patch of the previously non-working OS with version r11, unpatching it left it with a different MD5 and patching it again does not work (still requires password). So it just pooched my dll, although it still logs in with the proper password. The good news it that was a testing system, of which I don't care about. I did not make a copy of the dll before I started because I didn't really care. I DID make a copy of the dll for the system that was reported working as I care about that a bit more, but that doesn't do me any good to recover my test system to a point where I can try again from scratch like it was.

 
Thanks for the report, fault on my part.

• Download latest version of the script.
• Replace the corrupted DLL with the original one.
• Patch it.
• Test whether the patch is working.
• Record the MD5.
• Unpatch it.
• Test whether whether unpatch is working.
• Record the MD5.
• Report.

+1 for any sort of warning / backup system.

 
Not needed at this point.
 

Edit:
I do have a backup, but is this the correct MD5 for the origianal? I might have patched and unpatched once with original passpass before making the backup.
version: 6.1.7600.16385
b2a020adf96ab10ef3ef269849a726c8 *system32 msv1_0.dll

 
Yes, it's correct. Go ahead.

[steve6375]

@Sherlock

Can you check code in r12?

line 170 looks wrong ??

if not "%@retval%"=="0" goto :64BitPatch

should be :64BitUnPatch ???

Also line 160 has typo

pause Thie DLL is not compatible or has been already patched or unpatched

[Holmes.Sherlock]

@Sherlock

Can you check code in r12?

line 170 looks wrong ??

if not "%@retval%"=="0" goto :64BitPatch

should be :64BitUnPatch ???

Also line 160 has typo

pause Thie DLL is not compatible or has been already patched or unpatched

 

Thanks Steve, script updated.

[maximus57]

 
Thanks for the report, fault on my part.

• Download latest version of the script.
• Replace the corrupted DLL with the original one.
• Patch it.
• Test whether the patch is working.
• Record the MD5.
• Unpatch it.
• Test whether whether unpatch is working.
• Record the MD5.
• Report.

Tested with R13 on both systems and patch worked, and unpatching put both back to correct MD5 that I started with. I am assuming that you don't need all the details since it worked and I already gave the starting info previously.

[Wonko the Sane]

Tested with R13 on both systems and patch worked, and unpatching put both back to correct MD5 that I started with. I am assuming that you don't need all the details since it worked and I already gave the starting info previously.

Well, since there is at least one picky guy on this thread , I may make (on your behalf ) this Official and Final statement :
 
 

TO WHOM IT MAY CONCERN
I, maximus57, hereby declare that:
Starting with release r13 PassPass has been confirmed to be working with:
windows 7 64 bit SP1
version: 6.1.7601.17514
AND with:
windows 7 64 bit SP0
version: 6.1.7600.16385

to my complete satisfaction.
In faith,
maximus57

 

All is well that ends well .

 

BTW, the "16385" version is really a "no-no", even if you want to keep it at SP0 level the kb975467 mentioned earlier is one of those that makes sense to consider updating to.

 

Wonko

[Holmes.Sherlock]

Few changes have been made in the script to make it work flawlessly with 64 bit version of the DLL. Can anyone please beta-test the script once again for 32 bit DLLs?

 

Please follow the steps in Beta-testing section of the original post. ANY deviation renders the report meaningless.

[Holmes.Sherlock]

If you want to add this code feel free. It checks for the unpatch bytes  before patching and will refuse to run it if they exist
 
if this is experimental code, it makes sense to not trash the system or at least warn the user...
 

:32BitPatch
echo 32Bit Patch bytes \x83\xF8\x10
cat --locate=\x83\xF8\x10 %dllPath% > (md)0x9000+10
cat --locate=\x20 (md)0x9000+10
set n1=%@retval%
if %n1%==0 goto :warnUser
if %n1%>=2 set /p /u ask=WARNING: %n1% instances found in %file%! Press S to skip :
if not "%ask%"=="S" cat --hex --locate=\x83\xF8\x10 --replace=\x33\xC0\x90 %dllPath% > nul
if "%@retval%"=="0" goto :warnUser
goto :patchMessage
:64BitPatch
echo 64Bit Patch bytes \x48\x3B\xC6\x0F\x85
cat --locate=\x48\x3B\xC6\x0F\x85 %dllPath% > (md)0x9000+10
cat --locate=\x20 (md)0x9000+10
set n1=%@retval%
if %n1%==0 goto :warnUser
if %n1%>=2 set /p /u ask=WARNING: %n1% instances found in %file%! Press S to skip :
if not "%ask%"=="S" cat --hex --locate=\x48\x3B\xC6\x0F\x85 --replace=\x33\xC0\x90\x0F\x85 %dllPath% > nul
if "%@retval%"=="0" goto :warnUser
:patchMessage
echo
echo DLL at %2\%3 patched
goto :EOF
:warnUser
echo
pause The DLL is not compatible or has been already patched
configfile %patchDrv%
goto :EOF

:: Unpatches DLL file, %1 = patchDLL, %2 = (hdX,Y), %3 = WinDir
:unPatchDLL
set dllPath = %2/%3%dll%
:: Check for 0x6486 to identify 64-bit PE
cat --locate=\x64\x86 %dllPath% > nul
if not "%@retval%"=="0" goto :64BitUnpatch
:32BitUpatch
echo 32BitUnpatch
cat --locate=\x33\xC0\x90 %dllPath% > (md)0x9000+10
cat --locate=\x20 (md)0x9000+10
if %@retval%>=2 set /p /u ask=WARNING: More than one instance found in %file%! Press S to skip :
if not "%ask%"=="S" cat --hex --locate=\x33\xC0\x90 --replace=\x83\xF8\x10 %dllPath% > nul
if "%@retval%"=="0" goto :warnUserU
goto :unpatchMessage
:64BitUnpatch
echo 64BitUnpatch
cat --locate=\x33\xC0\x90\x0F\x85 %dllPath% > (md)0x9000+10
cat --locate=\x20 (md)0x9000+10
if %@retval%>=2 set /p /u ask=WARNING: More than one instance found in %file%! Press S to skip :
if not "%ask%"=="S" cat --hex --locate=\x33\xC0\x90\x0F\x85 --replace=\x48\x3B\xC6\x0F\x85 %dllPath% > nul
if "%@retval%"=="0" goto :warnUserU
:unpatchMessage
echo
echo DLL  at %2\%3 unpatched
goto :EOF
:warnUserU
echo
pause The DLL is not compatible or has been already unpatched
configfile %patchDrv%
goto :EOF

 
It's meaningless just to report the number of occurrences of patch byte sequences in the target DLL and asking for a decision from user. PassPass, before patching, checks whether unpatching is possible, irrespective of patch works or not. It refuses to patch if rolling back is impossible.
 
 

cat --locate=\x33\xC0\x90 %dllPath% > nul
if "%@retval%"=="1" goto :warnUser

 
 

:warnUser
pause This DLL is not compatible or has been already patched or unpatched
configfile %osDrv%
goto :EOF

[steve6375]

Hi,

Yes you are correct, sorry I didn't post the complete code. When I modified the code for Win8, it is necessary to test for the unpatch bytes actually in the 32 and 64 patch segment.

Download the E2B version of PassPass to see what I mean.

cheers

Steve

[Holmes.Sherlock]

Download the E2B version of PassPass to see what I mean.

It's teaching time! What do you mean by the following?

 

#clear memory in case it contains bytes that look like a compressed file header!
echo ffffffffffffff > (md)0x2000+1
echo ffffffffffffff > (md)0x2300+1
echo ffffffffffffff > (md)0x2500+1
echo ffffffffffffff > (md)0x5800+1
echo ffffffffffffff > (md)0x9000+1

 

 

And it issues warning if more than one patch sequence is found. How is it going to help?

 

cat --locate=%patt% %dllPath% > (md)0x9000+10
cat --locate=\x20 (md)0x9000+10  > nul
set n1=%@retval%
if %n1%==0 goto :warnUser
if %n1%>=2 set /p /u ask=WARNING: %n1% instances found in %file%! Press S to skip : 
if not "%ask%"=="S" cat --hex --locate=%patt% --replace=%rpatt% %dllPath% > nul
if "%@retval%"=="0" goto :warnUser
goto :patchMessage

[Wonko the Sane]

It's teaching time! What do you mean by the following?

 

#clear memory in case it contains bytes that look like a compressed file header!
echo ffffffffffffff > (md)0x2000+1
echo ffffffffffffff > (md)0x2300+1
echo ffffffffffffff > (md)0x2500+1
echo ffffffffffffff > (md)0x5800+1
echo ffffffffffffff > (md)0x9000+1

 

It's the next step after eeeeeeeeeeeeee (wait until we get to gggggggggggggg for the real fun to begin  )

Reference:

http://reboot.pro/to...n-as-1st-entry/

http://reboot.pro/to...tkeys/?p=173015

 

 

Wonko

[steve6375]

And it issues warning if more than one patch sequence is found. How is it going to help?

cat --locate=%patt% %dllPath% > (md)0x9000+10
cat --locate=\x20 (md)0x9000+10  > nul
set n1=%@retval%
if %n1%==0 goto :warnUser
if %n1%>=2 set /p /u ask=WARNING: %n1% instances found in %file%! Press S to skip : 
if not "%ask%"=="S" cat --hex --locate=%patt% --replace=%rpatt% %dllPath% > nul
if "%@retval%"=="0" goto :warnUser
goto :patchMessage

 

Well, as this is a test version and you do not know what affect it will have on all the different versions of the DLL, I like to know what I am patching.

 

If there is only one patch then there is no need for a warning. But if more than one patches are applied, that could have a knock-on affect with the functionality of the other subroutines in the DLL. So I think it only fair to warn the user that more than one subroutine is being patched and it is also good information if reported back.

 

1 patch = pretty safe

2 patches = hopefully pretty safe

23 patches = may have other side-affects on anything that uses this dll once you are logged in

 

The msv1_0.dll DLL has routines for

• NTLM authentication package authentication protocol.
• Default network authentication protocol in Windows NT 4.0.
• Performs authentication of users and computers in Windows NT 4.0 mixed environments.

P.S. Does the patch used by PassPass work for domain pwds or just local logon only? What about if someone accesses a remote share on a computer that has had the patch applied - would it allow it with any pwd?

[Holmes.Sherlock]

P.S. Does the patch used by PassPass work for domain pwds or just local logon only? 

 

It shouldn't work unless the password is locally cached. Though I don't have an environment to set up AD here at my home, I think the decision of logon success/failure is taken by the domain controller and the result is sent back to the client.

 

 

What about if someone accesses a remote share on a computer that has had the patch applied - would it allow it with any pwd?

 

Not sure, but worth considering. Theoretically, the password match should take place at that remote computer (i.e. remote computer should not send the NTLM hash to client but the success/failure report) and there is no point to have a method other than MsvpPasswordValidate() to verify supplied credentials.

[steve6375]

It's teaching time! What do you mean by the following?

#clear memory in case it contains bytes that look like a compressed file header!
echo ffffffffffffff > (md)0x2000+1
echo ffffffffffffff > (md)0x2300+1
echo ffffffffffffff > (md)0x2500+1
echo ffffffffffffff > (md)0x5800+1
echo ffffffffffffff > (md)0x9000+1

 

As in the posts that Wonko gave, basically you cannot just write to uninitialised memory using (md) or (rd) using grub4dos!

 

I found on many occasions that  write would not work to certain memory locations but I did not understand why, so instead I used echo > (md)0xnnnn+1 as that seemed to work OK!!!

 

The thread Wonko posted shows that write and cat only work depending on what is actually in the memory at that location!

i.e. just using write (md) on uninitialised memory is totally unreliable!

The problem is that grub4dos does not allow writes to a compressed file or what it thinks is a file or byte sequence that looks like a compressed file header.

So if (md)0x3000 just happen to contain a few bytes that look like a compressed file header block, grub4dos just refuses to write to it!

Therefore, you have two choices when writing to an area of memory:

 

1. Turn off the automatic decompression flag so g4d does not look for a compressed file header and turn it on again afterwards

or

2. initialise the start of the memory area first so that g4d won't mistake it for a compressed file header.

 

 

HTH

[Holmes.Sherlock]

1. Turn off the automatic decompression flag so g4d does not look for a compressed file header and turn it on again afterwards

 

How to do that?

[Wonko the Sane]

Well, as this is a test version and you do not know what affect it will have on all the different versions of the DLL, I like to know what I am patching.

Sure , and you will never use a patching program coming without source code.

As a matter of fact you would write your own program to do the patches (which is what you are doing right now, with your fork of PassPass, BTW ).

 

If there is only one patch then there is no need for a warning. But if more than one patches are applied, that could have a knock-on affect with the functionality of the other subroutines in the DLL. So I think it only fair to warn the user that more than one subroutine is being patched and it is also good information if reported back.
 
1 patch = pretty safe
2 patches = hopefully pretty safe
23 patches = may have other side-affects on anything that uses this dll once you are logged in

Oh, noes.  
 
NOT AGAIN.
 

• The 32 bit patch proposed is by design "wide" and it is going by design to patch multiple occurrences.
• The 32 bit patch proposed (that works for at least 2k to 7) is THE SAME ALREADY USED IN THE LAST FIVE YEARS AT LEAST (and it does patch ALL OCCURRENCES of the given search) in WindowsGate.
• WindowsGate does not, never did and probably will never warn about patching in multiple occurrences 

I will try to be more explicit:
It makes no sense to warn a user if what the program does is what it is supposed to do, i.e. patching each and every (yes, multiple and possibly affecting a lot of other functions) occurrence.

We like to live dangerously.

Why in these 5 years you did not decompile/reverse engineer WindowsGate and re-code it with the added warning?
No, wait, that would have been unfair, but you could well have issued a Security Bulletin to warn users about how dangerous it is/was.

Why don't you add that "warning scale" to your fork and be done with it?

We will then have a:

1. "safe" (because of the added warning) or "fair" version that will only work with or in conjunction with Easy2boot version 2 or later, that you will develop and maintain and host on your site (you are of course welcome to add to the description how your integrated Safe-o-Meter ® makes a lot of difference)
2. "dangerous" (because of the missing warning) or "unfair" version for more general use developed and maintained by Holmes.Sherlock and hosted on the "regular" project page at https://code.google.com/p/g4scripts/

 

 

The msv1_0.dll DLL has routines for

• NTLM authentication package authentication protocol.
• Default network authentication protocol in Windows NT 4.0.
• Performs authentication of users and computers in Windows NT 4.0 mixed environments.

Sure, and possibly many more.

The risk of the PC catching fire is high if more than one patch is done, very high if more than two.

 

P.S. Does the patch used by PassPass work for domain pwds or just local logon only? What about if someone accesses a remote share on a computer that has had the patch applied - would it allow it with any pwd?

Who knows?


@Holmes.Sherlock
Why not renaming your version of PassPass to PassPassRE (where RE stands for Reckless Edition or PassPassRU where RU stands for Really Unfair) so that at least it will be easier to distinguish the two versions?




Wonko

[steve6375]

How to do that?

http://reboot.pro/to...e-2#entry173024

[steve6375]

• The 32 bit patch proposed is by design "wide" and it is going by design to patch multiple occurrences.
• The 32 bit patch proposed (that works for at least 2k to 7) is THE SAME ALREADY USED IN THE LAST FIVE YEARS AT LEAST (and it does patch ALL OCCURRENCES of the given search) in WindowsGate.
• WindowsGate does not, never did and probably will never warn about patching in multiple occurrences 

Wonko

 

So win 7 has been around for 5 years and you know all the affects of your 64-bit Win8 patch which is included my version?  

I just think it is valuable for a 'test' version of software (which you yourself have said many times that PassPass is...) should inform the user about what the patch is going to do.

Once enough confidence in PassPass has been obtained from all versions of the dll and in all languages, I would feel confident in dropping the warning in my version, until then, I just want as much information as possible about what PassPass is doing to a user's system.

May I remind you that the original version of PassPass did not even report whether or not the patch was successful!