2 ms·

Ah, I see. The listed photos are just at the wrong angle to be able to read the chip markings (grr)... but I had a bit of a further poke around, and found a li

Ah, I see. The listed photos are just at the wrong angle to be able to read the chip markings (grr)... but I had a bit of a further poke around, and found a listing for a discontinued internal board for HTPC (!) setups: https://www.pulse-eight.com/p/117/internal-hdmi-cec-adapter https://www.pulse-eight.com/p/117/internal-hdmi-cec-adapter A reasonable bit of eye-strain later I at last identified that I was staring at an AT90USB162-15AU. Here's a reference for the -16AU: https://www.mouser.com/ProductDetail/Microchip-Technology-Atmel/AT90USB162-16AU?qs=OZGkuhlU921GAr4H4cBlBw%3D%3D https://www.mouser.com/ProductDetail/Microchip-Technology-At... Huh. 16MHz. That answers that then. (Now I'm a tad more idly curious why the firmware was unreadable.)

zorgmonkey 5y ago
If you end buying the product wireshark can capture USB data and then you'll be able to see exactly what data is sent to it when you use their flash util. On windows you'll need to also install USBPcap to capture USB traffic, but if I remember correctly it is bundled with wireshark and just unchecked by default. Otherwise you might try binwalk with the --disasm option (you'll need capstone installed for it to work) then it will attempt to search files for assembly for any of wide range of processors (obviously would fail if the firmware is encrypted, but I doubt a cheap product like this would bother). I'll also just briefly say that even though RCDATA is microsoft's recommended way to embed a file into an executable I've seen plenty of software that embeds files in other creative ways, so I wouldn't rule out the possibility that the firmware is somewhere else in the executable, binwalks entropy analysis mode can sometimes work firmware that is otherwise hard to locate.