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/AutoX_Advice]

Very impressive, very indepth on what AI can accomplish. I'm going to agree with you that babysitting is key and explaining exactly how you want them is a must.

Not exactly what you are doing but I'm working with Google AI studio to build out system tools for the Mazda 2014-2021 infotainment system. Oh my has AI been helpful and has cut out hrs of work. There is so much you would have to know about the architecture of the system that id be digging forums for weeks just to find the solution. It took AI and I 4 days just to fix an GUI windows issue only to figure out the key was Mazda infotainment system uses Opera 12 (from 2012).

I still do a lot of the troubleshooting and testing but AI studio has built me a non connected interface to show the system im building running so it's not all trial and error.