-
Notifications
You must be signed in to change notification settings - Fork 1
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.
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
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,
};
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.
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.