Image 1 — Reverse-engineered an abandoned AVerMedia capture box, then gave an AI a telnet shell and let it write new firmware
Image 2 — Reverse-engineered an abandoned AVerMedia capture box, then gave an AI a telnet shell and let it write new firmware

Reverse-engineered an abandoned AVerMedia capture box, then gave an AI a telnet shell and let it write new firmware

I wanted to record the 640×480 HDMI output of an RP2350 board, and I had a mostly-dead AVerMedia Game Capture HD II in a drawer. The hardware still works, but the ecosystem around it had died. The YouTube API it streamed to, the mobile app, and I'd lost the IR remote - and on top of that it refused 640×480 as "unsupported." So I opened it up instead of buying something.

Inside it's a TI DM368 (DaVinci, ARM926 @ 432 MHz) with a hardware H.264 encoder, ITE IT6604E/IT6613E for HDMI in/out, a Nuvoton NUC100 as the system MCU, and 128 MB NAND.

Getting in was pretty standard: found the UART header with a multimeter, dropped to a root shell , and dd'd the NAND out from there (it wasn't as straightforward as it sounds here, but in the end, it worked out 🙂). Fortunately, I didn't have to do a physical memory dump, that would have been quite a challenge. The downloadable firmware is 3DES-encrypted, but the on-flash system is already decrypted so that didn't matter. The old DES root hash cracked in ~30 min and one U-Boot env var flips on telnet for persistent access.

Then the fun part: I gave Claude Code the telnet shell and watched it go. It explored the running box on its own - drivers, the video pipeline, the MCU's I2C protocol, the TI codec stack - and then, with a lot of steering from me, wrote a whole new firmware: a capture app, HTTP/RTSP servers, a web UI, and the build + flash tooling. The result does native H.264 (the box's hardware encoder) over RTSP into OBS/VLC, the resolutions the vendor had blocked purely in software (640x480 I needed and up to 1080p) and has pretty usable control panel.

AI was a huge accelerator but it needed constant babysitting. My favorite failure: a U-Boot prompt printing "Hit any key to stop autoboot" while actually waiting for one specific key. But the AI fixated on that printed label and even as I kept telling it to just read the disassembly it wouldn't. When it finally did: the bootloader hardcodes a compare against 'U' (cmp r3, #0x55). It also once "confirmed" a claim using terminal output it had invented itself, and wrote that into its own persistent memory as fact.

You can read the full write-up on my friend's blog: https://chiptron.eu/reviving-old-unsupported-devices-with-ai-avermedia-game-capture-hd-ii/

u/MakerClass — 5 days ago
▲ 170 r/raspberrypipico+1 crossposts

picogame: a 2D game engine for the Pico - write games in CircuitPython, try them in the browser, run on the board

Sharing a project I've been building for almost a year - picogame, a 2D game engine for the Pico and similar grade MCUs. You write games in CircuitPython, the heavy lifting (rendering, collisions, effects) runs in native C, and you can try them in your browser before you even plug in a board.

Out of the box:

  • Build without hardware - the same game runs in your browser and on your desktop (a real CircuitPython simulator, not a mock), then unchanged on the board.
  • Fast in tiny RAM - native-C rendering + zero-RAM full-screen paths, so it runs smoothly on even plain RP2040.
  • Batteries included - sprites, scrolling tilemaps, a moving camera, collisions, sound, text, saved high scores.
  • A web level editor - build levels/scenes in the browser, load them in your game.
  • A launcher - keep several games on one board and pick from a menu.

Try it in the browser: https://picogame.makerclass.cz/playground/

Project repo (MIT): https://github.com/MakerClassCZ/picogame

I also wrote up why I built it and how it works: https://chiptron.eu/picogame-a-game-engine-for-circuitpython/

I'm the author - happy to answer anything!

u/MakerClass — 16 days ago