Monday, August 2, 2021

UHD USB Permissions in Ubunto 20.04 LTS

After installing libuhd and uhd-host on Ubuntu 20.04.02 LTS, I observed the following error after connecting a B205 and running uhd_find_devices:

[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5
[ERROR] [USB] USB open failed: insufficient permissions.
See the application notes for your device.

No UHD Devices Found

I found this thread while googling the error, which mentions udev rules. But rather than copy/paste rules from a three year old thread, I wanted to install the rules packaged with my version of uhd. I was able to find these in /usr/lib/uhd/utils/uhd-usrp.rules, and copied them in place as follows:

sudo cp /usr/lib/uhd/utils/uhd-usrp.rules /etc/udev/rules.d/10-uhd-usrp.rules

Works now yay.

[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5
[INFO] [B200] Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...

Friday, July 30, 2021

The DEFCON 29 Aerospace Village Badge

I saw a post about the Aerospace Village DC29 badge on twitter and decided to get one to play with, since the DC28 badge was so awesome. It's pretty clear that there are some secrets to unravel here, so I'm making this post to share my findings.

SPOILER WARNING: If you want to explore the badge yourself without my help, stop reading now!

First, let's have a look at the front and back sides and identify some interesting things.

I've annotated the image above to identify the interesting things, ignoring some obvious stuff like the batteries and power switch. It's a little hard to read the chip identification, but I see an ATMEGA88P in 32-QFP packaging [1]. If the label is to be trusted, [2] is probably an in-system programming header (which we may be able to use to extract the firmware) and [3] looks like a UART. There's also a 6-pin header labelled SA01.69, and I have no idea what that means yet. On the lower right of the back of the badge, there's also the writing "Have you connected MFDs?". I suspect in this context MFD means multi-function display.

The back of the badge also has a QR code, which contains the following URL: https://aerospacevillage.org/qr-test/, which displays a message about some password-protected content:

Over on the front of the badge we have some really cool art, which happens to contain 6 MFDs that are conspicuously made from solder pads. I've also annotated some blue LEDs [7] which are illuminated in the picture on the aerospace village website, but not on my badge. I'm guessing this is something that needs to be unlocked by interacting with the badge.

The UART

The UART on the back of the badge seemed like a good place to start, so I soldered some leads to it so that I could connect it to an oscilloscope (and maybe later to a connector of some sort). I connected the ground and tx leads from the UART to my oscilloscope and turned the badge on, and it seems like there's some data there.

Adjusting the time scale a bit, it looks like the symbol time is about 100us, which is really close to 104us, which correspond to a baud rate of 9600. The peak-to-peak voltage is around 5vdc, which is TTL level signalling not RS-232. I don't think I have USB serial adaptor that does TTL level signalling, so I'll connect this UART to a UART on an Arduino Uno and see what it looks like.

I wrote a really simple Arduino sketch that forwards data from the usb/serial port to a soft serial port on pins 2/3, so that I can interact with the badge UART.

#include <SoftwareSerial.h>

SoftwareSerial badge(2, 3); //rx, tx pins

void setup() {
  Serial.begin(9600);
  while (!Serial) {
    ;
  }

  badge.begin(9600);
}

void loop() {
  if(badge.available()) {
    Serial.write(badge.read());
  }

  if(Serial.available()) {
    badge.write(Serial.read());
  }
}

When I connected the badge to the Uno and turned it on, I saw this in the serial monitor:

Welcome to the Aerospace Village Airport (KASV)
Select from an available option to learn more:
	1. Airport Information
	2. Aerospace Village Information
	3. View current PIREPS
	4. About the Badge


Enter the desired menu number

Here are the responses that I see from the various menu selections:

1. Airport Information

Airport Information

KASV
Airport use:   Open to the public
Elevation: 203 ft
Time Zone: UTC -7 (UTC -8 during Standard Time)
RWY: 29/11
ATIS: 125.85
GND: 121.9
TWR: 119.35
DEFCON Approach: 120.45

Press ENTER to return to main menu

2. Aerospace Village Information

Aerospace Village Information

Build, inspire, and promote an inclusive community of next-generation aerospace cybersecurity expertise and leaders.
To learn more about the community, be sure to check out: aerospacevillage.org

Press ENTER to return to main menu

3. View current PIREPS

Current PIREPS

05 AUG 2021 0430Z: Pilot reported an "unidentified flying object" in the distance while on short final to RWY29.
05 AUG 2021 0435Z: Police reports of strange blue lights to the WNW of the airfield.

To report a PIREP please send an email to pirep@aerospacevillage.org with the subject line: "KASV PIREP"

Press ENTER to return to main menu

4. About the Badge

About the Badge

Designed by @cybertestpilot, github.com/daneallen/avBadge_2021
Artwork by Dan Ropp - flysurreal.com

Have you connected the MFDs in varying combinations?
Do you know what "Lost Comms" would look like from the control tower?
Are you familiar with Pilot Controlled Lighting?
Let us know what you think of the Badge!

Press ENTER to return to main menu

I mentioned before that the MFDs in the art on the front of the badge are done with solder pads, so I'm guessing that the message about connecting the MFDs in varying combinations should be interpreted literally.

MFDs

I numbered the MFD/solder pads on the front of the badge in the third picture in this post. Taking the advice from the About the Badge output, I measured the potential between each pad and ground with a multimeter and found the following:

1: 4.57v
2: 0v
3: 0v
4: 0v
5: 0v
6: 4.57v

The output above also mentions Pilot Controlled Lighting. If I understand correctly, this is a system that allows a pilot to control airfield lighting via radio. Using a jumper wire I played around with connecting the pads on the front of the badge and discovered that connecting either pad 1 or 6 to pad 3 toggles through four different runway lighting levels: off, low, medium, and high. I also discovered that if you connect pad 1 or 6 to pad 1 for about 3 seconds, a blue UFO will light up at the end of the runway. So cool! Interestingly, the runway lighting and UFO lighting settings seem to persist when you turn the badge off and on again.

Firmware

I soldered pins to the ISP connector onboard and was able to extract the ATMEGA88P firmware using a USB ASP v3 and a program called avrdude. The command below extracts the firmware and saves it to a file in Intel hex format.

sudo avrdude -c usbasp -p m88p -P usb -F -U flash:r:badge.hex:i

I'm still working on getting Ghidra to make something interesting of the program, but in the meantime I noticed the interesting string "Do you believe?" followed by what looks like ASCII art in the source. This string appears near the output that I pasted above, but it's not actually sent over the UART, so I'm guessing I have to do something to activate it.

I'll update this post as I learn more!

Friday, January 24, 2020

USB 802.11 chipset table

802.11AC USB adapters and their chipsets. I got tired of having to look this information up so I made a table.

Device Manufacturer Model Chip Manufacturer Chip Reference
Asus USB-AC53 Nano Realtek RTL8812BU ref
Cudy WU600 xxx xxx xxx
Cudy WU650 xxx xxx xxx
Cudy WU1200 xxx xxx xxx
Edimax EW-7822ULC Realtek RTL8822BU ref
EDUP AC1300 Realtek RTL8811 ref
EDUP EP-AC1607 Realtek RTL8811AU ref
EDUP EP-AC1686 Realtek RTL8812BU xxx
EDUP EP-DB1607 Realtek RTL8811AU ref
Inamax AC600 xxx xxx xxx
Linksys AE6000 MediaTek MT7610u ref
Linksys WUSB6100M Qualcomm QCA9377 ref
Linksys WUSB6300 Realtek RTL88xxAU ref
Maxesla ? xxx xxx xxx
Netgear A6210-100PAS MediaTek MT7612U ref
Netgear A7000-10000S xxx xxx xxx
Netgear A6100 xxx xxx xxx
nineplus ? Realtek RTL8812BU ref
Ourlink U631 xxx xxx xxx
Ourlink U636 xxx xxx xxx
Ourlink U1231 xxx xxx xxx
Ourlink U1291 xxx xxx xxx
QGOO ? Realtek RTL8811AU ref
Techkey AC1750 Realtek RTL8814AU+PA xxx
Techkey AC1200 Realtek RTL8812AU ref
TP-Link Archer T2U MediaTek MT7610U ref
TP-Link Archer T2UH (v2) MediaTek xxx xxx
TP-Link Archer T2UH (v3) Realtek xxx xxx
TP-Link Archer T2U Nano Realtek xxx xxx
TP-Link Archer T2U Plus Realtek xxx xxx
TP-Link Archer T4U (v3) xxx xxx xxx
TP-Link Archer T9UH xxx xxx xxx
Trendnet TEW-808UBM xxx xxx xxx
USBNOVEL USBNOVEL01 Realtek RTL8812AU ref

Sunday, January 12, 2020

Handy tshark filters for WiFi analysis

Sometimes Wireshark doesn't handle large pcap files gracefully, particularly files over a few GiB. Not to mention, using display filters to find exactly what you're looking for takes a long time (and isn't scriptable).

Enter tshark - the command-line version of Wireshark. I realized that, probably since I don't use it every day, each time I use tshark I find myself googling for the right arguments and filters to use. This post is a cheat-sheet for myself to remember some handy filters; Maybe someone else will find them useful too.

Generally if I'm using tshark, it's because I need to find some interesting packets within a much larger capture file. To do this, I have tshark read in the large pcap file, apply a filter, and write the filtered packets out to a new file using a command like this:

tshark -n -r input.pcapng -w output.pcapng -Y "filter"

Some tools don't yet process the pcapng format (e.g. aircrack-ng). You can use the -F flag to tell tshark to output the older format like this:

tshark -n -r input.pcapng -w output.pcap -F pcap -Y "filter"

Note: I use the -n flag to disable name resolution, including MAC OUIs. This is so I can more easily copy/paste MAC addresses with other tools.

The table below contains some display filters for specific use cases. Note that these will work with Wireshark and tshark.

Use Case Filter Notes
Beacons wlan.fc.type==0 && wlan.fc.subtype==8 && wlan.ssid==WCTF_01 Change ssid to target SSID
Probe Requests wlan.fc.type==0 && wlan.fc.subtype==4
EAPOL Handshake (wlan.ta==1a:a6:f7:31:91:48 || wlan.ra==1a:a6:f7:31:91:48) && eapol Set ta/ra to target AP MAC
Data Frames (wlan.ta==18:a6:f7:31:91:49 || wlan.ra==18:a6:f7:31:91:49) && wlan.fc.type==2 Set ta/ra to target AP MAC

I may add to the list above if I come across other common WiFi filters, but for now these are the ones I use most often.

Saturday, September 7, 2019

Fine, I'll enable IPv6

This is a follow up to my previous post on preparing my Ubuntu 19 system for travel. I've had to re-enable IPv6 on my Ubuntu laptop for a couple reasons which I'll discuss below. This wouldn't normally be post-worthy, except to help anyone else seeing the same errors due to disabling IPv6.

GPSd wants it

I've needed to run GPSd recently to work with a USB GPS device. Apparently GPSd really wants to bind to an IPv6 address. There's probably a way to make it not want this, but since I have other reasons to use IPv6 anyway, I'll just go ahead and enable it.

Just in case someone else comes across this error, here are the log messages that tipped me off:
gpsd.socket: Failed to listen on sockets: Cannot assign requested address
and
gpsd:ERROR: can't bind to IPv6 port gpsd, Cannot assign requested address

6LoWPAN

The 6 in 6LoWPAN means IPv6. There are some 6LoWPAN challenges at the Wireless CTF, and I'll need to be able to speak IPv6 to complete them (at least the challenges that require TX).

FYI: the device I'm using for 6LoWPAN is the openlabs 802.15.4 radio for the Raspberry Pi.

Do The Thing

Anyway, if you've disabled IPv6 via sysctl.conf, make sure the following lines are commented:
#net.ipv6.conf.all.disable_ipv6=1
#net.ipv6.conf.default.disable_ipv6=1
#net.ipv6.conf.lo.disable_ipv6=1

Sunday, July 28, 2019

Preparing Ubuntu 19 for travel

These are the steps I take to prepare my Ubuntu system for travel. It's far from a complete list, but I think these preparations will help reduce risks before using your system away from home.

I'm assuming you've already done the basic cyber hygiene stuff like FDE, strong passwords, lock-screen, etc.

1. Disable Avahi

Avahi is an MDNS service. Here's a description from avahi.org:
Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. This enables you to plug your laptop or computer into a network and instantly be able to view other people who you can chat with, find printers to print to or find files being shared.
Yeah, no thanks.  Let's disable that.
sudo systemctl disable avahi-daemon.service
sudo systemctl disable avahi-daemon.socket

2. Disable CUPS

I don't print from this computer so I don't need CUPS. CUPS runs a listening socket that I don't need and it also tries to start Avahi, so it's an unnecessary risk; Let's disable it.

sudo systemctl disable cups.service
sudo systemctl disable cups-browsed.service

3. Disable the NetworkManager connectivity check

By default, NetworkManager is configured to check for captive portals by periodically making HTTP GET requests. In Wireshark you'll a DNS query for connectivity-check.ubuntu.com, followed by an HTTP GET to http://connectivity-check.ubuntu.com/. This is a dead giveaway to anyone monitoring your traffic that your system runs Ubuntu and and NetworkManager.


This can be disabled by adding the text below to /var/lib/NetworkManager/NetworkManager-intern.conf
[connectivity] 
.set.enabled=false

4. Disable IPv6

I have no use for IPv6 on this machine, and since the addresses are ridiculous their presence makes traffic monitoring more difficult. I think the normal way to disable this is in the kernel via sysctl or sysctl.conf.

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1

Interestingly, these are already present at the bottom of my /etc/sysctl.conf, but my network interfaces still get IPv6 addresses. Why? If I check the values using sysctl, I can see that it's set for all, default, and lo, but not for my actual interfaces.

ted@a17:~$ sysctl net.ipv6.conf.all.disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 1

ted@a17:~$ sysctl net.ipv6.conf.wlp69s0.disable_ipv6
net.ipv6.conf.wlp69s0.disable_ipv6 = 0

The suggestion in this bug report to add a line to /etc/rc.local didn't work for me at first, but then I found a more complete solution here. Add the following to /etc/rc.local to disable IPv6 at boot time (and make sure the file is executable).

#!/bin/bash
# /etc/rc.local

/etc/sysctl.d
/etc/init.d/procps restart

exit 0

5. Disable geoclue

This service attempts to geo-locate the host system and shares that information with local applications (including web browsers) over DBUS. If that's not bad enough, it also sends MDNS queries looking for NMEA-0183 servers on the local network. Presumably this means it would connect to such a server if it found one?


I'm pretty surprised this is enabled by default (and more people aren't complaining about it).

sudo systemctl disable geoclue.service

6. Block outbound SSDP

Some applications use SSDP to discover things they can interact with on the network, like IOT TVs and Refrigerators and stuff. Chromium sends out lots of SSDP messages while it's running. Since this isn't a service that can be disabled, and I don't want to configure each application not to send SSDP, let's make a firewall rule to block outboung SSDP.


All the SSDP traffic I'm seeing from my machine has a UDP destination port of 1900. Execute the following command to add a firewall rule to block it.

sudo ufw deny out 1900/udp

7. Remove saved WiFi networks

This serves two purposes. First, to prevent your system from sending out 802.11 probe requests, which leak information about where you've been and the networks you've connected to. Second, to prevent your system from automatically connecting to any networks. To do this, we'll remove all saved network connections at boot time.

Add the following to /etc/rc.local to remove all saved 802.11 network connections at startup:

while IFS=\: read -r type uuid
do
    if [ $type == 802-11-wireless ]; then
        nmcli con delete uuid "$uuid"
    fi

done < <(nmcli -t -f TYPE,UUID conn)

Note: I adapted the above from this stackoverflow answer.

8. Make sure Bluetooth and WiFi are disabled at boot

Bluetooth is probably the bigger risk of the two, but let's play it safe and rfkill both at startup. Add the following to /etc/rc.local.
rfkill block all

9. Disable crash reporting

This step is probably optional, but like the previous steps it helps reduce the amount of information your system is leaking about itself.

sudo systemctl disable apport.service

There's probably more we can do to protect a Ubuntu system from threats while away from home. If I think of anything else I'll make a follow up post.

Sunday, June 23, 2019

TV WiFi Adaptor Hax

I was looking for a cheap 802.11ac USB adaptor based on an MT76 chip when I found some ZDGFMT7612U WiFi boards on eBay. The ZDGFMT7612U is meant to add networking capabilities to a TV, but it includes a USB interface and seems conveniently packaged, so I decided to see if I could it would work as a normal USB/WiFi adaptor for use with Kismet, etc.

The eBay item description read:
Sharp ZDGFMT7612U P/N: 1178206 Wifi Module Board for LC-55P6000U
Not super helpful, but the back of the board clearly shows the FCC ID 2AJVQ-ZDGFMT7612U.  If you didn't already know, the FCC equipment authorization database contains useful documents about electronic equipment authorized for RF transmission in the United States, including user manuals and internal photographs.
Using the FCC Equipment Authorization Search (EAS) I was able to find the exhibits for this device's authorization application, which include a user manual and internal photos (the search page is a little weird, and I ended up searching by the Grantee Code 2AJVQ and scrolling through the results until I found it).  The internal photos reveal that the ZDGFMT7612U is based on the MT7612U chip from MediaTek, and the user manual has a somewhat helpful pinout for the board's connector.
Looking at the pinout and the wiring harness that came with the board, it looks like pins 3-6 are the USB connection to the host, and pin 7 is the shield for USB cable.  Unfortunately only USB 2 pins are connected.  I de-pinned the pins I don't care about from the white connector going to the board, and spliced a USB A male connector to the other end.  All the colors matched up, so this was pretty easy.
When I plugged the resulting thing into a computer, nothing happened.  No smoke, which is good, but also no wireless device.  After some guesswork and some help from the folks in the Wireless Village Discord, I figured out that the WIFI_REG_ON pin turns on the voltage regulator that converts the 5 volts supplied by USB to the 3.3 volts required by the WiFi chip.  I used a 4.3k resistor to make a pull-up connecting pin 1 to the 5v pad on the board.

Note: The resistor value I chose probably isn't right, and there are probably better ways to do this, but I'm not an EE and it's working so far.  If you have any advice please leave a comment!
After adding the pullup, the device is seen by the Linux kernel and a new wireless interface is added using the mt76x2u driver.  Yay!

[758511.999389] usb 1-1: new high-speed USB device number 5 using xhci_hcd
[758512.150403] usb 1-1: New USB device found, idVendor=0e8d, idProduct=7612, bcdDevice= 1.00
[758512.150409] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[758512.150412] usb 1-1: Product: 802.11a㜵呃䴷NA
[758512.150415] usb 1-1: Manufacturer: MediaTek Inc.
[758512.150417] usb 1-1: SerialNumber: 000000000
[758512.323849] usb 1-1: reset high-speed USB device number 5 using xhci_hcd
[758512.500874] mt76x2u 1-1:1.0: ASIC revision: 76120044
[758512.534205] mt76x2u 1-1:1.0: ROM patch build: 20141115060606a
[758512.871760] mt76x2u 1-1:1.0: Firmware Version: 0.0.00
[758512.871761] mt76x2u 1-1:1.0: Build: 1
[758512.871762] mt76x2u 1-1:1.0: Build Time: 201507311614____
[758513.913630] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[758513.914392] usbcore: registered new interface driver mt76x2u

[758513.951582] mt76x2u 1-1:1.0 wlx40cd7a083350: renamed from wlan0

My next step is to do some performance testing against the venerable AWUS-036AC and see how well it works in monitor mode.  I think the small on-board antennas may put it at a disadvantage (I have no idea what the beam pattern for those things would look like).