DEV Community: Toluwanimi Alfred

How I Built a Windows Security Monitor That Records Intruders Automatically Using PowerShell

Toluwanimi Alfred — Tue, 29 Sep 2026 11:05:59 +0000

The Story That Started It All

Years ago, I watched a video that stuck with me.

An engineer had spent hours building an entire software from scratch. The moment he stepped away from his PC, someone who had been observing his pattern walked over, plugged in a flash drive, and copied the entire work.

The painful part was not just the theft. It was how it happened. The spy had been watching. He knew the pattern. He tried the security details a few times before he got in.

That video made me ask a question I could not stop thinking about:

How do you secure a PC in an environment where it cannot be stolen but can still be accessed without your permission?

That question sent me down a rabbit hole of research. A few weeks ago, curiosity turned into code.

What I Built

A Windows security monitoring tool built entirely in PowerShell with no third party security software.

Here is what it does:

After 3 failed login attempts on your Windows PC, two things happen automatically:

An email alert fires instantly to two configured addresses
The webcam starts recording silently The person trying to get in cannot stop the recording unless they have access to the code configured for manual stop or the keyboard shortcut built into the system.

A few days ago I confirmed it worked. I watched recorded footage of an actual attempt to enter my system.

How It Works

Step 1 — Monitoring Failed Logins

Windows logs every failed login attempt as Event ID 4625 in the Security Event Log. PowerShell can read this in real time.

$events = Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = 4625
    StartTime = (Get-Date).AddSeconds(-30)
} -ErrorAction SilentlyContinue

$count = @($events).Count

The key fix here was using a sliding 30 second window instead of counting from script start. Counting from script start causes the number to grow forever and trigger duplicate recordings. The sliding window resets naturally every poll cycle.

Step 2 — Email Alert via Gmail SMTP

The moment the threshold is hit, an email fires to two addresses using Gmail SMTP through PowerShell's built in System.Net.Mail.

$smtp             = New-Object System.Net.Mail.SmtpClient("smtp.gmail.com", 587)
$smtp.EnableSsl   = $true
$smtp.Credentials = New-Object System.Net.NetworkCredential($gmailFrom, $gmailPass)

No external libraries. No API keys to pay for. Just a Gmail App Password and two lines of configuration.

Step 3 — Webcam Recording via FFmpeg

FFmpeg captures the webcam using DirectShow, Windows built in camera interface.

$ffmpegArgs = "-rtbufsize 100M -f dshow -i video=`"Integrated Webcam`" -vcodec libx264 -preset ultrafast `"$outputFile`""

The biggest bug I hit here was that combining -NoNewWindow and -WindowStyle Hidden when launching FFmpeg from a script caused DirectShow to fail silently. The webcam light never turned on and no error was written. The fix was switching to ProcessStartInfo with the window set to Minimized instead of Hidden, which gives DirectShow the process context it needs.

Step 4 — Hotkey Stop via Win32 API

A separate script uses embedded C# inside PowerShell to register a global hotkey through the Win32 RegisterHotKey function.

protected override void OnHandleCreated(EventArgs e) {
    base.OnHandleCreated(e);
    RegisterHotKey(this.Handle, HOTKEY_ID, MOD_CONTROL | MOD_ALT, VK_S);
}

The original version called RegisterHotKey inside the constructor, which meant the window handle did not exist yet and the hotkey silently never registered. Moving it to OnHandleCreated fixed it.

Problems I Hit Along the Way

1. Event count kept inflating

Original code used StartTime set to script start time, so events accumulated forever. Fixed with a rolling 30 second window.

2. FFmpeg crashed silently with no error log

The combination of -NoNewWindow and -WindowStyle Hidden on Start-Process blocked DirectShow from accessing the webcam. No error. No log. Just a silent crash. Fixed by using ProcessStartInfo directly.

3. Two scripts running at the same time

During testing, an old version of the script was still running in the background while the new one started. Both tried to grab the webcam simultaneously and both failed. Always kill old PowerShell instances before starting fresh.

4. Parser errors from special characters

Em dashes and curly quotes copied into the script from documentation caused PowerShell parser errors that looked completely unrelated to the actual problem. Always write PowerShell in plain ASCII.

The Honest Limitation

Windows architecture locks webcam access to active user sessions. This means recording can only start after someone logs in, not before.

On Linux, PAM (Pluggable Authentication Modules) and V4L2 (Video4Linux2) make it possible to hook into the login process itself and trigger recording before anyone gets past the login screen.

A Linux port is something to explore in the future.

What I Learned

Windows Event Log is more accessible than most people realize. PowerShell can query it natively with no extra tools.
DirectShow is sensitive to process context. How you launch a process matters as much as what you put in the command line.
Silent failures are the hardest bugs. FFmpeg crashing with no output taught me to always check HasExited after launch and always redirect stderr somewhere readable.

- OS architecture decisions have real consequences. The Windows session model is a security feature. It is also the reason this tool has a fundamental ceiling.

The Full Code

Everything is documented and available on GitHub:

https://github.com/alfredoeinsteino2024/SecurityMonitor-PowerShell

The repo includes monitor.ps1, hotkey.ps1, stop.ps1, and a full README with setup instructions.

There are still bugs to fix and more to learn.

But curiosity got something working and that is enough to keep going.

We trust God in the process.

RescueHacks Alert: Building a Silent Emergency Dial Code That Actually Works

Toluwanimi Alfred — Thu, 10 Sep 2026 15:17:36 +0000

The problem I wanted to solve

Most emergency-alert apps make the same bad assumption: the person in danger has time, privacy, and a working data connection to open an app, unlock their phone, and tap through a UI.

If someone is being followed, robbed, or is in a situation where their phone is visible to a threat, none of that holds. What they do usually have is a phone that can dial a number, even on 2G and with zero data.

That's the idea behind RescueHacks Alert: dial a short USSD code, and an emergency contact gets notified on WhatsApp in real time. No app. No internet requirement on the victim's side. No visible menu that gives away what's happening.

The core design decision: no menu

My first instinct was to build an interactive USSD menu. Dial the code, see a list ("1. Medical, 2. Security, 3. Fire..."), and pick one. Standard USSD UX.

Then I thought about who's actually dialing this. If someone is being confronted, pulling out their phone and having a menu appear on screen is a giveaway. USSD sessions stay visible while they're active.

So I dropped the menu entirely. The emergency type is encoded directly in the digits the person dials with a single, silent action.

*384*23492*1#   → Medical
*384*23492*2#   → Safety threat
*384*23492*3#   → Accident
*384*23492*4#   → Disaster

Dial it, and the session ends immediately with no visible confirmation screen. To anyone watching, it looks like a dropped call attempt. Behind the scenes, the backend fires an emergency alert.

For the demo video, I narrated it with a shorter, more realistic-looking code like *911*[1-3]#. A real deployment would use a telecom-issued short code rather than a shared sandbox number. The working prototype runs on Africa's Talking's longer sandbox code above.

Architecture

Victim's phone
   │  dials USSD code
   ▼
Africa's Talking USSD Gateway
   │  HTTP callback
   ▼
AWS Lambda (USSD handler)
   │  parses emergency type from dialed digits
   ▼
Meta WhatsApp Cloud API
   │
   ▼
Emergency contact receives alert on WhatsApp

Everything runs on AWS SAM. API Gateway sits in front of a Lambda function that parses the incoming USSD session and triggers the WhatsApp send.

Where it got interesting: three bugs that taught me more than the happy path

1. The Lambda that "sent" messages that never arrived

Early on, the WhatsApp send was fire-and-forget. I called the send function but didn't wait for it before returning the USSD response. It worked sometimes.

The reason was simple: AWS Lambda freezes the execution environment as soon as it returns a response. If your background async call hasn't finished, it stops. No error. No completion.

The fix was straightforward once I understood it. await the WhatsApp send before returning the USSD response.

2. A WhatsApp template that Meta quietly reclassified

I submitted a message template under the Utility category, which is required for sending outside WhatsApp's 24-hour messaging window.

Meta approved it, then quietly reclassified it as Marketing. Marketing templates require recipient opt-in, which my test number didn't have. The API returned a success status with a valid message ID, but nothing arrived.

The dashboard never made the real reason obvious. I only found the actual category by querying the Meta API directly. For the hackathon deadline, I switched to plain-text messages inside the 24-hour window and documented the template fix for later.

3. A token that worked in testing and silently failed in production

My quick-test access token worked perfectly. The permanent system-user token used by the deployed app returned success but delivered nothing.

Same phone number ID. Same WhatsApp Business Account. Same recipient.

That pointed to a permissions issue rather than a code bug. The system user needed full control of the WhatsApp Business Account, along with the whatsapp_business_messaging permission, before the permanent token worked.

None of these problems were obvious from reading the documentation. They only showed up after building, deploying, and comparing "API says success" with "nothing arrived."

The result

End to end, dialing *384*23492*2# in the Africa's Talking sandbox simulator triggers a WhatsApp emergency alert on the registered contact's phone in real time. No app. No menu. No visible trace on the victim's screen.

What's next

RescueHacks Alert started as a hackathon weekend build. I look forward to

turning it into my final-year Mechatronics Engineering project by adding a physical SOS tracker (ESP32 + GPS + cellular), live location tracking, a responder dashboard, and AI-assisted emergency classification with confidence-scored outputs rather than overclaimed certainty.

That's a much bigger build with real hardware and power-budget constraints, and I'll be documenting the process as it develops.

Built for the RescueHacks hackathon on Devpost. Code, demo video, and submission details: https://devpost.com/software/rescuehacks-alert.

Building a Serverless Agriculture Platform with AWS

Toluwanimi Alfred — Wed, 02 Sep 2026 03:21:05 +0000

While building HarvestIQ, I started paying much more attention to how backend architecture affects the way a product can be built, deployed, and scaled.

HarvestIQ is an agriculture platform designed to help smallholder farmers access post-harvest intelligence, including market prices and buyer opportunities.

One of the interesting parts of the project is that a farmer can interact with the system through USSD, without requiring a smartphone or an internet connection.

The backend is built around a serverless architecture using AWS services.

This article breaks down how that architecture works and what I have learned from building it.

What does "serverless" actually mean?

The name can be misleading.

Serverless does not mean that there are no servers.

The servers still exist. AWS manages the underlying infrastructure, while I focus on writing and deploying the application code.

Instead of maintaining an always-running backend server, different parts of the application can run when they are needed.

For HarvestIQ, this works particularly well because many operations are event-driven.

A farmer makes a request.

A function executes.

Data is retrieved or updated.

The function finishes.

Another event can trigger another function later.

HarvestIQ's Serverless Architecture

The simplified architecture looks like this:

                    Farmer
                      |
                     USSD
                      |
                      v
              Africa's Talking
                      |
                      v
                AWS Lambda
                 /       \
                /         \
               v           v
          DynamoDB       Response


          EventBridge
               |
               v
          AWS Lambda
               |
               v
          Price / Alert
            Logic
               |
               v
             SNS
               |
               v
              SMS
               |
               v
             Farmer

Each AWS service has a specific responsibility.

AWS Lambda handles application logic.
DynamoDB stores application data.
EventBridge triggers scheduled operations.
SNS handles notifications.
Africa's Talking provides the USSD and SMS connectivity layer.

Let's look at each part.

1. USSD as the Entry Point

One of the design goals of HarvestIQ is accessibility.

A farmer should not necessarily need:

A smartphone
A mobile application
Mobile data
A web browser

A basic mobile phone with cellular connectivity can be enough.

The farmer interacts with HarvestIQ through a USSD menu.

For example:

HarvestIQ

1. Check Market Price
2. List Produce
3. View Buyer Demand
4. Set Price Alert

The USSD request is handled through the Africa's Talking USSD gateway and passed to the backend.

This is where AWS Lambda comes in.

2. AWS Lambda

AWS Lambda is the compute layer of the application.

Instead of maintaining a traditional server that is continuously running, I can deploy functions that execute in response to events.

The basic idea is:

Event
  |
  v
Lambda Function
  |
  v
Execute Code
  |
  v
Return Result

For example, when a farmer sends a USSD request:

Farmer
   |
   v
USSD Request
   |
   v
AWS Lambda
   |
   v
Process Request
   |
   v
Return USSD Response

The Lambda function can also communicate with other AWS services.

For example:

Lambda
   |
   +----> DynamoDB
   |
   +----> SNS

This means the application logic does not have to live on one large traditional backend server.

3. DynamoDB

HarvestIQ uses Amazon DynamoDB as its database.

This is where application data can be stored and retrieved by Lambda functions.

For example, the system can store information related to:

Farmers
Produce listings
Market prices
Buyer demands
Price alerts

A simplified interaction might look like this:

USSD Request
     |
     v
Lambda
     |
     v
DynamoDB
     |
     v
Retrieve Data
     |
     v
Lambda
     |
     v
USSD Response

For example, when a farmer requests the current price of maize, Lambda can query DynamoDB and return the relevant information through the USSD session.

4. EventBridge for Scheduled Jobs

Not everything in HarvestIQ starts with a farmer.

Some operations need to happen automatically.

For example, market prices may need to be updated periodically.

This is where Amazon EventBridge becomes useful.

Instead of keeping a server running and writing a program that constantly waits for the next scheduled operation, EventBridge can trigger a Lambda function according to a schedule.

Conceptually:

EventBridge
     |
     | Scheduled Event
     v
Lambda
     |
     v
Run Price Update
     |
     v
DynamoDB

For example:

8:00 AM  -> Lambda runs
10:00 AM -> Lambda runs
12:00 PM -> Lambda runs
2:00 PM  -> Lambda runs

The exact schedule depends on the application requirements.

This is one of the things I found interesting about event-driven architecture: the system does not need to continuously run code just to wait for something to happen.

5. Understanding Amazon SNS

This was one of the concepts I found particularly interesting.

Amazon SNS (Simple Notification Service) is a publish/subscribe messaging service.

A simple way to think about SNS is as a notification or broadcast layer.

Instead of having every part of the application know exactly how to deliver a notification, an application can publish a message to an SNS topic.

Conceptually:

Application
     |
     v
SNS Topic
   /   \
  /     \
SMS     Other Subscribers

In HarvestIQ, this can be useful for price alerts.

Suppose a farmer sets a target price:

Produce: Maize
Target Price: ₦85,000

Later, the system checks the current market price.

If the target condition is satisfied, the application can publish a notification through SNS.

The flow becomes:

EventBridge
     |
     v
Price-check Lambda
     |
     v
DynamoDB
     |
     v
Target condition reached
     |
     v
Lambda publishes notification
     |
     v
SNS
     |
     v
SMS notification
     |
     v
Farmer

The important distinction is that SNS is not the component deciding whether the target price has been reached.

The application logic does that.

Lambda determines that the condition has been satisfied, then publishes the notification to SNS.

SNS handles the notification delivery to its configured subscriber.

That separation of responsibilities makes the architecture easier to reason about.

A Complete Example

Let's put everything together.

Imagine a farmer wants to know the current price of maize.

Step 1: The farmer sends a USSD request

Farmer
   |
   v
USSD

Step 2: The request reaches the backend

USSD
   |
   v
Africa's Talking
   |
   v
AWS Lambda

Step 3: Lambda retrieves the data

Lambda
   |
   v
DynamoDB

DynamoDB returns the relevant market information.

Step 4: Lambda generates the response

DynamoDB
   |
   v
Lambda
   |
   v
USSD Response
   |
   v
Farmer

The entire interaction can happen without the farmer installing an application or using mobile data.

Now consider a different scenario: a scheduled price update.

EventBridge
     |
     v
Lambda
     |
     v
Fetch / Process Price Data
     |
     v
DynamoDB

And if a price alert condition is reached:

Price-check Lambda
       |
       v
Target reached
       |
       v
SNS
       |
       v
SMS
       |
       v
Farmer

This is the part of the architecture that makes the system event-driven.

Why Use Serverless?

There are several reasons this architecture made sense for HarvestIQ.

1. Less infrastructure management

I don't have to maintain an always-running application server myself.

AWS manages much of the underlying infrastructure.

2. Event-driven execution

Different parts of the application can execute in response to specific events.

For example:

USSD request
     ↓
Lambda

or:

Scheduled event
     ↓
Lambda

or:

Business condition
     ↓
Notification

3. Automatic scaling

Lambda can handle multiple invocations without me manually provisioning individual servers for each request.

The underlying infrastructure is managed by AWS.

4. Efficient use of compute

For workloads that are intermittent or event-driven, there is less reason to maintain an application server that is continuously running just waiting for requests.

Serverless Is Not Perfect

Serverless is not automatically the best architecture for every application.

There are trade-offs.

Cold Starts

A function that has not been invoked recently may experience additional startup latency depending on the runtime and configuration.

For some applications, that latency matters.

Execution Limits

Lambda functions are designed for bounded workloads rather than indefinitely running processes.

That means some workloads are better suited to other architectures.

Distributed Debugging

A traditional application might look like:

Client
  |
  v
Backend
  |
  v
Database

A serverless application can involve many managed services:

USSD
  |
  v
Gateway
  |
  v
Lambda
  |
  +----> DynamoDB
  |
  +----> SNS
  |
  +----> Other Services

EventBridge
  |
  v
Lambda

When something fails, understanding exactly where the failure occurred can require proper logging, monitoring, and tracing.

Vendor Lock-in

Using managed services deeply can also make an application more dependent on a particular cloud provider.

That is an architectural decision worth considering before building at scale.

What I Learned

Building HarvestIQ changed how I think about backend architecture.

The biggest lesson for me is that serverless is less about "not having servers" and more about changing who manages the infrastructure and how application components are executed.

I also learned to think in terms of events.

Instead of asking:

"What server should always be running?"

I started asking:

"What event should cause this piece of code to run?"

For HarvestIQ, those events can be:

Farmer makes a USSD request
              ↓
        Lambda executes

Scheduled update occurs
              ↓
        Lambda executes

Price condition is reached
              ↓
      Notification is published

That shift in thinking is probably the most valuable thing I have taken from building the project.

Conclusion

HarvestIQ started as an attempt to solve a real agricultural problem, but building it has also become an opportunity for me to learn more about cloud architecture and distributed systems.

The combination of Lambda, DynamoDB, EventBridge, and SNS gives the platform a relatively lightweight event-driven backend while allowing me to focus more on the application itself rather than server management.

I'm still learning, and there are several areas I want to explore further, particularly observability, security, cost optimization, and designing more robust distributed systems.

For me, this is one of the interesting parts of building software: the project solves one problem while teaching you how to solve the next one better.

Why the Power-of-Two Trick Works for Binary Fractions (And Why It Breaks for Everything Else)

Toluwanimi Alfred — Thu, 18 Jun 2026 12:25:50 +0000

If you've taken any course that covers number systems, you've probably learned the "repeated multiplication" method for converting a decimal fraction to binary. Multiply by 2, record the digit before the decimal point, keep the remainder, repeat. It works. You can pass an exam with it. But it also feels a little like a magic trick — you follow the steps, you get the right answer, and you have no real intuition for why it works or why it sometimes never ends.

Here's the thought process that gave me that intuition, and where it eventually breaks.

The starting point: 0.25

Take 0.25. The standard method says: multiply by 2 repeatedly, record the integer parts.

0.25 × 2 = 0.50 → record 0
0.50 × 2 = 1.00 → record 1

Read top to bottom: 0.25 = 0.01 in binary. Correct, but mechanical.

Here's the alternative way I started thinking about it instead. 0.25 is just 1/4. And 4 is 2². So instead of multiplying repeatedly, what if I convert the numerator and denominator to binary separately, and treat the division as what it actually is — a division by a power of the base?

1 in binary is 1.
4 in binary is 100.

So 1/4 is 1 / 100 in binary. And dividing by 100 (in any base) doesn't require long division if 100 is a power of that base — it just shifts the point. In decimal, dividing by 100 shifts a decimal point two places left because 100 is 10². In binary, dividing by 100₂ (which is 4 in decimal) shifts the binary point two places left for exactly the same reason: 100₂ is 2².

Shift the point in "1." two places left: 0.01₂.

Same answer, but now you can see why it's the answer instead of just trusting the algorithm.

This isn't a coincidence — it's how place-value systems work

This generalizes. Any fraction a/2ⁿ can be converted by writing 'a' in binary and shifting the point n places. 1/2 → shift 1 place → 0.1₂. 1/8 → shift 3 places → 0.001₂. 3/16 → 3 is 11 in binary, shift 4 places → 0.0011₂.

It's the same logic as why dividing by 1000 in decimal is "free" (just move the point three places) — except in binary, the powers that are "free" are powers of 2, not powers of 10. This is also, not coincidentally, the entire basis of fixed-point arithmetic in embedded systems: when a microcontroller needs to represent a fraction without the overhead of a floating-point unit, it represents the value as an integer with an implicit binary point at a fixed position, and operations that would otherwise need division become bit-shifts. The "trick" above is a small, hand-worked version of that same idea.

Where it breaks

The shortcut depends entirely on the denominator being a power of 2. Try it on 0.2, which as a fraction is 1/5.

5 in binary is 101. 101 is not a power of 2 (it's 4 + 1, not a single power), so there's no clean shift available. To get 1/101₂ you actually have to do binary long division, and unlike 1/4, this one doesn't terminate. It repeats forever: 0.0011001100110011...

This is the same underlying reason 0.1 + 0.2 doesn't exactly equal 0.3 in most programming languages — 0.1 and 0.2 are not exactly representable in binary floating point, because their denominators (10 and 5) aren't powers of 2. It's not a bug in your code; it's a structural consequence of representing base-10 fractions in a base-2 system.

So the boundary is sharp: this shortcut is fast and exact for denominators of 2, 4, 8, 16, 32, and so on (equivalently, decimals like 0.5, 0.25, 0.125, 0.0625, 0.375). For anything else, you're back to repeated multiplication, and the result may never terminate.

The takeaway

None of this is a new method — it's a restatement of how positional number systems and fixed-point representation work, just arrived at by asking "what is this algorithm actually doing" instead of memorizing the steps. But that's worth writing down, because most people learn the multiplication method as a rote procedure and never connect it to the much more general (and much more useful) fact: in any base, dividing by a power of that base is just a point shift, and that single fact is also why certain "simple" decimal fractions can never be represented exactly in binary — a fact that quietly underlies one of the most common gotchas in floating-point programming.