I'm on a Win7 platform, I have a third party software that opens and writes to a given file. I would like to intercept the data going into that file and view it, before the process finishes. While the file is being filled, it is visibly getting bigger in explorer, so the data is being written IMO. Of course, any attempt (using any high- or low-level api I know of, writing in Python if it makes any difference) results in an" access is denied" error 5 or "The process cannot access the file because it is being used by another process." error 32.
What am I missing?
You cannot access the file unless the other app allows it. When it opens/creates the file, it specifies sharing rights for the file. If you try to open the file while it is already open, using flags that are not compatible with the sharing rights, your open will fail. If you want to open the file for read-only access, the other app must open/create the file with read sharing enabled. You can use a tool like SysInternals Process Monitor to see what sharing rights the other app is actually using.
Related
I am working on a Windows application written in Java that writes its project specific information and settings in specific project files. I wish that only this application can read and modify the project files and settings and these files can not be read or edited via some text editor by the user or written to by some other application. I was thinking of adding obfuscation to prevent information access but how can i prevent any other user process from writing to the files.
As long as your application is running, you can just keep the file open in your application. You can specify how other processes can access the file while you have open when opening the file (the default usually is that no one else can write it, though)¹.
However, if your application isn't running all the time that won't work, obviously. The usual way to solve this is to run the application under a separate user account and only give that account permission to modify the files. That sort of thing works for servers and services, of course, but is rather rare for a normal user-facing application, though.
You can employ obfuscation, or store the contents elsewhere as well (e.g. another file in another place, registry, ADS, ...) and try recovering from a mismatch. But fundamentally, barring separate user accounts, you have no way of actually forbidding access to a file. Such things cannot be done with process-level granularity on Windows.
¹ I'm not sure how much control Java gives you over this, though. A quick look at FileInputStream seems to give you absolutely no control over the handle's sharing policy. You can use native code to open the file, though, though I'm not sure right now how to pass that to the usual Java I/O classes. It could be difficult.
I have one Vbscript which runs continuously on my system to monitor a web page on Internet Explorer.
I have permanently deleted this Vbscript file from its original location on system by mistake, However the script is still in RAM and is still running and monitoring the web page.
This script is very important to me but I have lost it :(
I want to know if there is any way by which I can recover the code of Vbscript file from system's RAM or any temporary file as the script is still running.
I am not allowed to use any file recovery software, so please don't suggest to install any third party data recovery software.
Try using 'ADPlus.vbs' script from WinDbg:
1. http://msdn.microsoft.com/en-us/windows/hardware/hh852365
2. http://support.microsoft.com/kb/286350
As the code was running, I followed the below process to recover the running code:
Go to Task Manager
Select the process and create dump
Open online dump analyser (www.osronline.com)
Upload dump file
Download the dump analysis
The dump analysis provided almost 95% of the correct code. Code within some loops were distorted or changed. As I was the owner of the code I was able to correct it.
Use HxD, it can view all ram content relative to any process at fly. It is commonly used to hack currently running games etc.
After locating your script, it might be needed to clear alphanumeric mess between your code, N++ and regex knowledge may be useful.
I have a VB6 application and it links to a MS Access DB. All records on a data entry screen are written or read using ADO/SQL.
At one user site, (using Win 7 - his UAC was set to the maximum security so to start with, there were errors reading/writing galore! Furthermore the app and Data (sub-folder) folder was set to only read. So once I corrected all of this by changing Security for "All User" to FULL CONTROL, the records were written to the DB. However when I open the MDB from MS Access directly I was unable to see ANY records in any of the 3 tables where the Client entered data from the front end.
So
1. either MS Access is hiding the rows in the table with data and display and blank table or
2. there is a hidden copy of the MDB in the Data sub-folder (as the program check the availability of the MDB file when it starts and if unavailable it posts a Message Box error
Has anyone seen this behaviour and if it is #2, how do I in Win 7 show all files - bear in mind that MDBs are not operating system files so by default should not be hidden. OR is this some AV (Symantec) activity?
Please see this link from Y 2004 which is exactly like my issue - but there was no answer:
http://www.pcreview.co.uk/forums/hidden-records-t1086918.html
Appreciate any help anyone can shed
Regards
Fonz
This sounds like an improperly designed application that puts writable data (an MDB file here) within a protected folder ("Program Files") and is being run with no application manifest stating that it is "Vista aware." If you do this Windows will try to fit a standard set of appcompat shims to the program, and in this case most likely the file virtualization shim is at work.
This results in each user creating private copies of the orginal data within their Virtual Store folder. These private copies are what gets updated.
A proper manifest would result in a fatal runtime error on this security violation instead, making it quicker to understand what is being done wrong and generally leading to a faster resolution.
Things such as INI files, MDB files, and other application resources that must be updated and available to any user of the system should be put into an application-specific folder your installer creates under [CommonAppData]. You installer should set the desired security attributes on the subfolder to contain writable files so that all users have the desired access. The default here is "owner" access which probably is not what you would want (file creator has full access, others have read access).
This works on any version of Windows including Windows 95 with the IE4 Desktop Update. It is fairly easy to accomplish via Installer MSI packages.
Are you 100% certain about which MDB file is being written to? If you are writing then seeing your records in the VB6 but then can't see them in the MDB that you open, it's possible that it's doing it to a different file.
I suggest you use process monitor to verify exactly which file is being written to by the VB6 app. That will allow you to troubleshoot further.
http://technet.microsoft.com/en-us/sysinternals/bb896645
It can be a little busy but it will let you establish exactly which file is being written to regardless of any asuumptions you make about the operation of your code.
For testing and development purposes, it would be nice to somehow simulate (spurious) file access errors to local files. For example, even if an application has correctly opened a file with the appropriate restrictive sharing flags, it still can happen that an attempt to access the file (through any of the Win32 API functions or your favourite framework, which internally will just call any of the Win32 API functions) can fail.
The only example I ever was able to track down was the virus scanner on a machine, but I guess there could be other reasons. (In this question's comment, Luke mentions something about "File system filter drivers".)
FWIW, I know of a few possibilities to "simulate" file problems, that I do not consider good solutions, either because they require to much manual work or because they don't fit for every app/file:
Place a file on a network drive or removable storage device - that way you can just mess up the device (unplug, disk-full, ...).
Open the application process in Process Explorer and close the handle of the file you want to test.
So the question really is if there are any ((semi)automated) tools that can mess up file access (on an NTFS drive) even though an application has already opened a file with appropriate (for the app) sharing flags.
Holodeck purports to allow Win32 API hooking, which would enable you to manipulate return codes as needed for Fault Injection.
If your API set of interest is well-defined, you could probably do this yourself using the Import Address Table approach described here.
UNIX file-locking is dead-easy: The operating system assumes that you know what you are doing and lets you do what you want:
For example, if you try to delete a file which another process has opened the operating system will usually let you do it. The original process still keeps it's file-handles until it terminates - at which point the the file-system will quietly re-cycle the disk-resources. No fuss, that's the way I like it.
How different things are on Windows: If I try to delete a file which another process is using I get an Operating-System error. The file is untouchable until the original process releases it's lock on the file. That was great back in the single-user days of MS-DOS when any locking process was likely to be on the same computer that contained the files, however on a network it's a nightmare:
Consider what happens when a process hangs while writing to a shared file on a Windows file-server. Before the file can be deleted we have to locate the computer and ID the process on that computer which originally opened the file. Only then can we kill the process and delete our unwanted file.
What a nuisance!
Is there a way to make this better? What I want is for file-locking on Windows to behave a like file-locking in UNIX. I want the operating system to just let me do what I want because I'm in charge and I know what I'm doing...
...so can it be done?
No. Windows is designed for the "average user", that is people who don't understand anything about a computer. Therefore, the OS tries to be smart to avoid PEBKACs. To quote Bill Gates: "There are no issues with Windows that any number of people want to be fixed." Of course, he knows that 99.9999% of all Windows users can't tell whether the program just did something odd because of them or the guy who wrote it.
Unix was designed when the world was more simple and anyone close enough to a computer to touch it, probably knew how to assemble it from dirty sand. Therefore, the OS usually lets you do what you want because it assumes that you know better (and if you didn't, you will next time).
Technical answer: Unix allocates an "i-nodes" if you create a file. I-nodes can be shared between processes. If two processes create the same file (that is, two processes call create() with the same path), then you end up with two i-nodes. This is by design. It allows for a fancy security feature: You can create files which no one can open but yourself:
Open a file
Delete it (but keep the file handle)
Use the file any way you like
Close the file
After step #2, the only process in the universe who can access the file is the one who created it (unless you want to read the hard disk block by block). The OS will keep the data alive until you either close the file or your process dies (at which time Unix will clean up after you).
This design is the foundation of all Unix filesystems. The Windows file system NTFS works much the same way but the high level API is different. Many applications open files in exclusive mode (which prevents anyone, even backup programs) to read the file. This is even true for applications which just display information like PDF viewers.
That means you'll have to fix all the Windows applications to achieve the desired effect. If you have access to the source, you can create a file in a shared mode. That would allow other processes to access it at the same time but then, you will have to check before every read/write if the file still exists, whether someone has made changes, etc.
According to MSDN you can specify to CreateFile() 3rd parameter (dwSharedMode) shared mode flag FILE_SHARE_DELETE which:
Enables subsequent open operations on a file or device to request delete access.
Otherwise, other processes cannot open the file or device if they request delete access.
If this flag is not specified, but the file or device has been opened for delete access, the function fails.
Note Delete access allows both delete and rename operations.
http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx
So if you're can control your applications you can use this flag.
Note that Process Explorer allow for force closing of file handles (for processes local to the box on which you are running it) via Handle -> Close Handle.
Unlocker purports to do a lot more, and provides a helpful list of other tools.
Also deleting on reboot is an option (though this sounds like not what you want)
That doesn't really help if the hung process still has the handle open. It won't release the resources until that hung process releases the handle. But anyway, in Windows it is possible to force close a file out from under a process that's using it. Process Explorer from sysinternals.com will let you look at and close handles that a process has open.