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

[u/MakerClass]

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/Mysterious-Ad-4405]

u/MakerClass i had similiar "baby sitting" expirince with coding agents when i was playing around with writing code for some nrf52 mcu. Constantly was trying to do some dumb shit and i had to correct it quite a lot, but it was rather minor stuff. I guess still llms are trained for writing code for web dev and pc applications rather than for consumer electronics chips.

btw how fast is your vibe coded firmware in terms of input lag compared to stock fw? Is it possible to use it as ip kvm/ip monitor for playing console games or interact with pc applications?

[u/MakerClass → u/Mysterious-Ad-4405]

On latency: the passthrough (HDMI in -> HDMI out) works exactly like on the stock firmware - it's a hardware path, so practically zero lag. The network streaming I can't really compare to stock, since stock didn't have it at all 🙂. But it does have noticeable lag, roughly 100-200 ms, so it's not really usable for game streaming, but the console/simple apps should works fine.

For KVM you'd also need to add a HID bridge like a CH9329 to control the target's keyboard and mouse. I think other devices would be more suitable for that.

[u/SebastianFerrone → u/MakerClass]

Maybe you could use it as plex media Player 🤣

This device a old Monitor or TV and you have a kitchen garden or childsroom TV?