Block any program at specific paths from being started
up vote
0
down vote
favorite
I want to block any program at a specific full-path name from being executed.
For example, if D:foo.exe
is in the blacklist, any program renamed and moved to that path will not run. If renamed or moved to something or somewhere else, then the program may run if other conditions allow (ACL, etc.).
Is there a solution that will work across all versions starting from Vista (NT 6.0)? Additionally, is there any solution specific to Windows 10? If so, what is the "minimum required" version (e.g. v1507)?
windows
add a comment |
up vote
0
down vote
favorite
I want to block any program at a specific full-path name from being executed.
For example, if D:foo.exe
is in the blacklist, any program renamed and moved to that path will not run. If renamed or moved to something or somewhere else, then the program may run if other conditions allow (ACL, etc.).
Is there a solution that will work across all versions starting from Vista (NT 6.0)? Additionally, is there any solution specific to Windows 10? If so, what is the "minimum required" version (e.g. v1507)?
windows
How about creating a placeholderD:foo.exe
? With ACL so it cannot be overwritten, removed, executed etc.
– Kamil Maciorowski
Nov 20 at 8:23
@KamilMaciorowski Good idea. That's not applicable in my case because the drive may be formatted, or other way that the ACL could be overridden programatically.
– iBug
Nov 20 at 8:38
Is there some X behind this Y? (like in XY problem). If the drive may be formatted or the executable may be renamed (and it's OK to run it then), then what's the point?
– Kamil Maciorowski
Nov 20 at 8:42
@KamilMaciorowski The actual case is that I'm going to perform some testing, and I repeatedly reset the testing area. For some other reasons, the path is fixed. I need the path to be blocked, but I'm in no need of blocking any specific program (files).
– iBug
Nov 20 at 8:49
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I want to block any program at a specific full-path name from being executed.
For example, if D:foo.exe
is in the blacklist, any program renamed and moved to that path will not run. If renamed or moved to something or somewhere else, then the program may run if other conditions allow (ACL, etc.).
Is there a solution that will work across all versions starting from Vista (NT 6.0)? Additionally, is there any solution specific to Windows 10? If so, what is the "minimum required" version (e.g. v1507)?
windows
I want to block any program at a specific full-path name from being executed.
For example, if D:foo.exe
is in the blacklist, any program renamed and moved to that path will not run. If renamed or moved to something or somewhere else, then the program may run if other conditions allow (ACL, etc.).
Is there a solution that will work across all versions starting from Vista (NT 6.0)? Additionally, is there any solution specific to Windows 10? If so, what is the "minimum required" version (e.g. v1507)?
windows
windows
asked Nov 20 at 8:18
iBug
2,20441639
2,20441639
How about creating a placeholderD:foo.exe
? With ACL so it cannot be overwritten, removed, executed etc.
– Kamil Maciorowski
Nov 20 at 8:23
@KamilMaciorowski Good idea. That's not applicable in my case because the drive may be formatted, or other way that the ACL could be overridden programatically.
– iBug
Nov 20 at 8:38
Is there some X behind this Y? (like in XY problem). If the drive may be formatted or the executable may be renamed (and it's OK to run it then), then what's the point?
– Kamil Maciorowski
Nov 20 at 8:42
@KamilMaciorowski The actual case is that I'm going to perform some testing, and I repeatedly reset the testing area. For some other reasons, the path is fixed. I need the path to be blocked, but I'm in no need of blocking any specific program (files).
– iBug
Nov 20 at 8:49
add a comment |
How about creating a placeholderD:foo.exe
? With ACL so it cannot be overwritten, removed, executed etc.
– Kamil Maciorowski
Nov 20 at 8:23
@KamilMaciorowski Good idea. That's not applicable in my case because the drive may be formatted, or other way that the ACL could be overridden programatically.
– iBug
Nov 20 at 8:38
Is there some X behind this Y? (like in XY problem). If the drive may be formatted or the executable may be renamed (and it's OK to run it then), then what's the point?
– Kamil Maciorowski
Nov 20 at 8:42
@KamilMaciorowski The actual case is that I'm going to perform some testing, and I repeatedly reset the testing area. For some other reasons, the path is fixed. I need the path to be blocked, but I'm in no need of blocking any specific program (files).
– iBug
Nov 20 at 8:49
How about creating a placeholder
D:foo.exe
? With ACL so it cannot be overwritten, removed, executed etc.– Kamil Maciorowski
Nov 20 at 8:23
How about creating a placeholder
D:foo.exe
? With ACL so it cannot be overwritten, removed, executed etc.– Kamil Maciorowski
Nov 20 at 8:23
@KamilMaciorowski Good idea. That's not applicable in my case because the drive may be formatted, or other way that the ACL could be overridden programatically.
– iBug
Nov 20 at 8:38
@KamilMaciorowski Good idea. That's not applicable in my case because the drive may be formatted, or other way that the ACL could be overridden programatically.
– iBug
Nov 20 at 8:38
Is there some X behind this Y? (like in XY problem). If the drive may be formatted or the executable may be renamed (and it's OK to run it then), then what's the point?
– Kamil Maciorowski
Nov 20 at 8:42
Is there some X behind this Y? (like in XY problem). If the drive may be formatted or the executable may be renamed (and it's OK to run it then), then what's the point?
– Kamil Maciorowski
Nov 20 at 8:42
@KamilMaciorowski The actual case is that I'm going to perform some testing, and I repeatedly reset the testing area. For some other reasons, the path is fixed. I need the path to be blocked, but I'm in no need of blocking any specific program (files).
– iBug
Nov 20 at 8:49
@KamilMaciorowski The actual case is that I'm going to perform some testing, and I repeatedly reset the testing area. For some other reasons, the path is fixed. I need the path to be blocked, but I'm in no need of blocking any specific program (files).
– iBug
Nov 20 at 8:49
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
You will need to write your own anti-exec program.
There are various articles to be found on hooking process creation in the kernel,
but they all require installing a driver, which is not very portable and will
encounter driver signature problems on later Windows versions.
The simplest solution would be to write a small DLL to be injected into all
processes, which will, in the context of the process, get its path and
terminate it immediately if coming from this path.
Injecting the DLL is done using regedit and navigating to
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWindowsAppInit_DLLs
.
On later versions of Windows, AppInit_DLLs
is disabled when Secure Boot is enabled.
See the Microsoft article
Working with the AppInit_DLLs registry value.
A skeleton for such a DLL may look like:
BOOL
WINAPI
DllMain ( HINSTANCE hInst, DWORD dwReason, LPVOID) {
TCHAR acModule[MAX_PATH];
switch (dwReason) {
case DLL_PROCESS_ATTACH:
GetModuleFileName(NULL,acModule,MAX_PATH);
to_be_written(acModule);
break;
default:
break;
}
return TRUE;
}
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
You will need to write your own anti-exec program.
There are various articles to be found on hooking process creation in the kernel,
but they all require installing a driver, which is not very portable and will
encounter driver signature problems on later Windows versions.
The simplest solution would be to write a small DLL to be injected into all
processes, which will, in the context of the process, get its path and
terminate it immediately if coming from this path.
Injecting the DLL is done using regedit and navigating to
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWindowsAppInit_DLLs
.
On later versions of Windows, AppInit_DLLs
is disabled when Secure Boot is enabled.
See the Microsoft article
Working with the AppInit_DLLs registry value.
A skeleton for such a DLL may look like:
BOOL
WINAPI
DllMain ( HINSTANCE hInst, DWORD dwReason, LPVOID) {
TCHAR acModule[MAX_PATH];
switch (dwReason) {
case DLL_PROCESS_ATTACH:
GetModuleFileName(NULL,acModule,MAX_PATH);
to_be_written(acModule);
break;
default:
break;
}
return TRUE;
}
add a comment |
up vote
0
down vote
You will need to write your own anti-exec program.
There are various articles to be found on hooking process creation in the kernel,
but they all require installing a driver, which is not very portable and will
encounter driver signature problems on later Windows versions.
The simplest solution would be to write a small DLL to be injected into all
processes, which will, in the context of the process, get its path and
terminate it immediately if coming from this path.
Injecting the DLL is done using regedit and navigating to
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWindowsAppInit_DLLs
.
On later versions of Windows, AppInit_DLLs
is disabled when Secure Boot is enabled.
See the Microsoft article
Working with the AppInit_DLLs registry value.
A skeleton for such a DLL may look like:
BOOL
WINAPI
DllMain ( HINSTANCE hInst, DWORD dwReason, LPVOID) {
TCHAR acModule[MAX_PATH];
switch (dwReason) {
case DLL_PROCESS_ATTACH:
GetModuleFileName(NULL,acModule,MAX_PATH);
to_be_written(acModule);
break;
default:
break;
}
return TRUE;
}
add a comment |
up vote
0
down vote
up vote
0
down vote
You will need to write your own anti-exec program.
There are various articles to be found on hooking process creation in the kernel,
but they all require installing a driver, which is not very portable and will
encounter driver signature problems on later Windows versions.
The simplest solution would be to write a small DLL to be injected into all
processes, which will, in the context of the process, get its path and
terminate it immediately if coming from this path.
Injecting the DLL is done using regedit and navigating to
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWindowsAppInit_DLLs
.
On later versions of Windows, AppInit_DLLs
is disabled when Secure Boot is enabled.
See the Microsoft article
Working with the AppInit_DLLs registry value.
A skeleton for such a DLL may look like:
BOOL
WINAPI
DllMain ( HINSTANCE hInst, DWORD dwReason, LPVOID) {
TCHAR acModule[MAX_PATH];
switch (dwReason) {
case DLL_PROCESS_ATTACH:
GetModuleFileName(NULL,acModule,MAX_PATH);
to_be_written(acModule);
break;
default:
break;
}
return TRUE;
}
You will need to write your own anti-exec program.
There are various articles to be found on hooking process creation in the kernel,
but they all require installing a driver, which is not very portable and will
encounter driver signature problems on later Windows versions.
The simplest solution would be to write a small DLL to be injected into all
processes, which will, in the context of the process, get its path and
terminate it immediately if coming from this path.
Injecting the DLL is done using regedit and navigating to
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWindowsAppInit_DLLs
.
On later versions of Windows, AppInit_DLLs
is disabled when Secure Boot is enabled.
See the Microsoft article
Working with the AppInit_DLLs registry value.
A skeleton for such a DLL may look like:
BOOL
WINAPI
DllMain ( HINSTANCE hInst, DWORD dwReason, LPVOID) {
TCHAR acModule[MAX_PATH];
switch (dwReason) {
case DLL_PROCESS_ATTACH:
GetModuleFileName(NULL,acModule,MAX_PATH);
to_be_written(acModule);
break;
default:
break;
}
return TRUE;
}
edited Nov 20 at 20:18
answered Nov 20 at 14:10
harrymc
248k10257546
248k10257546
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1376891%2fblock-any-program-at-specific-paths-from-being-started%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
How about creating a placeholder
D:foo.exe
? With ACL so it cannot be overwritten, removed, executed etc.– Kamil Maciorowski
Nov 20 at 8:23
@KamilMaciorowski Good idea. That's not applicable in my case because the drive may be formatted, or other way that the ACL could be overridden programatically.
– iBug
Nov 20 at 8:38
Is there some X behind this Y? (like in XY problem). If the drive may be formatted or the executable may be renamed (and it's OK to run it then), then what's the point?
– Kamil Maciorowski
Nov 20 at 8:42
@KamilMaciorowski The actual case is that I'm going to perform some testing, and I repeatedly reset the testing area. For some other reasons, the path is fixed. I need the path to be blocked, but I'm in no need of blocking any specific program (files).
– iBug
Nov 20 at 8:49