04/24/2019 at 05:59 •
While it's not as rich as IP, you can still describe the DRM-114 optical protocol as a stack. Let's go through all the layers.
Of course, the physical layer is infrared light. The IR LED has a peak wavelength of 950 nm, and the receiver has it's peak sensitivity centered there too. The receiver is configured to output a "0" bit whenever it sees a 36 kHz IR square wave. It requires a minimum of 6 cycles to reliably detect a 0 bit. This means we could use a bit rate of 6 kilobaud, but I decided to make it 4800 baud "just because."
Data link layer
The framing is asynchronous serial 8N1 at 4800 baud - again, with the 0 bits being represented as 36 kHz pulses and 1 bits being no IR at all. With this signaling, the output of the detector will be the actual decoded serial data stream the controller's UART will be looking for.
Data packets start with the two-character sequence DLE STX. This frame start sequence is followed by all of the bytes of the frame until the end. If the DLE character is seen organically in the packet data, it is transmitted twice. After the last byte of the frame, the two-character sequence DLE ETX is sent. A frame can be a maximum size of 192 bytes (not including the start, end or DLE "escape" characters).
A packet consists of 16 bytes of protected AES-128 key, followed by 16 bytes of IV and the ciphertext. The key is unprotected and is used with the IV and AES OFB mode to decrypt the ciphertext. The result is the plaintext message preceded by a 16 byte AES-CMAC over the plaintext using the same key as was used to decrypt the message. If the CMAC doesn't match the expected value, the message is discarded.
Messages start with a single byte of message type, followed by the null-terminated name of the sender. Message types are 0 for broadcast message, 1 for directed message, 2 for broadcast attention and 3 for directed attention. If the message is directed, then the null-terminated source is followed by a null-terminated destination name. If the message is not an attention message, then the null-terminated message text is appended.
That's it. The only part of the protocol that's undocumented is the key protection method. And I have no objection to anyone forking the source and supplying their own key protection method to make a working clone system, so long as their key protection method does not interoperate with DRM-114.
04/24/2019 at 05:29 •
DRM-114's actual functionality is sort of best described as "optical IRC."
First, attempting anything with RF at DEFCON is an exercise in futility. The noise floor is so high there that anything worthwhile is damn near impossible. Even the conference WiFi is problematic. But IR optical networking should suck a whole lot less (whether it actually does or not... remains to be seen).
So assume that you and a bunch of other folks equipped with DRM-114 and the appropriate dumb terminal are within optical range. Now what?
First, the serial parameters are 115,200 baud, 8N1. The UI will mask off the high bit, so it's 7 bit ASCII only within those 8 bits.
DRM-114 presents a simple prompt:
That prompt indicates that you are in broadcast message mode. Anything you type that doesn't start with a "/" will be sent as a broadcast message and any DRM-114 that manages to receive it without error will print out your name, a ":" and then your message.
Speaking of name... you can change your name with "/n [name]". The badge comes with a default name set - "def_" and 4 hex digits (they're random and based on the controller's serial number, so they should be unique). You can use "/n" without an argument to find out what the current name is. You can change it to anything reasonable (up to 8 printable ASCII characters). There's nothing to prevent multiple users from using the same name. Directed (that is, non-broadcast) messages directed to a name will be received by any and all badges that have that name set.
So how do you send a directed message? You use "/t [partner name]" to set the talk partner's name. If you do that, the prompt will change to
to let you know that the lines you type (again, that don't start with /) will be sent only to that partner destination name.
You can use "/t" by itself to revert to broadcast message mode.
In addition to directed and broadcast text messages, there are also "attention" messages. You send them with "/a". An attention message can be directed or broadcast. It's a directed attention message if you have set a talk partner, and will only be seen by that named partner. If you don't have a talk partner set, then the attention message will be broadcast. An attention message causes the bright blue ATTN LED on the SAO to blink and the message
"[so and so] wants attention!"
to appear. That message is also accompanied by an ASCII BEL character, so if your terminal has BEL support, that'll happen too.
IR networking being what it is, you may find that the occasional message is not properly received (gasp!). If this happens, the "/r" command can be used to repeat verbatim the last message (of whatever kind) was sent.
/h or /? can be used at any time to get help.
Goon special versions have additional functionality, but that's private for goons, so they'll have to figure it out on their own. The help text for goon versions lists the additional commands and should make it easy to figure out.
04/20/2019 at 16:54 •
Turns out, the manufacturer went ahead and made them black anyway. That's a nice bonus - I much prefer black to green. They're on their way back and should arrive Monday. I've updated the project gallery with a picture of an OSHPark board (the only difference is purple soldermask instead of black).
The goon variants are all done. Their special firmware will not be open-source and it will be a goon-only super-set of functionality. The soldermask is goon-red and they will be sold for the same price, but only to goons.
The only thing left when the manufactured boards arrive will be to add on all of the SAO connectors and program them.
I also need to make up a bunch of "CnD" certificates just in case someone does succeed in reverse engineering the key protection algorithm.
03/19/2019 at 20:01 •
I've ordered the goon boards. They're going to get red soldermask and special Goon firmware but otherwise be the same. I'm going to build those myself because it's going to be a relatively small number of boards.
The rest of them are going to be green because apparently black is harder for the fab to do small aperture openings in, which impacts the QFN footprint.
I'm also going to make a few "fake badge" USB UART boards so those who don't get a dumb badge will be able to talk to (and play with) DRM-114.
I've learned how to use the XMega lock bits so that folks won't be able to simply use PDI to rip the firmware out and decompile it to learn The Secret.
All in all, this project is ahead of schedule at the moment.
03/02/2019 at 20:49 •
I've decided to rev the hardware to move the attention LED pin to D7 to free up C0 and C1 for i2c, and connect the i2c pins up to the SAO connector.
I'm not sure what DRM-114 might do with i2c, but it's certainly better to have the option to do something.
03/01/2019 at 19:18 •
I've decided to try a version 2.0, which simply replaces the TQFP XMega with a UQFN (5mm) variant. It winds up being a slightly smaller board, but also just looks a little cleaner and more impressive.
I'm getting a prototype run done first, and if it succeeds, then that will be what's manufactured for DEFCON.
I'm also going to change the firmware to pick a random name if none is set (just so everyone isn't "default"), and to save the name to EEPROM so it can be preserved across power-cycling.
02/14/2019 at 05:12 •
SAO V2 is a thing now, and it's for certain that DRM-114 will be an SAO. It's intended to be paired with the VT69 badge, aka the Dumb Badge.
The only thing left is to figure out the final form factor and... I dunno... art?
I kinda hate doing the art part. I'm all about function over form. Sigh.
09/02/2018 at 01:50 •
So with the current 68 Ω series resistor, I tried the two newer LED options. With the higher power surface mount emitter and the light pipe, the range improved from about 5 to perhaps 8 feet, but with the through-hole emitter, I got pretty reliable reception at 25 feet. I feel like reducing the series resistance down to 20 Ω will make the whole thing reliable at up to 30 feet, which I think will be good enough to score.
I'll try next when the v1.1 boards show up with the through-hole pads. I think, at least from an electrical perspective, that that's going to be the final design. Aesthetically, I am not sure, but we have at least 8 months to ponder that one.
08/30/2018 at 02:28 •
The range at the moment is about 6 feet.
It didn't really improve even by cutting the series resistor for the LED in half.
Something must be done.
I currently have an XZTNI54W IR emitter, which has a spec of something like 2 mW/sr. My guess is that that's not enough. Switching to a VSMY1940X01 and dropping the series resistor down to 20 Ω or so should crank out more like 10 mW/sr, from what I can tell from the datasheet. Time will tell.
EDIT: Huh. Through-hole emitters can be had that will do more like 500 mW/sr. I'll have to give them a try.
08/30/2018 at 01:05 •
The hardware and firmware work. At least from a few inches away. Next is range testing. I have reasonably high hopes.