This time we’re hurtling through the layers of technology that make a graphics tablet (pen tablet) work, from operating systems politics to electromagnetic induction. I’ll be looking closely at two tablets, the Wacom Intuos Pro and Huion H610PRO, and going into a full teardown on the Huion.
Continuing the adventures from Part 1, this video wanders along several tangential paths, trying to get some data out of this device worthy of reversing. This time we spend a bit more time in IDA looking for Z80 code, tinker with SCSI trying to break things, and we even do some necromancy in trying to get grumpydisk working.
If you missed Part 1: https://www.youtube.com/watch?v=_tQ-I_qFE0c
If you want to hack along, check out the contents of inquiry.bin from this episode: https://www.dropbox.com/s/y47v77f6mkmym32/atj331-inquiry.bin?dl=0
I was debugging a Bluetooth-related problem on a Windows 7 machine recently, and I found another great example of why sometimes you get what you pay for, even when buying something as nominally standardized and homogeneous as a Bluetooth adapter. It so happens that this machine was using one of these $5 adapters with the fake antenna:
That was the first thing I noticed about these adapters. The second was that each and every one of them had the same address, 11:11:11:11:11:11. Someone didn’t feel like paying for a MAC OUI.. or an EEPROM.
Anyway, back to the present… I had been noticing that sometimes when sending a file to my cell phone from a Windows 7 machine, it would time out. It didn’t happen every time, but it seemed to time out more often than not. I dig a little deeper, and it looks like the file transfer application (fsquirt.exe) is never even getting a chance to open a connection to the phone! It is timing out far before that even happens. What’s the deal?
To make sense of this, it helps to understand a bit more about how the Bluetooth stack works in Windows 7. First a big caveat: I do not work at Microsoft, nor do I have any confidential information about the inner workings of Windows. All I have, really, are informed guesses based on my observations and perhaps a little reverse engineering to satisfy my curiosity.
The main actors here are:
- fsquirt.exe — The GUI wizard which walks you through sending a file to a Bluetooth device. It lets you choose a device, then it sends the file via the standard OBEX protocol.
- bthprops.cpl — Technically this is a control panel, but for historical reasons it also implements the public API for Microsoft’s Bluetooth stack. This includes entry points for enumerating attached radios, inquiring for nearby devices, and setting up service discovery records for the local machine. Applications can link to this as a DLL.
- fdbth.dll — Microsoft’s applications, like fsquirt, actually don’t use the public APIs from bthprops.cpl to inquire for nearby Bluetooth devices. Those public APIs are synchronous: they don’t return until the Bluetooth inquiry is totally finished. It is of course much more user-friendly to display Bluetooth devices as they are discovered, and Microsoft’s apps do this by using an undocumented Function Discovery provider.
- bthserv.dll — Some operations in bthprops.cpl go directly to the bthport driver using device ioctls, but there is a system-wide service which maintains a database with the state of all known Bluetooth devices. It’s also responsible for maintaining local SDP records. The APIs in bthprops.cpl communicate with bthserv.dll via local RPC calls.
- bthport.sys — This is the kernel-mode driver which does most of the work. It receives remote name requests, inquiries, and many other operations in the form of ioctls from user-space code.
The important fact I learned while investigating this bug: Inside bthport.sys, there is a global FIFO queue of actions which contact remote devices. If anyone asks to read a device’s name, to perform an inquiry, or to establish an ACL connection with a remote device, it goes in this queue. From Microsoft’s perspective this probably simplifies handling unreliable Bluetooth radios quite a lot, since we never rely on the radio to handle more than one of these operations at a time. Additionally, Inquiry operations are rather heavy-weight, and depending on your link manager settings, you may not be able to do anything else while they’re in progress.
So, back to the hang. When I traced the communications between the USB dongle and the Windows 7 Bluetooth stack, I found this:
The setting: fsquirt has just finished the wizard pane where we’re looking for nearby devices. It notifies fdbth that it no longer needs to keep looking. But in its haste to prettify the UI as much as possible, it has already started asking for human-readable names for all of the Bluetooth devices within earshot. Those requests go into bthport’s queue. The fsquirt app wants to establish an ACL connection to my phone already, but it’s waiting in line behind one of these name requests.
In case you don’t have the Bluetooth spec memorized (I sure don’t), here’s a play-by-play of the USB log:
- OUT 05 04… — The PC asks the Bluetooth dongle to get a human-readable device name for one of the nearby devices.
- IN 0F… — Command is in-progress.
- (Over 20 seconds elapse)
- IN 03 0B 08… — Connection request finished, error code 08 (Timed out)
But wait! We never asked the device to create a connection! We asked it to read the other device’s name! This looks like a pretty grievous firmware bug in this decrepit little dongle. As we see below, Windows is pretty confused too. My “waiting” and “timed out” notes indicate the state of the fsquirt wizard. The timestamps aren’t saved in this log, but fsquirt is only willing to wait 10 seconds or so before giving up. It’s waiting on bthport, and bthport is waiting on any response, even a timeout, from the Bluetooth adapter.
And it keeps waiting, for 70 seconds. Why so long? It should never take that long for a Bluetooth device that’s actually present to respond. Well, actually it isn’t waiting on the remote device. It’s waiting on the radio itself. The radio is programmed to time out after a much shorter interval specified by Windows, in this case about 20 seconds. Windows is relying on the radio to implement this timeout. What we’re seeing here is an even longer failsafe timeout, to catch errors with the local radio. Like the one we just experienced.
When Windows finally gives up on waiting for our buggy radio to respond correctly to the remote name timeout, we can see it issue the next command. This time it’s the Create Connection command that fsquirt had been waiting on. But fsquirt is already long gone, and the user is already frustrated.
If we’re lucky, the user throws the buggy Bluetooth dongle out the window, not their PC.
This is a quick plug for a spiffy project that M. K. Borri (spiritplumber) has been building using my usb-fs-host object. He’s connecting an Android phone to a Propeller microcontroller, emulating the ADB debug protocol on the µC, and using this as a communication bridge in order to control robots from the phone. He has a video to demonstrate his progress:
This project is actually remarkably similar to the IOIO, but actually his was announced first 🙂 Both projects appear to be using a single-chip solution for USB, but on the IOIO that means using a PIC that has built-in USB, whereas on this project spiritplumber used my software USB implementation for the Prop.
Currently the IOIO is a $50 commercial product, whereas this Propeller project could be built for maybe $15. It’s possible the IOIO might get cheaper once the design is opened up in the future, but for now this might be a good alternative for anyone who wants to play with an IOIO but either can’t get their hands on one, doesn’t want to pay fifty bucks for it, or who wants something that interfaces well with other Propeller objects.
He’s been getting a bit discouraged by the lack of community response, so if you’re interested at all I’d encourage you to jump in and join the discussion! His project was just featured on Hack a Day, and there’s an active discussion thread over on the Propeller forums, including links to his source code releases so far.
After going months without a lot of time for working on my hobby projects, I finally had a few free days to work on debugging my embedded Bluetooth stack for the Propeller. I got it working well enough to demo a Serial Port Profile device, implemented using only a Propeller Demo Board and a $2 USB Bluetooth dongle.
I’d like to make a more detailed post about this once the project is a bit further along… but for now just a brief description and a couple teaser photos 🙂
This is one of those things that people have said was impossible, and I’ve wanted to try it for a while. I finally found an excuse. I wanted a way to build more cheap wireless networked devices. You can get bluetooth and wifi adapters that are microcontroller-friendly, but it’s a niche market so you’ll pay a lot. I wanted a way to use the $2 bluetooth dongles and $10 wifi adapters you can easily find online or at your local electronics shop. But these devices are all USB, and USB host controllers aren’t yet common on small hobbyist-friendly microcontrollers like the Arduino and Propeller. So, I decided I’d see if it was possible to implement a USB host controller entirely in software on the Parallax Propeller microcontroller.
Turns out that it is. This still needs more development before it’s generally useful, but it’s already showing potential. Of course there’s a long list of caveats on something that pushes the limits of both the Propeller and the USB spec, but none of them should be deal-breakers for most applications.
The Virtual USB Analyzer is a graphical tool for analyzing USB sniffer logs. It can do some basic protocol decoding, and it has a graphical timeline view which helps to visualize the latency and concurrency characteristics of USB traffic.
This release only adds a single feature, but it’s one that many people have probably been waiting for: support for Linux’s built-in usbmon sniffer tool.
With usbmon, tracing all USB traffic on your system is as simple as cat’ing text from a sysfs node to a file. It doesn’t have quite as many features as VMware’s low-level capture logs, but for most users (especially users debugging Linux USB drivers) this should be more than sufficient.
If you aren’t familiar with usbmon, the first thing to read is Documentation/usb/usbmon.txt from your kernel sources. That will tell you the basics, including how to capture raw data from the kernel. There are a few other simple front-ends for making this data more human-readable. If you’re using vusb-analyzer, those tools aren’t required. Just save the raw data to a file with a .mon extension, and hand that to vusb-analyzer.
This feature was a patch contributed by Christoph Zimmermann. Without his contribution, I no doubt would have procrastinated this release for many more years 🙂
Paul and I are leaving on a cross-country train trip next week, for Jen and Shawn’s wedding in Colorado. I’m sure the view will be great, and I’m bringing a handful of books- but Paul and I are geeks and we need our electro-doodads. If only we had a way to run our Nintendo DS and PSP for the ~30 hours that the trip will take…
I sifted through my stockpile of junk, and came up with this:
It’s kind of like a mega-size Minty Boost, or a heftier version of the Kensington power pack. The Minty Boost weighs in at about 6 Watt-hours, depending on the AA cells you use. The Kensington pack is rated at 7 Watt-hours, with a Lithium Ion battery. This brick occupies the middle-ground between the Minty Boost and a car jump-start battery, weighing in at 84 Watt-hours. It should run and charge a Nintendo DS for at least 30 hours.
It’s built almost entirely from junk that I had lying around the house: (Your house may vary.)
- 12 Volt 7 AH Lead-calcium battery
- Aluminum box, in my stockpile of project enclosures
- Receptacle end from a cigarette lighter extension cable
- DC-DC converter from an old Nokia phone charger (for a phone I no longer use). Swapped a resistor with a trimmer pot for 5V output.
- USB sockets from a dead 4-port hub
- Heavy duty wires and quick-disconnect plugs from a dead UPS
- Odds and ends: Switch, mounting hardware, fuse holder, wire nuts, foam weather-stripping, JB-Weld epoxy, heat shrink tubing, LED, resistors
Parts I had to buy at the local Fry’s:
- 10 Amp fuse (Pack of five for a few dollars)
- 12V 1 Amp lead-acid battery charger ($20)
- Cigarette lighter plug for the charger ($2)
Now here’s hoping that nobody thinks it’s a “hoax device”…
P.S. I’m still working on the Robot Odyssey DS port and in fact there are some interesting bits of UI working now- but I haven’t quite reached another blog-worthy milestone yet.
This is the latest geeky addition to our home decor. It’s a Kodak W820 digital picture frame, showing a graph of real-time temperature data collected from around the house: upstairs and downstairs, garage, outdoors, and even inside the refrigerator.
More photos on Flickr, implementation details below…
Most of my friends probably know that back in 2004, when I was still in college, I built a set of wireless temperature sensors. Each one is an Altoids tin containing a 9V battery, a Dallas 1-wire temperature sensor, PIC microcontroller, and a little 315 MHz AM radio transmitter. I built several of these indoor wireless sensors, plus one outdoor sensor which I built out of PVC pipe.
The PIC spends most of its time sleeping, but every 20 seconds or so it wakes up to read the current temperature from the 1-wire sensor. Most of the indoor sensors have the 1-wire temperature probe soldered to the side of the Altoids tin, for the best thermal conductivity. The refrigerator sensor has a length of 30-gauge wire that leads the 1-wire sensor itself into the fridge.
Every couple of minutes, each sensor transmits a burst of packets back to the base station. The base station is another piece of custom hardware: a matching AM radio receiver, some LEDs, and a TUSB3210 microcontroller to do protocol decoding and to interface back to a server machine over USB. In this case, the host machine is a little NSLU2 embedded Linux box which also acts as our home network’s file server.
The software running on the server machine has had a rough history. My original implementation was ridiculously complicated: The receiver unit connected to an NSLU2 embedded Linux box over USB. That machine ran a daemon, written in C, which listened for packets over USB and stored their contents in a remote MySQL database. The MySQL database was running on a more powerful server (a 1 GHz Athlon at the time) which had plenty of disk space. That server also ran a web application using mod_python, which pulled data from MySQL, generated graphs on demand using rrdtool, and generally looked really pretty.
My reasons were mostly historical. I wanted to save all of the temperature data (for another project I had at the time), so instead of sending data directly to a lossy RRD file, I just used rrdtool as a cache for the data I was about to graph. As you can imagine, if the cache ever had to be rebuilt, the server would come crashing to its knees. This implementation was plagued with performance and reliability issues.
So, I recently reimplemented a simpler server software solution. I hacked up the C daemon so that instead of writing to a MySQL database, it forks off an rrdtool process to store the data directly into an RRD database. Instead of generating graphs on-demand, I have a small update-graphs shell script which uses rrdtool to generate all of the graphs. This scripts is run from cron every 5 minutes. The resulting graphs aren’t nearly as intricate as the ones that my mod_python app used to generate, but anything looks pretty if you antialias it 😉
The digital picture frame
This frame is a Kodak W820, an amazingly featureful little gadget that I picked up at the local Fry’s for $180. It has an very pretty 8″ 800×480 display and a rather unique touch-based user interface. It also does a pretty ridiculously good job at playing video, considering it’s a picture frame.
But anyway, the real reason to buy this frame is for its Wi-fi connectivity. If you connect it to your network, you get a range of useful and “useful” services:
- The frame runs its own HTTP server on port 80, with a web interface you can use for managing settings. You can’t upload pictures via this interface, but it does mean that you can configure the picture frame entirely without using Kodak’s silly Windows software.
- It’s a uPnP media server and a client. The software that comes with it uses uPnP to browse an upload/download files on the frame’s internal memory or memory card, and the frame itself can use uPnP to stream images from your PC. This is a really interesting feature that could be exploited for more dynamic applications…
- It has a Flickr client. Yes, the frame itself actually speaks the Flickr API.
- There’s some fancy-pants Kodak online service, which looks like it’s probably little more than an RSS feed in disguise.
- And best of all, you can give it custom RSS feeds. Like, say, real-time temperature graphs!
The only snag I hit in setting this up was in trying to keep the frame from caching old versions of the temperature graph. It seems to ignore HTTP cache control headers, and the cache seems to be able to hold quite a nontrivial amount of image data!
The best solution I’ve found so far: Use the RSS <ttl> tag to force the frame to reload the RSS feed itself pretty frequently. Then, in my update-graphs script, I dynamically generate an RSS file which includes a timestamp in the URL and GUID for each image. This seems to do the trick.
I’m really interested in graphing my home power usage, using a receiver circuit based on the one I built for The Kilowatt Clock. I’m currently waiting for some parts from Digi-key, but I’ll definitely blog about this when it’s done.
If you’re at all interested in displaying real-time stats around the home or office, I’d definitely encourage you to play with this picture frame. It has some great hacking potential, and I’m really excited to see what kinds of uses others come up with.
From late 2005 to early 2007, I worked on the USB virtualization stack at VMware. We ran into all sorts of gnarly bugs, many of which were very hard to reproduce or which required access to esoteric or expensive hardware. To help with debugging problems both internally and with customers in the field, we added logging support to our virtual USB stack. Starting with VMware Workstation 5.5, if you set the right hidden config option we’d start dumping the contents of all USB packets to a log. It was a USB sniffer (like USB Snoopy), but built into the virtual hardware.
To make it easier to analyze the resulting logs, I started working on a GUI tool that could navigate through these giant log files. This tool proved to be really useful within our team at VMware, and we’d often ask customers on the beta forums to generate log files that we could analyze. I called this tool vusb-analyzer.
Well, it’s been a while, but I’m proud to now have the opportunity to release vusb-analyzer as open source software under the MIT license. This isn’t just a code dump- I removed the tool from our internal repository today, and all future development will occur in the open, in a Subversion repository on Source Forge.
Currently, vusb-analyzer is most useful for analyzing logs captured by VMware products. Indeed, this is a convenient way to debug USB drivers. You can attach your USB device to VMware Workstation, VMware Fusion, or the free-as-in-beer VMware Player, and it can transparently save a plaintext log of all USB packets that pass through. Debugging a driver in a VM is really convenient, and I find it quite useful, but I understand it’s not for everybody. If you already have a favorite USB sniffer tool, it’s easy to extend vusb-analyzer with a log format plugin so it can read other formats. We already did this once, to add support for the logs generated by our favorite hardware USB analyzers.
I hope vusb-analyzer turns out to be useful for the open source community, particularly to those who are working on Linux device drivers. To get started, visit the project’s web site:
Besides the usual introduction and download links, there is also a detailed tutorial with lots of shiny screenshots 🙂