I'm looking at an application that saves "high value content" in a tmp file in the temp directory while it's handling it. When it finishes handling it, and closes the file, it gets deleted automatically.

A little research has shown me that they're calling CreateFile with 0 for the sharing options, and with the DELETE_ON_CLOSE flag set.

I'm looking for a "non-driver, non-hooking" way to break windows stranglehold on these files so that I can copy them to another directory for later inspection.

Anyone know how to do this?

there's a list of about 20 programs here that might do the trick for you: http://ccollomb.free.fr/unlocker/

GREAT! Thanks disavowed! (Even a link to one that has source).

If the file exists for some time you could use the WinAPI CreateHardLink to create a second dir entry for that file. When the application deletes the file, then only the first dir entry is deleted, the second entry together with the file data will be intact and available for inspection.

radix

& if you want save FLV files from such deletion, use Opera browser, which has FLV-file copy in it's cache!

According to the Win32 API:

"Flags, attributes, access, and sharing that are specified in CreateFile operate on a per-file basis. That is, if you open a file that does not allow sharing, another application cannot share the file by creating a new hard link to the file."

Hmm INTERESTING! But I'm interested in AAC files.

Yet another resource to try, if you do not have enough already, is one of the file recovery tools available. Unless the app really WIPES and over-writes the file in question, you should be able to un-delete it with minimal effort, if you do it early enough after the program runs. . .

I guess I should have stated this earlier, I'm looking to do this programatically.

It's starting to look like a "CreateRemoteThread" and using CopyFile, might be the hot ticket.

One thing I was thinking about was changing the permissions on the file, but I don't know if that's possible with it still being open.

What I'm up to, is I'd like to write some code to snag the media that is sent to my machine by a website with a name that refers to a woman who opened a box in Greek mythology that unleashed all the evils into the world. That should keep JMI happy. I avoided the name, but still told you who it is.

The media that they send down is in AAC format, and their site runs a flash player that calls DirectX stuff under the hood to handle them.

Oh thank God you didn't directly mention "Pandora's" name.

Did I give it away???

Regards,

You crack me up sometimes JMI. Since it's technically a target, and we don't mention target names, I figured I'd err on the side of safety.

I've found some weird results. I found an app called "WhoUses", which is supposed to tell you who has a file locked. So, I fire up PANDORA, and using ProcMon I see the location, and the name of the file it has opened. So, I supply WhoUses with the filename, and it returns NOTHING. It's like it can't tell who has the file locked.

Yes, while the app is running you cannot access the file via the created hard link - but the hard link protects the file data from getting lost if the file (the first created dir entry) gets deleted, so you can access the file data *after* the app has terminated.

radix

Yep, works like a charm! Thanks radix!

Other methods: Close the running app with task manager, attach Olly to it and close Olly, and the oldest and most likely to create damage - hit the power switch, or pull the plug.

SiGiNT

psuedo code..
loader starts process suspended and breaks at first code execution..not many ways to do that..Search for Pointers to code pushed onto the stack of a call before a function and set a breakpoint just after the call..(the return address)..
Write file 'dump' to the stream and access the Stream in wordpad..


now that is completely untested..and there some inkling of DualMapping in there..but you might already have seen that

so here are others options ive contemplated...
single step with lookahead call & jmp disassembly (looks for encrypted routines..)
single step with Stack code checking..(disassembly of 'suspicious' stack values..ie this shouldn't test a value if it only has the lower word in the dword filled out..handles)
use 'a' encryption check based on the ones found by the lookahead routines(calls and jmps) to see if they are still encrypted.. if not return to next framesetup for next call..repeat checks for encryption routines

Why not simply hook CreateProcessA/W with an IAT patch or using the detours library or further just reverse the target and change the flag in the CreateProcess call? Granted you may need to hook CreateProcess(Ex)A/W in the target's launcher as well if it needs to be completely automated on program startup as well as adding the CREATE_SUSPENDED flag so on return from CreateProcess you can be sure kernel32.dll is imported and that your patch will take place without concurrency issues (remember to call ResumeThread on the returned primary thread handle and you are all set).

All good ideas! The problem I had, was that the application that was using the file, was a browser. I wanted to be as unobtrusive as possible. The CreateHardLink solution turned out to be perfect.