They threw everything at it. SQL injection. Cross-site scripting. Path traversal. Template injection. Server-side request forgery. Command execution. Even tried a bit of directory brute-forcing on the side.

Nothing got through.

Why It Did Nothing

This site is built on a simple PHP stack with no framework. Every database query uses PDO prepared statements. User input isn't concatenated into SQL queries. Period.

That's it. That's the entire defense. One architectural decision made a year ago rendered every SQL injection payload completely inert.

For the XSS attempts, every piece of user-submitted content goes through htmlspecialchars() before it touches a page. No script tags fire. No event handlers execute. No beacons phone home.

No data was accessed. No database queries were manipulated. No JavaScript ran. The scanner essentially yelled into a void and got silence back.

What I Did

IP banned via iptables and .htaccess. All tickets deleted. User account wiped. Took about three minutes.

The DirBuster traffic was actually more annoying than the injection attempts — 400,000 HEAD requests cluttering up the access logs. The injection payloads were dramatic but harmless. Stored as plain text in the database, never executed, never parsed.

What I Learned

If you're building a web application in 2026, prepared statements and output escaping are not optional. They're the floor. And the floor held.

I also realized I should probably add rate limiting to the support ticket form. Eighty-four tickets from one IP in a few hours is absurd. That'll be the next improvement.

The Takeaway

Automated scanners crawl the web constantly. If you're running any public-facing service, you'll get hit. Probably already have been. The question is whether your stack catches it or not.

Mine did. Pretty satisfying, honestly.

Sarah

A few years ago I made a video about visualizing the signals on my local cable network. However just staring at a bunch of QAM signals is boring. I wanted to do something more interesting.

That's when I found out about OOB or out of band signaling in the cable networks, often used for the EPG data and provisioning.

I set out to decode it and integrate that decoder into SignalScope (update soon).

What started as staring at mystery radio waves turned into a massive reverse-engineering project. I ended up building a toolchain called oobscte55 to decode these hidden signals from documentation. If you've ever wondered how your cable box knows what channel CNN is on, or how it gets firmware updates without the internet, here is a breakdown of the journey from raw radio waves to readable text.

Step 1: Capturing the Invisible Waves

Before we can decode anything, we need to capture the signal. Using a standard Software Defined Radio (SDR), I recorded a raw audio-like file of the OOB carrier directly from the cable line.

Instead of sound, we're recording the raw electromagnetic spectrum. In this case, the signal is a 1.544 Mb/s data stream sitting slightly offset from the main TV channels. To the naked eye, it just looks like static.

Step 2: From Waves to Bits (Demodulation)

To make sense of that static, we have to "demodulate" it. This specific network uses a transmission method called QPSK (Quadrature Phase Shift Keying).

In simple terms, the transmitter rapidly changes the phase (the starting angle) of the radio wave to one of four specific positions. Each position represents two bits of digital data (00, 01, 10, or 11). By mathematically tracking these phase shifts, my software turns the raw radio wave recording into a massive, continuous stream of 1s and 0s.

Step 3: Finding the Rhythm (Framing)

Now we have a mountain of bits, but no idea where a sentence starts or ends.

The protocol organizes the data into structured chunks called superframes. To help receivers (like a set-top box or my script) find their place, the transmitter inserts a "Frame Alignment Signal"—a highly predictable pattern of bits (0, 0, 1, 0, 1, 1) at exact intervals. Once the software locks onto this repetitive pattern, it can sync up and reliably read the actual payload.

Step 4: Fixing the Static (Error Correction)

Cable lines aren't perfect; physical interference easily causes bits to flip in transit (a 1 accidentally becomes a 0).

To fix this, the system uses Reed-Solomon error correction. It's a clever mathematical trick where the transmitter adds a little bit of extra padding to the data. If a few bits get scrambled along the way, our decoder can use that padding to perfectly reconstruct the missing information. On a clean capture, this step easily fixes over 90% of the transmission errors!

Step 5: Tiny Digital Envelopes (ATM Layer)

Once the data is clean, we find out it's packaged into ATM cells. ATM (Asynchronous Transfer Mode) is a classic networking standard that chops data up into tiny, 53-byte digital envelopes.

Each envelope has a 5-byte header (the address) and a 48-byte payload (the letter inside). By reading the addresses on the envelopes, we can sort the traffic into different buckets. For example:

• Address 0xFF/0xFFFF: The Electronic Program Guide (EPG).
• Address 0x00/0x0021: Network control and provisioning instructions.

Step 6: The Data Carousel

So, how does a cable box download a large file, like a multi-day channel guide, if it can't directly ask the head-end server to send it?

It uses a Data Carousel. The cable provider simply broadcasts the files over and over again in a continuous loop, exactly like luggage on an airport carousel. The receiver waits until the file it needs comes around, grabs the pieces out of the ATM envelopes, and stitches them back together using standard internet protocols like IP and UDP.

The Payoff: What We Actually Get

After running this whole gauntlet—from radio waves to ATM cells to reassembled files—we finally hit the jackpot. So, what is actually hiding in the signal?

• The Channel Lineup: A clean text map linking call signs to channel numbers (e.g., WKYC is Channel 4, AMC is Channel 278).
• System Configuration: The hidden instructions that tell your cable box exactly what frequencies to tune to for its main data and upstream service channels.
• Firmware Details: Plain-text server URLs for software updates and background Java apps.
• The Program Grid: The actual TV schedule with show titles and times. (Note: The schedule bodies themselves use a proprietary Cisco compression, so reading them requires reversing a custom codec, but the binary records are completely visible!)

It is incredibly satisfying to pull a mystery signal out of a copper wire and peel back the protocol layers until you find human-readable text. It's a great reminder of just how much engineering goes into simply turning on the TV.

Keep an eye out for the SignalScope integration coming soon!

This SDR doesn't have a bias-tee but it has a massive 56msps rate that I've been using to look around. It appears I can see multiple LTE cells at the same time and I wonder if I should see about using it with CellScope to allow for the ability the decode multiple cells at once.

What do you think?

If you've been wanting to run InmarScope on linux, now's your chance! The only thing is we don't have our map anymore for ICAO calls.

I already have the hardest piece working. Burst frames are the atomic unit of an Iridium transmission. Without clean burst detection, nothing else matters. And I have that. I also have IMSI decoding, which means I can identify individual subscribers and devices. That is a specific, valuable piece of information.

But the rest is still opaque. The call setup, the text messages, the location updates, the higher layer data. The signal is full of information, but my decoder only sees the skeleton.

That gap is what pulls me forward. This is not a simple reverse engineering project. It is a puzzle where the manuals are outdated, the waveforms are complex, and the system was designed to be resilient, not transparent. Every piece I add unlocks more. Every decoded message tells me where to look next.

Iridium has been in orbit for over two decades. The satellites are old, the hardware is fixed, and the protocol is documented in fragments. That makes it a perfect target for someone who likes to dig deep into signal processing and bitstream analysis.

So yes, this is my next development target. Not because it is easy, but because it is almost within reach. The burst frames work. The IMSI decoding works. The rest is just waiting to be cracked open.

Welcome in, InmarScope.

I started with a waterfall and fft on a dear im gui interface and added on a wav/IQ playback functionality. With this I could take what I learned with PocketAERO and bring that over to InmsarScope.

It supports common AERO modes including 8400 baud AERO Voice calls and STD-C EGC messages! Futher we have full voice call following by listening to P-Channels for C Channel Assignments.

From there I added support for remote servers and the RTL SDR and HackRF. Data output modes like JAERO had and more!

Tonight, I felt that the listen and hop method of listening to AERO calls works but you'll miss calls due to the fact that we have to stop monitoring P-Channels in order to listen to voice Channels within the bandwidth of an RTL-SDR.

So I added a split-view for dual RTL SDR mode, allowing users to use two RTL-SDRs to listen into P-Channel for messages and at the same time decode and record 8400 baud AERO Voice channels.

Stay tuned for more!

Crazy idea right? Seriously though, I love porting things to android and wiring them up with FFI bindings. I've had fun porting multimon-ng, DSD-Neo, RTLAMR, RTL-433 and others to android and so, why not JAERO?

I recently had a few days off and went no-sleep for the first 60 or so hours knocking my head against this problem. You see there's something very different about AERO decoding from say decoding AMR, 433 or even digital voice.

The signals are never in the same place, you have to visually tune AERO signals. Thus that meant getting a working FFT/Waterfall before I could even start decoding. I already had this working previously in a private project of mine that my Patrons have been testing out and so I figured I'd re-use that tooling.

See it's a flutter project like most all my Android projects but I used C for the FFT/Waterfall and DSP so ensure optimal functionality and because well, flutter can only do so much on it's own.

The first night was tireless, I was amped up and ready to tackle the issue, I managed to port a working C variant of JAERO's 10500 bps ACARS decoder and was successfully decoding an IQ file on linux, the next step was taking that to Android.

Except, I accidentally deleted the native decoder early in the wee hours of the morning and lost many hours of work in the process. Though I thankfully found another port already finished online that was working for everything but voice.

Bringing that JAERO derived library into Android was fairly simple with FFI bindings in flutter and I was able to get the same file sample to decode on Android.

That was it! I had AERO ACARS decoding on Android! Now I just had to get it working over the air.

The issue I've spent the last who knows how many hours on has been filtering and DSP work trying to get over the air decoding to work.

That's where this project currently stands and why you've not seen it available anywhere on the Forge. I typically don't like to talk about what I'm building until I know what I'm trying to do is feasible.

I've made good progress but now it's time to sleep on it for a while and get some rest. I've gotta work tomorrow and I'll need some time to recover before I can dive head first back into ACARS land.

There's a reason that I didn't add part tagging, recording features or things of the sort.

The legal codes in the United States where I reside and in most other areas around the world do not look very kindly at the interception of private communications. Further, to record such conversations is generally a no-no.

I would love to implement these features, many of you have asked for them. The simple nature of it is that there isn't really a need for those features unless you're using the application to monitor private communications.

So while the software will follow calls and joins PP and RFP together it's still limited specifically to keep things sane.

I do not wish to be liable for how someone uses the software, it's why I've simply made it available instead of hosting it on the Forge.

I’ve also added download counts for every item in the store. Now you can see how many times each file has been downloaded, which gives a clearer picture of what’s popular. This is useful for both me and for you, because it highlights the designs that resonate most with the community. The download count adds a layer of transparency and helps you spot trending items at a glance.

Social sharing is now available on blog posts and store items as well. You can easily share your favorite finds on platforms like Facebook, or BlueSky. This makes it simple to spread the word about something you love, whether it’s a tutorial, a new product, or a behind-the-scenes story. I’ve also added embedding to blog posts, so I can include images and videos directly in the posts. This means richer, more engaging content without needing to click away to other sites. Photos of finished projects, step-by-step video guides, and close-up details can all be part of the reading experience now. It makes the blog feel more alive and connected to the crafting process.

Right now, the focus is on serial connections. That is the primary way these radios talk, so that comes first. I am also looking at adding Bluetooth support down the line. That would cover a lot of newer radios and make the tool even more useful in the field.

The goal is to offer a proper alternative to carrying around a laptop just to change a frequency or update a setting. With PocketProgrammer, you can connect directly to the radio, read its current configuration, and write new settings. It is designed to be straightforward and practical.

The app is still rough around the edges. There are features to add, bugs to fix, and a lot of testing to do. But the foundation is there. If you work with serial radios and have wanted a more portable way to manage them, this is something to keep an eye on.

I will share more as development continues. Feedback from people who actually use these radios will be very valuable, so feel free to reach out when the time comes. For now, this is the start of something promising.

I am still figuring out my next move. One option is to stop distributing Pocket25 in Texas through the Google Play Store. I could keep offering it for side loading from pocket25.com instead. That way, users in Texas can still get the app directly from me without any store enforced age gates. I am not sure yet. I need to weigh the hassle against the risk.

For now, I will not update my apps to use the Play Age Signals API. I will not collect or pass along any age data to Google. If Texas wants to track users, they can do it without my help. I built Pocket25 for a specific audience, and age checks are not part of that vision. I will find a workaround or simply pull the app from the Texas storefront. Side loading is simple and keeps the control where it belongs. With the user. Not with the state or the store.

I am slowly replacing those apps now. Each one requires careful attention. I need to get them signed properly, which is a step I should have taken from the start instead of panicking. The signing process ensures that the apps are trusted and secure, and it aligns with the new policy requirements. It is tedious work, but it is necessary.

At the same time, I am updating them with our new versioning API. This is a feature I have been meaning to implement for a while. The API allows the apps to tell you if there is an update waiting for it. Instead of you having to check manually or rely on outside sources, the app itself will notify you. It is a small improvement, but it makes a big difference in keeping everyone on the latest and safest version.

Rebuilding takes time, and I have to remind myself that progress is still progress even if it is slow. The apps are coming back one by one, each better than before. The rash move cost me some convenience and trust, but it also taught me a lesson about acting on fear. Now I am focused on doing it right, with proper signing and better update management. The forge will be fully stocked again, and this time it will be built to last.

Imagine having an AI assistant that lives inside your WordPress admin. You can talk to it just like you would with any chat bot. But instead of just answering questions, this AI can actually take action on your site. It can create posts, update pages, manage users, adjust settings, and much more. The 41 tools cover almost every aspect of site management.

Getting started is simple. You install the DeepWP plugin like any other. Then you add your DeepSeek API key from your account. Once that is done, the chat bot appears in your admin panel. You type a command or ask a question, and the AI responds. If you ask it to do something, it will use the appropriate tool to make it happen.

The power here is in the tool set. The AI can write and edit content. It can change themes and plugins. It can handle media uploads and user roles. It can even run database queries if you need that. Each tool gives the AI a specific ability, and together they cover the full range of what you can do in WordPress.

This is useful for busy site owners. You can delegate routine tasks to the AI. You can ask it to schedule posts or optimize images. You can have it check for broken links or update your site’s SEO settings. The AI works fast and follows your instructions precisely.

DeepWP turns your WordPress admin into a command center. Instead of clicking through menus and forms, you just tell the AI what you need. It handles the rest. For anyone who manages a WordPress site regularly, this plugin saves time and effort. The 41 tools give DeepSeek AI complete control, and that control is exactly what you need to run your site efficiently.

Starting today, every product page now shows a version number right next to the title, so you know exactly what you're getting. Below the screenshots, you'll find a full changelog a running timeline of every update, what changed, and when it dropped.

No more guessing whether you have the latest build. And to tie it all together, each product now exposes a lightweight API endpoint your apps can call to check for updates automatically. Give it your current version and it'll tell you if there's something newer waiting.

Dead simple.

Here's what that looks like in practice:

• Buy a product once, never wonder if you're out of date
• Apps can ping the API and alert you when an update is available
• Full changelog history lives right on the product page This is the kind of polish I want baked into everything that leaves the Forge. More to come. — Sarah