January 15, 2026

Jailbreaking a Kindle

Jailbroke a Kindle Oasis. Because why wouldn't you turn a locked-down e-reader into a desk dashboard? E-ink displays are stupid expensive in India. Hundreds of dollars for a decent panel. But I had a Kindle. Linux-based. E-ink. Perfect.

The jailbreak itself? Tedious. Firmware 5.18.2, which blocks WinterBreak outright. AdBreak technically works but requires Special Offers (ads), and Amazon India doesn't expose that toggle. No ads = no AdBreak path. Got initial SSH access via USB, then handed it over to Claude Code. The agent did maybe 90% of the work. SSH'ing into the Kindle, reading forum threads, piecing together exploits, installing KOReader, setting up usbnetlive. Just back-and-forth between the agent and the device. I'd check in, confirm steps, let it continue.

Then came the real work: rendering a dashboard. Cal.com-inspired. Weather widget, calendar timeline with overlapping events, todos. Full landscape layout at 1680×1100. Sounds simple until you hit Kindle's ancient WebKit. No CSS Grid. No Flexbox. Google Fonts won't load. @font-face gets ignored. Fell back to tables, fixed widths, system fonts (Amazon Ember). Stripped out every modern CSS construct.

But here's the bigger problem: KOReader doesn't execute JavaScript. At all.

Spent hours building a client-side dashboard with XHR calls, DOM updates, intervals refreshing data every 5 minutes. Deployed it to the Kindle. Opened it. Saw the HTML skeleton with placeholder dashes. No weather. No calendar. No todos. Just static markup.

Suspected ES6 issues first. Converted const/let to var, rewrote arrow functions, ditched template literals. Still nothing. Built a test file with simple DOM manipulation (document.getElementById().textContent = 'test'). Pushed it. Text stayed unchanged. JavaScript just doesn't run in KOReader's HTML viewer.

Pivoted to server-side rendering. Built a /kindle endpoint in Express that fetches weather (open-meteo, live data for Gurugram), pulls 30 realistic calendar events with overlap logic, grabs todos, then generates complete static HTML with all data embedded. Added a meta refresh tag (5-minute reload). No JavaScript. Just HTML with data baked in.

Deployed it. Worked.

Then the agent found the Chromium binary buried in the system (/usr/bin/chromium/bin/kindle_browser). On its own. Just knew it needed to meet my requirements (landscape dashboard, no URL bar, clean interface) and hunted through the filesystem until it discovered the browser binary and figured out the --content-shell-hide-toolbar flag. URL bar? Gone. KUAL menu integration for easy launching. Slight moment of awe watching a multi-tool agent autonomously solve the problem. This felt like the real breakthrough. Auto-triggering the browser, no chrome, just content.

Tried framebuffer rendering too, basically overriding the screen directly, writing raw pixels to /dev/fb0 (the display memory), bypassing all UI layers. Rotated the image 90° for landscape. Worked perfectly. Until the battery overlay started stomping over it every few minutes. System-level UI elements you can't suppress. Explored, tested, abandoned. Browser-based approach is cleaner.

But landscape? Still not solved. Browser appears hardcoded to portrait. Tried mesquite framework orientation locks, tried CSS rotation (old WebKit laughs at transforms), tried physical rotation. Nothing. Browser stays portrait. Landscape is a hard requirement. Not there yet.

The workflow for this was pure agent magic. SSH'd into the Kindle over Wi-Fi, set up a continuous deploy loop where the agent curled the server-rendered HTML, transferred it via scp, tested it, iterated. I barely touched the terminal. Just gave it long-running tasks: "fix the layout," "add calendar overlap," "make the weather widget bigger," "find Chromium and remove the URL bar." Let it burn tokens.

How many tokens? Millions. Easily 200-300 million. Maybe more. The agent had filesystem access, SSH access, web access, multiple tool chains. It ran nodemon servers, killed port conflicts (port 5000 was occupied by ControlCe, moved to 5001), debugged CSS rendering bugs, wrote server routes, fixed API endpoints, created KUAL menu integrations, built screenshot capture tools (~/kindle-screenshot.sh that reads /dev/fb0 and converts to PNG for easy testing). Continuous loop. I'd give it a vague instruction, walk away, come back to a working solution.

Was it worth hundreds of dollars in token cost to render a calendar on a jailbroken Kindle? Absolutely. This is what agents are for. Not toy demos. Real work. Tedious, multi-step, iterative work where you'd normally context-switch yourself into exhaustion. The agent held the entire state: jailbreak logs, server config, SSH credentials, CSS constraints, WebKit limitations, Chromium launch flags, framebuffer stride calculations, deployment commands. I just steered.

The dashboard still isn't perfect. Landscape orientation unsolved (hard blocker). Event overlap rendering could be tighter. But it's there. Live weather. Full calendar. Todos. Auto-refreshing every 5 minutes. On an e-ink display. Code committed to git (kindle-dashboard once I push it). KUAL menu with launch options. Screenshot tool for testing. The whole system.

Tomorrow's a holiday. Probably spend it solving landscape, maybe hooking it to my actual calendar, adding real todo sync. Get it production-ready. Then push the repo public so someone else equally obsessed can skip the 72-hour jailbreak/CSS/SSH/Chromium debugging loop.

Also still learning vector databases on the side. That's the slow burner. Structured plan in place, just grinding through fundamentals. How they work, use cases, indexing strategies. But this? This was the fun chaos. The kind of project where you realize agents will become part of our life. You can't hold this much state in your head. The context switching alone would kill you. Jailbreak exploits, firmware limitations, WebKit quirks, server routing, SSH deployment, framebuffer rendering, browser flags, orientation locks. Let the agent handle it. Just keep feeding it problems.

Building on sand still sucks. But building with the right tools? That's when it clicks.