- Published on
Poking at an O.MG Cable with the tools macOS already ships
- Authors

- Name
- Shuqi Wang
I got an O.MG Cable and wanted to see it from the defender's side: plug it into my own MacBook and figure out how much the machine can tell me about it using only the tools that ship with macOS — system_profiler, hidutil, and the Unified Log. What shows up, and can I trust it?
To have something to observe, the cable types one fixed harmless sentence into a text field on a trigger — no shortcut keys, no opening apps, nothing that leaves the machine. The payload is boring on purpose:
REM harmless text only
DELAY 4000
STRING this is a harmless hid appearance test
ENTER

Setup: MacBook Air (Mac14,2, M2), macOS 15.7.4 (24G517), one O.MG Elite Cable. In its config the cable reports itself as Apple / USB-C 60W, VID 0xd3c0, PID 0xd34d.
What the built-in tools show
I looked at the keyboard/HID inventory in three states — cable unplugged, plugged in and idle, plugged in and typing — with two commands:
system_profiler SPUSBDataType # USB devices, minus the JSON noise
hidutil list | grep -i -E "Keyboard|Usage|Built-In" # cut to the keyboards
First gotcha, before any results: the reflex command ioreg -p IOUSB -l returns nothing useful on Apple Silicon. The M-series host controller hangs devices off AppleUSBHostController, not the legacy IOUSB plane, so a lot of BadUSB walkthroughs written for Intel Macs are quietly reading an empty tree here. Worth knowing before you conclude "the cable is invisible" when really your command is looking in the wrong place.
The actual result: plugged in but idle, the cable doesn't show up as a keyboard at all. The keyboard-HID count stays at the built-in baseline of four (internal keyboard/trackpad plus Touch Bar, all real Apple, VID 0x5ac) across a full unplug/replug. system_profiler shows no external device either. This isn't a discovery — on-demand HID enumeration is how these cables dodge inspection, it's the whole point of the hardware — but it's the thing to internalize: a point-in-time scan of a resting O.MG looks exactly like an empty port.
The interface only exists while it types. Polling hidutil ~10×/s across five triggers, the keyboard count jumps to 6 for the duration of each payload and drops back:

Each pulse lasts ~4.5 s — which is just DELAY 4000 plus typing time; nothing deeper than that. Two things about those pulses are worth noting:
- Each trigger registers two HID services, not one — a keyboard (
primaryUsage 0x6) and a pointer (0x2). One "charging cable," two input devices. - The VID it exposes is
0xd3c0, but it calls itselfApple— and Apple's real USB vendor ID is0x05ac, the same one on the built-in keyboards. Spoofing VID/PID is BadUSB 101, but the interesting bit is that the string and the number contradict each other: a device claiming "Apple" under a non-Apple VID is inconsistent with itself, which is the kind of thing a host-side check could key on.
What the log does and doesn't catch
During plug/unplug the Unified Log records only USB-C port power activity — no device identity, no HID detail. The replug even gets matched as an ACM (serial) service, not a keyboard:
00:10:19.788 removePowerSources(): [Port-USB-C@1/Power In] Removing all power sources...
00:10:19.789 terminate(): [Port-USB-C@1: USB3] Terminating IOPortTransportStateUSB3...
00:10:33.294 start(): [Port-USB-C@1: USB2] Found ACM service during startup!
When the HID interface does appear during a payload, the log has an IOHIDService … Service added line for it — so the appearance is visible at the event-stream level even though the resting device isn't. That's the useful bit: a periodic scan misses the cable entirely, but something watching the HID event stream would at least catch the moment it wakes up.
So, with nothing but stock macOS tooling: a plugged-in O.MG is indistinguishable from a charger until the instant it types.