Transcription
ATtention Spanned: Comprehensive VulnerabilityAnalysis of AT Commands Withinthe Android EcosystemDave (Jing) Tian, Grant Hernandez, Joseph I. Choi, Vanessa Frost, Christie Ruales, andPatrick Traynor, University of Florida; Hayawardh Vijayakumar and Lee Harrison, SamsungResearch America; Amir Rahmati, Samsung Research America and Stony Brook University;Michael Grace, Samsung Research America; Kevin R. B. Butler, University of urity18/presentation/tianThis paper is included in the Proceedings of the27th USENIX Security Symposium.August 15–17, 2018 Baltimore, MD, USAISBN 978-1-939133-04-5Open access to the Proceedings of the27th USENIX Security Symposiumis sponsored by USENIX.
ATtention Spanned: Comprehensive Vulnerability Analysis ofAT Commands Within the Android EcosystemDave (Jing) Tian 1 , Grant Hernandez1 , Joseph I. Choi1 , Vanessa Frost1 , Christie Ruales1 ,Patrick Traynor1 , Hayawardh Vijayakumar2 , Lee Harrison2 , Amir Rahmati2,3 , Michael Grace2 ,and Kevin R. B. Butler11 Florida Institute for Cybersecurity (FICS) Research, University of Florida, Gainesville, FL, uales,traynor,butler}@ufl.edu2 Samsung Research America, Mountain View, CA, e}@samsung.com3 Department of Computer Science, Stony Brook University, Stony Brook, NY, USAAbstractAT commands, originally designed in the early 80s forcontrolling modems, are still in use in most modernsmartphones to support telephony functions. The roleof AT commands in these devices has vastly expandedthrough vendor-specific customizations, yet the extent oftheir functionality is unclear and poorly documented. Inthis paper, we systematically retrieve and extract 3,500AT commands from over 2,000 Android smartphonefirmware images across 11 vendors. We methodicallytest our corpus of AT commands against eight Androiddevices from four different vendors through their USBinterface and characterize the powerful functionality exposed, including the ability to rewrite device firmware,bypass Android security mechanisms, exfiltrate sensitivedevice information, perform screen unlocks, and injecttouch events solely through the use of AT commands. Wedemonstrate that the AT command interface contains analarming amount of unconstrained functionality and represents a broad attack surface on Android devices.1IntroductionSince their introduction, smartphones have offered substantial functionality that goes well beyond the abilityto make phone calls. Smartphones are equipped with awide variety of sensors, have access to vast quantities ofuser information, and allow for capabilities as diverse asmaking payments, tracking fitness, and gauging barometric pressure. However, the ability to make calls over thecellular network is a fundamental characteristic of smartphones. One way this heritage in telephony manifests itself is through the support of AT commands, which aredesigned for controlling modem functions and date to the1980s [24]. While some AT commands have been standardized by regulatory and industry bodies [35, 42], they Davebegan this project during an internship at Samsung ResearchAmerica.USENIX Associationhave also been used by smartphone manufacturers andoperating system designers to access and control devicefunctionality in proprietary ways. For example, AT commands on Sony Ericsson smartphones can be used to access GPS accessories and the camera flash [18].While previous research (e.g., [20, 46, 47]) has demonstrated that these commands can expose actions potentially causing security vulnerabilities, these analyses havebeen ad-hoc and narrowly focused on specific smartphonevendors. To date, there has been no systematic study of thetypes of AT commands available on modern smartphoneplatforms, nor the functionality they enable. In effect, ATcommands represent a source of largely undocumentedand unconstrained functionality.In this paper, we comprehensively examine the ATcommand ecosystem. We assemble a corpus of 2,018smartphone firmware images from 11 Android smartphone manufacturers. We extract 3,500 unique AT commands from these images and combine them with 222commands we find through standards to create an annotated, cross-referenced database of 3,722 commands. Toour knowledge, this represents the largest known repository of AT commands. We characterize the commandsbased on the evolution of the Android operating systemand smartphone models and determine where AT commands are delivered and consumed within different smartphone environments. To determine their impact, we testthe full corpus of 3,500 AT commands by issuing themthrough the USB charging interface common to all smartphones. We execute these commands across 8 smartphones from 4 different manufacturers. We characterizethe functionality of these commands, confirming the operation of undocumented commands through disassemblyof the firmware images.Our analysis of discovered AT commands exposespowerful and broad capabilities, including the abilityto bypass Android security mechanisms such as SEAndroid in order to retrieve and modify sensitive information. Moreover, we find that firmware images from newer27th USENIX Security Symposium273
smartphones reinstate AT command functionality previously removed due to security concerns, causing thosevulnerabilities to re-emerge. In short, we find that ATcommands accessed through the USB interface allow almost arbitrarily powerful functionality without any authentication required. As such they present a large attacksurface for modern smartphones.UsbServiceApplications (APKs)27427th USENIX Security Symposiuminit.usb.rcRILsysfs (/sys/class/android usb)UserSpaceUSB GadgetCDC ACM DriverModemDriverAndroid Composite DriverKernelSpaceUDC DriverBasebandProcessorUSB Gadget DriverUSB Device Controller DriverUSB Device Controller (UDC)Figure 1: Android USB architecture diagrams. The leftshows an Android device behaving like a USB modemwhen connected with a host machine and the right is anoverview of the Android USB stack.2Background2.1 Development of Attack Scenarios and Mitigations. We demonstrate that previously-disclosedattacks targeting the lock screen [49], which required malicious application access, can be performed through a USB cable without requiring anycode on the target phone. We demonstrate that arbitrary touchscreen events can be injected over USB.We discover multiple buffer overflow vulnerabilities and commands to expose the contents of /procand /sys filesystems, as well as path traversal vulnerabilities. We even discover a method to “brick”and “unbrick” certain phones. We also discuss howmechanisms such as “charger” mode and SELinuxpolicies only partially mitigate the threat that broadlyaccessible AT commands can pose to smartphoneplatforms.UsbSettingsMgr/dev/ttyXYZUDC Comprehensive Runtime Vulnerability Analysis.We systematically test 13 Android smartphones and1 tablet for exposure to the USB modem interfaceand find that 5 devices expose the modem by default while 3 other devices will do so if rooted.Using this interface, we comprehensively test all3,722 AT commands to determine the effect of bothstandard and vendor-specific commands on individual devices. We characterize notable classesof commands that can cause vulnerabilities suchas firmware flashing, bypassing Android securitymechanisms, and leaking sensitive device information. We find that new smartphone platforms reintroduce AT command-based vulnerabilities that werepurportedly previously patched.Android InitNative DaemonsOur contributions can be summarized as follows: Systematic Collection and Characterization ofAT Commands. We develop regular expressionsand heuristics for determining the presence of ATcommands in binary smartphone firmware images,extracting AT commands into an annotated databasethat tracks metadata and provenance for each command. Our database and code are publicly availableat http://atcommands.org.UsbDeviceMgrAT CommandsFirst developed by Dennis Hayes in 1981, the AT (ATtention) command set comprises commands that predominantly start with the string “AT” [16]. The AT commandset rapidly became an industry standard for controllingmodems. It allowed for performing actions such as selecting the communication protocol, setting the line speed,and dialing a number [40]. The International TelephoneUnion (ITU-T) codified the AT command set over the telephone network in Recommendation V.250 [35]. In the late90s, ETSI standardized the AT command set for GSM [26]and SMS/CBS [25], and later for UMTS and LTE [27].Based on the Hayes and GSM AT command sets, additional AT commands were introduced for CDMA andEVDO [42, 43].Manufacturers of cellular baseband processors (whichprovide modem functionality in cellular devices) haveadded proprietary and vendor-specific AT commands totheir chipsets [18, 34, 45]. As a result, smartphones alsosupport their own AT command sets and expose modemand/or serial interfaces once connected via USB to receivethese AT commands. In some cases, these vendor-specificAT commands are designed to be issued by software toinvoke specific functionality, (e.g., backing up contact information on a PC). These vendor-specific commands often do not invoke any functionality related to telephony,but to access other resources on the device. Androidphone makers further extended the AT command set byadding Android-specific commands (e.g., to enable debugging over USB) to be consumed by the Android OSrunning on the application processor [58]. These AT commands are also usually sent over a USB connection.11 It is also possible to send a subset of AT commands over Bluetooth,although functionality is limited [21].USENIX Association
2.2USB on AndroidAs the most important and widely adopted peripheral interface in the Android ecosystem, USB is responsible fora number of important tasks, including battery charging,data transmission, and network sharing with other devices. To accomplish these tasks via USB, Android devices support three different USB modes: host, device,and accessory mode. USB device mode, the most common mode and our focus because of its widespread use,is used when the phone connects to a PC and emulatesdevice functionality such as exposing an MTP (MediaTransfer Protocol) endpoint.As shown in Figure 1, the Android USB implementation in device mode relies on both the Linux kernel andthe Android framework. In the kernel space, the Androidcomposite driver exposes a sysfs entry to user space andinterfaces with the kernel’s USB gadget driver. DifferentUSB functionalities (such as USB Mass Storage or MTP)require different gadget drivers to be loaded. The gadgetdriver sits above the USB controller driver, which communicates with the USB device controller (UDC) hardware. Within the user space, the Android UsbService provides Java interfaces to applications, instantiating UsbDeviceManager and UsbSettingsManager to enable users toswitch between different USB functionalities. The Android init daemon typically takes care of setting userrequested USB functionality by loading an init.usb.rcscript during startup. This init script contains detailed procedures for setting functionality on the phone, essentiallywriting data to the sysfs.2.3Android USB Modem InterfaceUSB Modem functionality in Android can be accessed ifthe smartphone vendor exposes a USB CDC (Communication Device Class) ACM (Abstract Control Model) interface from within their phones. Once enabled and connected, this creates a tty device such as /dev/ttyACM0,enabling the phone to receive AT commands over the USBinterface [47]. As shown in Figure 1, the tty device relaysAT commands to the Android user space. Vendor-specificnative daemons read from the device file, and take furtheractions based on the nature of the AT command. Thesedaemons can handle vendor/carrier-added AT commands,such as “AT USBDEBUG” (enabling USB debugging)locally, without notifying the upper layer. Otherwise,(pre-installed) applications will be triggered to processthe commands. These AT commands are often designedto provide shortcuts for managing, testing, and debuggingwithin Android. For Hayes and GSM AT commands, suchas “ATD” (which enables voice dialing), the RIL (RadioInterface Layer) will be triggered to deliver the commandto the baseband processor.USENIX AssociationVendor# of Firmware# of AT 91299112245010085357791251416696Total20183500Table 1: Per vendor counts of firmware images examinedand AT commands extracted from all images.2.4Threat ModelThroughout the paper, we assume a malicious USB host,such as a PC or a USB charging station controlled by anadversary, tries to attack the connected Android phone viaUSB. We assume the attacker is able to access or switchto the possibly inactive AT interface — if available. Withaccess to this interface, the attacker will be able to sendarbitrary AT commands supported by the target device tolaunch attacks. We assume that all of these attacks canbe fully scripted and only require a physical USB connection. Additionally, we assume that Developer Optionsand USB Debugging are disabled by default. During theextraction of AT commands from firmware images, we assume that the existence of AT commands in binaries andapplications are not purposefully obfuscated, encryptedor compressed.3Design & ImplementationWe design and implement methods to extract, filter, andtest AT commands found within the Android ecosystem.Our procedure for acquiring these commands is shownin Figure 2. We begin by identifying and retrieving 2,018Android binary smartphone firmware images, covering 11major Android cellphone vendors. The details of this corpus are shown in Table 1. Next, for each firmware, weunpack the image using a variety of tools and extract ATcommand strings using a regular expression. After additional filtering, we recover 3,500 unique AT commands,many of which have differing parameter strings.2 Finally,using this database, we evaluate the security impact ofthese commands on real Android devices by setting upan automated testing framework to send the commands tophysical Android devices and monitor any side-effects.2 We extracted a total of 7,281 AT commands when different param-eter strings are included.27th USENIX Security Symposium275
LG1. Download/Crawl2. ExtractHTCbuild.build.proppropSamsungMfg. SitesPublic T”3. nAT DBImageNFigure 2: A graphical depiction of our paper’s Android firmware image processing pipeline.3.1AT Command ExtractionWe first gather Android firmware images from manufacturer websites and third-party hosts. For more details onthe downloading process, see Section A.3. With a corpusof firmware images, we begin extraction and filtering forcommands. We traverse each Android firmware imageas deeply as possible, recovering unique AT commandsand parameter combinations. Additionally, we also capture build information for each image from the standardAndroid build properties file, build.prop. This file provides key metadata about the image itself. We also collect any USB init/pre-configuration files (e.g., init.usb.rc)found in Android boot images to gain insight into the USBmodes supported by each firmware.In order to find AT commands present in firmware images, we look in every file for any string containing theregular expression AT[ *!@# % &]. AT commands witha symbol immediately following the ATtention string areknown as extended AT commands. Original EquipmentManufacturers (OEMs) are free to add any amount of extended commands to their products. We focus on solelycollecting AT extended command references within thesefirmware images for later categorization and testing.Many pieces of firmware were archived using standard formats. Vendor-specific formats included: HTC’s.exe format, unpackable using the HTC RUU DecryptTool [12]; Huawei’s update.app format, unpackable usingsplitupdate [10]; LG’s .kdz/.dz format, unpackable usingLGE KDZ Utilities [7]; and Sony’s .ftf format, unpackable using 7-Zip. Any nested archives directly under thetop-level archive (e.g., Samsung images’ several nestedtars) are similarly unpacked.Once all files are extracted from the archives, we process each file according to its characteristics. For nativebinaries, such as ELF, we are limited to using stringsto extract all possible strings, over which we grep forany of our target AT prefixes. For text-based files, grepis applied directly to catch potential AT commands. ForZIP-like files, we unzip and traverse the directory to examine each extracted file. ZIP-like files include yaffs (unpacked using unyaffs [13]), Lenovo’s SZB (unpacked using szbtool [11]) and Lenovo’s QSB (unpacked using a27627th USENIX Security Symposiumqsb splitter [6]) formats.If the file is a VFAT or EXT4 filesystem image (e.g.,system.img), we mount the filesystem and traverse itonce mounted to check each contained file. Filesystemimages are not always readily mountable. They may besingle or split-apart sparse Android images, which we firstconvert into EXT4 using the Android simg2img tool [9].They may be provided as unsparse chunks, which needto be reconstituted according to an instruction XML fileindicating start sector and number of partition sectors foreach chunk. They may otherwise be provided as sparseAndroid data images (SDATs), which are converted intoEXT4 using sdat2img [8]. Sony filesystem images, in particular, may be given in SIN format, which are convertedinto EXT4 using FlashTool [3].Android filesystem partitions contain APK files, whichwe decompile using dex2jar [2] and jd-cli [5] treating theoutput as text files to pull AT commands from. Similarly,we also decompile JAR files using jd-cli before extractingAT commands from them. Any discovered ODEX filesare first disassembled using baksmali [1], after which welook for AT commands in the assembly output. We thenreconstruct the DEX file using the assembly output withsmali and decompile it using jadx [4] before looking forAT commands in the resulting output.3.2Building an AT Command DatabaseAfter AT commands are extracted from each image, wedevelop a script to parse the “AT” matches. This script applies additional filtering with a more strict regular expression and uses a scoring heuristic to eliminate commandsthat appear to be invalid.For every command found, we record metadata such asthe vendor, image, and filename where it was discovered.Additionally we find any parameters to the AT commandand store the unique combinations with the command. Toorganize the data, we use MongoDB with a single toplevel document for each vendor. Each vendor has an arrayof images, which in turn have Android metadata, including, but not limited to, Android version, phone model, andbuild ID. Finally, each image has a list of AT commands.USENIX Association
Modem CommandOptional ParametersAttentionNameATATATAT EXECREAD ?TEST ?CSET 0,1,“param”Extended CommandNamespace ( , %, )SpecificationUsage# of AT CommandsHayes [16, 17]ITU-T V.250 [35]ETSI GSM 07.05 [25]ETSI TS 100 916 [26]BasicApplicationSMSGSM46612095Total (unique)222Table 2: Additional AT commands were manually collected from several specification documents, for a total of222 unique AT commands.Figure 3: A colorized representation of AT command syntax.123456789101112131415(?:[ a - zA - Z0 -9] ) # Left of the AT must NOT# be a letter or number(? P cmd # Capture the matchAT [! @ # % &* ]# Match AT [ symbol ][ A - Za - z0 -9]{3 ,} # Match the name and)(? P arg \? # Capture the match# Match AT READ ?# Match AT CSET 0 ,1 ," param " [ " ’ ;% ,? A - Za - z0 -9] \? # Match AT TEST ? # Match a blank parameter)?# Match AT EXECFigure 4: The regular expression developed to match extended AT commands. The regular expression syntax isfrom Python. All white space is ignored. Note that theregex is matching both text files and binary data.Filtering Lines containing AT commands as discoveredusing strings and grep are what we call coarse-grainedmatches. This means any matching lines may be invalidor spurious. We define an invalid match to mean not conforming to the expected patterns of an AT command. Figure 3 shows the syntax of an AT command, with differentcolors describing the modem attention string, commanddelimiter, command name, and parameter string. It alsoshows the four primary uses of AT commands: executingan action, reading from a parameter, testing for allowedparameters, and setting a parameter. In practice, whatthese types actually do is left up to the implementation.Regardless, these four types are the standard syntax patterns we aim to match.To capture these four types, we develop a regular expression as shown in Figure 4 to match their syntax. Line1 of the RE will ignore any matches that are not at thebeginning of the matched line and have a letter or number immediately to the left of the “AT” directive. Line4-7 will capture and match the AT directive, the extendedcommand namespace symbol, and the command name,which must be greater than or equal to three charactersand only contain letters, numbers and underscores. Lines9-15 will capture any optional argument to the command.USENIX AssociationLine 10 will match a read variant, line 12 a set variant witha non-zero amount of numeric parameters, string parameters, and nested AT commands separated by semicolons(e.g., AT CMD 1,10,"var"; OTHER 1,2). Line 13 willmatch the test variant and finally line 14 will match anempty parameter.Despite this more restrictive regular expression, certaincommands such as AT L2f, AT baT, and AT tAT commonly end up in the AT command database. Upon testingand visual inspection, we define commands of this appearance to be spurious matches. These false positive matchespolluted our analytics and cause a large increase in uniquecommands, which in turn slows down our testing. Byobserving the make-up of these invalid commands, wedeveloped a simple heuristic to score commands basedoff of three features: the command length, the characterclasses present, and the valid to invalid command ratio ofthe file in which it was discovered. For more details onthis heuristic visit Section A.2.In summary, the regular expression helped us discard33.2% of all 1,392,871 processed lines across all images.The heuristic eliminated an additional 2.4% of all processed lines and brought the total unique AT commandcount down from 4,654 to 3,500, a 24.8% reduction. Withless invalid commands matched, the signal to noise ratioof database increased and our AT command testing wasfaster.Generating a DB Once we have filtered and storedevery AT command along with any found parameters,we generate plain-text DB files for input into our testing framework. We create DB files containing every unique command and parameter and vendor-specificATDB files. These give us different test profiles for phonetesting. In addition, we also manually collect AT commands from multiple specifications, as shown in Table 2.Many of these commands are not extended AT commands(AT[symbol]) and would not be matched during our filtering step. Also, these AT commands may not be foundinside the Android firmware, but should be supported bybaseband processors meeting the public specifications.Thus, we include these in our database.27th USENIX Security Symposium277
3.3AT Command Testing FrameworkAfter all command databases have been built, we are ableto send AT commands to phones with an exposed AT interface. To achieve this, we developed a Python script running on Ubuntu 16.04 that uses PySerial to interact withthe phones. When a phone that exposes an AT interface isplugged in, the Linux kernel will read its USB configuration descriptor and load any necessary drivers. To Linux,the modem interface appears as a Communication Device Class (CDC) Abstract Control Model (ACM), whichcauses the usbserial driver to be loaded. This drivercreates one or more /dev/ttyACM device nodes. PySerial opens and interacts with these device nodes directlyand sets parameters such as the baud rate and bitwidth. Inpractice, we were able to communicate with all modemsusing a 115200 baud, 8-bit, no parity, 1 stop bit scheme.For some manufacturers, the USB modem interface isnot included in the default USB configuration. In thiscase, there may be a second hidden configuration than canbe dynamically switched to using libusb directly. Weuse a public tool called usbswitch [47] to select the alternative USB configuration, enabling communication overthe modem interface. Once a modem is exposed, we senda command, wait for a response or a timeout, and log bothsides of the conversation for future review. This loggingis crucial for understanding what unknown commands aredoing to a phone under test.During our preliminary testing, we discovered commands that reboot, reset, or cause instabilities in thephone. We thus blacklist certain commands to allowour framework to continue without human intervention.These blacklisted commands are returned to for furthermanual inspection. For suspicious commands, we manually rerun them on the target phone couple of times tonarrow down on the exact functionality and behavior.4AT Command AnalysisTo understand the prevalence and security impact ofAT commands on the Android ecosystem, we performfirmware analysis and runtime vulnerability analysis, andwe launch attacks. In the firmware analysis, we first examine the entire corpus of AT commands extracted fromfirmware to discover trends in their occurrence across vendors and Android versions. Our goal is to gain insightinto the general usage of AT commands from within theAndroid ecosystem. We then take a closer look into thenative binaries and applications that contain the most ATcommands per vendor. This information advises whichbinaries to put into IDA for further analysis. We also inspect the USB configuration files inside these images andprovide an estimate of how many images may potentiallyexpose the USB modem interface.27827th USENIX Security SymposiumIn the runtime vulnerability analysis, we first look at14 Android devices to confirm their exposure of a USBmodem interface. We launch our AT command testingframework on 8 different Android devices that do exposesuch an interface and collect command information basedon both response and observable effects on the physicaldevices during our testing. We categorize these commands and further show their security impact. We leverage the knowledge gained of AT commands from runtimeand IDA analysis to create new attacks using AT commands, and we verify these attacks on off-the-shelf Android phones.4.1Firmware AnalysisDistribution of AT Commands Across Vendors. Welook at the number of unique AT commands across select vendors, namely Google, Samsung, and LG. Asthe base of all other Android variants, AOSP (AndroidOpen Source Project) keeps the number of AT commandscontained inside the factory images around 70 on average. Figure 5a shows the distribution of these commandsacross AOSP firmwares. The average amount of AT commands is fewer than 100 across all versions, and is under75 starting from version 4.3. Version 4.2 has the largestvariance across different images. We correlate this withthe wide product line support of the Nexus series, whichlater became the Pixel phone series.New AT commands are constantly added into stockROMs due to vendor-specific customizations. Figure 5bpresents the number of AT commands found in SamsungAndroid images. Our results show that the number of ATcommands generally increases across different versionsbefore Android 5.0. Although the average number staysfairly stable after version 5.0, it is still above 400. Thismeans that given an image, Samsung has at least 300 additional AT commands compared to its AOSP counterpart.This trend is even more apparent for LG, with the number of AT commands increasing monotonically as the Android version grows, as shown in Figure 5c. The averagenumber of AT commands within LG Android version 7.0images is over 375.AT Command Top 10. Table 13 in the Appendix showsthe frequency of each of the top 10 most frequent AT commands overall and per different major vendor. All of thetop 10 from the aggregation are standard GSM AT commands, which manage modems and calls. Similarly, allof the most frequent commands found in AOSP imagesare also GSM-related. In contrast, 3 non-standard ATcommands (“AT DEVCONFINFO”3 , “AT PROF”4 , and“AT SYNCML”5 ) are among the most common ones in3 Get the device configuration information.4 Retrieve information, such as “AT PROF “Phonebook””.5 Synchronization Markup Language support for device syncing.USENIX Association
4.04.14.24.3 4.4 5.0Android Version5.16.07.0(a) ATcmd Distribution of Google.7.12.22.34.04.14.2 4.3 4.4 5.0Android Version5.16.07.0(b) ATcmd Distribution of Samsung.7.14.45.05.1Android Version6.07.0(c) ATcmd Distribution of LG.Figure 5: AT Command distribution across three major Android smartphone manufacturers.GoogleATcmd#/vendor/lib/libsec-ril o.so18373372319Samsung/bin/at distributor/md1rom.img/app/FactoryTest CAM.apk/bin/sec /arm/LGBluetooth4.odex35437271915Table 3: Top 5 binaries which contain the most AT commands per Google, Samsung, and LG.Samsung images besides the 7 GSM-related commands.Surprisingly, 8 of the top 10 AT commands in LG arenon-standard (prefixed by “AT%”). Further investigationshows them all to be vendor-specific. We extend our inspection to the top 20 AT comm
2.2 USB on Android As the most important and widely adopted peripheral in-terface in the Android ecosystem, USB is responsible for a number of important tasks, including battery charging, data transmission, and network sharing with other de-vices. To accomplish these tasks via USB, Android de-vices support three different USB modes: host, device,
