GLIDE.EXE usage for original Windows 95 (OEM1) systems.
What you can and can't do with GLIDE.EXE.
PWL.EXE usage for original Windows 95 (OEM1) systems.
What you can and can't do with PWL.EXE.
PWLCRACK.EXE usage for the latest version of Windows 95 (OSR2).
What you can and can't do with PWLCRACK.EXE.
SHAREPW.EXE usage for one of the registry hacks.
The only thing you can do with SHAREPW.EXE
PWL_KEY.COM usage for original Windows 95 (OEM1) systems.
What you can and can't do with PWL_KEY.COM.
First known post regarding *.PWL encryption.
Follow up post to the first known post.
How to disable a screen saver password.
Other places you can get *.PWL information.
Another detail that might be useful in a Netware/ Windows 95 hack.
What's the point of all this crap?
This text describes how to use GLIDE.EXE in order to decrypt passwords encrypted in Windows 95 password files.
First of all, this reference is nothing if you don't have what you need to implement this information.
You will need the GLIDE.EXE program.
It should be available from this site in the UTILITIES section.
Now then, go to a Windows 95 machine with a Netware or Windows logon. You don't necessarily need to login to do this. So if you don't want to login, then don't. Get to the DOS PROMPT any way you can and type this command:
You should see C:\WINDOWS>.
COPY *.PWL A:
This will copy all the *.PWL files to your floppy drive. Wait until you have all of them (this file copying process may take as long as six minutes so plan your schedule accordingly) copied on to your floppy disk and then take the disk home to your computer. Why wait? Why take it home? Because you don't want to do this at a public computer. Chances are good you will not be allowed to use a public computer in such a way anyway. Of course, this should be common sense, so if this is something new to you, then you must be a newbie. Or an idiot.
So copy the *.PWL files from your floppy drive to your personal computer.
Now make sure that GLIDE.EXE and all of the *.PWL files you are about to crack are in the same directory.
Suppose you have a PWL file named SUPER.PWL. Usage is as follows:
GLIDE SUPER.PWL
This should crack the file in under two seconds. If it doesn't, it is because the Windows 95 machine you got the *.PWL files from is up to date and thus the encryption algorithim is different than the original algorithim that was used in the first edition of Windows 95 (a.k.a. OEM1). If several lines of dots scroll up the the screen, then the file cannot be cracked. Most *.PWL's will be approximately 606 bytes in size if they can't be cracked by the glide program. If the file in question is approximately 606 bytes in size, then click here. Any file that is larger than 606 bytes in size and from an original release of Windows 95 can be cracked with the GLIDE program (that has been my experience with this). If you can crack the file, you will know it almost instantly.
Now if the file can be cracked, then you will want to output the cracked contents to something for future reference. So you might want to do this. Usage is as follows:
GLIDE SUPER.PWL >SUPER.TXT
This will output the encrypted contents into a file called SUPER.TXT. If you want to view those contents, you can just open the file.
At this point it's easiest to type:
EDIT SUPER.PWL
Go through the file and find the password. You're done.
What's the matter? GLIDE.EXE isn't working on your system? Well, that's because your system is current and up to date. You must have one of the latest releases of Windows 95 or Windows 98. With GLIDE.EXE you CAN decrypt *.PWL files from the first release of Windows 95. You CAN'T decrypt *.PWL files created from the latest version of Windows 95 or Windows 98. If you want to know how to use GLIDE.EXE, then look at this.
PWLCRACK.EXE usage for the latest version of Windows 95 (OSR2). To use PWLCRACK.EXE properly, you have to be on a machine with one of the latest releases of Windows 95 (OSR2) on it. This program will not work on a machine with the original release of Windows 95 on it. The first thing you want to do is get PWLCRACK.EXE. It should be available from this site in the UTILITIES section. Next, prepare a floppy disk. Copy the program PWLCRACK.EXE to a disk. Next, go to the machine you would like to get *.PWL information from. Now this is the tricky part. This program, PWLCRACK.EXE was intended to retrieve only lost passwords (so far as I know). Since that's the only thing it does, you have to be logged in for it to work. In other words, when you run this program, you have to be logged in to a Windows 95 profile or maybe even a Netware account (Novell Client 32; if I'm wrong, you know how to send e-mail). In yet even more words, you have to have entered a username and a password into a login prompt for this program to function the way it was designed to. Once you are logged in, go to the DOS PROMPT. You should see C:\WINDOWS>. Now type this: A:\PWLCRACK.EXE What happens once you have activated the program is self explanatory. You see the output of the program along with it's credits. (m2mike's hacking theory begins here) If there is no output, then the profile you are logged in as has no passwords in the registry. I think this program pulls passwords from the registry by doing a "registry request". "Registry requests" are discussed very briefly in the first known post. I have opened PWLCRACK.EXE with DOS edit and there is what looks to be many registry tags in there. Naturally I am inferring that this program, PWLCRACK.EXE, uses the registry to get passwords (if I'm wrong, you know how to send e-mail)(m2mike's hacking theory ends here).
If you want to get the output from the PWLCRACK program then type this in the DOS PROMPT: A:\PWLCRACK.EXE >A:\USERNAME.TXT This will redirect the output of the program to a text file on your floppy disk. Now take the contents and do what you will with them. For the most part, this has been described in the previous section, but let me clarify some things. PWLCRACK.EXE does NOT decrypt *.PWL files (GLIDE.EXE DOES decrypt *.PWL files, but only from the first release of Windows 95 (OEM1)). PWLCRACK.EXE probably does pull something from the registry. What specifically, I'm not sure. What it pulls from the registry MIGHT be encrypted, but I doubt that. Located elsewhere in this document are locations within the registry that allegedly hold password values in plain text. If the registry does hold passwords in plain text, then you don't really need this program. Just run REGEDIT.EXE and then access the values you need to see. Now don't misunderstand me. This program is not useless. Besides getting the password for the account you are logged in as, this program can extract Dial-up Networking passwords and passwords on a Windows 95 networked machine (a Windows 95 peer to peer network has nothing to do with netware; don't get confused). Now when it comes to Network Neighborhood, this program can also extract passwords from a password protected computer. When I say a password protected computer, I mean a computer or maybe a server on the network that has a hard drive password protected over the network. Now what you CAN'T do with this feature of PWLCRACK.EXE is being on a terminal and running the program from there to get a password on another terminal. This program DOES NOT interface with a network. Example: You are trying to access the hard drive of another computer via Network Neighborhood. You double click on the C drive of that computer you are accessing. A password prompt comes up in a window that says something to the effect of "A password is needed to complete this connection." This is the password I am referring to in the above paragraph. The program DOES NOT interact with a network in any way. Even if you have a drive mapped, it WILL NOT work, so don't waste your time trying. You must physically access the computer or server you are needing the password from. This is the tricky part. You might not have access to this machine, but assuming you do, login through whatever window is available (chances are good this login window will be Novell Client 32 or some variant of Novell). Get in any which way you can and run the program. You will have the password for that computer once you have run it (I could be wrong here; if I'm wrong here, you know how to send e-mail; pressing escape to get through the login prompt might not put you into a windows profile, which I believe is necessary to retrieve any passwords). End of example. Another example for this programs' use: The admin/sysop walks away from the workstation for a split second and then you get on their computer, run the program, and retrieve their password. Doing that shouldn't take more than 2 minutes (if you're fast). End of example.
First make sure you have the target *.PWL file in the same directory as the PWL.EXE program.
Second, you should be aware that the instructions included with the PWL.EXE program are written in Russian, not English. Because most of the people using this program don't have translation software and will not be Russian, I am including some basic instructions here so you English speaking folks know how to use the PWL.EXE program.
Usage for PWL.EXE is as follows:
If you wish to use a dictionary attack against the file, then type PWL.EXE PWLNAME PWLNAME.PWL DICTION.ARY
The above command is assuming that the username for the *.PWL file is PWLNAME, the name of the *.PWL file is PWLNAME.PWL, and the name of the dictionary file is DICTION.ARY.
If you want to use a brute force attack, then type PWL.EXE PWLNAME PWLNAME.PWL
The above command is assuming that the username for the *.PWL file is PWLNAME and the name of the *.PWL file is PWLNAME.PWL.
When conducting a brute force attack, you might notice that it goes through all the ascii characters. Since the password is probably only letters and numbers, you can edit the file named PWL.INI and customize the character set to use only letters and numbers for a brute force attack. I also suggest eliminating the letters Z,X, and Q from the character set since so few words have those letters in them. I would also recommend you go to http://www.hackers.com and download a dictionary file generator. It can be very useful. It also helps if your computer is VERY powerful. At least 600 Mhz, 16 gigs of space, and 256 megs of RAM would be ideal.
You can get the login password for that user id, but you can't get passwords to other resources that might also be encrypted inside the *.PWL file. It should also be noted that this program WILL retrieve passwords that are in *.PWL files regardless of how large those *.PWL files are, although most of the *.PWL files from the first release of Windows 95 are 606 bytes in size by default. GLIDE.EXE could never decrypt the *.PWL files that are 606 bytes in size, but this program can and that is why it is worth using.
Taken from ThePsyko on alt.2600.
I've noticed several posts recently about cracking win95 passwords.... So I thought I'd post this up here
for networks using win95 clients and peer to peer networking,
The passwords are found in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Network\LanMan/
Within the data for each share are two registry entries: Parm1enc and
Parm2enc. Parm1enc is the "Full access" password, while Parm2enc is
the "Read only" password.
Once you get the data from these values, you can use sharepw to crack them...
ThePsyko Aspiring Public Enemy ICQ# 9240214
So, first you get the data in the method described above. Once you have that data, write it down. Take the information you have written down and plug that in to the SHAREPW.EXE program.
I have come across some information that has shed some light on how the two digit values representing letters in the password are encrypted. I have read that the two letters are hexadecimal ciphertext (so it is hex). However, you don't really need to worry about this because all these nice programs will do the decrypting work for you.
The only thing you can do with SHAREPW.EXE
PWL_KEY.COM usage for original Windows 95 (OEM1) systems.
With PWL_KEY.COM two other programs are included.
There is a program called KEY2PWD.COM which will convert a 4-digit hex key to a password.
There is also a program called PWD2KEY.COM which will convert a password to a 4-digit hex key. The PWD2KEY.COM program can be especially useful because if you think you know the password, then you can see what the 4-digit hex value is for a given password and this can make a good starting point for the decryption process.
I should mention that I have had intermittent results with this program. If you attempt to run this program on a *.PWL file that is only 606 bytes in size, then the program will not work. For some reason the program will think that the *.PWL file is empty. For *.PWL files where only one resource is encrypted it only seems to work sometimes (if I'm wrong, you know how to send e-mail). Of course, your mileage may vary.
And now for some old news group postings regarding the *.PWL hack. For the anonymity of the people who originally posted this stuff, I have left their names out of this and just pulled out the information. Windows for Workgroups can assign passwords to shared resources such as shared directories, printer queues, and network DDE shares. To save having to enter a password for each resource each time you log on, it keeps encrypted copies of the passwords in password (.PWL) files and decrypts them with the password you use initially to log on. The details of this are mostly undocumented "for security reasons". They're about to become documented... When you log on for the first time or when you delete your .PWL file, Windows will ask you whether you want it to create a password file for you. This contains the encrypted passwords. You add passwords to the file using the semi-documented WNetCachePassword() function and retrieve them using the equally semi-documented WNetGetCachedPassword() function. Anything running on the machine at any time a user is logged on can use WNetGetCachedPassword() to retrieve any of the passwords in the .PWL file. When you add a password, you supply the name of the resource it pertains to (eg "\\NTSERVER\PRINTER1"), the password itself, and a number from 1 to 254 for the resource type (more about 0 and 255 later). Windows reserves resource types 1,2, and 3 for its own use for network resources. The .PWL file is not protected from modification. To use a new password to access the network, simply delete the .PWL file and Windows will ask you if you want to create a new one the next time you log on. There can be no more than 255 passwords with types 1 to 127 (half of 254). If more than 256 are added, Windows starts throwing existing ones away to make room. You can avoid this by giving the resource a type from 128 to 254, but once you've used up this range all further attempts to add passwords will fail. By adding too many passwords of either type, you can either cause all existing passwords to be discarded by Windows or saturate the password file so no new passwords can be added. Most users (if they can figure out what's going wrong) will respond by deleting the password file and starting again with a new file, giving you a chance to recover from any "'mistakes" you may have made with their .PWL file. The .PWL file contains a small header, two blocks of 256 byte-fields, and then the encrypted password resources. The header consists of a 4-byte magic ID "\xB0MFN", a 4-byte count of the number of password resources, 256 fields containing resource numbers or 0 if this resource is unused (which is why resource type 0 isn't allowed), and 256 fields containing a resource key or 0xFF if this field is unused (which is why resource type 255 isn't allowed). When you add a new password resource, Windows scans throught the second array looking for the first 0xFF entry and then used this to store the password information. Following this data come the encrypted password resources. Windows stores the logon password in memory at all times, performing a simple transformation on a copy of it whenever it's needed to encrypt or decrypt resources. The password is copied around to other memory locations as needed. Since the original password location isn't in a VxD (Windows virtual device driver), it can be swapped to disk at any point, and given that it's in memory for the whole time Windows is in use but is only rarely used, it probably does end up in the swapfile on numerous occasions. The transformation performed on the in-memory password, which reduces a variable-length password to 32 bits, is as follows: unsigned long result = 0L; for( i = 0; i < passwordLen = 1;i++) { int tmp = ( int ) ( result >> 25 ); result += toupper(password[ i ]); result = ( result << 7 ) | tmp; } Note the use of passwordLen + 1, which includes the null terminator at the end of the string as part of the password. The effect is simply to rotate the final result by 7 bits as toupper(password[ i ]) == 0. Here's the output from the password "blem": After After add rotate i = 0 00000042 00002100 i = 1 0000214C 0010A600 i = 2 0010A645 08532280 i = 3 085322CD 29916684 i = 4 29916684 C8B34214 This 32-bit key is then passed to RC4 which is used to encrypt or decrypt the resources. The above key would be passed to RC4 as { 0x14, 0x42, 0xB3, 0xC8 }. The RC4 implementation was licensed by MS in object form and probably comes from the BSAFE toolkit. I assume everyone has seen RC4 so I won't include it here (in any case the implementation used by Windows is fairly grotty, I'd recommend using the asm version I posted to sci.crypt a few weeks ago). The RC4 key usually doesn't contain anywhere near 32 bits of entropy, although as a whole it's not spectacularly ugly (you just keep rotating the 32-bit value, adding in one letter of the password each time). It's probably easier to brute-force the 32-bit key than to try anything clever based on the fact that the password will generally consist entirely of uppercase letters. There have been numerous posts in the past on the insecurity of Windows networking. This one shows that even the basic access control mechanisms are highly insecure, and what's more can't really be made secure: You can patch Windows to use the whole logon password instead of the mangled 32-bit version as the RC4 key, but then you need to contend with the fact that any program can get a password with WNetGetCachedPassword() at any time (think of the possibilities with a machine running arbitrary apps and a live internet connection to send the results over) and that the original password is sitting in memory (and in the swapfile) most of the time. In conclusion: The Windows password/.PWL encryption is quite weak and should not be relied upon to keey any information secure, or to secure access to sensitive resources.
A few days ago someone posted a description on how Windows 95 produces RC4 keys of 32-bits size to protect the .pwl files. I verified the information and wrote a program to decrypt .pwl files with a known password, I then discovered that the .pwl files were well suited for a known plaintext attack as the first 20 bytes are completely predictable.
The first 20 bytes of any .pwl files contains the username, which is the same as the filename, in capitals, padded with 0x00. From then I wrote a program to bruteforce the .pwl file and optimized it so it would run in less than 24 hours on an SGI. I ran a test of the bruter software and recovered an unknown RC4 key in 8 hours, but the decrypted file was still largely unintelligable. I then proceeded to decrypt the file at all possible starting points and discovered valuable information (cleartext passwords) offset in the file.
This has truly spectacular implications: RC4 is a stream cipher. It generates a long pseudo random stream that it uses to XOR the data byte by byte. This isn't necessarily weak encryption if you don't use the same stream twice, however WIN95 does. Every resource is XORed with the same pseudo random stream. What's more the 20 first bytes are easy to guess. This is easy to exploit: XOR the 20 bytes starting at position 0x208 with the username in uppercase, and slide this string through the rest of the file (XORing it with whatever is there) this reveals the 20 first bytes of the different resources.
And from there I went on to study the structure of the .pwl file. It is something like this (decrypted):
USERNAME........wpwpwpwpwpwpwpwpwpwp
rs???????
rs
rs rs????????????
rs???????
Where wp is i word pointer to the different resources (from start of pwl file). The first 2 bytes of the resource (rs) is its length in bytes (of course XOR with RC4 output). It is fairly easy to find all the resource pointers by jumping from start of resource to next resource, had it not been for the fact that the size is sometimes incorrect (courtesy of M$).
What follows is a short c program that tries to remedy this and reconstruct the pointertable thus generating at least 54 bytes of the RC4 pseudo random stream, and then proceeds to decrypt as much as possible from the different resources.
What does this show? Although RC4 is a fairly strong cipher, it has the same limitations as any XOR stream cipher, and implementing it without sufficient knowledge can have dire consequences. I strongly suggest that the programmers at Microsoft do their homework before trying anything like this again!
There are a few programs out there that can crack the current encryption scheme, but they are crude at best. One utility you can try is a program called Pwltool.
It should be noted that if you are upgrading Windows 3.x to Windows 95, the upgrade CD used to install Windows 95 uses the original (OEM1) encryption scheme. This means that as soon as you have upgraded from 3.x to 95, your *.PWL files are succeptable to decryption via the GLIDE.EXE program. Not a good thing, especially if it's your system you would like to secure. It should also be noted that the current encryption scheme is supposed to be implemented in the latest version of Windows 95 (OSR2) and Windows 98.
By the way, I think the author of the GLIDE.EXE program may also wish to remain anonymous so I am not including his name here.
This post was taken from alt.2600. cyrez@hotmail.com wrote: Ok, I cannot tell you how to get the actual password, but I can tell you how to take over that Windows account, do anything you want to it, and then put the original password back! Ok, here it goes... Type all of the following!!!
Ok, now when you re-enter under the "USER" account, Windows will ask you to delete the user.PWL file because it's corrupted. Now you can put any password you want for that account! This allows you to take over the account. Now if you want the user to be able to go back into his or her account, with his or her password, just type the following at the DOS prompt again... COPY USER.BAK USER.PWL (Whether or not you delete USER.BAK is up to you. I recommend that you do.)
If you would like to delete the backup file you made, simply type this in the DOS PROMPT: DEL USER.BAK If you changed anything in his or her account, then he or she will see some interesting stuff! P.S. This method will not necessarily work if Netware is installed on the machine. The author of this post mentions the "Windows" account. However, a Netware account is not mentioned at all. I haven't been able to test this myself, but I am assuming that Netware of any kind will interfere with this trick. Of course, a Netware hack is the goal if you are trying to access a file server on a network. Windows 95 may fall for this trick, but I don't think the Netware will. I think this method would only be good for machines at home or possibly even in the workplace. ENJOY!!! GUYS!!!
DEBUG USER.PWL
D
E101 00 (Take part of the password out.)
D100 (Just see what you have done.)
W (Write, what you have done to USER.PWL.)
Q (Quit.)
Ok m2mike, my Windows 95 computer is the most insecure system I have ever had. What steps do I take to secure my system?
First of all, if you are running Netware Client 32, whenever you login via the Netware Client 32, you still get prompted by Windows 95. To be technical, you will encounter a window that asks you whether or not you would like the computer to keep your individual settings.
When you logon through a Windows 95 logon screen you will be asked if you want the computer you are on to keep your individual settings (things such as what wallpaper you have on the desktop, what icons are on the desktop, what programs are in the start menu, etc...). The computer will ask you something to the effect of "You have not logged on at this computer before. Do you want to keep your individual settings?" This is where things get interesting. How you respond to that question determines whether or not a *.PWL file with your username is created. If you say NO, a *.PWL file WILL NOT be created. If you say YES, then a *.PWL file with your username WILL be created.
SAY NO!
When you say no, a *.PWL file is not created. If this happens to be a machine with the original version of Windows 95 (OEM1), then this prevents a potential hack. If the *.PWL file is not created, then the *.PWL file can't be decrypted via the GLIDE.EXE program. If this happens to be a current machine with one of the latest versions of Windows 95 on it, then PWLCRACK.EXE can't do a thing either.
Now sometimes after you say no to the individual user settings prompt, you will be asked to confirm your password.
CLICK CANCEL OR PRESS ESCAPE!
This will not add any information to the *.PWL, which is what you want if you care about security. No added information means that if your *.PWL file is succeptable to decryption, then when it is decrypted no relevant information will be extracted.
Besides a *.PWL being created when you say "YES" to that question, some other things in Windows 95 happen. When you say "YES", your username gets written to C:\WINDOWS\SYSTEM.INI under the {Password Lists} section. There are also various registry entries that get added to the Windows 95 registry. You will get you very own USER.DAT, which is a file that contains all of YOUR registry settings. You can view these registry files if you go into the following directory.
C:\WINDOWS\PROFILES\USERNAME\USER.DAT
C:\WINDOWS\PROFILES\USERNAME\USER.DA0
There is a reason why one's registry files are pertinent to the *.PWL hack. (Time for m2mike's hacking theory) In theory, some hacker who knew what the hell he or she was doing could run REGEDIT.EXE and edit the registry so that the confirmation window would never come up. What this means is that you will never get that window asking you if you want to keep your individual settings or not. If that window could be bypassed, then a *.PWL file would automatically be created without the user knowing that it had been created (password caching would have to be enabled for this to work). And if a *.PWL file is created, then the user's password is potentially open to a hack (depending on the version of Windows; in other words, depending on the encryption scheme). However, to actually do this would require a decent knowledge of the inner-workings of the registry. The default registry settings, if I'm not mistaken, are located in the C:\WINDOWS\ directory (you hackers can work the problem from here)(m2mike's hacking theory ends here).
Speaking of registry, the following is where you might look to get password values in plain text from the registry.
Windows 95 Passwords
Windows 95 may store user passwords in plaintext throughout the registry. Although the actual locations may vary in various releases, it may be worth it to check out these locations:
Password locations:
HKEY_LOCAL_MACHINE\System\controlset001\services\gophersvc\parameters
...\controlset002\"
...\curentcontrolset\"
...\msftpsvc\parameters\
...\w3svc\parameters\
Username locations:
HKEY_LOCAL_MACHINE\Software\microsoft\windowsnt\currentversion\winlogon
...\System\controlset001\services\bh\parameters
...\controlset002\"
...\curentcontrolset\"
...\Services\gophersvc\parameters\anonymouseusername
...\logsqlusername
...\msftpsvc\parameters\anonymoususername
...\logsqlusername
...\w3svc\parameters\anonymoususername
...\logsqlusername
So if your password is somewhere in the registry in plain text, then what good is Windows 95 security? Simple answer. Windows 95 sucks when it comes to security.
Another step to take when it comes to not just *.PWL security, but Windows 95 security in general, is to check all of your Dial-up Networking icons. If you have a teenager or some other mischief maker in the house or workplace, then you want to check all of your connections one by one and make sure you don't have the Save Password check box checked. If you check that box, then that password information gets sent to the *.PWL file. It also stays in the Password text box (it probably also gets sent to the registry). If the password is left in the text box, then anyone who comes across them can use them. Internet accounts and other things like that can literally be stolen. While there are actually two or more ways to steal Dial-up Networking connections, I will only reveal this one because the other method is irrelevant here. I will say this about the second method however. Revelation 1.1. Go search for it.
Ok m2mike, I have done what you said. I have said no to this and I have said yes to this and I did this and that and I clicked this and that and so on and so forth. You will probably notice that when you login, a window pops up that asks you whether or not it should keep your individual settings for future use. I told you to say NO. If you say yes, then information gets added to your *.PWL.
You will probably also notice that when you login, you are asked to confirm your password and I told you to CLICK CANCEL OR PRESS ESCAPE. You might also notice that once you have confirmed your password, you will not be asked again the next time you login. That's because Windows 95 now has your password information contained in the *.PWL file. Windows 95 doesn't bother you again to confirm your password because it just pulls that information from the *.PWL file instead of bothering you to type it in. And I have already said that you don't necessarily want to put that information inside a *.PWL because it's vulnerable.
And you will also notice that each time you login, you have to answer these questions. Most users get tired of answering these questions. They will simply answer the way they shouldn't answer because they figure out that if they tell the computer, "YES, KEEP MY INDIVIDUAL SETTINGS" and "HERE COMPUTER, CONFIRM MY PASSWORD", then the computer will never ask them again to do those things. Instead of prompting the user for the input, it just gets the information it needs from the *.PWL file.
Where am I going with this? To avoid answering these questions all of the time and to avoid your *.PWL being vulnerable to a hack, there are some steps you can take to make sure you don't need to worry about your password being retrieved from your *.PWL file by a hacker.
First, it is a good idea to periodically delete your *.PWL file. If someone ever comes by your system and tries to download your *.PWL file, they will get nothing.
Second, you can turn off password caching. This means that when someone logs in, no *.PWL file is created.
Third, update your system to what is current. This prevents a GLIDE.EXE attack.
Fourth, get all the patches you can for Windows 95. This doesn't totally secure your system, but it helps.
Fifth, get a different system. Perhaps one of the various flavors of UNIX. Perhaps this flavor of UNIX.
In conclusion, Windows 95 sucks.
PC MAGAZINE:
Obviously, the protection gained by password-protecting
a system this way is minimal. Still, it may prevent casual snooping.
If you're interested in protecting your windows 3.x system in this
fashion, you need to take one step not mentioned in the description
above. Before you can get Windows 3.x to launch a screen saver, you
must convince Windows the screen saver is an executable file. Edit the
programs= key in the [Windows] section of WIN.INI to include scr, like
so:
programs=com exe bat pif scr
Now place a program item for the screen saver in the StartUp
group, adding /s to the command line.
Windows 3.1 works with a wide variety of DOS versions, and many of
those DOS versions do not support skipping CONFIG.SYS and AUTOEXEC.BAT
processing by pressing F5 at start-up. If your version of DOS is one
such, simply hold down the Shift key during Windows start-up. This
will prevent the StartUp group programs from being loaded, thus
permitting you to edit the .INI files.
Under Windows 95, dragging a shortcut to your screen saver into the
StartUp menu will cause the screen saver to be launched automatically
at start-up. Windows 95 already recognizes that .SCR files are
executable. To get into a Windows 95 system that's protected in this
way, again simply hold down the Shift key while Windows 95 is
starting. As in Windows 3.x, this prevents the automatic loading of
the programs in the StartUp menu.
To disable the screen saver's password protection, you'll need to
edit the Registry. Start the REGEDIT utility from the Run menu and
navigate to the key
HKEY_CURRENT_USER\Control Panel\Desktop
You should see a value named ScreenSaveUsePassword in REGEDIT's
right-hand panel. Double-click this value and change its data from 1
to 0. Now the screen saver is not password protected.
There is also a theory that if you press any key 80 times it will bump out of the screen saver, then you can edit the registry. I have never done this though. I hope this helps.
In the article described above, there is a method that describes how to disable the screen saver password via the registry editor. This method is only to be used assuming that you dont' have full access to the desktop because of some silly program such as Foolproof. Otherwise, you would simply right-click on the desktop and disable the screen saver password through the Windows 95 GUI (graphical user interface).
Windows Screensaver bug
Summary
Description: Some versions of Win/Win95/WinNT seem to allow people to bypass screensaver password "security" with control-alt-delete and contol-ESC
Author: Common knowledge
Compromise: Take over "passworded" winbloze machines (local)
Vulnerable Systems: Some Win95 and WinNT boxes
Date: October 1996
Details
Exploit:
Just like the descriptions says. Sometimes you can bypass the "password"
prompt by control-alt-delete or control-ESC.
The above article on the "Windows Screensaver bug" was taken from http://www.insecure.org.
NOTE: The DisablePwdCaching value should be added as a DWord value.
Cautions:
You can edit the Registry using System Policy Editor (Poledit.exe) or Registry Editor (Regedit.exe). Check with your network administrator before you make any changes to the Registry.
For information about how to edit the Registry, view the "Changing Keys and Values" online Help topic in Registry Editor (Regedit.exe). Note that you should make a backup copy of the registry files (System.dat and User.dat) before you edit the Registry.
Using Registry Editor incorrectly can cause serious problems that may require you to reinstall the Windows 95 operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
System Policy Editor (Poledit.exe) is available in the Admin\Apptools\Poledit folder on the Windows 95 CD. Use the Add/Remove Programs tool in Control Panel to install System Policy Editor.
NOTE: System Policy Editor is not included in the floppy disk version of Windows 95. You can download Policy.exe, a self-extracting executable file containing Poledit.exe, from http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wumanagementtools/w95policyeditor/default.asp?site=95
Other places you can get *.PWL information. If this information isn't enough, then go try the following url's: http://www.nmrc.org Go look at section 8 of the Netware Hacking FAQ. There is some information there regarding the *.PWL hack. http://www.webdon.com/vitas/pwl.htm There is some information located at the site that sells Pwltool. Pwltool is the program that is supposed to be able to crack any *.PWL file (OEM1 and OSR2). The information there is just reiterating what I already have here.
There is only one thing that should be known about Windows 98 and that is this. The way it encrypts *.PWL files is exactly the same as the current version of Windows 95 (OSR2). This means that any *.PWL file from a Windows 98 OS is succeptable to a brute force attack via a program such as Pwltool. You can always count on Microsoft to have security holes in their operating systems. :-)
The technique I am about to describe was first used in the field in March or April of 1997. I don't know the technical details as to how or why it works, but it does. This is what I did.
First, you need to access the Control Panel.
Second, double-click the Network icon and then click the Identification tab.
Third, click the box that is labeled Workgroup.
When you click the box Workgroup, you should see the name of the server that you usually connect to when you or any other user logs in. In other words, what you will see in the Workgroup box is the name of the network server you connect to when you login. In yet even more words, you will see the name of the default server in that box.
There should be an option in this part of the Network Control Panel where you can view a list of users for your server. The option for viewing a list of users will not be here if you do not have Netware installed. If you have no Netware, then you have no list of users. This is where you can experiment.
If there is a server listed there named something like "HACK1", then try changing it to "HACK2".
You will have to restart the computer for the new settings to take effect. In other words, if you want to see a list of users from the server named "HACK2", then you will have to restart the computer to see the list of users from the server named "HACK2".
What does this do? Suppose you have a list of users on "HACK1", then you can get the list of users not only from "HACK1", but you can also get a list of users from "HACK2".
This function of Windows 95 is similar to the "USERLST.EXE" command in Netware 3.x and the "CX.EXE" command in Netware 4.x. You can get a list of users from servers that you would not be normally allowed access to. This can be very useful in going through user id's and seeing which ones might not have a password assigned to them.
As far as I know this method of gathering a list of users via the Control Panel works with Netware 3.x. I don't know if it works with Netware 4.x. I am also unaware if Novell Client 32 interferes with this method.If you happen to know the name of the target server you would like access to, then this method can be very useful. The only drawback is that you have to have access to the Control Panel in Windows 95. If you don't have access to the Control Panel because of a silly program named FoolProof, then click here. If you have access to the Netware commands via the DOS prompt, then don't even bother with this.
Just something to experiment with.
The entire point of all the *.PWL file and password hacking techniques described in this document is to get a network password to access a network. More specifically, a Novell Netware network that runs under Windows 95. Some of these methods can also be used to access other computers on a peer to peer network. It is also to show that even the most basic functions in an operating system are vulnerable to "hacks" or whatever you would like to call it.
As always, if something here is wrong, then e-mail m2mike@yahoo.com. Thank you.