Forem: SAINT

Flutter Dev + AppSec Engineer Built a KRA PIN Checker That Stores ZERO User Data (And Still Makes Money with M-Pesa Tokens) 🛡️🇰🇪

SAINT — Sun, 09 Nov 2025 13:21:48 +0000

Flutter Dev + AppSec Engineer Confessions: How I Built a Privacy-Obsessed KRA PIN Checker That Even My Paranoid Security Friends Approve Of 🛡️🇰🇪

Hey devs, DevSecOps ninjas, and fellow security weirdos! 👋

I’m a part-time Flutter dev by night and a full-time Application Security Engineer by day. That means I spend 9-5 hunting bugs in other people’s code… and then come home to make sure I don’t become the bug myself. 😅

Let me tell you about PinSight(checKRA) – the app I built from absolute scratch that lets Kenyans verify any taxpayer PIN by kenyan IDs instantly using M-Pesa tokens.

No login. No data stored. No “free tier” nonsense. Just pure, privacy-first magic.

And yes — ONE codebase, ALL platforms:

✅ Android

✅ iOS

✅ macOS

✅ Windows

✅ Linux

Because why write the same secure app five times?

Here’s the story from both sides of my brain:

1. The Developer Side (Flutter Joy 🎨)

Entire UI in Flutter → single codebase, zero platform-specific nightmares
Kenyan-themed design with slide + fade animations (animated_widgets)
Single screen flow: dropdown → ID → “Check PIN” → result card in flag colors 🇰🇪
Token balance in app bar, auto-triggers Buy Tokens dialog when zero (feels like magic)
flutter_dotenv so I never commit secrets (lesson learned the hard way)

2. The Security Engineer Side (Paranoia = Default Setting 🔒)

Most apps treat privacy like a suggestion. Mine treats it like oxygen.

What I deliberately DIDN’T do:

❌ No Firebase Auth
❌ No Google/Sign-in-with-anything
❌ No SharedPreferences / Keychain abuse
❌ No logging of IDs, names, or phone numbers
❌ No analytics with PII (Firebase Analytics events only, anonymized)

What I DID do (AppSec flex):

Every query is ephemeral – deleted instantly after response
Tokens stored on private Node.js backend (MongoDB Atlas) behind HTTPS
Tokens auto-delete when count = 0 (no zombie data)
M-Pesa callback IP-whitelisted to Safaricom only
Always ACK ResultCode: 0 to M-Pesa (no infinite retries)
Signed releases with upload keystores (Android) & Apple Developer certs (iOS/macOS)
Secrets in .env – never committed
Custom regex validation per taxpayer type

3. The DevSecOps Side (Shift-Left or GTFO)

Backend on Render with auto-TLS
/health endpoint for uptime monitors
MongoDB Atlas IP access list
Full CI/CD ready (GitHub Actions workflows in repo)
Tested every flow in Daraja sandbox
Repo structured so contributors can’t leak secrets

Payment Methods (Kenya + Global)

🇰🇪 M-Pesa STK Push & Buy Goods (instant)
🌍 PayPal coming next week! (for diaspora & international users)

Pricing? Brutally honest:

1 token = 1 verification. Buy exactly what you need.

KES 50 → 1 token
KES 100 → 2 tokens
KES 300 → 6 tokens
KES 600 → 14 tokens (best value)

Pay via M-Pesa → approve → paste SMS code → done.

PayPal flow drops soon — same token system, global reach.

Tech Stack

Frontend: Flutter (Dart) – truly cross-platform

Backend: Node.js + Express + MongoDB Atlas

Payments: Safaricom Daraja API + PayPal (incoming)

Hosting: Render (paid HTTPS)

Analytics: Firebase (events only)

Download Links

Android: Play Store (live!)
iOS: App Store (review passed, live in 24h)
macOS / Windows / Linux: Direct download from GitHub Releases
APK / IPA / DMG / EXE / AppImage on request – DM “AppSec approved” 😉

GitHub – All Assets for early access of the app

🔗 assets + desktop builds:

https://github.com/HovSaintBrandon/checKRA-supaApp-release

Star it if you hate data leaks. Fork it if you want to help add PayPal! 🚀

Support: hovsaintbrandon@gmail.com

If you’re a dev who actually cares about security, a DevSecOps warrior tired of fixing messes, or just a Kenyan (or friend of Kenya) sick of shady “free” PIN checkers that sell your data…

…try it. I built it the way I wish EVERY app was built.

Let’s make privacy the default — on every platform. 🇰🇪🔒🌍

P.S. Yes, I pentest my own app in my free time. Yes, I’m that guy. 😎

Flutter #Dart #CyberSecurity #AppSec #DevSecOps #KenyaTech #PrivacyFirst #Mpesa #PayPal #CrossPlatform #DesktopApps #NoLoginNoProblem

Cyber Deep Surveillance

SAINT — Wed, 10 Sep 2025 12:26:00 +0000

SAINT

Sep 10 '25

FlexiSPY and State Surveillance: Technical Lessons from the BBC Kenya Case

#cybersecurity #deepsurveilance #spyware

Comments

3 min read

FlexiSPY and State Surveillance: Technical Lessons from the BBC Kenya Case

SAINT — Wed, 10 Sep 2025 12:25:02 +0000

In May 2025, BBC filmmaker Nicholas Wambugu alleged that his phone was tampered with while in Kenyan police custody. A forensic report from Citizen Lab confirmed that FlexiSPY, a commercial spyware package, was installed on his device on May 21, 2025, while still in state possession.

This case highlights how lawful custody of a device can be abused for targeted surveillance. Below we break down what FlexiSPY is, how it works, and what security professionals should know.

What is FlexiSPY?

FlexiSPY is sold as “parental control” and “employee monitoring” software but functions like advanced spyware. Once installed, it operates with elevated privileges and resists detection.

Capabilities include:

Call interception and recording
Message extraction (SMS, WhatsApp, Telegram, Signal)
Location tracking in real time
Camera and microphone activation
File manipulation (altering or deleting stored data)
Exfiltration of credentials

Technical Behavior of FlexiSPY

FlexiSPY is typically sideloaded or installed manually when attackers have physical access to the device. In the Kenya case, the spyware was deployed while the device was in custody, a strong indication of insider access.

Persistence mechanisms:

Registers as system services to survive reboots
Disguises itself under names mimicking legitimate OS processes
Uses root or jailbreak exploits on some devices to escalate privileges

Network activity:

Periodic connections to command-and-control (C2) servers over HTTPS
Data exfiltration occurs in compressed, encrypted payloads
Traffic often shows unusual frequency even when the device is idle

Indicators of Compromise (IOCs)

Based on open-source and forensic research into FlexiSPY deployments:

File/System Artifacts

Presence of hidden APKs with misleading names (SystemServices.apk, SyncManager.apk)
Modified permissions in /system/priv-app/ on Android devices
Unexpected cron jobs or background daemons on jailbroken iOS devices

Network Indicators

Repeated DNS lookups to unknown domains not associated with OS updates
Outbound HTTPS traffic to non-standard ports (e.g., 4433, 8443)
Large bursts of encrypted traffic when calls/messages are active

Behavioral Indicators

Faster battery drain
Device heating up during idle periods (due to microphone/camera activation)
Unexplained permission prompts or new accessibility services enabled

Defensive Measures

For journalists, activists, and developers working on sensitive projects, awareness and mitigation are critical.

Preventive:

Avoid reusing devices after state seizure; treat them as compromised
Enable full-disk encryption to make tampering harder
Use strong device passcodes and disable USB debugging

Detection:

Use tools like MobSF, apktool, or Frida for static/dynamic analysis of suspicious apps
Deploy YARA rules for identifying FlexiSPY binaries in scans
Monitor device traffic with MITM proxies or Pi-hole DNS filtering to flag suspicious connections

Response:

Perform full firmware reinstallation rather than a simple factory reset
If high risk, migrate to a new device and treat the compromised one as untrusted
Use forensic services like Citizen Lab or open-source frameworks like Mobile Verification Toolkit (MVT) to analyze potential infections

Why This Case Matters for Developers

The Kenyan case demonstrates how commercial spyware is weaponized against civil society. For developers and security researchers:

Be aware of dual-use tech: “monitoring tools” often blur into surveillance
Build security into your apps: enforce secure communications, detect rooted/jailbroken environments, and monitor for abnormal OS behaviors
Contribute to tooling: open-source detection frameworks are vital for protecting journalists and activists who lack access to enterprise security budgets

Final Thoughts

The FlexiSPY incident in Kenya is a reminder that surveillance is not theoretical. It affects real people, often those exposing uncomfortable truths. As security professionals, we have a responsibility to not only study these tools but also to build countermeasures that protect privacy and freedom of expression.

The intel Management Engine:~The Ghost in your machine

SAINT — Tue, 12 Aug 2025 05:51:30 +0000

Most Intel systems include a hidden microcontroller known as the Intel Management Engine (IME), recently renamed the Converged Security and Management Engine (CSME).

This chip is embedded within the platform chipset and operates independently from your main CPU and operating system. It has direct, low-level access to your system’s memory, network interfaces, storage devices, and peripherals.

The ME runs its own lightweight operating system—based on the MINIX microkernel in recent versions—separate from Windows, Linux, or any other OS you use. This allows it to perform tasks even when your computer appears to be powered off, provided it remains connected to a power source.

Because it operates below the OS layer, IME can monitor and control critical system functions, enabling remote management, firmware updates, and hardware-based security features. However, this level of control also makes it a potential security risk if exploited or misused.
Why This Matters

Invisible Layer: The Intel Management Engine runs on its own processor inside the chipset, completely separate from your main CPU. It operates independently of your operating system and remains active even when the system is powered off (as long as it’s plugged in). This means it works beneath all user-level controls and monitoring tools
.
Full Access: IME has direct access to your system’s memory, network interfaces, storage, and peripheral devices. It can bypass any OS-level security controls, firewalls, or antivirus software, giving it privileged control over the entire platform.
Closed-Source: The IME firmware and operating system are proprietary and closed-source. There is no public audit or full transparency on what code runs inside it, leaving users blind to potential backdoors or privacy issues.
Vulnerabilities: Over the years, security researchers have discovered multiple critical vulnerabilities in IME firmware. Some allowed attackers to gain stealthy, persistent control over affected machines, often undetectable by traditional security tools.

Intel states that IME is designed for legitimate IT use cases, such as remote system management, hardware-based security, and fast boot features. While these are valid purposes, it means users must trust a hidden, privileged subsystem they cannot fully inspect, audit, or disable on most hardware

PoC: Detect Intel ME (CSME) on Linux
You don’t need outdated tools. On modern systems, Intel ME shows up as CSME, HECI, or Active Management Technology in PCI device listings

run:

lspci -nn | grep -Ei "csme|heci|active management"

Example output from a real machine:

00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
00:16.3 Serial controller [0700]: Intel Corporation Sunrise Point-LP Active Management Technology - SOL [8086:9d3d] (rev 21)

If you see CSME, HECI, or Active Management Technology, Intel ME is present and active.

Mitigation Steps

Buy Hardware with ME Disabled at the Factory Some manufacturers, such as Purism and System76, offer laptops and desktops with Intel ME disabled or significantly limited during manufacturing. These devices come with custom firmware that neutralizes or removes much of the ME’s functionality, reducing the attack surface and increasing user control. Choosing such hardware means you get stronger privacy and security guarantees out of the box.

2.Use me_cleaner to Strip ME Firmware For advanced users, me_cleaner is an open-source tool that can neutralize many of Intel ME’s features by modifying the firmware image. This process requires extracting your system’s firmware, applying the tool, and then flashing the modified firmware back to your device. This approach is risky: a failed flash can brick your device, and it may void warranties or violate terms of use. However, it can drastically reduce ME’s capabilities and potential for abuse
.

3.Choose Platforms That Avoid or Allow Disabling ME If you want full control and transparency, consider hardware platforms that do not include Intel ME or provide easier methods to disable it. Some AMD systems use a similar module called PSP, but certain vendor boards allow its disablement or have more open designs. Open-source hardware initiatives and RISC-V systems also offer alternatives that avoid opaque management engines entirely
.

The Intel Management Engine is effectively a hidden computer inside your machine, with privileges far beyond your operating system. If you cannot see it running, audit its code, or fully remove it, you must ask who it truly serves — you, the user, or someone else with access to this powerful subsystem.

As Sun Tzu _wrote in _The Art of War:

“If you know neither the enemy nor yourself, you will succumb in every battle.”

In security, knowing what’s inside your system is the first step to defending it.

How I Caught an MPESA API Leak Hiding in Plain Sight

SAINT — Wed, 30 Jul 2025 08:47:37 +0000

_
So here's the tea_ 🍵.

A while back, I picked up a Django consulting gig — nothing major, just helping out a startup that was panicking over something real bad:

“Bro, someone’s draining our MPESA till via the Daraja API.”

They kept rotating their consumer key and secret, but the money kept disappearing. It was like patching a leaking pipe without finding the hole. So they called me in.

🔍 The Setup
I asked for full access to the codebase. They were using Django (bless them — I love Django too), and they had a clean enough setup. But something instantly made me flinch:

python

# settings.py
DEBUG = True
🚨 Red flag. Big one.

They were running production with Django’s debug mode on — which basically hands over your server's internals on a silver platter whenever something crashes.

I started poking around and spotted something worse...

💀 The Leak Was Right There...
They had this endpoint meant to parse JSON from requests:

python

def index(request: HttpRequest) -> JsonResponse:
    consumer_secret = os.getenv("CONSUMER_SECRET")
    consumer_key = os.getenv("CONSUMER_KEY")
    data = json.loads(request.body.decode("utf-8"))  # 💥 crashes on bad JSON
    return JsonResponse(data)

Looks innocent enough, right?

Well... anytime that JSON payload was invalid — like if someone sent a GET instead of a POST or posted broken JSON — Django threw an unhandled exception.

But with

DEBUG=True

, it responded with the entire stack trace...

And guess what was sitting right there in the local variables?

Yup. The consumer key and secret. 🫠

So if a curious hacker sent a malformed request to that endpoint… they’d get a nice, juicy traceback with the keys to the kingdom.

🔧** My Fixes**
I immediately told them:

Rotate the consumer credentials — assume they’re already out there.

Set

 DEBUG = False

— like yesterday.

Wrap the JSON parsing in a try-except block to catch garbage input:

python

try:
    data = json.loads(request.body.decode("utf-8"))
except json.JSONDecodeError:
    return JsonResponse({"error": "Invalid JSON"}, status=400)
After patching it, the bleeding stopped

🔍** Bonus: I Got Curious…**
Out of curiosity, I ran a few dorks on Shodan and Censys to see how many live Django apps in Kenya still had DEBUG=True.

Let’s just say... we’re sitting on a ticking time bomb.

🧠 Lessons Learned
Never — ever — deploy Django with DEBUG=True. It’s basically broadcasting your secrets to the world.

Wrap any fragile logic (especially input parsing) in try/except blocks.

Treat dev tools like weapons — fine in the lab, deadly in prod.

Assume your environment variables are vulnerable when stack traces are exposed.

That’s it. One line of careless code almost cost them a business.

And the scary part? Most of this could've been caught with a simple code review.

If you're building anything with sensitive APIs — especially involving money — take time to audit your error handling and config. It could save you millions... or your reputation.

Happy coding — and stay paranoid. 🧠💻

Where There’s a Shell, There’s a Way – Tales from a Terminal Addict

SAINT — Wed, 30 Jul 2025 08:34:56 +0000

I used to think the terminal was just that black window that hackers used in movies. I’d open it, type ls, stare blankly at the output, and close it like I’d just entered a room I had no business being in.

Fast forward to now — I live in the terminal. I write scripts that scan networks, exploit vulnerabilities, automate boring tasks, and sometimes, accidentally shut things down (yes, I’ve wiped /var without a backup — we’ve all been there). But one thing I’ve learned the hard way:

If you know your way around the shell, you’re dangerous — in the best possible way.

This is my journey through ethical hacking, DevSecOps, and shell scripting — told from behind the prompt.

👣 ** It All Started With a Ping...**
Before Metasploit, before Burp Suite, before CI/CD pipelines, there was ping. That was my first real "hack." I pinged my own IP. Then my router. Then my friend’s router. That curiosity led me to:

nmap — to scan everything that breathed on the network.

nc — to open mysterious ports and send weird messages.

bash — to stitch it all together in a script that made me feel like a god.

Truth is, the shell gave me control. Not just over machines — over knowledge. Over processes. Over my own impatience.

🔥** Ethical Hacking: Shell or Be Shelled**
If you've ever landed a reverse shell during a pentest, you know the adrenaline. But getting shell access is just the start. What you do next is what separates script kiddies from real operators.

Some real-life lessons:

A client left an SSH private key in a world-readable directory. Guess what I used to find it? find / -type f -name "*.pem" 2>/dev/null

During a red team engagement, I had nothing but a low-priv shell. But a quick uname -a and a Google search later — boom, kernel exploit.

Once, I got in through a misconfigured cronjob. A simple shell script with malicious payload ran every 5 minutes. Set and forget.

Hackers don’t always need exploits. Sometimes, all you need is a working shell and some patience.

🛡️ DevSecOps: When Scripting Becomes Security
We love talking about shifting left, building secure pipelines, and “baking in” security. But 90% of the work? It's bash.

Need to check for open ports before deploying a container? Write a script.

Want to automate secret rotation? Write a script.

Need to block IPs after too many failed logins? Script it. Log it. Push it.

In my current setup, I’ve got scripts that:

Run daily scans with lynis and email me diffs.

Check container base images for vulnerabilities using trivy.

Auto-kill instances with outbound traffic to shady IPs. (True story — saved us once.)

And guess what? It all started in the shell.

⚙️ Favorite One-Liners (and Screw-Ups)
Let’s keep it real — half the stuff I do now came from trial, error, and Reddit. Some favorites I keep in my toolbox:

⛏️ Quick privilege check
find / -perm -4000 2>/dev/null

🐚 Stabilize a shell like a pro
python3 -c 'import pty; pty.spawn("/bin/bash")'

💣 Wipe a directory without confirmation (don’t use this unless you're sure)
rm -rf /var/log/*

And of course:

❌** Accidentally locked myself out of SSH**
chmod 000 /etc/ssh/sshd_config — rookie mistake. Recovery was not fun.

💡** Why the Shell Still Matters in 2025**
We’re surrounded by fancy tools — IDEs, dashboards, UIs. But when those fail, it’s the shell that remains.

Got a production issue at 3AM? You’re SSHing in, not clicking buttons.

Trying to analyze logs for a DDoS attack? awk, grep, cut, sort.

Running a CTF? You’re not winning without shell-fu.

🎯** Final Words from One Addict to Another**
If you’re just getting into hacking, DevOps, or scripting, don’t underestimate the terminal. It might look boring, but it’s a superpower. And once you fall in love with it, there’s no going back.

The shell doesn’t lie. It doesn’t sugarcoat. It just does what you tell it to — for better or worse.

So yeah. Where there’s a shell, there’s a way. And for me, there’s no other way

Quantum Root

SAINT — Thu, 24 Jul 2025 07:07:57 +0000

"If the code exists, I exist. If the code doesn’t, I never did."
— The Quantum_Root

🧠** What is Quantum Root?**
Quantum Root is a theory I've been developing — part cybersecurity, part philosophy, part code. It describes a backdoor or malicious presence that exists within a system before the system is even written. Think about that. Your future app, system, or infrastructure might already be compromised — before you ever typed a single line of code.

🔍 The Premise
Imagine a developer (or attacker) who creates a popular programming language, library, or module. They subtly inject a hidden mechanism — not an obvious vulnerability, but a dormant capability — that only activates when certain conditions are met.

Now imagine you, an honest dev, building your app using this language or importing this module. Just by installing it — the attacker now exists within your system.
Their presence is woven into the very DNA of your code.

You never saw them. You never gave permission. But they were always meant to be there — written in potential, not yet in action.

That’s Quantum Root.

🧬 The Root That Exists in Potential
A quantum root doesn't live in your app — it lives in every app that could be written using tainted dependencies. It’s like a quantum particle: it doesn’t fully exist until observed.
But the moment you write your system using the vulnerable codebase — the attacker "collapses" into existence. Boom — they exist in your environment.

If you don’t write that code?
They never exist.
Your system remains untouched.
It’s almost... poetic.

🔧 Real-World Parallels
This might sound sci-fi, but we’ve seen pieces of this in:

Supply chain attacks — like the SolarWinds breach

Malicious npm packages (e.g., event-stream, coa, colors.js)

Language-level exploits — flaws or intentional design quirks in languages, frameworks, or compilers

Closed-source backdoors in precompiled binaries

But Quantum Root goes further — it's not just a backdoor, it’s an existential presence.

🔮 Why Does This Matter?
It challenges our idea of security-by-design

It raises questions about trust in tooling and dependencies

It introduces a new threat model: "latent existence"

And honestly — it’s kind of terrifying.

🤔 Final Thought
If the only thing keeping an attacker out is the fact that you haven’t written your app yet, then maybe...
they’re already waiting.
In the code.
In the future.
In the Quantum.