Windows folder password

Question

I have been thinking to implement the following program, just out of curiosity and learning experience. I want to write a program for password protecting a folder, so you can only open the folder after entering the correct password. I know this is specific to the operation system, so let it be Windows. I guess this is only possible in C++, but if it is also possible in plain C# or Java(which I doubt), then please tell me.

Could someone point me in the right direction? Thanks in advance!

Best regards, Petar

Do you mean that your program is going to be a service and all user actions concerning folders must do through your service? Sounds tricky... — Armen Tsirunyan, Apr 02 '11 at 12:07
@Armen Tsirunyan - Yes, it can be said so. Some folders will be password protected, some not. — Petar Minchev, Apr 02 '11 at 12:15
Here's a tricky question (and I think the solution is an encryption driver): Alice and Bob connected to a machine with encrypted folder F. Alice knows the password for F and Bob doesn't know the password for F. Bob tries to get into the folder in "weird" ways (cmd.exe or his own application) and finds encrypted files, as they should be. Alice inserts the password for F, so you decrypt the files. Now, how do you decrypt the files and making sure that Bob will not be able to touch them? Somehow have to make sure that users that don't have access to F will not be able to access it! — TCS, Apr 02 '11 at 12:19
sounds like a File System driver. http://www.osr.com/fddk.html — kenny, Apr 02 '11 at 12:36
@Petar Minchev: take a look at this: http://stackoverflow.com/questions/1109564/intercept-windows-open-file Accepted answer applies to folders as well. — Aoi Karasu, Apr 02 '11 at 12:39
I think Aoi Karasu's link provides the best concept to realize your program. — Falcon, Apr 02 '11 at 13:01

Falcon · Accepted Answer · 2011-04-02T13:03:03.963

If you want a bulletproof protection of your files, then just protecting access to the folder is not enough, you'd have to encrypt them and there're secure containers and file system encyptions on the market.

If it does not need to be high security, you can hook into Windows I guess. You'll especially need to hook into the directory listing functions, like FindFirstFile, FindNextFile and OpenFile also probably (and into their derivates like FindFirstFileW) and maybe some others.

You do that by redirecting calls to kernel32.dll to your custom functions, see a little code example below which I found on the internet:

    unsigned char Store[10];
    //redirect FindNextFileW to your custom function
    void HookAPI()
    {
        DWORD OldProtect, NewProtect = PAGE_EXECUTE_READWRITE;
        HMODULE hmod = GetModuleHandle("Kernel32.dll");
        long pa = (long)GetProcAddress(hmod,"FindNextFileW");
        long pa2 = (long)MyFindNextFile;
        long dAddr = pa2 - pa - 5;
        unsigned char *p = (unsigned char *)pa;
        unsigned char *p2 = (unsigned char *)(&dAddr);

        VirtualProtect((void *)pa,5,NewProtect,&OldProtect);

        for (int i=0;i<5;i++)
            Store[i] = p[i];

        p[0] = (unsigned char)0xE9;
        for (int i=0;i<4;i++)
            p[i + 1] = p2[i];

        VirtualProtect((void *)pa,5,OldProtect,&NewProtect);
    }

    void UnHookAPI()
    {
        DWORD OldProtect, NewProtect = PAGE_EXECUTE_READWRITE;
        HMODULE hmod = GetModuleHandle("Kernel32.dll");
        long pa = (long)GetProcAddress(hmod,"FindNextFileW");
        unsigned char *p = (unsigned char *)pa;

        VirtualProtect((void *)pa,5,NewProtect,&OldProtect);

        for (int i=0;i<5;i++)
            p[i] = Store[i];

        VirtualProtect((void *)pa,5,OldProtect,&NewProtect);
    }

    BOOL WINAPI MyFindNextFile(HANDLE hFindFile,LPWIN32_FIND_DATAW lpFindFileData)
    {
        UnHookAPI();
        BOOL ans = FindNextFileW(hFindFile, lpFindFileData);

        //your logic here, display password prompt to user e.g.

        HookAPI();
        return ans;
    }

What you want to do can also be done with Java (JNI) or C# (pinvoke), but it'd be a real detour. I'd use something which can be compiled to native code.

Edit: Aoi Karasu provided a link to a post which suggests to use a FileSystemFilterDriver, which is probably the best concept to realize the application in question.

What kinda hook would you use for this? I mean which hook enables you to monitor specific API calls ? — Adham Atta, Apr 02 '11 at 12:54
You do not monitor them, you "bend" the calls via memory manipulation. — Falcon, Apr 02 '11 at 13:04
Are you sure that FindNextFile and FindFirstFile are being used by explorer? And even so, what happens once you decrypt? how do you prevent other users in the system to access the decrypted files? — TCS, Apr 02 '11 at 13:21
@falcon: I may not understand this well ,So please correct me if I'm wrong ,Wouldn't I be "bending" the calls done from my process space only ? I mean why would this have any effect on calls coming from other processes where the address of the kernel function is untouched. — Adham Atta, Apr 02 '11 at 13:56
@Adham you're right, but you usually hook that code into any running process anyway. That's not a problem if you're running some program with elevated privileges on the target machine. — Falcon, Apr 02 '11 at 15:51
@T.C. Read my post thoroughly. If you want a good protection, use a crypto container or an encrypted filesystem. Someone with access to the raw data can always access unprotected data. On a multiuser system, someone who can read your memory will always be able to read the contents of your decrypted files anyway. — Falcon, Apr 02 '11 at 15:53
To clarify how non-bulletproof the second case is: I've written a serious app that unpatches such modifications. (Reason: people writing such security code aren't very good coders, either. Their code crashed, but of course that was in our process.) — MSalters, Apr 04 '11 at 09:08

score 0 · Answer 2 · answered Apr 02 '11 at 12:29

An idea from the top of my head for a "simple" implementation.

The idea is to use windows authentication to create such protected folders.

Your application can generate a user for each encrypted folder F. So for folder Fi you will generate user Ui with password Pi.

Also, for each Fi your application will have to make sure that ONLY Ui have access to it, and that no one can add access to it. Also, encrypt the files using window's encryption in NTFS.sys (there should be a simple function to encrypt the files in windows API, can't remember its name).

Now, if someone wants to access Fi you will popup a messagebox asking for the password, if they are right (you can use AccessCheck()) you can open explorer with Ui credentials pointing to Fi OR add Ui credentials to the user (in this case you will have to remove them at some point, so it could be tricky).

score 0 · Answer 3 · answered Apr 04 '11 at 09:13

Windows (NTFS) supports "junction points". These are entries in the file system that tell Windows to execute a bit of code. A common type of junction point is the hardlink to another file or folder. However, you can add other types with matching drivers.

In your case, your encrypted folders could really be junction points that work like secured hardlinks. Yo only resolve the hardlink for authorized users. Because this works at NTFS kernel level, you don't need to worry about the million different file functions that exist in the different layers of Windows.

Windows folder password

3 Answers3