Find file History
Latest commit 7f59cce May 30, 2016 @rpaleari rpaleari Add CVEs
Failed to load latest commit information. Add CVEs May 30, 2016
usbswitcher.c Update usbswitcher.c Apr 14, 2016

Modem interface exposed via USB

  • Authors: Roberto Paleari (@rpaleari) and Aristide Fattori (@joystick)
  • Samsung ID: SVE-2016-5301
  • ID: CVE-2016-4030, CVE-2016-4031, CVE-2016-4032
  • Notification date: 11/12/2015
  • Release date: 11/04/2016

Some months ago we tweeted a video showing a "lock screen bypass" on a Samsung Galaxy S6 phone. In this post we provide the technical details behind that attack.

In a nutshell, when connected to a USB master (e.g., a normal laptop), Samsung Android phones expose (or can be forced to expose) a serial interface which can be exploited to communicate with the USB modem.

This communication channel is active even when both USB tethering and USB debugging (i.e., ADB) are disabled, and can be accessed even when the device is locked. An attacker who gains physical access to a (possibly locked) device can thus use this interface to send arbitrary AT commands to the modem. This permits to perform several actions that should be forbidden by the lock mechanism, including placing phone calls or sending SMS messages.

As a foreword, consider that in the following we assume that "USB debugging" is not enabled on the target device. When ADB is enabled, things are way too easy :-)

How does it work?

For old Samsung devices and firmware versions, such as the GT-I9192 (Samsung S4 Mini with build I9192XXUBNB1), just plugging the smartphone into a Linux host exposes a usb-serial modem, accessible using the corresponding Linux device (e.g., /dev/ttyACM0). After connecting to the modem through this interface, it is possible to send certain AT commands, some of which are delivered to the baseband modem while others are processed by user-space applications.

Exploitation of this vulnerability on more recent firmware versions (e.g., latest versions of the Samsung S4 and Samsung S6 software) is not so straightforward: in the default configuration, when the device is connected it exposes to the host only a MTP interface, used for file transfer.

However, we discovered that an attacker can still access the modem by switching to secondary USB configuration. As an example, consider our test Galaxy S6 device. When USB debugging is off, the device exposes two USB configurations, with the CDC ACM modem accessible via configuration number 2.

$ lsusb -v
Bus 001 Device 007: ID 04e8:6860 Samsung Electronics Co., Ltd Galaxy (MTP)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x04e8 Samsung Electronics Co., Ltd
  idProduct          0x6860 Galaxy (MTP)
  bNumConfigurations      2
  Configuration Descriptor:
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         6 Imaging
      bInterfaceSubClass      1 Still Image Capture
      bInterfaceProtocol      1 Picture Transfer Protocol (PIMA 15470)
      iInterface              5 MTP
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          105
    bNumInterfaces          3
    bConfigurationValue     2
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower               96mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              6 CDC Abstract Control Model (ACM)

Thus, before being able to connect to the modem the attacker has to switch the device to USB configuration number 2. This operation can be performed by the host PC without the need to unlock the device.

For our PoC we developed a very rough C tool, usbswitcher, that switches any attached Samsung device to USB configuration #2 (this is fine for the devices we tested, but your mileage might vary). The tool uses libusb to do the job, but the same task can probably be accomplished using the /sys/bus/usb pseudo-filesystem.

The trick we used to force the phone to switch the configuration is to first reset the USB device (via usb_reset()), and then switching the configuration (via usb_set_configuration()). Sometimes it doesn't work at the first try, so just run usbswitcher twice to ensure the configuration is switched properly :-)

Possible consequences

The most obvious consequence of accessing the modem is the possibility to place phone calls and send SMS messages. For the former, the following AT command can be used:


This command starts a phone call to destination +123456, even when the device is locked. This is the very same command we issued for the demo video we tweeted.

As a response to our tweet, people asked if this vulnerability can be also exploited to gain access to the device, e.g., to access the phonebook, photos, and the internal storage. Well, theoretically AT commands should be directly processed by the baseband processor, which normally should not be able to access the "Android world". However, as we mentioned before, the journey of an AT command is more convoluted and some AT commands are eventually interpreted by user-space applications, so things may be different than what expected.

As an example, during our tests we observed that the S4 mini (build I9192XXUBNB1) supports several AT commands that could be abused to control some Android settings. Among these, AT+USBDEBUG command permits to enable "USB debugging" (i.e., ADB), AT+WIFIVALUE enables and disables the Wi-Fi, and so on.

On more recent phones and firmware versions, Samsung probably became aware of the risks related to such commands and introduced a blacklist-based mechanism (enforced by the ddexe binary application) to filter out dangerous ones. As an example, issuing an AT+USBDEBUG on the Galaxy S6 results in the following messages to be recorded to the system log:

D/DataRouter(  302): write [151] bytes of data to USB fd[9]
D/DataRouter(  302): After the usb select
D/DataRouter(  302): read usb data[len:12]
D/DataRouter(  302): read usb data message:AT+USBDEBUG
D/DataRouter(  302): Not allowed AT cmd!!
D/DataRouter(  302): Before the usb select

Affected devices

We confirm this issue affects the following device models. Other models and firmware versions are probably affected as well, but they were not tested.

  • SM-G920F, build G920FXXU2COH2 (Galaxy S6)
  • SM-N9005, build N9005XXUGBOK6 (Galaxy Note 3)
  • GT-I9192, build I9192XXUBNB1 (Galaxy S4 mini)
  • GT-I9195, build I9195XXUCOL1 (Galaxy S4 mini LTE)
  • GT-I9505, build I9505XXUHOJ2 (Galaxy S4)