Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That USB to CEC passthru box is $44.92 for reference. I do wonder what chipset it's using under the hood to do its thing, but given the combination of HDMI licensing/royalty fees, manufacturing tooling, the little custom enclosure it has (looks like molded/formed plastic, if I'm using the right term), then factoring in the low production volume, and considering that this seems to be a smaller operation... I think it's quite plausible the margin on the thing is quite small. Very plausible.

While on the page I was curious if the firmware was open source. While writing this and properly articulating the bit about HDMI royalty (and also just now realizing it might need to deal with HDCP... ah) I now realize the question is moot, but I didn't think of any of what while looking at the webpage, so I wondered if it would be interesting to have a cursory poke at the firmware download.

7-Zip (also available as a commandline program as p7zip-full on debian et al) is honestly grossly understated it its capabilities. I didn't feel like remembering how to invoke binwalk so tried `7z x firmware-v7.exe` almost as a bit of a challenge and it actually worked :)

  $ 7z l ~/Downloads/firmware-v7.exe 
  Path = /home/i336/Downloads/firmware-v7.exe
  Name = WEXTRACT.EXE            .MUI
  OS Version = 6.1
  Image Version = 6.1
  Subsystem Version = 5.0
  Subsystem = Windows GUI
  DLL Characteristics = Relocated NX-Compatible TerminalServerAware
  Comment = FileVersion: 9.0.8112.16421
  FileVersion: 9.00.8112.16421 (WIN7_IE9_RTM.110308-0330)
  CompanyName: Microsoft Corporation
  FileDescription: Win32 Cabinet Self-Extractor                                           
  ----
  Path = .rsrc/RCDATA/CABINET
  Type = Cab
  Physical Size = 1348694
  ID = 7086

    Date      Time    Attr         Size   Compressed  Name
  ------------------- ----- ------------ ------------  ------------------------
  2016-04-13 13:05:12 ....A       184800               flash.exe
  2012-08-29 16:19:56 ....A       619536               driver1.exe
  2012-02-21 04:24:52 ....A       816224               driver2.exe
  2012-07-31 15:35:30 ....A          400               flash.cmd
  2012-03-10 11:27:28 ....A        67008               libusb0.dll
  ...
It output even more lines of metadata than I included. I removed probably 50% of output so as not to spam the subthread.

Awesome.

Hmm... what if I do the same to `flash.exe`?

  $ 7z l flash.exe 
  ...
  Linker Version = 10.0
  OS Version = 5.1
  Image Version = 0.0
  Subsystem Version = 5.1
  Subsystem = Windows CUI
  DLL Characteristics = Relocated NX-Compatible TerminalServerAware

     Date      Time    Attr         Size   Compressed  Name
  ------------------- ----- ------------ ------------  ------------------------
  ...
                      .....        67392        67392  .rsrc/RCDATA/101
                      .....         2496         2496  .rsrc/RCDATA/102
  ...
  ------------------- ----- ------------ ------------  ------------------------
  2016-04-13 22:05:07             183568       183568  9 files
HMMmmmm, RCDATA you say?

Extracting (`7z x ../flash.exe` from an empty subdir) produced newline-less ASCII hex output ("EF19541A19D258B099B877545DE0B65BBBC5602..."), so after a bit of `printf "$(cat 101 | sed 's/../\\x&/g')" > 101.bin` I came up with... nothing.

Binwalk has no idea what it is. Perhaps the start of the files ring bells for some humans?

  $ ls -l
  -rw-r--r-- 1 i336 i336 67392 Apr 13  2016 101
  -rw-r--r-- 1 i336 i336 33696 Apr  1 05:46 101.bin
  -rw-r--r-- 1 i336 i336  2496 Apr 13  2016 102
  -rw-r--r-- 1 i336 i336  1248 Apr  1 05:48 102.bin

  $ xxd 101.bin | head -n 5
  00000000: ef19 541a 19d2 58b0 99b8 7754 5de0 b65b  ..T...X...wT]..[
  00000010: bbc5 6020 54e7 ca9a 1fb7 beca 0a39 95c4  ..` T........9..
  00000020: c876 de8a 4705 19a5 9f03 4c56 5d83 9550  .v..G.....LV]..P
  00000030: f5ad 2930 5f07 9b46 21b1 91a0 d091 4685  ..)0_..F!.....F.
  00000040: 3ada 0ce3 305b 49e1 939e 7384 3c5a 5794  :...0[I...s.<ZW.

  $ xxd 102.bin | head -n 5
  00000000: f3f1 7b55 3f33 cbed 426e 1ab7 5792 4425  ..{U?3..Bn..W.D%
  00000010: 8e75 1566 5597 8183 c1ce 9265 6acf 3b73  .u.fU......ej.;s
  00000020: 1370 47b4 5431 399b f73f 0f6a 6323 3329  .pG.T19..?.jc#3)
  00000030: 0e52 25ad 0530 5d03 9393 bc8c 40c8 f0fb  .R%..0].....@...
  00000040: c63c 7ddb 4d3a cd89 ab4a e6c7 cb2f ab4f  .<}.M:...J.../.O
For what it's worth, having realized this might be touching HDCP or for all I know might be an FPGA bitstream, I emphasize my interest is purely coming from a decidedly non-exhaustive sense of "ooh that's a cute product, I wonder what firmware it runs and how it broadly works internally" entirely made up of idle curiosity :)


HDCP is unrelated to the CEC bus. CEC is completely separate and unencrypted. The pulse-eight adapter, AFAIK, should just be a female-female connector with two pins plugged into a microcontroller.

I've toyed with the idea of replicating its functionality on an Arduino, but ended up just buying the adapter :)

In the end, I'm not sure how doable it is, but it shouldn't be too complex. Licensing is another matter. I'm at a loss as to why GPU makers don't wire it up though.


I see (TIL a lot about CEC, added some info to a sibling comment).

I incidentally found https://hackaday.io/project/168696-cec2usb while poking around, last updated a couple years ago so probably not available for sale anymore, but open source at least.


Unpacking the files also produces a certificate, and the strings command on the flash.exe executable reveals also references to various related links, so it is possible that the firmware is also encrypted and signed.

  ---
  http://s2.symcb.com0
  http://www.symauth.com/cps0(
  http://www.symauth.com/rpa00
  http://s1.symcb.com/pca3-g5.crl0
  SymantecPKI-1-5670
  Symantec Corporation1
  Symantec Trust Network100.
  Symantec Class 3 SHA256 Code Signing CA
  ---
... etc.


The intel NUC exposes the CEC pins to the motherboard, and the same company makes an internal USB/CEC adapter for $15 less[1]. That PCB is almost entirely an MCU and a crystal, so the plastic box and HDMI passthrough adds $15.

1: https://www.pulse-eight.com/p/154/intel-nuc-hdmi-cec-adapter


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

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-At...

Huh. 16MHz. That answers that then.

(Now I'm a tad more idly curious why the firmware was unreadable.)


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: