I Turned Three Beginner Python Scripts Into a Windows Desktop App

QuantumCat — Thu, 15 Oct 2026 01:54:57 +0000

I Turned Three Beginner Python Scripts Into a Windows Desktop App

In May 2026 I was teaching myself cybersecurity the way a lot of people
do: tutorials, notes, and a vague feeling that I didn't actually
understand what my own computer was doing on the network. So I wrote
three small Python scripts to find out:

Network-Monitor (net_watch.py, 57 lines) — poll ss -tun every 3 seconds, diff against the last snapshot, print and log new connections, tag each peer LOCAL or EXTERNAL, keep a top-talkers count.
Port_scanner (~25 lines) — prompt for an IP, sequential connect_ex scan over 11 common ports with a 1-second timeout, print the open ones.
Snapshot-Report (~100 lines of os.popen) — write a timestamped triage report of the machine, plus a basic "suspicious process" check.

They were beginner scripts, and I mean that as a precise technical
description.

The embarrassing parts (which were the education)

The committed monitor didn't run. Line 19 is missing a closing
parenthesis, and an if further down is misindented. It sat on GitHub,
publicly broken, because I never ran the committed copy. Lesson zero
of shipping anything: run the thing you ship, from a clean checkout.

My monitor tagged the wrong endpoint. The script grabbed the first
IP-looking token on each line — the local endpoint, i.e. my own
machine, forever. What a watcher cares about is the peer. It also
classified "private" by string prefix (10., 192.168., 127.),
which silently misses the whole 172.16.0.0/12 private range — and
CPython's ipaddress module has opinions about CGNAT space
(100.64.0.0/10) that a failing test had to teach me.

My port scanner couldn't say "closed." Open ports printed;
everything else was silence. Closed (connection refused) and filtered
(timeout) are different answers, and a scanner that can't tell them
apart is only telling you a third of the story. It was also
sequential — up to a second per port of just… waiting.

My suspicious-process detector flagged "sync." The check was a
substring search of the ps aux output for names like nc. "Sync"
contains "nc". A name heuristic is a hint to go look; it is not
detection, and pretending otherwise sends you chasing ghosts.

The rebuild

I rewrote all three properly and combined them into one app, the
QuantumCat SOC Toolkit: a Tkinter GUI (stdlib only — no framework)
with five tabs — Monitor, Port Scanner, Snapshot Report, AI Analyst,
Settings/About.

The monitor parses ss output into structured records, classifies IPs properly, and keys events on the peer endpoint with clean process name (pid) labels. (On Windows, where there's no ss, it uses psutil with a netstat -ano parser as fallback.)
The scanner is threaded, covers 25 well-known ports with service names, reports open/closed/filtered as distinct states, and does an optional passive banner grab — it reads what a service volunteers, nothing more.
The snapshot report keeps the original's soul — one timestamped file you can hand to someone — but every section degrades to an "(unavailable)" line instead of crashing, and the flagged-process check compares actual process names, labelled in the app as the basic heuristic it is.
Everything is covered by test suites, because of lesson zero.

The local AI analyst

The fourth tab is the new idea. It collects what the other tabs found
and produces a plain-English assessment in a fixed template:

VERDICT: one line
What looks normal
What deserves a second look
Suggested next steps

It runs on a local model via Ollama — plain HTTP to localhost,
the only network destination in the app besides your own scans. A
security tool that phones your data home to a cloud AI would be a bad
joke, so there is no cloud anything: no accounts, no telemetry, no
analytics. And if you don't have Ollama, a built-in rule engine
produces the same template from the same findings, so the app works
out of the box either way. Ollama just writes smarter explanations.

The packaging lesson (the biggest one)

My first instinct was to ship the way my scripts lived: Linux, a
folder, run it from a terminal. Two problems. The actual user machine
was Windows. And "works if you know the incantation" is not
"works."

An earlier build proved it: extract a ZIP, the executable bit gets
dropped, and the file manager asks "open with what?" — dead on
arrival for a normal person. So the standard became a rule:

It should feel like installing Wireshark, not like adopting a
project. Double-click, install, desktop shortcut, click the cat,
app opens.

What shipped:

A real Windows .msi installer — per-user, no admin prompt, Desktop and Start Menu shortcuts with the cat icon, clean uninstall through Windows Settings.
A Linux .deb for the Debian/Ubuntu family and a portable .tar.gz (tar preserves the exec bits the ZIP lost).
The full Python source included in the download, for transparency and for anything the packaged builds don't cover.

No terminal gymnastics on either platform. The only add-on is Ollama,
and the included Start_Here guide walks through installing it and
pulling a model step by step.

Honest limits

This is a learning and triage tool built by a self-taught developer.
It is not a replacement for professional security software, and it is
not a packet analyzer — Wireshark is still king there. This toolkit's
job is watching, summarising, and explaining: what is my machine
talking to, what's listening on it, and what does that probably mean,
in words a person can act on.

DEV Community: QuantumCat

I Turned Three Beginner Python Scripts Into a Windows Desktop App

I Turned Three Beginner Python Scripts Into a Windows Desktop App

The embarrassing parts (which were the education)

The rebuild

The local AI analyst

The packaging lesson (the biggest one)

Honest limits

Links