Logistics Difficulty – Why I Try Avoiding Newark

I’ve spent a long time ordering parts from all over… while my #1 choice is always Digi-Key, I’ve used many of the others. Newark is often cheaper so I’ve done my share of ordering through them, but probably about 25% of orders have some sort of issue. This blog post is basically just a summary of those issues, as I’m curious if others have come across them too. Or maybe I’m just spoiled with Digi-Key, and everyone else fails to live up to them.

It’s possibly worth noting I’m ordering moderate amount of stuff ($6K-$15K/year for past two years from Newark) directly, so don’t think issues are only because I’m ordering a few resistors/capacitors. It’s far from a nice large production customer, but I’d think it might be enough volume to vaguely care.

Website Issues – Login, Cart Changes

For some reason there’s always been issues with the carts. When I login after adding stuff it seems to sometimes empty the cart, sometimes it adds a bunch of old parts into it. Most recently they dropped a discount code which cost me $60. So be sure to carefully double-check cart contents, as I’ve also accidentally ordered higher quantity than anticipated since it doubled-up (oops).

Shipping Roulette

Like Digi-Key, Newark likes to claim they will ship stuff out same-day before some cut-off. Unfortunately for me Digi-Key’s shipping is always 2-day to me (I guess due to location of Fed-Ex depos), but Newark’s is often 1-day. This means I’m forced to use Newark when I need stuff tomorrow, despite my love for Digi-Key.

But that’s not as easy as you might think. To begin, submitting an order before the deadline doesn’t mean it will ship that day. I’ve been told a few times (after calling to figure out how orders don’t appear to be shipping in time) that it has to be processed, meaning your credit card or account is charged before the cut-off. How does that happen? I have no idea. Basically after submitting an order you’ve got to ensure you get the final confirmation (not the auto-confirm email). Many times I’ve had to call customer service who tells me the credit-card processing was delayed for unknown reasons, which causes you to miss the cut-off even if the order is submitted several hours before it.

Newark also decided to change default shipping at one point. They used to only offer next-day shipping, so when you checked out you’d get the order the next day (pending issues I mentioned before). But then they changed the default to “UPS Ground” shipping to Canada which takes several days (3-5). Initially you couldn’t even pick air shipping online, and had to call in(!).  They’ve fixed that issue so if you’re careful to select “air” it should work, although you still don’t get a price quote on shipping until the order ships (even though it’s normally a reasonable flat-rate of like $12-$20). So it’s all a bit of a gamble… unless you want to read through every time, you’ve got to hope Newark hasn’t changed their shipping policy on every order, and when they do you find out because your parts are late.

Packing Insanity

Newark’s packing is always interesting. They shipped my Metcal MX5210 (~$1000 CAD so not something you want damaged/lost) in the original unsealed (but closed) cardboard carton . Basically the friction fit was keeping the cardboard flap sealed, as it tumbles through UPSes various belts:

Note I’d also ordered a METCAL unit from Mouser (so almost same box) – they had taped the internal METCAL box closed, and shipped it inside of another box.

Most of the time orders are shipped without a lot of sense put into things. Crystals were just in a bag (as shipped from manufacture – so it’s not like someone repacked them) inside the main box for example, but then some pin-headers will be put in a bag in a padded envelope.

They managed to nick this ATMega328P when (I assume?) cutting a tube to length:

For the most part it’s just cost I eat – nothing was enough to really matter long-term, but it’s clear a lot of their cost savings come from making customers eat these costs (who the hell is going to waste their time RMAing a $5 chip?). I guess I collected enough hassle to make a blog post at least.

So there you go – a quick run-down of some stuff to watch out for. Sometimes items are only stocked at Newark, so I don’t worry too much about it. But it’s always frustrating as Newark is so close to being good, but then has a few easy-to-fix issues that hold it back. Maybe one day it will improve, until then I’ll keep with old reliable Digi-Key who has never failed me!

 

 

Philips Hue, AES-CCM, and more!

This is just a quick blog post to update you on some rather interesting research that will be coming out led by Eyal Ronen. At Black Hat USA 2016 I did some teardown of the Philips Hue system, and described the possibility of a lightbulb worm.

Check this landing page which now has a draft PDF of what that became. This draft paper details how you can (1) recover the encryption keys used to encrypt the firmware updates, and thus encrypt/sign your own images, and (2) details a bug specific to a version of a range-checking protocol which allows reflashing of bulbs over longer distances. The end result is this basically solves all the roadblocks I had identified as stopping the lighbulb worm from actually happening [NB: the distance-check bug has been FIXED already in firmware updates which solves this specific spreading vector].

To me the most interesting part is a demonstration of side-channel power analysis being useful for breaking a rather good encrypted bootloader. To be clear the Philips Hue does a great job of implementing a bootloader on an IoT device… it’s one of the better I’ve seen, especially considering we are talking about a lightbulb. But it’s very very difficult to hide from side-channel power analysis and other “hands on” embedded hardware attacks, instead it’s better (but more expensive logistically) to push the solutions to the higher-level architecture. If each bulb had a unique encryption key (maybe derived from the MAC address using an algorithm on a secure server if you don’t want to store all those keys) it would provide an excellent layer of defense.

I’m working on making a description of the AES-CCM attack, which will be posted to the wiki page.

 

Q: What does that mean to someone using Hue, is it safe?

A: Philips released a OTA update to fix the bug that allows spreading over longer distances (October 3rd update). This is a great example of a fast response by a company who takes this stuff seriously. Basically – if I was choosing a smart light platform, I’d probably use Hue (I have a few of them in my house too).

 

Q: What’s power analysis?

A: This isn’t a FAQ type answer – but you can see an intro video I made. Basically we use tiny variations in power consumption of a device as it’s running to determine information about secrets held within the device.

 

Q: What if I want more information?

A: Please contact Eyal for more details, if you want to discuss specific questions, etc. Note the Philips-specific details (such as scripts, keys, etc) will never be released, please don’t ask for them.

 

Q: Does a worm exist?

A: NO. It would be extremely reckless to make such a worm, as it would be VERY hard to contain the spread should you have a bunch of Hue devices around you. Instead that research paper demo’d all the pieces, but stopped short of putting them together (we wouldn’t want a criticality accident).

Philips Hue – R.E. Whitepaper from Black Hat 2016

At Black Hat 2016 I presented on some reverse engineering of the Philips Hue (also see my other post about getting root on it, which was part of that presentation).

If you were at the talk, you would have also seen mention that you’ll want to keep your eyes out for future publications by Eyal Ronen. You can see his website for more research related to the Hue as well, and follow him on twitter @eyalr0. He’s been doing some work in parallel that I think will do more than just R.E. the bulbs (as I did), and actually bring some of my `possible’ attacks to become real proof-of-concepts.

Summary of the work (to make it clear):

  • I did NOT make a worm. The title was a question someone asked me, and the talk is about the security of the Hue.
  • The mention of a possible ‘Long Range Take Over’ was new/unreleased research by Eyal Ronen – do not credit me with that. It’s part of a larger research publication that will get released at some point.
  • Philips did a rather good job (all things considered). The only trade-off I really call out is reuse of encryption keys across all FW updates for all devices, which is basically what makes a theoretical worm possible.
  • Rooting the Hue (earlier post) is a local attack and very nice for hardware hackers. There are unique root passwords which is a great security step, so far I haven’t found flaws in the Hue Bridge 2.0 besides that.
  • There’s a lot of “interesting vectors” which the talk goes over. Given enough time some of them may give, but it’s a question of who is motivated enough to spend a lot of time on them.

You can get the full slides here too:

Philips Hue Reverse Engineering (BH Talk ‘A Lightbulb Worm?’) Slides [PDF, 8MB]

Here’s a copy of the very large whitepaper I wrote too:

Philips Hue Reverse Engineering (BH Talk ‘A Lightbulb Worm?’) Whitepaper [PDF, 5MB]

This whitepaper is a bit of a ‘data dump’ and ~48 pages of random stuff. But useful if you are interested in pushing this further!

Black Hat Slides – PIN-Protected HD Enclosure / MB86C311A Research

This is a quick post to link to slides from my Black Hat USA 2016 work.

This work stands directly on the work done by Joffrey Czarny & Raphaël Rigo presented at HardWear.io last year (2015). They discovered the issues w.r.t. the stream-mode cipher being used by all manufactures on the MB86C311A, and the fact that secrets are stored on the HD itself. Their work is available at:

They have some newer work coming out which looks to be very interesting, so please keep your eyes out for that. Anyway onto my stuff. The following is a link to my slides:

Brute-Forcing Lockdown Harddrive PIN Codes [Slides]

 

Getting Root on Philips Hue Bridge 2.0

This post will briefly show you how to get a root console on the new Philips Hue Bridges (the square ones). It’s rather easy, the only special tools you require are a USB-Serial cable & a torx screwdriver.

P1080978

There’s a video with full details, this post is just the specifics if you don’t want a very boring walk-through:

  1. For the serial cable (a standard 3.3V type one, DO NOT use a 5V cable), there is a 6-pin header along the bottom. Pin ‘1’ has a square footprint, and counting from pin 1 the connections are:
    Pin 1 = GND
    Pin 4 = RX In (connect to TX Out of your serial cable)
    Pin 5 = TX Out (connect to RX in of your serial cable).

    P1080980

  2. The bottom left-corner of the 2-row header is GND. You’ll have to short that with a wire to the following test point:

    P1080981
    This test-point is shorted to GND with a paper-clip or wire. Click image for full-sized to see in better detail.
  3. To get the system working, check you are getting boot messages. Now, restart the system and after you get a bit of output, short the pin. You might see some output like this:
    U-Boot 1.1.4 (Sep  8 2015 - 04:08:21)
    
    bsb002 - Honey Bee 2.0DRAM:  
    sri
    Honey Bee 2.0
    ath_ddr_initial_config(195): (16bit) ddr2 init
    tap = 0x00000003
    Tap (low, high) = (0x8, 0x22)
    Tap values = (0x15, 0x15, 0x15, 0x15)
    64 MB
    Top of RAM usable for U-Boot at: 84000000
    Reserving 214k for U-Boot at: 83fc8000
    Reserving 192k for malloc() at: 83f98000
    Reserving 44 Bytes for Board Info at: 83f97fd4
    Reserving 36 Bytes for Global Data at: 83f97fb0
    Reserving 128k for boot params() at: 83f77fb0
    Stack Pointer at: 83f77f98
    Now running in RAM - U-Boot at: 83fc8000
    Flash Manuf Id 0xc8, DeviceId0 0x40, DeviceId1 0x13
    flash size 0MB, sector count = 8
    Flash: 512 kB
    *** Warning *** : PCIe WLAN Module not found !!!
    In:    serial
    Out:   serial
    Err:   serial
    Net:   ath_gmac_enet_initialize...
    Fetching MAC Address from 0x83febe80
    Fetching MAC Address from 0x83febe80
    ath_gmac_enet_initialize: reset mask:c02200 
    Scorpion ---->S27 PHY*
    S27 reg init
    : cfg1 0x800c0000 cfg2 0x7114
    eth0: 00:03:7f:11:20:ce
    athrs27_phy_setup ATHR_PHY_CONTROL 4 :1000
    athrs27_phy_setup ATHR_PHY_SPEC_STAUS 4 :10

    Which will then fall back to a prompt:

    ath>

    Good news! We can now get everything working for you. You can print the existing variables if you wish:

    ath> printenv
  4. Set a boot delay such we can enter the menu without the boot hack:
    setenv bootdelay 3

    Check it works with

    printenv bootdelay

    and confirm you get a line like this:

    bootdelay=3

    Finally, save the setting with:

    saveenv

    You can now reset the system (use the ‘reset’ command), and confirm there is a count-down that gives you time to hit “enter” and get this prompt again.

  5. Now let’s fix the root password. Before doing this, I suggest you keep a copy of the old value:
    printenv security

    This would let you restore things back to default. Then the following will set the root password to ‘toor’:

    setenv security '$5$wbgtEC1iF$ugIfQUoE7SNg4mplDI/7xdfLC7jXoMAkupeMsm10hY9'

    You may have to copy this into notepad first to ensure it all fits on one line! The quotes are critical here. Again check it works with printenv, then type saveenv to store things to disk.

    If you want your own password, simply use the ‘mkpasswd’ command in Linux to generate an appropriate string.

  6. Once again reset the board – assuming you used saveenv, that root password will be used by the system now. You should be able to log in with root/toor!
  7. Once you are in, there’s a few changes you’ll want to make. We’ll edit the file /etc/rc.local:
    # vi /etc/rc.local

    And add the following:

    iptables -I INPUT -p tcp --dport 23 --syn -j ACCEPT
    telnetd

    This will open the telnet port & start the daemon on boot. Write the file and quit with :wq. You may also want to add the /etc/rc.local to the /etc/sysupgrade.conf file to avoid it being overwritten in the future.

    See the comments below – someone found a way to get ‘dropbear’ to allow root login too. This requires usage of a different password hash, but it’s great as SSH is much nicer to work with than telnet!

  8. Try using telnet to connect now. You can find the IP of the bridge using ifconfig, but you can also get it through the Hue app.You can also try using “Philips-hue.local”, which I’d first check via ping to see if it resolves:
    ping Philips-hue.local
  9. I’ve done the 25-July-2016 update without issue too (after first rooting the hub with an earlier version). I’ll continue to update this as updates happen.

BONUS – How did I figure this out?

The “bomb out to uboot prompt” is a known bug. Once in the prompt, I could edit the bootarg command with this:

setenv std_bootargs 'board=BSB002 console=ttyS0,115200 ubi.mtd=overlay rootfs=/dev/mtdblock:rootfs rootfstype=squashfs noinitrd init=/bin/sh';

This gives me a shell which doesn’t require a login. But many things are broken/disabled in this mode. It was however enough to find that there is another script that runs on startup which uses the uboot env variable, and copies it into the shadow file for the root password.

With this knowledge it’s easy to use mkpasswd to make an appropriate shadow file entry. Easy!

I also checked with two different Hue Bridge v2.0 devices. They contained different root passwords (at least different salts). I’ve been told the root passwords are indeed unique per device, which is a good step to stop someone from attacking your virgin Philips Hue 2.0 bridge.

As an interesting note – other people have also discovered this independently of me. Between writing this post & actually linking it from anywhere (i.e., so you could actually find it) pepe2k figured out the same thing on a forum post.

As well someone else did this same “overwrite root” attack already, but had used an external programmer to write the FLASH memory chip:

So it’s worth considering that many devices may be broken even if there isn’t some fancy Black Hat talk or otherwise. Most of the attacks (such as this one) are fairly well-known and pretty basic.

UPDATE: At DEFCON 24, I guess someone gave this type of attack a marketable name. You can see the idea called pin2pwn here.

A Low-Cost X-Y Scanner using 3D Printer

This summer, our summer intern Greg d’Eon made a quick project to build a X-Y Scanner from a 3D printer (by ‘quick’, I mean it took him less than 2 days!). You can see the source code up on GitHub. Anyway, 3D printers are very nice as they have fairly high resolution and fairly low cost. Here’s a quick video:

We’re using it to measure EM emissions frequencies over a PCB, but you could also use this for side-channel emissions, or fault injection. While the resolution might not be high enough for getting at specific features on a chip surface, it can still be used for general positioning.

With your EM emissions, you can graph X-Y vs. amplitude – here I’ve constrained the range to get an idea where the 96 MHz emissions are concentrated. Probably more interesting would have been to use a 2D plot with colour overlaid over the PCB design:em_plotYou can also do things like plot frequency vs. position with strength of the signal given by color. In the following graph the X position is fixed, and only the Y position is varied. You can see here the 96MHz oscillator of the SAM3U microcontroller on the ChipWhisperer-Lite for example:

650MHz_05

 

Low-Cost SMD Soldering Setup

The following blog post shows some details of my SMD soldering process. This was based on a larger video I did (linked below) showing the entire soldering process.

Video of Soldering Setup

The following shows me soldering a complete board with BGA device.

Equipment Used

In the above video, there are several pieces of equipment used. The following shows you some of the important ones.

Reflow Oven

I’m using a T962A reflow oven. I recommend this over the T962, which is a smaller version. The T962A has 3 heat lamps so has a more even heat distribution. Be aware you can’t use the full surface area – about the middle half I find is successful, but depends a little on complexity of the PCB.

I specifically purchased mine from this seller on AliExpress, check other sellers as prices change over time. You might turn it on quickly to confirm it works, but before doing much there are some important fixes:

  • Removing masking tape, replace with Kapton (Polymide) tape. See instructables post for details.
  • Fixing missing ground connections. Some versions have poor grounding between the outer (metal!) case and the wall plug. See the wiki page for a photo of this fix.
  • Updating the firmware and adding a cold-junction sensor. This is the most complex task, and requires soldering a DS18B20 to the mainboard, then using a USB-Serial adapter to reflash the firmware. See the front page of the T962-Improvements Github Repo, which has links to the required soldering. There is also an optional fix to reduce the very noisy small fan.

Fume Hood

I built a fume hood out of the following:

  • 2×4’s for frame.
  • Thick plastic drop-sheet.
  • Powerful vent booster fan with variable speed control.
  • Active charcoal oven range hood filter (mounted in top of fume hood).
  • Active charcoal filter for car cabin (mounted in cardboard box used as exhaust).

You can also improve one out of a range hood from an oven. See video for general fume hood construction.

Manual Pick-n-Place

FIG4

This requires three things:

  1. Vacuum pump, which you can make from a Tetra Whisper pump (see instructables link). Get some of the nice silicon tubing at the same time (like $3 from Amazon).
  2. Syringe with hole drilled into body. You can get syringes (don’t need the pointy bit!) from pharmacy, or order from Newark/Digikey. When you cover the hole, you force the vacuum through the tip, picking up the part. Release your finger from the hole to drop the part. See the above video for details.
  3. The tips for pick and place, which are “Luer Lock” needles bent slightly (for small parts) or commercially available tips (for larger parts).

The tips are the only somewhat tricky thing. I had a good selection from a previous SMD picker tool, something like this kit for example (which is Chip Quick Inc. part #V8910). These tips are actually the same “Luer Lock” that fits into syringes, check E-Bay for cheaper kits:

V8910 Chip Quik Inc. | V8910-ND DigiKey Electronics

You can also buy Chip Quik Inc part #VCS-9-B which has a bunch of these tips. It’s not the cheapest way, but if you are in a hurry will do! But all of these tips are for larger parts (i.e. maybe SOT23-3 at smallest). If you get into chip resistors, you need to go smaller.

For the small parts, you can bend “needle tips” slightly. You can buy packs of 50 from Digikey (search “Luer Lock”), but might find it cheaper to get individual ones from either medical supply places, or buying products which use them. For example some static-safe squeeze bottles come with a few tips. Again the expensive but easy route is Chip Quik part # SMDTA200 which has a bunch of different sized tips.

http://media.digikey.com/Photos/Apex%20Tool%20Photos/KDS2312P.JPG

Stencils

There is three main options for stencils:

  1. Laser cut stainless steel.
  2. Third-party cut Kapton film.
  3. Self-cut Kapton/Mylar film.

For laser-cut stainless steel, this can typically be ordered with your PCB fab. For example 3PCB.com and Dirty PCBs offer them very cheaply (~$25) when ordering PCBs. This is almost always the best choice, as the stainless steel stencils are very reliable and I’ve had great success with BGA devices.

You can also use third-party services to cut Mylar or Kapton film for you. OSHStencils is one example of a supplier.

Finally, you can make your own. You’ll need some practice to cut BGA parts, but it’s quite easy to cut stencils for less demanding applications. I have a previous blog post on my method.

I’ve been making my own stencils with this process for some time with great success.

FIG3

Solder Paste/Squeegee

I purchased the squeegee from Dirty PCBs. There are some other blog posts on squeegee options you might look at.

I generally just buy solder past from Digikey. Digikey does a great job of cheaply shipping to Canada, and the paste comes in an awesome cold pack thingy that keeps it cool during the trip. Chip Quik (again with the Chip Quik sorry, I don’t have a connection with them but just end up using their stuff!) sells some nice small syringes. Be aware it does have a shelf life… I’ve used past about 6-12 months paste that date, but you will eventually see issues (balling, flux separates). I recommend keeping to the suggested date to avoid giving yourself the headache of discovering your paste is bad after you’ve tried soldering your PCB. The cost of all your parts is probably a lot more expensive than the cost of replacing your paste.

 

SECT-2015 Talk Slides

On Friday at 14:15 I’m giving a talk about my open-source power analysis and glitching projected called ChipWhisperer at SEC-T. Here is some useful links if you watched the presentation:

See information about the entire project at www.ChipWhisperer.com too! Video will be posted online at some point too.

ESC SV 2015 – USSSSSB: Talking USB From Python

At ESC 2015 SV I gave a talk on using USB From Python, see the talk description here. This blog post is serving as a placeholder to allow me to update links to software used during the live demo.

For SuperCon 2015, there is a Project Page with these details too. You can also ask questions on the project page.

Download Slides

There is two versions of the slides. Use the SuperCon slides, but I left a copy of the ESC ones here in case you wanted the original for some reason.

Download Slides from Hackaday SuperCon 2015 (Newer Version for SAMD21) [PDF, 10MB]

Download Slides from ESC2015 (Older version for SAMD11) [PDF, 10MB]

Tools to Install

  1. Atmel Studio 6.2
  2. WinPython-2.7
  3. libusb-win32-devel-filter (NB: No need to open the filter install wizard when done)
  4. USBView

SAMD11 Errata

For ESC I used a SAMD11 device, which needs a bit of a hack.

There is a bit of an “oopsie” in the SAMD11 devices. This bug isn’t in the official errata yet, and I’ve been told it’s limited to engineering sample devices (which were used in some of the early dev boards).

Basically the 48MHz oscillator calibration byte is wrong, and you need to manually tune this. You’ll know this problem exists as the device won’t be detected by Windows:

usbbad

The work-around isn’t super-fun. First, use the programming interface to see the starting value of the DFLL48M_COARSE_CAL fuse:

pllbad

Next, search in the source code for reference to the dfll_conf.coarse_value variable. You will find where it is being setup, and you can override the value. Basically you have to experiment a bit to find a working value:

pllhack

 Reference Code

USB Test – Slide 87

import usb.core
dev = usb.core.find(idVendor=0x03eb, idProduct=0x2402)
print dev

If you get “None”, make sure you installed the “Filter Driver” using the LibUSB tools!

Control Endpoint Read – Slide 94

import usb.core
dev = usb.core.find(idVendor=0x03eb, idProduct=0x2402)
dev.set_configuration()

data = dev.ctrl_transfer(0b10100001, 0x01, 3<<8, 0, 4)

print data

If you get a “device is not functioning” error just skip this one…

Sending Output Report

import usb.core
dev = usb.core.find(idVendor=0x03eb, idProduct=0x2402)
print dev

dev.set_configuration()

data = [ord('1'), ord('1'), 0, 0, 0, 0, 0, 0]
dev.write(0x02, data)

Receiving Input Data (Press button to see change)

import usb.core
dev = usb.core.find(idVendor=0x03eb, idProduct=0x2402)
print dev

dev.set_configuration()

for i in range(0, 10):
    while True:
        try:
            test = dev.read(0x81, 8, timeout=50)
            break
        except usb.core.USBError, e:            
            if str(e).find("timeout") >= 0:
                pass
            else:
                raise IOError("USB Error: %s"%str(e))
     
    print test

 Full GUI Example

#Public domain - simple USB GUI Example by Colin O'Flynn

from PySide.QtCore import *
from PySide.QtGui import *
import usb.core
import sys

class USBForm(QDialog):
    def __init__(self, parent=None):
        super(USBForm, self).__init__(parent)
        self.setWindowTitle("ESC 2015 Demo")

        layout = QVBoxLayout()
        self.setLayout(layout)

        self.pbConnect = QPushButton("Connect")
        self.pbConnect.clicked.connect(self.con)
        self.isConnected = False

        self.pbLED = QPushButton("LED Blinking")
        self.pbLED.setCheckable(True)
        self.pbLED.clicked.connect(self.changeLED)
        self.pbLED.setEnabled(False)

        layout.addWidget(self.pbConnect)
        layout.addWidget(self.pbLED)

        self.swStatus = QLineEdit()
        self.swStatus.setReadOnly(True)
        layout.addWidget(self.swStatus)

        self.butTimer = QTimer(self)
        self.butTimer.timeout.connect(self.pollButton)


    def con(self):
        if self.isConnected == False:
            #Do USB Connect Here
            self.dev = usb.core.find(idVendor=0x03eb, idProduct=0x2402)
            self.dev.set_configuration()

            #Sync changeLED
            self.changeLED()
            
            self.isConnected = True
            self.pbConnect.setText("Disconnect")
            self.pbLED.setEnabled(True)
            self.butTimer.start(100)
        else:
            self.isConnected = False
            self.pbConnect.setText("Connect")
            self.pbLED.setEnabled(False)
            self.butTimer.stop()

    def changeLED(self):
        if self.pbLED.isChecked():
            #Send command to make LED on
            self.dev.write(0x02, [ord('1'), ord('1'), 0, 0, 0, 0, 0, 0])

            self.pbLED.setText("LED On")            
        else:
            #Send command to make LED blink
            self.dev.write(0x02, [ord('0'), ord('1'), 0, 0, 0, 0, 0, 0])
            self.pbLED.setText("LED Blinking")

    def pollButton(self):
        try:
            data = self.dev.read(0x81, 8, timeout=50)
            if data[0]:
                self.swStatus.setText("Button Pressed")
            else:
                self.swStatus.setText("Button Released")
                
        except usb.core.USBError, e:
            if str(e).find("timeout") >= 0:
                pass
            else:
                raise IOError("USB Error: %s"%str(e))


if __name__ == "__main__":
    app = QApplication(sys.argv)
    form = USBForm()
    form.show()
    sys.exit(app.exec_())