Re: How to block system copy commands at driver level
- From: Ray Trent <rat@xxxxxxxxxxxxx>
- Date: Fri, 30 May 2008 08:50:18 -0700
Ok, well, by and large, driver hackers aren't the best people to ask
about GUI level windows internals, but there are a number of tricks you
could try, including global windows message hooks, Shell Extensions,
clipboard monitoring, hooking of the CopyFile/Ex function (using, e.g.,
Detours), etc.
Still... are you talking about just Windows Explorer? Because hundreds
of apps implement copy and paste functionality for files, and they don't
all do it through the clipboard. In particular, File Menu->Copy types of
functionality are probably implemented by a lot of apps using a simple
Open Source&Dest/Read Source/Write Dest loop, and you're not going to be
able to deal with that.
Also, I don't know enough about it to say for certain, but I really
don't know how the cmd prompt copies files, or whether there's a good
way to squeeze in there.
In any event, I agree with another poster that called this "snake oil".
It's really not improving your security the same way that, say,
encrypting the data would.
Bipin Mistry wrote:
Hello Ray,
I do agree that there is no limits to copy file(hacking the data),
thats the reason our task is limited to restrict standerd copy/paste
methods which are as follows:
1. [Ctrl + C],
2. Right Click Menu -> Copy
3. File Menu -> Copy
4. Command prompt copy
5. Drag& Drop
Bipin
On 5月30日, 午前3:02, Ray Trent<r...@xxxxxxxxxxxxx> wrote:
I think that your biggest difficulty here is that your problem space is
completely undefined. Which of the following things do you need to prevent:
1) Just well-known GUI-level copy commands such as cut-and-paste&
drag-and-drop.
2) #1 + opening a command prompt and typing "copy z:foo.txt a:"
3) #2 + preventing a specific list of existing archiving/copying
applications from copying the data.
4) #3 + preventing someone opening the file in notepad, selecting all
the data, and pasting into another program, and saving the data from there.
5) #4 + preventing the user from writing any program that would allow
the copying of data from z: to any other location.
The problem you have is that #4 and #5 are impossible, as long as you
allow arbitrary read-access to the data by any program that you don't
control 100%. But if you control the program 100% then you don't need
what you're asking for here, because the app can just refuse to copy it.
And then there's 6) #5 + preventing the user from debugging your
application, extracting the data from memory, and copying it to another
location for duplication.
You can't stop #6 *even if* you control the only program that can read
the data, as long as it's possible for the user to see the data at some
point, unless you required external hardware support (such as a monitor
that decodes encrypted data in order to display it, and an app that
never stores decrypted data in memory).
And then there's 7) #6 + preventing the user from taking a digital
photograph of their screen and running the data through OCR to save it
on another machine.
If you can fix #7, well, patent it quick because the big media companies
will make you rich beyond your wildest dreams.
So... which of these do you need to prevent? I don't see any hope for
anything above #3, actually... but who knows.
Seriously, though, just encrypt your data. Then it doesn't matter if
someone copies it.
Bipin Mistry wrote:
Hello Tim--
As you stated below
Not at the driver level. Just stop and think for a moment: how is theNow I also understand that there is only read/write at driver level
"copy" program implemented? It's a loop:
hSrc = CreateFile( ... );
hDst = CreateFile( ... );
while( 1 ) {
ReadFile( hSrc, Buffer ... );
if( end of file )
break;
WriteFile( hDst, Buffer ... );
}
that is what been called in loop.
but to call this loop there should be some system event which also
contains hSrc& hDst information.
we can trace that and can figure out that current process required to
copy data from restricted (z:) to local zone (c:) or so...
As per me thinking logically
Way 1
1. we need to figure out a way to identify<< hSrc>> & << hDst
2. check for<< hSrc>> with restricted (z:) then do not perform
this task& reset the system& environment variable
Way 2
1. Hook the clipboard where Copy / Paste commands gets triggered
2. Check for Copy source with restricted (z:) then ignore the copy
sequence.
Way 3 (by Alexander Grigoriev)
1. When restricted drive (z:) is mounted user can not access any
other drive or network share folder in write mode.
Although these all are just thinking process, haven't come across who
have implemented.
If any one have any updates or improvement or tips& tricks to do any
of above then please do get back on this thread.
Bipin
Ray- 引用テキストを表示しない -
- 引用テキストを表示 -
--
Ray
.
- References:
- How to block system copy commands at driver level
- From: Bipin Mistry
- Re: How to block system copy commands at driver level
- From: Maxim S. Shatskih
- Re: How to block system copy commands at driver level
- From: Bipin Mistry
- Re: How to block system copy commands at driver level
- From: Tim Roberts
- Re: How to block system copy commands at driver level
- From: Bipin Mistry
- Re: How to block system copy commands at driver level
- From: Ray Trent
- Re: How to block system copy commands at driver level
- From: Bipin Mistry
- How to block system copy commands at driver level
- Prev by Date: damn Windbg
- Next by Date: Re: Horizontal Scrolling
- Previous by thread: Re: How to block system copy commands at driver level
- Next by thread: Will R200 sample in WDK6000 work when VidPN support changed to MMDMM_SUPPORT_TEST?
- Index(es):
Relevant Pages
|
