How does folder hiding software work? - windows

Last few days i have been working on building an application to hide folders(thanks to the paid versions of such softwares). After a heavy googling I zeroed into some shell script that would first create a folder and then rename the folder to "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}". It would then hide this folder by using the command attrib -s -h Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}. The funda behind this is to make it a system folder and hide it. But if you would uncheck the Hide sytem folders in Folder option the control panel becomes visible. I would like to make this folder completely invisible as how the other folder protecting softwares do.
Can somebody throw some more light on this?
Thanks a ton...

Most folder hiding software works by implementing either an extension for Windows Explorer or a file system filter driver.
The first method means that certain items will not be visible when browsing folders in Windows via the UI, but will still be visible to other software and via the command prompt. For example, the Recycle Bin and Temporary Internet Files folders work this way.
The file system filter driver method proxies calls between Windows and the underlying file system and only allows certain requests through. This is similar to how virus scanners prevent access to infected files.

The general idea is that you hook the file system API's and filter out the file system entries you want to hide.
But JelloMonkey is right - this is rootkit behavior and you will get flagged as malicious by rootkit detectors for this kind of behavior. That's likely to get your entire directory quarantined or deleted.

Related

How to completely "lock" a folder to prevent new file creations (copy & paste included)

I am currently opening a folder to restrict access to it, as I don't want to set an ACL on the actual folder.
Is this possible with CreateFile()?
Copy and Pasting works, and that is a problem for me. Drag-and-drop from Windows Explorer does not, however, and has the desired effect.
Any advice here?
I'm merely trying to prevent as much access as possible to the folder with CreateFile() for security reasons, and would prefer to use the CreateFile() API.

Why does .MSI file open read-only?

I am attempting to open a .MSI installer package file to modify it. Whenever I try to open it, it opens in read-only mode. I see this with Orca, with InstEd, or when opening the file directly via code:
`MsiOpenDatabase()` (ERROR_OPEN_FAILED with MSIDBOPEN_DIRECT or
MSIDBOPEN_TRANSACT persistence modes).
The file itself does not have the read-only attribute set (in fact, has no attributes set)
I am using an account with Administrators group access
As far as I can tell, no other process has the file open
No installs are in progress or suspended
I can copy the file to another location, and open it read/write there. But the original, I cannot touch
Thanks in advance for your help.
My guess is that this is caused by one of the following factors:
Custom NTFS access rights - defined for the file in its security descriptor
The file might be "blocked" - marked with a special flag after being downloaded via Internet Explorer.
The resolution for the latter is to right click the file and select properties and click the unblock button at the bottom of the property page and pressing OK.
The resolution for custom NTFS rights are done in a similar way by going into the security
tab of the property page for the file, but it is easier just to copy and paste the file and use the fresh copy with the default security.
Found it.
#Glytzhkof, you almost had it but there's a detail I did not know about, and left out. This is a package that lies in a folder under "access protection" by my system's anti-virus program: a filesystem hook that blocks modification of critical system and AV files. Turn off access protection temporarily, and the file is wide open.
Fortunately, one of my teammates had some experience with this, and suggested I try it. Bingo.
Thanks, all.
What I have done to get it working was to create first a backup of the MSI file, and then open that backup. It worked for me
Try to close/kill processes that might interfere, for example:
Other running Install shield instances
Installshield updater
Installshield licensing service
Antivirus

Opening a CHM file produces: "navigation to the webpage was canceled"

I am trying to open a .chm file.
I downloaded the source, extracted it, and double clicked on Waffle.chm and clicked "Open" but no matter what element in the chm file I click, I get the message:
Navigation to the webpage was canceled.
What you can try:
Retype the address.
What's going on here?
Summary
Microsoft Security Updates 896358 & 840315 block display of CHM file contents when opened from a network drive (or a UNC path). This is Windows' attempt to stop attack vectors for viruses/malware from infecting your computer and has blocked out the .chm file that draw data over the "InfoTech" protocol, which this chm file uses.
Microsoft's summary of the problem: http://support.microsoft.com/kb/896054
Solutions
If you are using Windows Server 2008, Windows 7, windows has created a quick fix. Right click the chm file, and you will get the "yourfile.chm Properties" dialog box, at the bottom, a button called "Unblock" appears. Click Unblock and press OK, and try to open the chm file again, it works correctly. This option is not available for earlier versions of Windows before WindowsXP (SP3).
Solve the problem by moving your chm file OFF the network drive. You may be unaware you are using a network drive, double check now: Right click your .chm file, click properties and look at the "location" field. If it starts with two backslashes like this: \\epicserver\blah\, then you are using a networked drive. So to fix it, Copy the chm file, and paste it into a local drive, like C:\ or E:. Then try to reopen the chm file, windows does not freak out.
Last resort, if you can't copy/move the file off the networked drive. If you must open it where it sits, and you are using a lesser version of windows like XP, Vista, ME or other, you will have to manually tell Windows not to freak out over this .chm file. HHReg (HTML Help Registration Utility) Utility Automates this Task. Basically you download the HHReg utility, load your .chm file, press OK, and it will create the necessary registry keys to tell Windows not to block it. For more info: http://www.winhelponline.com/blog/fix-cannot-view-chm-files-network-xp-2003-vista/
Windows 8 or 10? --> Upgrade to Windows XP.
"unblocking" the file fixes the problem. Screenshot:
Win 8 x64:
just move it to another folder or rename your folder (in my case: my folder was "c#").
avoid to use symbol on folder name. name it with letter.
done.
In addition to Eric Leschinski's answer, and because this is stackoverflow, a programmatical solution:
Windows uses hidden file forks to mark content as "downloaded". Truncating these unblocks the file. The name of the stream used for CHM's is "Zone.Identifier". One can access streams by appending :streamname when opening the file. (keep backups the first time, in case your RTL messes that up!)
In Delphi it would look like this:
var f : file;
begin
writeln('unblocking ',s);
assignfile(f,'some.chm:Zone.Identifier');
rewrite(f,1);
truncate(f);
closefile(f);
end;
I'm told that on non forked filesystems (like FAT32) there are hidden files, but I haven't gotten to the bottom of that yet.
P.s. Delphi's DeleteFile() should also recognize forks.
The definitive solution is to allow the InfoTech protocol to work in the intranet zone.
Add the following value to the registry and the problem should be solved:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000001
More info here: http://support.microsoft.com/kb/896054
Go to Start
Type regsvr32 hhctrl.ocx
You should get a success message like:
" DllRegisterServer in hhctrl.ocx succeeded "
Now try to open your CHM file again.
other way is to use different third party software. This link shows more third party software to view chm files...
I tried with SumatraPDF and it work fine.
I fixed this programmatically in my software, using C++ Builder.
Before I assign the CHM help file, Application->HelpFile = HelpFileName, I check to see if it contains the "Zone.Identifier" stream, and when it does, I simply remove it.
String ZIStream(HelpFileName + ":Zone.Identifier") ;
if (FileExists(ZIStream))
{ DeleteFile(ZIStream) ; }
There are apparently different levels of authentication. Most articles I read tell you to set the MaxAllowedZone to '1' which means that local machine zone and intranet zone are allowed but '4' allows access for 'all' zones.
For more info, read this article:
https://support.microsoft.com/en-us/kb/892675
This is how my registry looks (I wasn't sure it would work with the wild cards but it seems to work for me):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000004
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"UrlAllowList"="\\\\<network_path_root>;\\\\<network_path_root>\*;\\ies-inc.local;http://www.*;http://*;https://www.*;https://*;"
As an additional note, weirdly the "UrlAllowList" key was required to make this work on another PC but not my test one. It's probably not required at all but when I added it, it fixed the problem. The user may have not closed the original file or something like that. So just a consideration. I suggest try the least and test it, then add if needed. Once you confirm, you can deploy if needed. Good Luck!
Edit: P.S. Another method that worked was mapping the path to the network locally by using mklink /d (symbolic linking in Windows 7 or newer) but mapping a network drive letter (Z: for testing) did not work. Just food for thought and I did not have to 'Unblock' any files. Also the accepted 'Solution' did not resolve the issue for me.
Moving to local folder is the quickest solution, nothing else worked for me esp because I was not admin on my system (can't edit registery etc), which is a typical case in a work environment.
Create a folder in C:\help drive, lets call it help and copy the files there and open.
Do not copy to mydocuments or anywhere else, those locations are usually on network drive in office setup and will not work.

Is it possible to check in/out files from a webserver with a FF-plugin or Chrome extension?

I am creating a CMS and want to know if its possible to download a folder, edit things and upload it back to the server without much user interaction.
For example just press a checkout button and the files are stored on your computer. after you are finished editing these files you press the checkin button. no selecting files again and such things.
Is it possible to access the filesystem and up/download files after a user gives you the permission?
In Firefox - yes, add-ons have full access to the hard drive and can download/upload files. See for example FireFTP, also code snippets.
In Chrome - no, extensions are not allowed to access the hard drive, other than limited access via File System API (which is a virtual file system actually). Best you can do is including a binary NPAPI plugin into your extension and making it write to disk. Users will see lots of scary warnings when installing this extension.

IFileSaveDialog - choosing folders in Windows 7

In Vista, I have been using an IFileSaveDialog to let users pick a "save-as" folder. Users export a folder of images, say, and need to choose a new or existing target folder.
Briefly, the code goes like this:
IFileSaveDialog* dialog; // created
dialog->SetOptions(FOS_PICKFOLDERS);
dialog->Show(NULL);
dialog->GetResult(&shellItem)
In Windows 7, the FOS_PICKFOLDERS option appears to have been disallowed (and is marked as such in the API). The return value on the SetOptions call is E_INVALIDARG. If I use a IFileOpenDialog, I'm allowed to set the folders option, but the user is prompted with an error when choosing a nonexistent folder (despite my setting flags suggesting not to do this).
Is there an alternate way to get the new IFileDialog to act as a "save folder" dialog?
[To head off some comments, the SHBrowseForFolder API still exists, but is still not an acceptable solution for our UI deciders.]
The reason for this can be found in the documentation:
FOS_PICKFOLDERS: Present the Open dialog offering a choice of folders rather than files.
Using FOS_PICKFOLDERS for "save" was never supposed to be supported - but Vista didn't enforce it. Use IFileOpenDialog instead and you're good to go.
You are picking an existing folder (not specifying a folder to create), so open was always the correct choice.
I haven't played around with the Windows 7 dialogs yet, but downloaded the Windows® API Code Pack just this morning as I am implementing the Thumbnail Toolbar and Icon Overlay in the application I am working on. It'll probably point you in the right direction.

Resources