# Password protecting folder in windows using a .bat/ .exe file: is it such a bad practice?

I have been browsing the internet looking for simple ways to password protect a folder in Windows 7 without any extra software nor BitLocker.

I have found several places that state that using a .bat file (and then converting it to an .exe file to avoid people opening it in a text editor and making sense of it) would allow this.

However something tells me this is a not very secure system.

I share here some of the typical .bat file's code they claim to work and password protect the folder:

@ECHO OFF
if EXIST "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}" goto UNLOCK
if NOT EXIST Private goto MDPrivate
:CONFIRM
echo Are you sure to lock this folder? (Y/N)
set/p "cho=>"
if %cho%==Y goto LOCK
if %cho%==y goto LOCK
if %cho%==n goto END
if %cho%==N goto END
echo Invalid choice.
goto CONFIRM
:LOCK
ren Private "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}"
attrib +h +s "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}"
echo Folder locked
goto End
:UNLOCK
set/p "pass=>"
if NOT %pass%== wonderhowtogoto FAIL
attrib -h -s "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}"
ren "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}" Private
echo Folder Unlocked successfully
goto End
:FAIL
goto end
:MDPrivate
md Private
echo Private created successfully
goto End
:End


Would this be easy to crack after we export it into an .exe file? What if I encrypt the .exe file for extra security?

And also, would the folder need to be hidden for this "trick" to work? What are those keys like 21EC2020-3AEA-1069-A2DD-08002B30309D?

Thanks very much for throwing some light over here.

• Just cheap tricks that achieve nothing. Useful for a bit of fun on school computers at a young age perhaps. What were your sources? Do we need to correct them, or were they just "for fun"? – Lightness Races in Orbit Feb 14 '18 at 3:12
• "(and then converting it to an .exe file to avoid people opening it in a text editor and making sense of it)" This won't stop people looking at it. The moment they realise the exe doesn't run properly they'll open it in a text editor to find out why and see it's a renamed batch file. – Pharap Feb 14 '18 at 3:23
• Nitpick: if NOT %pass%== wonderhowtogoto FAIL -> if NOT %pass%== wonderhowto goto FAIL – jkd Feb 14 '18 at 3:44
• @Pharap : Where I think "Notepad" fits the definition of "right tool" (there will be a lot of crap as well, but the text should be directly viewable) - unless of course the "convert to exe" ROT13 encodes the text. – Martin Bonner Feb 14 '18 at 8:17
• @jakekimdsΨ to be perfectly honest the whole thing could be summed up as goto FAIL – Chris H Feb 14 '18 at 14:05

This batch script doesn't protect anything at all. It just renames the folder in question and sets the system and hidden attributes, which makes the folder a little bit harder to find and might keep your ten-year-old child from seeing it, but it won't stop anyone else.

At most, we might call this "security by obscurity", but I'm hesitant to even call it that, because in reality, setting the hidden and system attributes don't obscure that much.

There is no encryption going on at all – the folder doesn't get password-protected, the password is only used in the batch file to block someone from using the batch file to automatically remove the hidden and system attributes and rename the folder back to something sane.

Would this be easy to crack after we export it into an .exe file?

Yes. Simply extract all strings from the .exe file and you'll find the "password".

What if I encrypt the .exe file for extra security?

Again, the script does not provide any security at all. If you encrypt the batch/.exe file, you make it harder to use, but you don't actually make the folder in question more secure.

What are those keys like 21EC2020-3AEA-1069-A2DD-08002B30309D?

These don't mean anything by themselves (edit: see Bob and Danny's comments about junction points for an explanation of their meaning). They might be part of a larger system the batch file is part of, but they don't add anything to the security of the actual folder – it's just part of the folder's new name while it is "hidden".

You've already said it: Use BitLocker or VeraCrypt. Veracrypt can work with container files which will contain a whole tree of folders and it offers real security, as does BitLocker.

If you don't want to use any extra software, do what Mike suggests and zip the folder, protecting it with a password. This offers you nowhere near the security of BitLocker, VeraCrypt, and compatriots, though.

• It looks like, at least on some versions of Windows, folders that follow a specific naming pattern (Control Panel.{GUID}) will open up a specific Control Panel applet rather than showing the contents. Of course, this is trivially defeated by renaming the folder (no password required), browsing with something other than Explorer (cmd, powershell, heck even your web browser...), etc.. – Bob Feb 14 '18 at 3:13
• Why do you say zipping the folder with a password offers nowhere near the security of BitLocker? Winzip offers a choice of AES-128 and AES-256. – Martin Bonner Feb 14 '18 at 8:20
• Because security isn't just about the strength of an encryption algorithm, it's about the whole system. So even if the zip encryption is strong (it used to be very weak, btw), the programmers wanted to develop a system that could compress files plus encrypt the result, not provide secure storage. So they most likely didn't think about things like sensitive data, including the encryption keys, getting paged out to disk, or about the system logging sensitive information to the system log, or about overwriting sensitive data with random bytes, etc etc.Providing secure encrypted storage is hard. – Pascal Feb 14 '18 at 8:49
• @MartinBonner because when viewing files from a password protected zip the plaintexts get copied into %tmp% on the harddrive; they do get deleted later but using normal delete instead of a secure erase. – ratchet freak Feb 14 '18 at 15:23
• "These [hex strings] don't mean anything by themselves" - that's incorrect, they are junction points. Even if you can see hidden folders, if you attempt to open this folder, it will open the Control Panel instead. You'll need to rename the folder to actually open it. – BlueRaja - Danny Pflughoeft Feb 15 '18 at 11:24

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

The system you propose works (though I wouldn't use the word "secure") only as long as the code remains secret. Even if you "hid" the .bat code by renaming it to .exe and gave that file to any moderately-skilled hacker, they will open it in a text editor fancier than notepad and figure out what you've done in less than 30 seconds.

Instead, try turning it into a key-based system where you don't need to hide the code. For example, compress the folder into a password-protected ZIP and access it only in memory (i.e. in a zip viewer program) rather than extracting it to disk.

• It's not secure even if the code remains a secret - this "protection" can be broken even accidentally, since any full disk scan/search will find matching documents if they're stored in this "hidden" folder. – Peteris Feb 14 '18 at 16:34
• @Peteris Let's say it works as long as the existence of the folder and its garbled name remain secret, which do appear to be goals of the system. It just uses really bad implementation to try to achieve them. – jpmc26 Feb 16 '18 at 2:05
• @jpmc26 no, it doesn't work - scanning all folders works even if "the existence of the folder and its garbled name remain secret"; the files inside and their contents are searchable, findable and will show up even accidentally if the user runs a search for something and the search (as it should) scans all folders on the drive, or (more likely) uses an index computed from all folders on the drive. Including ones the user didn't know about or that had weird, garbled names. – Peteris Feb 16 '18 at 11:32
• @Peteris If you scan everything and find the name of the folder, you know it exists and know the name of it and they are no longer secret. The fact that the implementation relies on them remaining secret (which would not happen in an attack or maybe even by accident, as you demonstrate) is why it's bad. That's how Kerchoff's Principle applies here; those are pieces of information other than the key. – jpmc26 Feb 16 '18 at 12:01

Is it such a bad practice?

# Yes.

The batch file doesn't use the password to un-hide your folder, it just compares it and if it turns out correct, runs the "unlocking" commands. And there's nothing preventing you from running these commands without checking the password:

attrib -h -s "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}"
ren "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}" Private


Boom, the secret folder is "unlocked". No cracking needed.

This doesn't even provide obscurity - regular Windows search will still search files inside a renamed and hidden folder. Just tested it out of curiosity.

No point even opening the exe file; just do the usual search for files of the right type - which is exactly what someone trying to steal your files would begin with (well, maybe right after your Documents), and it will pop out.

It's not even good for a .bat. If the goal was obscuring a file from computer-illiterate guests, but keeping it visible to all power users to it, you could move it to a partition with no letter assigned to it, calling it by GUID.

There are also fancier tricks to obscure a bat than turning it into an exe, like making it self-modifying, but nothing that provides security without encryption.

This script just sets the system and hidden flags of folder "Private" (attrib +h +s), which hides it from normal display in Windows Explorer and from a default listing on the commandline using dir, and furthermore renames the folder so that (if the first change does not prevent the user from seeing it), it is not shown as a folder in Windows Explorer, but as the Control Panel, which is the purpose of the the funny looking name part "{21EC2020-3AEA-1069-A2DD-08002B30309D}".

However, the first change can easily be circumvented by changing the Explorer option set to "show hidden files, folders, and drives". Actually, this is the setting on my computer. For the DIR command, you would just have to use DIR /a:HS instead of purely DIR to show the folder.

And the second change only applies to Windows Explorer, not to the command line or any program that just lists files without using Windows Explorer. Note, however, that the file open or save dialogue shown in many applications also is a variant of Windows Explorer, behaving mostly the same.

Actually, you could do the attribute change yourself using the attrib command, and for the "hidden" attribute, but not the "system" attribute, also in the folder properties dialogue in Windows Explorer. And the renaming, of course you could do as well on the command line. And as you can do the changes, you can also revert them on the command line without needing to know any password.

So, in the end, this script only hides the folder from Windows Explorer or the file listing in default mode. But users with some technical knowledge can circumvent it. In fact, the password is only needed if you want to use this batch file to unhide the folder, but not if you just do that on the command line or in tools like third-party file managers yourself, so that is completely useless. And hence the discussion how to hide it is moot.