I'm using OSXFuse
https://osxfuse.github.io/
And wanted to know if I can tell apart the following operations:
File is opened by the user
File is previewed in Finder
My problem is that for both cases readFileAtPath is called, and seemingly with the same parameters.
Apparently this cannot be done using the simple API, as read is read no matter who requests it.
But that's the point, if you could identify who requested to read, you could block it for some processes.
Using Fuse's C api, you could you fuse_get_context(), and get the pid, and from it get the process name. No need for more.
See my question at Fuse Google Group.
Related
Basically I need to download a .txt file to my teachers macbook saying something along the lines of "I was here" including my name & student ID.
If I can manage to do this I instantly pass the security class.
For those of you who want to hear (or read) the story, read the following paragraph, for the rest just skip it.
My teacher from my Computer Security class has given everyone a challenge, the one who leaves a txt file saying you were here on his macbook's desktop will instantly pass the class. He usually keeps an eye on his macbook and if you want access to it you'd have to steal it without him seeing you do it. His disk is encrypted and he has long passwords. I have thought about a few approaches and I want to get as much information on each approach as possible. First approach was simply hanging a recorder somewhere in the room to record him typing in his password then stealing his mac and creating the txt file. Second approach was somehow getting him to run a file that would create said txt file. And third approach is basically injecting javascript code into his sites which silently download the txt file to his desktop. Now I just need to know if it's even possible to silently download said file.
So here we finally come to the question, is there a way of silently downloading a txt file, and if so how would one do it?
And if it isn't possible, does anyone have any ideas for me to place the txt file on his pc?
EDIT: For those of you wondering, its uni/college not some kind of preschool.
Well, Have you performed any scans on this particular macbook? Do they host any services, like a web server or other service from this machine? That would be the traditional starting point.
Otherwise, Social Engineering, is probably the best way forward. You could pull off the student version of what happened to Ross Ulbricht. Wait for them to log into the machine. Then get some of your mates to create a significant distraction. Download and execute a quick executable that places your "proof" on the desktop (Or just be a quick typist) Profit.
Alternately:
Create a malicious executable.
Change the icon of executable to look like a word document.
Name Executable "Love Letter" or something juicy.
Place the executable on Flash Drive.
Place 5-10 "Boring" useless, normal files on there too. 2-3 pictures. (Just to get his guard down)
Leave this flash drive on or (Preferably near) his desk.
Wait.
This executable should create the text file on the desktop, pop up a smug message, Take a screenshot, and email both you and him the picture as proof.
The executable should also be designed to no longer work after a certain amount of time.
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.
I am trying to figure out when and how does Windows update File Access Times on files.
First of all, most Windows installs come with File Access Times disabled for performance reasons, so before wrapping your head around it here is what you need to do in order to activate last access times on NTFS file systems: modify the key [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem] value name NtfsDisableLastAccessUpdate to DWORD 0 value data(if it is set to 1 of course). If it doesn't exist just create it.
Upon reading File Times article on MSDN i am still in doubt as to how Windows updates access times.
My questions are as follow:
Do access times update upon issuing a WinApi CreateFile() with FILE_READ_ATTRIBUTES ? In my case, while doing it programmatically, it doesn't. Opening up the File Properties dialog of that file through the Explorer Shell does update the access time.
Do access times update upon issuing a WinApi ExtractIconEx() to read an icon from a file?
In my case doing so programatically, it doesn't. Opening up the File Properties dialog of that file through the Explorer Shell does update the access time.
If you ask me, both of those cases should update the file access times, but it seems to me that direct WinApi calls don't update them or Window/NTFS driver really lags behind, while operating on files from Windows Explorer do update pretty well. What do you think is or could be the issue here?
As a side note, i did do CloseHandle() as per:
The only guarantee about a file
timestamp is that the file time is
correctly reflected when the handle
that makes the change is closed.
My end conclusion is that, indeed the opinions lying around the web are true and Windows does update File Access Times in a random fashion and thus one really shouldn't in no way depend on Windows File Access Times.
Off-topic rant: Sorry forensics guys, you'll have to prove access times using another method or you can have your case invalided in seconds. :P
No, accessing the metadata of the file isn't going to change the last access time (name, attributes, timestamps). Wouldn't work well in practice, just looking at the directory with Explorer would change it. You have to actually open the file. ExtractIconEx() would normally be an excellent candidate, except that Windows can play tricks with it. A hidden desktop.ini file can redirect the icon to another file.
Using the last access time is pretty worthless for forensics. You'd need a file system filter driver. Similar to the one embedded in SysInternals' ProcMon utility. It might be using ETW btw, that got pretty powerful at Vista time. Nevertheless, your project just got 10 times more complicated.
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.