Some crazy things have happened since the previous episode: There were rather mysterious test results with different Zener diodes that took me some time to figure out, I’m actively joining forces with the Cryptech project and I’ve ordered the first generation of proper test PCBs among other things.
Table of Contents
00:00:54 SPAM! SPAM! SPAM! SPAM! (Not so) Wonderful SPAM!
00:01:35 FTDIgate, and why to remove their chips from any board design
00:02:50 USB Vendor and Product IDs (VID/PID)
00:03:25 Dave Jones’ reaction on his EEVBlog
00:03:50 Impact of the driver on the victims
00:05:14 Response of the Maker scene
00:06:03 Microsoft (and others) driver update scheme security
00:06:42 Inherent insecurity of the FTDI chip design
00:09:05 Reconsidering the reasons why or why not to use FTDI
00:09:37 Other things I don’t like about FTDI and their chips
00:13:23 Why I used FTDI chips anyway
00:15:33 Alternatives to consider
00:16:55 VUSB and the Digispark: Unfortunately not an option this time
00:18:25 The Microchip MCP 2210 SPI<->USB interface chip
00:19:15 Using PIC microcontrollers to replace the FTDIs
00:22:50 Using a single microcontroller with built-in USB for the ARRGH project
00:24:00 Dropping the USB interface itself
00:25:05 Using GPIO pins on a computer
00:25:30 Next steps with the ARRGH board
00:28:15 Other things that happened since BIVBLOG#31…
Regarding airport security: I take the train while travelling in Europe. It’s not as fast but you spare yourself the security theatre. Moreover, it’s more environmentally friendly :).
If you want to obtain a USB Product ID, you can buy it from objective development and MCS Electronics.
I would also advise you against programming the PIC in assembly. PIC16 microcontrollers have no usable call stack. The PIC 18 seems have a call stack of 31 level but I can’t take it serious either. SDCC worked for the PIC16 microcontroller I developed for back then but has some overhead due to the stack management.
Another option would be to use the Cypress EZ-USB FX1 or similar. They probably don’t suit your requirements but if you want to use USB 2.0 at full speed with a FPGA they are quite useful. I’ve also seen devices that use USD HID controllers (e.g. thermometers).
If you choose the PIC18, I would make it a USB CDC device, so that you don’t need any drivers.
If SDCC doesn’t work for you, MikroC for PIC seems to be a good alternative.
If you want to start a business, there are already competitors (HobbyTronics, Firmware Factory).
Your Spam filter also seems to have a high false positive rate.
Hi Matthias,
> I take the train while travelling in Europe.
so do I if it’s practical, but Stockholm is *quite* a trip by train. Good news is that the next RIPE meeting is in Amsterdam, and that’s a no-brainer if there ever was any.
> If you want to obtain a USB Product ID, you can buy it from objective development and MCS Electronics.
If I get seriously into building this, then I’ll surely do some more research on it. But to my understanding these product ID “resellers” operate in a way that’s somewhat legally disputable, and I don’t really want to wind up in the middle of some silly ((un-)preferably US law) lawsuit.
> I would also advise you against programming the PIC in assembly.
I’ll avoid *any* assembly if I can: I’ve got the traumatic experience of learning assembly on an 8088, and of course writing portable assembly code is kind of tricky, too:-)
> Another option would be to use the Cypress EZ-USB FX1 or similar.
Unfortunately, as far as I’ve seen on the Cypress web page they don’t come in DIP packages, which is the key reason for the PICs. The idea is to make it as easy as possible for people to build their own devices, and QFN packages are somewhat counterproductive when it comes to that.
If I can’t get around SMD, then a somewhat more obvious choice might be an Atmel ATXmega, simply because thanks to Arduino more people are familiar with the Atmel stuff.
> If you choose the PIC18, I would make it a USB CDC device, so that you don’t need any drivers.
That is actually a reason to go straight for the PIC18, then.
> If SDCC doesn’t work for you, MikroC for PIC seems to be a good alternative.
Hmm, again that seems to be proprietary, and as such not a good choice if things are seriously meant to be auditable.
> If you want to start a business, there are already competitors.
I know, but if people actually care about things being auditable then I might still have something interesting to offer.
Anyway, right now I’m rather busy so progress is rather slow, but the most pressing need at least with regard to the Cryptech.is project that I can help with is some sort of test suite for hardware-generated random numbers; so I’m working on that first.
> Your Spam filter also seems to have a high false positive rate.
Well, “example@example.com” might actually ask for being considered spam:-) Anyway, I’m not exactly happy about it either, but since I set that spam filter up it dealt with about 26k spam posts; there’s no way to deal with that manually any more.
Cheers,
Benedikt