Security Ripcord

Cutaway Security Blog and Projects

RfCat Dongle Update for Docker IEEE 802.15.4 Toolkit on Windows 10

For the TL;DR crowd, Windows 10 was not recognizing any device flashed with older versions of RfCat firmware. Dominic Spill had already identified the issue and created a pull request to fix an extra byte in the USB descriptor length field. Turns out Atlas had originally added that extra byte so that older Windows versions would recognize the dongles. Thus, RfCat has been updated to address this issue and Windows 10 will now recognize devices flashed with RfCat firmware. The rest of this post will outline the process I took to track down this issue and help get Dominic’s pull request merged.

YS1 Running in Docker IEEE 802.15.4 Toolkit

Windows 10 Not Recognizing YARD Stick One

My problems started when I wanted to test the Docker IEEE 802.15.4 Toolkit. I plugged in my trusty YARD Stick One (YS1) and Windows 10 complained that it did not recognize the device.

Windows 10 USB Error

My initial research pointed me to a thread in the The YARDStick Mailing List Archives. Dominic Spill had looked into the issue and even updated his fork of the RfCat repo. To test this update I had to fall back to a Linux-based system.

Running RfCat on modern and updated versions of Linux (multiple distros) is relatively easy and there should not be any issues. However, when there are issues the error messages generated by hardware, such as dongle supported by RfCat, can be misleading or not helpful. This is primarily due to USB and hardware interactions with the operating system rather than debugging messages built into RfCat. Therefore we need to correlate debugging messages produced by the tool and the operating system.

Using Ubuntu I plugged the YS1 in and used the “lsusb” command to determine if the OS recognized the device. The “OpenMoko, Inc.” entry in the following textbox is the YS1.

1
2
3
4
5
6
7
8
cutaway> ~$ lsusb
Bus 001 Device 002: ID 0e0f:000b VMware, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 067: ID 1d50:605b OpenMoko, Inc.
Bus 002 Device 004: ID 0e0f:0008 VMware, Inc.
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Next I checked the “dmesg” command to see how the operating system responded when the device was plugged in.

1
2
3
4
5
6
7
8
cutaway> ~/Radio/rfcat/firmware$ dmesg | tail -7
[165181.541530] usb 2-2.2: new full-speed USB device number 29 using uhci_hcd
[165181.637358] usb 2-2.2: config 1 descriptor has 1 excess byte, ignoring
[165181.646099] usb 2-2.2: New USB device found, idVendor=1d50, idProduct=605b
[165181.646101] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[165181.646102] usb 2-2.2: Product: YARD Stick One
[165181.646103] usb 2-2.2: Manufacturer: Great Scott Gadgets
[165181.646104] usb 2-2.2: SerialNumber: 0000

The [165181.637358] usb 2-2.2: config 1 descriptor has 1 excess byte, ignoring entry demonstrates that there is an issue with the firmware configuration. It appears that Ubuntu handles this issue gracefully. This was confirmed by using RfCat to communicate with the YS1 and print the configuration of the device. The following textbox shows that the operating system recognizes the device as the YS1 and that the device is currently configured with a really old version of the RfCat firmware.

1
2
3
4
5
6
7
8
9
10
cutaway> ~/Radio/rfcat/firmware$ rfcat -r
'RfCat, the greatest thing since Frequency Hopping!'

[SNIP for Brevity]

In [1]: print d.reprRadioConfig()
== Hardware ==
Dongle:              YARDSTICKONE
Firmware rev:        0298
Bootloader:          CC-Bootloader     

Updating YS1 with Latest RfCat Firmware

As with any troubleshooting, I needed to get the YS1 updated with the latest version of the firmware. This process is done by moving into the firmware directory and running the make command associated with updating the YS1 via the CC-Bootloader: make installRfCatYS1CCBootloader. The Makefile is configured to force the dongle into bootloader mode so that the device can update. Unfortunately, as can be seen in the next textbox, the installed version of RfCat firmware did not force the device into bootloader mode.

1
2
3
4
5
6
7
8
9
10
11
12
13
cutaway> ~/Radio/rfcat/firmware$ make installRfCatYS1CCBootloader


==RfCatYS1CCBootloader.hex building==
sdcc -Iinclude -DBUILD_VERSION=`../revision.sh` --xram-loc 0xF000  --code-loc 0x1400 appFHSSNIC.c chipcon_usb.rel chipcon_usbdebug.rel chipcon_dma.rel bootloader.rel cc1111rf.rel global.rel cc1111_aes.rel -DYARDSTICKONE -DCC1111 -DUSBDEVICE
appFHSSNIC.c:459: warning 84: 'auto' variable 'chan_table' may be used before initialization
appFHSSNIC.c:464: warning 84: 'auto' variable 'chan_table' may be used before initialization
packihx <appFHSSNIC.ihx >bins/RfCatYS1CCBootloader.hex
packihx: read 501 lines, wrote 956: OK.
if [ ! -c /dev/RFCAT_BL_YS1 ] ; then ../rfcat --bootloader --force && sleep 1 ; fi ;
rfcat_bootloader /dev/RFCAT_BL_YS1 erase_all

Something is talking to the RfCat dongle (Modem Manager, most likely).  Retrying again after 5 seconds.  This can take a minute, please be patient.

Users of RfCat are most likely familiar with the “Something is talking to the RfCat dongle” message. While I do recognize this error message I did remove the Modem Manager package, just in case. Running the command again I realized that the package was not the issue. A little more research and reading the RfCat “README” file helped me understand that the YS1 was not being placed into bootloader mode. To accomplish this pin 7 and pin 9 on the YS1 debugging pads need to be jumpered. While this is outlined in the README file the following image shows how I jumpered these pins prior to plugging the device into the USB port.

YS1 Jumpered for Flashing

Jumpering these pins will force the YS1 into bootloader mode. Running the installation command should flash the device with the new firmware. Actually, it fails again, as can be seen in the following textbox.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
cutaway> ~/Radio/rfcat/firmware$ make installRfCatYS1CCBootloader

==RfCatYS1CCBootloader.hex building==
sdcc -Iinclude -DBUILD_VERSION=`../revision.sh` --xram-loc 0xF000  --code-loc 0x1400 appFHSSNIC.c chipcon_usb.rel chipcon_usbdebug.rel chipcon_dma.rel bootloader.rel cc1111rf.rel global.rel cc1111_aes.rel -DYARDSTICKONE -DCC1111 -DUSBDEVICE
appFHSSNIC.c:459: warning 84: 'auto' variable 'chan_table' may be used before initialization
appFHSSNIC.c:464: warning 84: 'auto' variable 'chan_table' may be used before initialization
packihx <appFHSSNIC.ihx >bins/RfCatYS1CCBootloader.hex
packihx: read 500 lines, wrote 955: OK.
if [ ! -c /dev/RFCAT_BL_YS1 ] ; then ../rfcat --bootloader --force && sleep 1 ; fi ;
Entering RfCat Bootloader mode, ready for new image...
Already in Bootloader Mode... exiting
rfcat_bootloader /dev/RFCAT_BL_YS1 erase_all
Traceback (most recent call last):
 File "/usr/local/bin/rfcat_bootloader", line 210, in <module>
   serial_port = serial.Serial(serial_port_name, timeout=1)
 File "/usr/lib/python2.7/dist-packages/serial/serialutil.py", line 282, in __init__
   self.open()
 File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 289, in open
   self.fd = os.open(self.portstr, os.O_RDWR|os.O_NOCTTY|os.O_NONBLOCK)
OSError: [Errno 2] No such file or directory: '/dev/RFCAT_BL_YS1'
[Errno 2] No such file or directory: '/dev/RFCAT_BL_YS1'
Makefile:357: recipe for target 'installRfCatYS1CCBootloader' failed
make: *** [installRfCatYS1CCBootloader] Error 255

In this case, the issue is demonstrated in the debugging message. Flashing the YS1 fails because the /dev/RFCAT_BL_YS1 is not created when the YS1 is plugged in. Luckily this is an easy fix. Creating a symlink to this device will allow the firmware update script locate the device and proceed with the process. The following textbox demonstrates this process.

1
2
3
4
5
6
7
cutaway> ~/Radio/rfcat/firmware$ ls -al /dev/RFCAT*
lrwxrwxrwx 1 root root 7 Jul  5 13:30 /dev/RFCAT_BL_D -> ttyACM0

cutaway> ~/Radio/rfcat/firmware$ sudo ln -s /dev/RFCAT_BL_D /dev/RFCAT_BL_YS1
cutaway> ~/Radio/rfcat/firmware$ ls -al /dev/RFCAT*
lrwxrwxrwx 1 root root  7 Jul  5 13:30 /dev/RFCAT_BL_D -> ttyACM0
lrwxrwxrwx 1 root root 15 Jul  5 13:30 /dev/RFCAT_BL_YS1 -> /dev/RFCAT_BL_D

With the symlink in place the firmware installation proceeds as expected. Note that the old firmware has to be cleaned up, using make clean, or the Makefile will not build the firmware with the new source code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
cutaway> ~/Radio/rfcat/firmware$ make clean

==== CLEANING STUFF UP ====
rm -f *.ihx *.rel *.hex *.sym *.asm *.lst *.lnk *.map *.mem *.rst

cutaway> ~/Radio/rfcat/firmware$ make installRfCatYS1CCBootloader


==RfCatYS1CCBootloader.hex building==
sdcc -Iinclude -DBUILD_VERSION=`../revision.sh` --xram-loc 0xF000  --code-loc 0x1400 appFHSSNIC.c chipcon_usb.rel chipcon_usbdebug.rel chipcon_dma.rel bootloader.rel cc1111rf.rel global.rel cc1111_aes.rel -DYARDSTICKONE -DCC1111 -DUSBDEVICE
appFHSSNIC.c:459: warning 84: 'auto' variable 'chan_table' may be used before initialization
appFHSSNIC.c:464: warning 84: 'auto' variable 'chan_table' may be used before initialization
packihx <appFHSSNIC.ihx >bins/RfCatYS1CCBootloader.hex
packihx: read 501 lines, wrote 956: OK.
if [ ! -c /dev/RFCAT_BL_YS1 ] ; then ../rfcat --bootloader --force && sleep 1 ; fi ;
rfcat_bootloader /dev/RFCAT_BL_YS1 erase_all
RC = 0 (OK)
rfcat_bootloader /dev/RFCAT_BL_YS1 download bins/RfCatYS1CCBootloader.hex
Writing :0614000002148B0240AD56  RC = 0 (OK)

[SNIP for Brevity]

Writing :034C82008200228B  RC = 0 (OK)
Skipping non data record: ':00000001FF'
rfcat_bootloader /dev/RFCAT_BL_YS1 verify bins/RfCatYS1CCBootloader.hex && rfcat_bootloader /dev/RFCAT_BL_YS1 run
*** warning! this version of CC-Bootloader can only read 16 byte blocks!
*** upgrade recommended!
Verifying 0003 bytes at address: 4C82 (OK) Skipping non data record: ':00000001FF'

After updating the YS1, unplug the device, wait a moment, replug device, and check firmware version using RfCat. The following textbox shows the OS does not produce the “extra byte error” and that the YS1 is running the latest version of the RfCat firmware.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
cutaway> ~/Radio/rfcat/firmware$ dmesg | tail -5
[291600.903503] usb 2-2.2: new full-speed USB device number 82 using uhci_hcd
[291601.016522] usb 2-2.2: New USB device found, idVendor=1d50, idProduct=605b
[291601.016525] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[291601.016526] usb 2-2.2: Product: YARD Stick One
[291601.016527] usb 2-2.2: SerialNumber: 0000

cutaway> ~/Radio/rfcat/firmware$ rfcat -r
'RfCat, the greatest thing since Frequency Hopping!'

[SNIP for Brevity]


In [1]: print d.reprRadioConfig()
== Hardware ==
Dongle:              YARDSTICKONE
Firmware rev:        0425
Bootloader:          CC-Bootloader

Test Updated YS1 on Windows 10

The final step is to test the dongle on Windows 10. As can be seen in the very first image of this post, this test was a success. Windows 10 now recognizes the YS1 and the CC1111EMK dongle that I updated at the same time. The image also demonstrates that VirtualBox can communicate with these dongles and provides Docker containers access to them via the virtual USB ports. Thus, RfCat on Docker IEEE 802.15.4 Toolkit works like a charm.

Multiple missions accomplished thanks to Dominic Spill, Atlas, and (of course) Michael Ossmann.

Go forth and do good things,
Don C. Weber (cutaway)