Jump to content











Photo
* * * * - 3 votes

PassPass - Bypass the Password


  • Please log in to reply
430 replies to this topic

#26 Holmes.Sherlock

Holmes.Sherlock

    Gold Member

  • Team Reboot
  • 1444 posts
  • Location:Santa Barbara, California
  •  
    United States

Posted 04 June 2013 - 02:06 PM

...translated into my grumpier manners means EXACTLY:


One more item included to avoid possible confusion.

 

  • Windows version (e.g. XP, Vista, 7)
  • Service pack (e.g. SP0, SP1)
  • Architecture (e.g. 32-bit/64-bit)
  • msv1_0.dll version (e.g. 6.1.7600.16525) along with MD5 checksum, if possible

Original post updated.



#27 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 June 2013 - 02:31 PM


One more item included to avoid possible confusion.

 

  • Windows version (e.g. XP, Vista, 7)
  • Service pack (e.g. SP0, SP1)
  • Architecture (e.g. 32-bit/64-bit)
  • msv1_0.dll version (e.g. 6.1.7600.16525) along with MD5 checksum, if possible

Original post updated.

Yeah, I also updated my referenced post, though I am starting to suspect :dubbio: that you could make a good (italian) politician :w00t:, since you have set a "rule" that noone respects you add a new one as to make respecting them more difficult. :ph34r:

 

 

:cheers:

Wonko



#28 Holmes.Sherlock

Holmes.Sherlock

    Gold Member

  • Team Reboot
  • 1444 posts
  • Location:Santa Barbara, California
  •  
    United States

Posted 04 June 2013 - 05:34 PM

Yeah, I also updated my referenced post, though I am starting to suspect :dubbio: that you could make a good (italian) politician :w00t:, since you have set a "rule" that noone respects you add a new one as to make respecting them more difficult. :ph34r:


Here are two candidates so far.
 

it work well on 7 sp1 x86/64


Compliance level 60%

 

P.S. tested on XP PRO (English) OK :-)


Compliance level 20%



#29 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 June 2013 - 05:45 PM

You see?

With all my grumpyness, I would made them - respectively - 75% and 25% :) (but of course - as said - anything less than 100% is not useful, while making it 120% including the MD5 of the .dll is appreciated :smiling9:).

 

:cheers:

Wonko



#30 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 04 June 2013 - 05:57 PM

Works on Win 7 64-bit SP1 v6.1.7601.17514 - however there were a side-affects - I had to re-sign up with DropBox as the credentials seems to have been lost (all files had to be re-indexed!), also a gmail app that runs on Windows login had to be provided with my account credentials again.

 

Also, it strikes me that the approach of using grub4dos may not be quite as good as the NT Offline password solution, because of the 137GB BIOS bug that many USB BIOSes have, it means if the dll is past 137GB then grub4dos can't patch it on those systems.

[Edit]Does not apply to internal HDD[\Edit]



#31 Holmes.Sherlock

Holmes.Sherlock

    Gold Member

  • Team Reboot
  • 1444 posts
  • Location:Santa Barbara, California
  •  
    United States

Posted 05 June 2013 - 01:19 AM

Works on Win 7 64-bit SP1 v6.1.7601.17514 - however there were a side-affects - I had to re-sign up with DropBox as the credentials seems to have been lost (all files had to be re-indexed!), also a gmail app that runs on Windows login had to be provided with my account credentials again.

 

For Dropbox and GMail app, does random password work?

 

Also, it strikes me that the approach of using grub4dos may not be quite as good as the NT Offline password solution, because of the 137GB BIOS bug that many USB BIOSes have, it means if the dll is past 137GB then grub4dos can't patch it on those systems.

 

So far I can remember, for buggy BIOS-es having a 'narrower' internal USB bus, geometry(hdX) returns the partitions within 137GB limit. In that case, the script will fail to probe partitions beyond the limit. But whatever is detected, those can be patched, still.

 

Wasn't there a workaround to use Plop's USB driver?



#32 DarknessAngel

DarknessAngel

    Member

  • Members
  • 33 posts
  •  
    South Korea

Posted 05 June 2013 - 05:47 AM

Here are two candidates so far.
 


Compliance level 60%

 


Compliance level 20%

oh sorry

 

it tested on

 

windows 7

sp1

x86/64

6.1.7601.17514 (all updated at now)

not virtual machine


Edited by DarknessAngel, 05 June 2013 - 05:48 AM.


#33 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 June 2013 - 11:44 AM

Works on Win 7 64-bit SP1 v6.1.7601.17514 - however there were a side-affects - I had to re-sign up with DropBox as the credentials seems to have been lost (all files had to be re-indexed!), also a gmail app that runs on Windows login had to be provided with my account credentials again.
 
Also, it strikes me that the approach of using grub4dos may not be quite as good as the NT Offline password solution, because of the 137GB BIOS bug that many USB BIOSes have, it means if the dll is past 137GB then grub4dos can't patch it on those systems.
Sure :thumbsup:, and also booting a PE is more "safe", and using the right password is even better... :whistling:
 
Heck, the idea is to (boldly ? :dubbio:) go where no man has been before (and do so in less bytes).
 
BTW with any password editor you usually change password, the idea here is to login with *any* password, as soon as you revert the patch and re-login with the good password everything should be "as before" (of course online services such as dropbox and gmail - and possibly also Twitter and Facebook - won't work).

About the 137 Gb USB bug it is - AFAIK - ONLY related to USB devices, the scope of the tool is to patch the INSTALLATION of windows (which normally is on an internal hard disk, which either has - or has not - a 137 GB BIOS limit, and if it has it won't simply allow a hard disk bigger than that).

You have probably failed to read attentively the Careware license with which the tool has been released:
http://jaclaz.alterv...s/careware.html

Particularly this part ;):
 
 
STANDARD DISCLAIMER

Though every reasonable effort has been made in testing this script, the Author accepts no liability whatsoever. This script may or may not do whatever it is supposed to do, it could even possibly completely destroy your software, hardware and set your house/office to fire.

No warranty implied, not even that of fitness for any particular purpose apart taking up a little bit of your hard disk space.


:cheers:
Wonko

#34 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 05 June 2013 - 12:45 PM

(of course online services such as dropbox and gmail - and possibly also Twitter and Facebook - won't work).

About the 137 Gb USB bug it is - AFAIK - ONLY related to USB devices, the scope of the tool is to patch the INSTALLATION of windows (which normally is on an internal hard disk, which either has - or has not - a 137 GB BIOS limit, and if it has it won't simply allow a hard disk bigger than that).

Wonko

 Yep, you are correct of course! On my Asus EeePC 904HA, the 137GB limit is only on USB devices accessed through the BIOS.

 

re. online services - why don't they work correctly when the dll is unpatched? 



#35 Holmes.Sherlock

Holmes.Sherlock

    Gold Member

  • Team Reboot
  • 1444 posts
  • Location:Santa Barbara, California
  •  
    United States

Posted 05 June 2013 - 01:37 PM

re. online services - why don't they work correctly when the dll is unpatched? 


Probably Wonko did not mean that.



#36 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 June 2013 - 02:55 PM

Wonko would like to make this Official statement:
 
 
 
Wonko (the Sane) has NO idea whatsoever how:
  • Dropbox
  • Gmail
  • Facebook
  • Twitter
  • each and every other Online service, of any kind, listed or not listed above
actually:
  • work
  • authenticate
  • whether their authentication is connected with (or is completely independent from) the actual NT authentication
BUT he strongly doubts :dubbio: that the same Online services do work when NT Offline password (or Sala's password renew, or any other tool working around the NT authentication) are used instead of WindowsGate or the PassPass grub4dos.
Additionally he suspects :unsure: that the list of things that won't work will include any among:
  • Active directory services
  • Network shares
  • Remote access
  • possibly *any* other non-strictly-local activities, programs and *what not*
Whether any of the above (or anything not listed above) will cease to work definitely or temporarily after having made access to a Windows NT based system with anything excluded the "right" password and whether their functioning will be re-established afterwards "as before"  is *UNKNOWN*, but besides that the whole thing is out of the scope of the tool.
 
A car user comparison would go like this :whistling::
Q. My wife lost the keys of her car, and the car is in the office parking lot, how can I open and start it so that I can drive the car home?
A. You can open the car by using a set of lockpicking tools, depending on the car model you can also lockpick the start lock and make it start.
Q. OK, I managed to use successfully the tools and managed to drive the car back home, I noticed how the bluetooth of the car didn't connect with my wife's phone anymore.
A. The idea is to drive the car home, not that of talking handsfree on the phone while doing it.


 that hopefully clears (or completely fails to :w00t:) the matter at hand.

:cheers:
Wonko

#37 Holmes.Sherlock

Holmes.Sherlock

    Gold Member

  • Team Reboot
  • 1444 posts
  • Location:Santa Barbara, California
  •  
    United States

Posted 07 June 2013 - 04:19 AM

Easy2Boot now supports PassPass. Thanks Steve.



#38 maximus57

maximus57

    Newbie

  • Members
  • 29 posts
  •  
    United States

Posted 11 June 2013 - 11:15 PM

Worked -
windows 7 64 bit SP1
version: 6.1.7601.17514
md5: 4c1e16b9a53102c8d6fba587cbcb95de


Did NOT work (patch successful but still needed correct password as if it did not do anything) -
windows 7 64 bit SP0
version: 6.1.7600.16385
md5: f40388a19f3be3cec25656ce07392877

 

Both of these are real installs, but on a multiboot system (partitions 1 and 2 respectively, both recognized by passpass). There is also a BartPE install on partition 0 that passpass also recognized, but I obviously did not try to patch that one.


Edited by maximus57, 11 June 2013 - 11:15 PM.


#39 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 11 June 2013 - 11:17 PM

Unless you use my modified version you cannot tell that the patch was successful (unless you use a hex editor to examine the contents of the dll) as the original code does not give any error if the patch was unsuccessful...



#40 Holmes.Sherlock

Holmes.Sherlock

    Gold Member

  • Team Reboot
  • 1444 posts
  • Location:Santa Barbara, California
  •  
    United States

Posted 11 June 2013 - 11:19 PM

Did NOT work (patch successful but still needed correct password as if it did not do anything) -
windows 7 64 bit SP0
version: 6.1.7600.16385
md5: f40388a19f3be3cec25656ce07392877

 

Does the MD5 change after patching?

 

The original MD5 is what you have reported.

http://www.windowall..._id=594&page=40

 

I suspect that the file was not patched at all. Please confirm.



#41 maximus57

maximus57

    Newbie

  • Members
  • 29 posts
  •  
    United States

Posted 11 June 2013 - 11:22 PM

Unless you use my modified version you cannot tell that the patch was successful (unless you use a hex editor to examine the contents of the dll) as the original code does not give any error if the patch was unsuccessful...

 

Actually after the failure I did use your modified version that said the patch was already done (or not compatible) if i tried it twice. Same result after unpatching twice. So it seemed like it worked according to your modified passpass. Did not try an actuall file compare from before and after.



#42 Holmes.Sherlock

Holmes.Sherlock

    Gold Member

  • Team Reboot
  • 1444 posts
  • Location:Santa Barbara, California
  •  
    United States

Posted 11 June 2013 - 11:24 PM

Actually after the failure I did use your modified version that said the patch was already done (or not compatible) if i tried it twice. Same result after unpatching twice. So it seemed like it worked according to your modified passpass. Did not try an actuall file compare from before and after.

 

Please compare file hashes and fc /b, if possible, between patched and unpatched files.



#43 maximus57

maximus57

    Newbie

  • Members
  • 29 posts
  •  
    United States

Posted 11 June 2013 - 11:28 PM

Does the MD5 change after patching?

 

The original MD5 is what you have reported.

http://www.windowall..._id=594&page=40

 

I suspect that the file was not patched at all. Please confirm.

 

In both cases the MD5 that I reported did not change between the before and after. I used Marxio-FCV from within the op system to get the MD5 from the windows/system32/msv1_0.dll. That is the correct file and location? Is it possible that I need to do the checksum from a boot cd to get the real result?

 

Also, I am getting the same MD5 from the one in system32 as syswow64 using this method, and they are different sized files. Hmmmmmm......


Edited by maximus57, 11 June 2013 - 11:33 PM.


#44 Holmes.Sherlock

Holmes.Sherlock

    Gold Member

  • Team Reboot
  • 1444 posts
  • Location:Santa Barbara, California
  •  
    United States

Posted 11 June 2013 - 11:30 PM

That is the correct file and location?

 

Yes, it is.

 

 

Is it possible that I need to do the checksum from a boot cd to get the real result?

 

I don't think so.

 

Can you please give the geometry of the disks attached?



#45 maximus57

maximus57

    Newbie

  • Members
  • 29 posts
  •  
    United States

Posted 11 June 2013 - 11:39 PM

Yes, it is.

 

 

 

I don't think so.

 

Can you please give the geometry of the disks attached?

 

Please explain what you want you want regarding the geometry. And I am also going to try actual file comparisons on the working and non working systems from an outside boot source. Some of that may take me a bit of time...



#46 Holmes.Sherlock

Holmes.Sherlock

    Gold Member

  • Team Reboot
  • 1444 posts
  • Location:Santa Barbara, California
  •  
    United States

Posted 11 June 2013 - 11:41 PM

Please explain what you want you want regarding the geometry.

 

When Grub4DOS boots up, press 'c', which will drop you to command line. Now, if there are two hard disks attached, those will be numbered as hd0 and hd1.

Try geometry(hd0) and geometry(hd1) commands, write it down on a paper (since it's your real system) and post the output.

 

Take your time.



#47 Holmes.Sherlock

Holmes.Sherlock

    Gold Member

  • Team Reboot
  • 1444 posts
  • Location:Santa Barbara, California
  •  
    United States

Posted 11 June 2013 - 11:50 PM

Also, I am getting the same MD5 from the one in system32 as syswow64 using this method, and they are different sized files. Hmmmmmm......

 

Can you please clarify?



#48 maximus57

maximus57

    Newbie

  • Members
  • 29 posts
  •  
    United States

Posted 12 June 2013 - 12:57 AM

Here are my results from copying the files using hirens boot cd after every change, and then comparing them. Also, you should get some of the geometry from this. The first one (hd1,1) was the successful one, and the second one was the failed one. It shows the change did happen. Also note that I am using grub4dos to boot the partitions, and have it set to hide each one from the other when selected (if windows sees another windows... nothing good ever happens).

 

 

hd1,1 unpatched ef12b8385aa2849999008a977918f96b *system32 msv1_0.dll
hd1,1 unpatched 4c1e16b9a53102c8d6fba587cbcb95de *syswow64 msv1_0.dll

hd1,1 patched c9f89969e7c445913f2b84888c9c19ab *system32 msv1_0.dll
hd1,1 patched 4c1e16b9a53102c8d6fba587cbcb95de *syswow64 msv1_0.dll


hd1,2 unpatched b2a020adf96ab10ef3ef269849a726c8 *system32 msv1_0.dll
hd1,2 unpatched f40388a19f3be3cec25656ce07392877 *syswow64 msv1_0.dll

hd1,2 patched e02c3232ddd12d9d594974702f9d217f *system32 msv1_0.dll
hd1,2 patched f40388a19f3be3cec25656ce07392877 *syswow64 msv1_0.dll
 



#49 Holmes.Sherlock

Holmes.Sherlock

    Gold Member

  • Team Reboot
  • 1444 posts
  • Location:Santa Barbara, California
  •  
    United States

Posted 12 June 2013 - 02:30 AM

hd1,2 unpatched b2a020adf96ab10ef3ef269849a726c8 *system32 msv1_0.dll

hd1,2 unpatched f40388a19f3be3cec25656ce07392877 *syswow64 msv1_0.dll

hd1,2 patched e02c3232ddd12d9d594974702f9d217f *system32 msv1_0.dll
hd1,2 patched f40388a19f3be3cec25656ce07392877 *syswow64 msv1_0.dll
 

 

In the second case, it is not being patched at all. Problem in patching routine. But, I have to be sure which copy of the DLL is actually invoked during login.



#50 maximus57

maximus57

    Newbie

  • Members
  • 29 posts
  •  
    United States

Posted 12 June 2013 - 02:50 AM

In the second case, it is not being patched at all. Problem in patching routine. But, I have to be sure which copy of the DLL is actually invoked during login.

 

The dll in system32 was changed it both cases. But in both cases the dll in syswow64 was not changed. Both are Win7x64 systems.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users