Devices

Identifying devices is complicated since the unprivileged user cannot list the /dev directory. The approach we took was to analyze the applications and libraries in the recovery Firmware and recover /dev paths.

Loaded Device Drivers

We can view the /proc/devices proc entry and find the names and device numbers for the loaded drivers.

cat /proc/devices
Character devices:
  1 mem
  4 ttyS
  5 /dev/tty
  5 /dev/console
  5 ttyprintk
 10 misc
 89 i2c
 90 mtd
153 spi
249 nullconsole
250 bsg
251 iio
252 rtc
253 pwm-chardev
254 gpiochip

Block devices:
 31 mtdblock
259 blkext

Enabling Peripherals Devices

Even though the drivers have been loaded, the device nodes may not have been created yet. There is an unauthenticated Security Monitor IOCTL that can be called to enable the driver and this will cause some devices to become available in the /dev directory that otherwise wouldn't be there. The test app has a peripheral command to enable all devices:

> peripheral all
set 4:1 to 1
set 4:4 to 1
set 4:5 to 1
set 4:6 to 1
set 4:7 to 1
set 4:8 to 1
set 4:9 to 1
set 6:0 to 1
set 6:1 to 1
set 6:2 to 1
set 6:3 to 1
set 6:4 to 1
set 6:5 to 1
set 5:0 to 1
set 5:1 to 1
set 5:2 to 1
set 5:3 to 1
set 5:4 to 1
set 5:5 to 1
set 2:0 to 1
set 2:1 to 1
set 2:2 to 1
set 7:0 to 1

The IDs from above are device driver number:index number. The Security Monitor IOCTL uses its own ID mapping, not the device IDs, in /proc/devices. The following is the Azure Sphere device ID mapping:

enum azure_sphere_peripheral_type {
    AZURE_SPHERE_INVALID = 0,
    AZURE_SPHERE_GPIO = 1,
    AZURE_SPHERE_PWM = 2,
    AZURE_SPHERE_INT = 3,
    AZURE_SPHERE_UART = 4,
    AZURE_SPHERE_SPI_MASTER = 5,
    AZURE_SPHERE_I2C_MASTER = 6,
    AZURE_SPHERE_ADC = 7,
    AZURE_SPHERE_I2S_SLAVE = 8,
};

Disabling Peripherals

In addition to enabling, you can disable peripherals including UARTs. For example disabling the /dev/ttyS9 device (assigned to the built in networkd app) kills the host to device SLIP connection:

> nc 192.168.35.2 4444
===================================
Welcome to micro shell!
===================================
> peripheral 4 9 0
...

The host connection is now down and you need to reset the device in order to restore communications. This is also listed in Issues.

Device File Permissions

We cannot view the /dev directory, but if we know the paths, we can look up file permissions:

crw-------    1 root     root      251,   0 Jan  1 00:59 /dev/adc0
crw-------    1 root     root        5,   1 Jan  1  1970 /dev/console
crw-rw----    1 sys      gpio      254,   0 Jan  1  1970 /dev/gpiochip0
crw-r-----    1 sys      1005       10, 183 Jan  1  1970 /dev/hwrng
crw-------    1 root     root       89,   0 Jan  1 00:46 /dev/i2c-0
crw-------    1 root     root       89,   1 Jan  1 00:46 /dev/i2c-1
crw-------    1 root     root       89,   2 Jan  1 00:46 /dev/i2c-2
crw-------    1 root     root       89,   3 Jan  1 00:46 /dev/i2c-3
crw-------    1 root     root       89,   4 Jan  1 00:46 /dev/i2c-4
crw-------    1 root     root       89,   5 Jan  1 00:46 /dev/i2c-5
crw-r-----    1 root     root        1,  11 Jan  1  1970 /dev/kmsg
crw-------    1 root     root       90,   0 Jan  1  1970 /dev/mtd0
crw-------    1 root     root       90,   2 Jan  1  1970 /dev/mtd1
brw-------    1 root     root       31,   0 Jan  1  1970 /dev/mtdblock0
brw-------    1 root     root       31,   1 Jan  1  1970 /dev/mtdblock1
crw-rw-rw-    1 root     root       10,  61 Jan  1  1970 /dev/pluton
crw-------    1 root     root      253,   0 Jan  1 00:59 /dev/pwm0
crw-------    1 root     root      253,   1 Jan  1 00:59 /dev/pwm1
crw-------    1 root     root      253,   2 Jan  1 00:59 /dev/pwm2
crw-rw----    1 sys      rtc       252,   0 Jan  1  1970 /dev/rtc0
crw-rw-rw-    1 root     root       10,  62 Jan  1  1970 /dev/security-monitor
crw-------    1 root     root        5,   3 Jan  1  1970 /dev/ttyprintk
crw-------    1 sys      appman      4,  65 Jan  1  1970 /dev/ttyS1
crw-rw----    1 sys      1007        4,  68 Jan  1 00:00 /dev/ttyS4
crw-------    1 sys      appman      4,  69 Jan  1  1970 /dev/ttyS5
crw-------    1 sys      appman      4,  70 Jan  1  1970 /dev/ttyS6
crw-------    1 sys      appman      4,  71 Jan  1  1970 /dev/ttyS7
crw-------    1 sys      appman      4,  72 Jan  1  1970 /dev/ttyS8
crw-rw----    1 sys      1001        4,  73 Jan  1  1970 /dev/ttyS9
crw-rw-rw-    1 root     root        1,   9 Jan  1  1970 /dev/urandom
crw-rw-rw-    1 root     root        1,   5 Jan  1  1970 /dev/zero

Most notably, we can see that others have read/write access to /dev/pluton and /dev/security-monitor.