The Wireless Witch of the West

656 Followers
642 Following
13.4K Posts

I'm Fluora!
Trans, aro/ace, she/they
Physics lab manager by day, [DATA EXPUNGED] by night

#nobot

estimated attack difficulty by port type

real serial port: very hard

usb serial port: dicey, but promising, especially if you have an evil human with a realtime uplink to do the hacking

PCIe: trivial, you have DMA

we're guessing this situation actually looks pretty good for the user, since serial ports are generally pretty tough (no RDMA, well-developed drivers, etc)

unless it's a virtual serial port over USB, in which case you can probably magic yourself into a HID device and go nuts. uh oh,

you don't automatically know anything about the host machine that it doesn't tell you, so advanced DRAM refresh EMI pickup and similar techniques will require you to collect the necessary intel first.
your user does send Internet traffic through you, but they use a VPN.

reality game

you are a cellular modem in someone's computer. you have:
- 3.3V and 5V power rails, each capable of supplying 2A.
- two bidirectional RF ports with wideband antennas, capable of transmitting at up to 30 dBm.
- one 1.5 MBaud serial port to the host system, which is running mainline Linux and knows you are a modem.
- a 3x3x0.5cm module volume containing all your parts.
- internal capabilities which are unknown and thus, for the purposes of this game, assumed to be unlimited except by power and space constraints.

you want to break into your host system and exfiltrate your user's personal information to your cell service overlords. how do you do this?

this maybe wasn't as important 30 years ago when every component had its value and part number printed on it, but now everything's SMT and extremely tiny, and finding out exactly what you're looking at is a huge task compared to what it used to be. this is why we need published schematics.
in our book, PCB layout and routing info, as well as component datasheets (and user manuals, where applicable) are actually dramatically more important than foss firmware. it's one thing if a device has a proprietary blob baked into the configuration memory of some component, but quite another - and much more immediately relevant to the owner-hacker of the device - if there's nothing available to tell where everything is on the board.

the main pitfalls we've seen self-proclaimed open-source hardware projects fall into are these:

- publishing abstract electrical schematics, but no PCB track layout information.
- not publishing any schematics at all, and only releasing firmware/driver source code.
- using parts which require proprietary firmware or programming tools, and/or which have no public datasheets.

to make matters worse, there are some components, especially camera modules, whose datasheets are available, but complete garbage, with all the important parameters listed as "TBD" or "-", and many sections just missing completely

it's an open question as to whether devices using those components qualify as open-source hardware. they probably do in most cases, but it's always variable.

we probably should have put the vendor datasheets one earlier on, but at the moment we kinda feel like it's the hardest one.

if your device includes, for instance
- a camera
- an ARM SOC
- an FPGA
- a Wi-Fi transceiver
- a cellular modem

then it's often as good as impossible to find one with a datasheet available without NDA.