Developers: builders or explorers?

via Arduino Blog


Last spring we collaborated with VisionMobile to run a survey on IoT developers and also the value that Open source has in the field.

We discovered that Between IoT developers there is a big chunk of open source enthusiast. 1/5 value the importance of using open source tools and platforms.

Developer that define themselves explorers cover a crucial role in the field. It is from them that all the truly new, out-of-the-box ideas come from.

Only by exploring seemingly crazy ideas can the Internet of Things reach its full potential. The open source ecosystem is often the area where these ideas bloom.

While open source is so valued between developers, there is still a lot of work to be done. 60% of the opensource enthusiast in fact, think that open standards are missing in IoT.

We are really happy that the connected Home is the most interesting vertical market for developers, and we can’t wait to see what this big group of explorers will develop in the next future. Hopefully the next big invention will be open source.

Find a full article on Developer Economics website.

On Casa Jasmina website you can explore the infographic in high-res with some  interesting data:


The most important role of Internet of Things developers is to explore new possibilities. The technology is widely available; in no small part because of open source software and hardware projects. Now we need to learn where we can take it. We can build it, but should we?

Enginursday: Windows Drivers & Security

via SparkFun Electronics Blog Posts

TL;DR — SparkFun's drivers for MS Windows are now signed! No more wasting time disabling security features.


Signed Drivers

Beginning with Windows Vista, Microsoft slowly began increasing the requirements of code running in Windows to be digitally signed. Here is their definition of code signing:

A signed driver is a device driver that includes a digital signature. A digital signature is an electronic security mark that can indicate the publisher of the software, as well as whether someone has changed the original contents of the driver package. If a driver has been signed by a publisher that has verified its identity with a certification authority, you can be confident that the driver actually comes from that publisher and hasn't been altered.

Their kernel-mode code signing policy is an important step in securing the operating system and making the lives of users easier. Being able to verify the integrity of a file every time the image of the file is loaded into memory reduces the odds of the OS loading modified or malicious code into ring 0. Giving users easy ways to load malicious code into the kernel is a great way of giving malicious people an easy way to do bad things to systems.

Secure Operating System

This is a bit of a tangent, but what good is a signed driver if the OS can be modified to ignore it? Please ignore that fact that if someone can modify the OS, you already have big enough problems. Focus instead on the fact that many of the better hackers and security researchers chain together a handful of small things to make big things happen. It's similar to finding a simple buffer overrun or getting a system to crash with a fuzzer. The system isn't necessarily vulnerable YET. It's often only a matter of time before it is. SHA-1 isn't actually vulnerable yet, but all of the major browsers are removing support for a reason. You don't want weakened security when you don't have to have it.

Beginning with Windows 10 (the standard OS delivered with most new PCs) "all new Windows 10 kernel mode drivers must be submitted to and digitally signed by the Windows Hardware Developer Center Dashboard portal. Windows 10 will not load new kernel mode drivers which are not signed by the portal."

Attacks on computer firmware have been around since at least the 90's, with fun code such as CIH & later Mebromi. In the last few years that type of attack has been making the news more often. Firmware vulnerabilities such as those for BIOS, or those for UEFI have increased the awareness for the need to actually do something about it. A fairly new security feature named UEFI Secure Boot is on the market. It's been required for Windows 8 machines to be part of the Windows Hardware Certification Program and be “Designed for Windows” certified. That rule also specified that PC manufacturers had to provide a way to turn it off. Microsoft no longer requires (as far as I dug) that PC manufacturers give the option to turn off secure boot.

Secure boot begins in hardware with a Trusted Platform Module (TPM) on the motherboard. A TPM is hardware that securely stores cryptographic information such as security certificates and encrypion keys. A TPM is designed to never release this sensitive data. They allow for remote attestation to determine if the initial stage firmware has been modified. This chain of cryptographic verification continues up the stack. Windows will only boot if every layer is certified to be unmodified. A properly implemented system like this makes it mathematically impossible or at least intractable to run sofware that has been modified by someone malicious. Sure you can disable this security feature, but I don't believe you should without a good reason. I don't believe installing a driver for microcontroller is a valid reason.

What Changed?

I recently finished up a project that required a new driver. A customer or two mentioned that it didn't work on Windows 8. That's not okay with me; at least not if I had the support to fix it. I use OS X, Linux, and Windows 7, probably in that order. I'd never really run into the issue. The drivers build in to the OS for the POSIX systems just work. In Windows 7 you get an error saying that the driver isn't signed. I know the driver came from a trusted source and why I was installing it. That's not a big deal to ignore. Around 10 steps with multiple reboots to make my system less secure before that last 'uncomfortable' step is a bigger deal to me.

Unsigned driver warning

Unsigned driver warning

The process of signing a driver is somewhat expensive and time consuming. It's a real barrier to tiny companies. We have to sell a lot of RedBoards to cover the cost. Thankfully management here agreed with me that the customer experience was worth the investment. The issue was relatively new. People had only been seeing it for around 3 years, or like myself, never. The issue also had a workaround. It had grown to be an issue with over 20 poducts at least for a period of time. Partners and collaborators had started signing their drivers. It appears that Arduino waited a year and a half to sign their Windows 8 drivers and they (LLC) are arguably a software company.

SparkFun Electronics now owns an Extended Validation (EV) code signing certificate. That cert along with a Microsoft cross-signing ceritificate, the Windows Driver Kit, and a few custom batch scripts now allows us to create and sign security catalog files (.cat).

The missing component in the previous paragraph is an .inf file. These are text files containing all of the information that the device installation components need to install a driver. Basically it tells Windows all of the settings and files required for a driver. Once the inf file has been processed and a signed cat file has been generated, Windows will trust and use the driver. You can right click on the inf and select install, or you can have the OS find the driver information in the device manager. Any of the tools or methods that you may use to install drivers should work.

Install menu option

Right click on the inf to install the driver

Much more tempting to click 'Install' near the words 'trust software' than to click 'Install this driver software anyway', right??

Signed driver install dialog

Driver signed by Spark Fun Electronics Inc

A few drivers I wrote basically from scratch. Others were simply signed by certificates that don't meet the requirements of the last 3 releases of Windows. Those I simply resigned with a valid certificate. They should behave exactly the same other than be trusted by Windows. As with any software release by any company, the general public is likely to be able to find bugs or break things the engineering team never imagined possible. If you have any issues, please let us know so we can fix them.

comments | comment feed

Recovering a bricked CC3D board using a Bus Blaster

via Dangerous Prototypes


Angus describes on his blog how he used the Bus Blaster to recover a bricked CC3D board:

A few months ago I went to upgrade my OpenPilot CC3D board an something went amiss and I ended up trashing the bootloader. I didn’t have a SWD dongle to reprogram it with so its been collecting dust. I just purchased a v3 bus blaster for a different project I’m working on and it has a SWD firmware so I thought I’d try and recover the CC3D. Below are the steps I used.

More details at Angus Ainslie’s blog.

The Bus Blaster is a high-speed JTAG debugger for ARM processors, FPGAs, CPLDs, flash, and more. You can get a Bus Blaster v3 for $34.95 at Seeed.

USB Infrared Toy free PCB build

via Dangerous Prototypes


Kuba Tyszko built a free USB IR Toy PCB. With the USB IR Toy you can use a remote control with your computer, view infrared signals on a logic analyzer, capture and replay remote control buttons.

If you build a free PCB we’ll send you another one! Blog about it, post a picture on Flicker, whatever – we’ll send you a coupon code for the free PCB drawer.

Get your own handy Bus Pirate for $30, including world-wide shipping. Also available from our friendly distributors.

Barrel o’ Fun: Arcade machine barrel table

via Raspberry Pi

What do you do if you are given a big old wine barrel? You could make it into a twee garden planter; go over Niagara Falls in it; or cut off the end and make a secret passage like in Scooby Doo. Or you could do the obvious thing and build a Raspberry Pi-powered arcade machine. Matt Shaw did just that. Arcade games, wine and Donkey Kong style barrels—three of our favourite things in one.

The arcade machine in all it's barelly glory

The arcade machine in all it’s barelly glory

The machine itself has the benefit of a sit-down cocktail cab (you can put your drinks on top) with the standup advantage of being able to jostle your opponent. It’s a nice clean build—deliberately low tech—wired using crimps and block connectors with no soldering. The Raspberry Pi runs the excellent PiPlay, an OS for emulation and gaming.

The other great thing about this project is its scrounginess. Reusing and repurposing makes us happy and this whole project does just that: an unloved 4:3 monitor, free table glass from online classifieds and an old barrel. The main costs were the buttons, joysticks and wiring and the whole build came in at around £90.

Circuit testing at it's finest!

The circuit tester is quite brilliant

Although we’ve blogged about Pi-powered arcade machines before (we have two in Pi Towers, we like them, OK? :)) the point is that if you have a Pi lying around then you can make a games machine out of almost anything. For not much money. (And as someone who spent every Saturday feeding their pocket money into arcade machines in seedy arcades in Southport, that’s an amazing thing.)

The post Barrel o’ Fun: Arcade machine barrel table appeared first on Raspberry Pi.

A JTAG/XSVF Library for Arduino

via Arduino Blog


Marcelo Jimenez developed a library to use an Arduino as a JTAG programmer. Basically a Python script uploads a XSVF file to an Arduino which interprets it and performs the necessary JTAG manipulation in order to do the programming.

The project is pretty simple because it just uses  a few resistors and some wires and the library is included in the Arduino library manager or you can check it  on Github.

He also wrote an article to explain some JTAG, SVF and XSVF basics:

 I have recently felt the need to incorporate a JTAG port in a project to program a hardware that contained a CPLD. The idea was to both program it and perform some integrity tests on the board. I imagined something using pogo pins, to make it easier and quicker to test everything. I would also write the necessary test routines and generate some kind of report.

With this objective in mind, I have decided to design an Arduino shield to do the job. The testing routines were not really a big deal. And I was sure I would find some JTAG library for Arduino ready to be used. That was not the case.

There were some projects using Arduino to control a JTAG TAP (Test Access Port), but they were all incomplete. And I had no idea what was really JTAG. So I had to study a little bit to make things work for me.

In the end, the challenge proved enlightening. There were some caveats, both from hardware and from software. I’ll try to address them in this article.

Continue reading on his blog.