Hi.

Here is my new small tool WindowsGate for accessing any local users accounts without password knowing.
It is designates for work with Windows Live CDs.

Version 1.1 features:

• target OS can be installed on any paths
• two gates available now:
  
  • msv1_0.dll patch
  • utilman.exe replacement (WinKey+U shortcut) - run any process with system privileges from WindowsGate

The plugin can be downloaded here:
http://www.virtualexile.com/wg/windowsgate.cab (290kB)



Version 1.0 features:

• Unlock/Lock functions (enabling/disabling logon password validation)
• existing passwords remains untouched (without password reset or overwrite operations)
• windows registry remains untouched
• without password (hash) cracking
• SFC/WRP remains active
• support for all NT version: 2000/XP/2003/Vista/2008

The plugin can be downloaded here:
http://www.virtualexile.com/wg/windowsgate1-0.cab (283kB)

Best regards

Nice!

Am I correct in presuming you are the same Damian that made Dreampack?

Whether you're him or not, welcome to the forums.

jaclaz

Still the same Damian

Damianie Bąkowski chce ci powiedzieć ze wykonałeś zajebisty programik

Do you have to re-enable password checking from within PE?

Like when my kids forget thier password, I can boot to PE and disable password checking and access the account, and after I recover/change the password, can I re-enable password checking from windows? Or do I have to boot back into PE?


Another Question:
Does this effect EWF encrypted files?

Either way this looks really nice!

Sweet!
Thanks for sharing.

Dzięki, miło to słyszeć



Yes, with usage of button "Lock".
However, in Vista/2008, You can try enter at command prompt (run in the admin security context) this:

sfc /scanfile=c:\windows\system32\msv1_0.dll


EWF?
maybe EFS encrypted files?

While you explore Windows with the disabled password check, any EFS encrypted file will be unreadable unless you enter right password while logon.
To decrypt files you need private key assigned with you encrytpion certificate.
All private keys and other secure content is stored in protected place. This place is secured with use of your account password.
If you normally change the password, Windows will decrypt the secured objects (private keys) and encrypt again it with your new password.
When you set new user password (not change password, where you must enter old password) or reset it offline with use of any third-party tools, then all informations stored in user protected store will be inaccessible. You will be not able to export you certificate with private key any more.
But the unaccessible private keys should remain in protected store.
So when someone change/reset password to the original one, private key will be again available and all encrypted files.

For the record, Nuno already made a .script for winbuilder:
http://www.boot-land.net/forums/index.php?...ic=4070&hl=

jaclaz

Does your statement:

However, in Vista/2008, You can try enter at command prompt (run in the admin security context) this:

sfc /scanfile=c:\windows\system32\msv1_0.dll


mean that you are patching msv1_0.dll to disable password checking?

Yes.

msv1_0.dll = Authentication Package

So we cant access Admin accounts. Or are all accounts accessible.





I would suggest a small how to use the program within the WindowsGate program.

For example having this in there



and maybe this also.

One of the first questions I was going to post. But I see someone beat me to it.



adding XPE support shortcut to plugin, for those that use Numenu.

Thanks!

Im testing the Script for Winbuilder right now.
http://www.boot-land.net/forums/index.php?...ic=4070&hl=

Finished tests. All are positive.

This is a good tool to keep on the admin belt - thank you for sharing!

Thank you very much for sharing this with us...

Is WindowsGate able to patch 32 and 64 bits systems ?

EFS .... YES
The connection between brain and fingers does not always work.

Someones having a Senior moment

Ive no reason to be here other than to badger hilander999 in return for what i feel is character assassination in other threads....

I was actually being serious and could probbly get a nice gift-pack of cheese sent out if you want to divulge your location via PM.

By now i thought everyone would know that my location is:

The Tower Of Solitude
Darlinghurst.
Sydney. N.S.W. 2010
Australia (Otherwise known as the coalition of the gullible, country number: 2)

Just look for the sign: The National Institute For The Shaping of Young Minds

Or look up three floors for the rifle mounted on the window sill

You just described every third building in my neighborhood.

Yes but you live in the US dont you, what my idol Hunter S Thompson described as "The Kingdom Of Fear"

Sure, there i expect the sight of guns protruding from windows is de riguer.

The sight of mine however is an uncommon sight, and definitely sends the message that i will not surrender myself or my cheese easily and any attempt to breach the defenses will result in the highest possible price.

Thanks for your suggestions.


Only x86 target systems.
I have no contact until now with 64 bits system

Good job on your discovery and coding the program! This tool should be very very useful, especially for fixing others' computers. No more needing to NULL their password, just "Unlock" the OS!

By the way, since you are somehow modifying a DLL, isn't it possible that a Windows Update may cripple the patched DLL? Or is it possible that a Windows Update could download a new DLL and your software is trying to patch it and can't find the right bytes, or replacing it with an older file?

Yes it is.

Exactly as it happened to the original SFC/WFP workarounds.

But is also well possible that tomorrow the sky falls on our heads :

http://www.asterix-international.de/asterix/characters.shtml


So why bothering?

jaclaz

Because I'd say making it a dynamic patch would be more efficient so that you don't need to update the program very often (it should automatically search for proper spot to patch, instead of hard-coding the offset to patch or the modified DLL itself). So the program would work for just about every update.

Just a hint, that's usually how I program my patcher/loader.

#EDIT:
I'm taking back what I said. He already has it efficiently dynamically patching.

Yes, Windows Update can install new version of patched DLL.
Also the SFC (or Vista's WRP) can restore original version of DLL - but we have a luck because SFC/WRP doesn't care (by default) about files modified offline unless you force settings to scan all protected files at boot time.


No, a think WindowsGate will work always
There is no other way.
If you want to check user's password then you must compare two hash values - byte by byte - and return binary result - are the same or not.
Authorization routines was not changes from Windows 2000. 8 years without changes.
So WindowsGate must work correctly forever
But - never say never.


WindowsGate is a universal patcher. That is way it works on all version of this DLL.

Yeah, we are lucky.


Thanks for letting us know about your research of how windows checks your password


Yes, after trying it out myself, I found this out. Thanks, and again, good work.

It also looks great with the XP Silver theme on my BartPE CD. Keep in mind I took this screenshot on VMWare with XP SP3 installed (it detects SP3 and works perfectly).

Btw, wallpaper is squished because I made it for 1920x1200 on real PC.

#EDIT:
One practical suggestion for improving your program would be making it also work for Windows Installations that don't use the standard "WINNT" or "WINDOWS" folders as well, some "leet g33kz0rs" use other names for their "windows" folder.

Tested Windowsgate on Vista SP1 domain member - did it job like promised.
Will it work on domain controller?

I highly doubt it would work properly on AD.

I have thinked about it.
But is there a way to define that folder at XP or Vista installation?
Thanks for suggesion.


Should work for local accounts.
Msv1_0 package is responsible for authorization the local users.
But there is also possibility that users from the network will logon on theirs accounts. See the diagram below:



At the MSDN:

If the domain controller will do all the checks of the password hashes, then... maybe?

Yeah, there's a way to define the folder on XP installation at least.

By the way, I suggest that you do it the Paraglider way (efficient): give the user an option to locate the windows directory themselves if necessary (like, a "config" button in the middle, or something, which will allow them to add an undetected windows installation to the list).

#EDIT: I just tested this on Vista SP1. It seems to "work", but I can't lock it back afterwards. I ran WindowsGate on my PE CD, unlocked vista, rebooted, logged into Vista account w/o a password, it worked, I did a reboot, back to PE CD, opened up WindowsGate.... Lock button is greyed out, only Unlock available???

I think it has some Vista issues.

#EDIT2: After another reboot into PE CD, the Lock button is now available, and it locked fine. Strange.

By the way, do you happen to be Adam Boileau from New Zealand?

Unless Poland or Damian has moved recently and also chaged his name, I find it highly improbable:
http://www.911cd.net/forums//index.php?sho...=21204&st=2

jaclaz

Eh? Because This guy released the source for the exploit:
http://storm.net.nz/static/files/winlockpwn

It looks for byte signatures then patches. The "WinXP SP2 msv1_0.dll technique" seems to be what WindowsGate uses.

You may be unaware that Damian has a long story about "low-level" Windows tricks, do check his "old" projects:
http://www.d--b.webpark.pl/dreampackpl_en.htm
and his was the original idea of patching the WFP SFCFILES.dll:
http://www.911cd.net/forums//index.php?sho...181&st=1111

jaclaz

If it makes any difference I do know that a domain controller has NO local accounts and actually must be ON the domain on the right subnet in order to log onto the console. I've found this out the hard way by fat fingering a static IP address on a DC that was sent to a site with a different subnet. BTW: Got around it by using a mini-router set to the WRONG subnet (I knew which subnet I set the DC on) and hooked the WAN side to the real subnet side.

There are NO LOCAL accounts on a machine once it's been promoted to a DC. It uses ONLY domain accounts.

@jaclaz: Damn, I didn't know.

Correction: WindowsGate work also on 64-bit target systems.



No way.

By the way, do you happen to patch at the same place as this guy?

For the record, and probably out of topic, I recently learned about a "trick" apparently used by some technicians to open a command prompt at login time:
http://www.msfn.org/board/Access-COMMAND-S...9.html&st=8

Basically some feature of XP allow that pressing keys "windows" + "U" to bring up the file narrator.exe, but apparently there is no check made that it is actually a "real" narrator.exe, and it can be a renamed cmd.exe.

Not having an XP system that I can use to play with handy, I did not test it, but it sounds about right, question is would it be a command prompt open with which proviledges?

Any taker to test and report?

jaclaz

Renaming narrator doesn't work, win-U still brings up the utility manager. I think it must be utility manager that needs to be replaced?

Edit: renaming utilman.exe does not bring up a cmd window either.

Been experimenting with vmware.
Have fast user switching turned on (not sure if this makes any difference)
I've tried renaming (at different times) the utilman, narrator and maginfy to cmd, none of them work.
The command window never appears.

Edit:
Turned off the welcome screen and also tried renaming osk.exe, no go.
I even tried copying notepad to narrator (just for the heck of it)

The test system is SP2

Maybe it has been "fixed" in SP2.

And then it is possible that some kind of "checksum" is made on the renamed file.

Too bad.....

jaclaz

I think it's due to SFC. It automatically replaces the "new modified" EXE with the one from the DLLCache folder.

One thing that is sure to work (even with domain controllers) is to open the registry of the local machine and navigate to the following location:


You then change ScreenSaverActive to 1 and change SCRNSAVE.EXE to cmd.exe instead of logon.scr. Then you can do whatever you want.
This still works as of Vista SP1.

Cheers

No. I patch alternative piece of code.


Really nice trick


Read this:

LOL. Be sure to change the screen-saver time to like "2 seconds" or something as well

Of course, this will only work if you have an admin account or a BartPE CD w/ Remote RegEdit.

Rather than renaming those files to cmd.exe, how about renaming cmd.exe to those names?

This can also be done with Peter Nordahl's password reset disk.

The raw hive editing feature to unlock windows accounts can also be used to navigate and change the values on other registry keys.

---

I have a *feeling* that it is possible to change logon.scr even from a guest account under vista if you avoid the Win32 API to handle the registry structure.

Holy crap, it does work on X64 as well! I just tried it on XP Pro X64 Edition SP2, and it worked just as well as on x86.

No, not only did I rename the files outside of the target OS, but after it booted I verified they had not been changed back.

Yes, I figured it was something along those lines even when trying to lauch something from utilman.
But nothing ventured, nothing gained.

That's what I've been doing, it's what I understood the idea was.