Member Avatar for Mr.M

Hi Dw.

I have a question of how can one detect a
program attempting execute/run and also most
importantly how to allow/deny programs to
execute/run.
I'm sure we all have came across with UAC
where it ask you to allow or deny that program
from running, normally this for elevating
privileges to Admin, but I don't want to use
UAC rather want to create something working
like it except that UAC only notify on privilege
elevation but mine I want it to detect a
program that is attempting to execute then ask
a user if s/he wants to grant or deny that
particular program from running.
Thank you.

  • 3 Contributors
  • 3 Replies
  • 361 Views
  • 2 Weeks Discussion Span
  • Latest Post Latest Post by Mr.M

Dani AI

Generated

Short answer: for Windows use the OS application-control features (don’t reimplement them unless you must). AppLocker and Windows Defender Application Control (WDAC) let you declare allow/deny rules and have the OS enforce them; they are the least-error-prone way to stop unwanted launches. UAC is a different mechanism—it prompts for elevation, not general per-executable allow/deny. (learn.microsoft.com)

If the goal is only detection (log + ask), common low-level signals are available: kernel process/image notifications (PsSetCreateProcessNotifyRoutineEx) and higher-level event streams like WMI/ETW (Win32_ProcessStartTrace / ETW). Those are excellent for monitoring and logging, but they are notification-only in typical usage and do not by themselves stop execution. Use them when you want to audit or build a prompt-history, not to reliably block an in-flight process. (learn.microsoft.com)

To actually block a launch you need a kernel-side enforcement point. The common, supported approach is a file-system minifilter that inspects open/create for executables (IRP_MJ_CREATE) and cancels the create or return an error (FltCancelFileOpen or a denied status). That allows blocking before a process fully starts, but it means writing a kernel driver (high complexity, crash risk, and Windows requires proper signing for kernel components). Test thoroughly in VMs and prefer OS-managed AppLocker/WDAC for production. (learn.microsoft.com)

If building a custom solution, use this pattern: minifilter (blocking policy) + small user-mode policy service + fast in-driver allowlist cache. Never wait inside kernel callbacks for a user click—signal user-mode, update the policy, then let the driver enforce. Example (conceptual) post-create callback that cancels an open when policy disallows it:

FLT_POSTOP_CALLBACK_STATUS
PostCreate(PFLT_CALLBACK_DATA Data, PCFLT_RELATED_OBJECTS FltObjects, PVOID *Ctx)
{
    if (IsExecutableOpen(FltObjects->FileObject) && !IsAllowed(FltObjects->FileObject->FileName)) {
        FltCancelFileOpen(FltObjects->Instance, FltObjects->FileObject);
    }
    return FLT_POSTOP_FINISHED_PROCESSING;
}

As noted, OS internals are subtle; as hinted, Windows has built-in options—use them first, and only move to kernel code when policy, performance, or enforcement requirements make it unavoidable. (learn.microsoft.com)

Recommended Answers

All 3 Replies

Member Avatar for マーズ maazu

I suggest you read Andrew Tanenbaums "Modern Operating Systems" book. You will realize how complex schedulers and interrupt requests occurs in the nanoseconds!

Member Avatar for ipswitch

for Windows easy!

Member Avatar for Mr.M

how?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.