This chapter focuses on the foundational knowledge that is required when performing an IoT penetration test. It provides basic concepts about the many attack surfaces within IoT and lays the groundwork to assist testers with jump-starting an IoT testing lab.

We will discuss the current state of IoT penetration testing and each area of possible attack surface to address how testing has advanced over the years. Then we will go over the basics of firmware security, web application security, mobile application security, hardware security, and radio communication.

Finally, we will walk you through how to set up the software tools and hardware tools required for testing.

Over the last few years, the spotlight has been on IoT devices due to the sheer amount being deployed, the conveniences they provide, their ease of use, and the potential security risks they pose in our society. With the IoT boom taking place before our eyes, we as a people are closer to a technology singularity. The dependence on IoT and the internet, which powers them raises concerns about safety, privacy, and security. Due to the spread of devices infiltrating all industry verticals, such as consumers, entertainment, commercial, medical, industrial, energy, and manufacturing, it has been proven that consumers, as well as commercial technology operators and owners, are unable to properly ensure the security of these devices. The reliance on device manufacturers to provide the proper assurance that devices are built with methodologies such as security-by-design is heavily dependent on the industry in which the device was made for.

Each industry vertical and region has its own respective regulations for testing devices. It is important to do your own due diligence prior to testing in order to ensure laws are not being broken. In some regions, such as the United States, security research for consumer devices is allowed and exempt from the Digital Millennium Copyright Act (DMCA), so long as the research is acting in good faith, is lawfully acquired, conducted in a controlled environment, and does not violate the Computer Fraud and Abuse Act (CFAA) of October 2016. This means security research for connected vehicles, cameras, various smart home devices, video game consoles, and jailbreaking mobile devices are now legal. After a long road of battles with the DMCA and the security community, this is a big win.

Now that such laws have passed, this is where we come in; we will go through assessing device firmware, web applications, mobile applications, hardware, and radio communications. First, we need to understand what the full scope of IoT is, including penetration testing approaches, and life cycles, to recognize all of its attack surfaces. Let's discuss the fundamentals of each IoT component in order to understand the attacks.

Testing applications, networks, and devices for security flaws are vital for keeping the internet more secure and safe. Whether testing occurs by the manufacturers, third-party consulting firms, enterprise security teams, or security researches, approaches vary depending on the information given to the testers who are performing the assessment. Ideally, a comprehensive test should include the entire IoT system as well as its infrastructure, and not just the device itself, but it is not uncommon for testing to include only a subset of an IoT system due to pricing or technical ability.

Black box assessments are common and known to be performed for a relatively low cost. These types of assessments are performed with no prior knowledge of the technology or device implementations employed. More often than not, black box assessments are performed by security researchers or third-party consulting firms, but can also be conducted by internal security teams for risk assessment purposes.

White box assessments are when testers are given full access to source code, network diagrams, architecture diagrams, data flow diagrams, and various other pieces of detailed information on the technology employed by the target device. Generally, the more information on the target device or application(s) given to testers beforehand, the better the test results will be. White box assessments are more expensive but also ensure a more thorough review of a device's security controls and its implementation.

Grey box assessments are performed when testers have limited or partial knowledge that an insider of the organization is aware of. These assessments can consist of testers only knowing the application stack and libraries utilized, but not having detailed documentation on the API.

Firmware is a kind of software that is written to a hardware device in order to control user applications and various system functions. The firmware contains low level programming code that enables software to access hardware functions. Devices that run firmware are known as embedded systems which have limited hardware resources, such as storage capabilities as well as memory. Examples of embedded devices that run firmware are smartphones, traffic lights, connected vehicles, some types of computers, drones, and cable set-top boxes.

It is apparent that embedded technology and the firmware that runs on these devices controls our daily lives, from the critical infrastructure cities rely on, to bank ATMs and the homes that consumers live in. It is important to understand what a firmware binary consists of as well as its associated properties. Firmware is comprised of a bootloader, kernel, filesystem, and various other resources. There are different types of firmware built upon embedded Linux, embedded Windows, Windows IoT core, and various Real Time Operating Systems (RTOS). This book will be geared toward an embedded Linux environment, however, the principles will remain platform agnostic.

The following diagram represents what a piece of firmware contains: flash contents, the bootloader, the kernel, and a root filesystem:

Let's first have a look at the bootloader. A bootloader's responsibility is to initialize RAM for volatile data storage, initialize serial port(s), detect the machine type, set up the kernel tagged list, load initramfs (initial RAM filesystem), and call the kernel image. The bootloader initializes hardware drivers via a Board Support Package (BSP), which is usually developed by a third party. The bootloader resides on a separate Electrically Erasable Programmable Read-only Memory (EEPROM), which is less common, or directly on flash storage, which is more common. Think of the bootloader as a PC's BIOS upon start up. Discussing each of the bootloaders' responsibilities in detail is beyond the scope of this book; however, we will highlight where the bootloader works to our advantage. Some of the common bootloaders for ARM and MIPS architectures are: Redboot, u-boot, and barebox. Once the bootloader starts up the kernel, the filesystem is loaded.

There are many filesystem types employed within the firmware, and sometimes even proprietary file types are used depending on the device. However, some of most common types of filesystems are SquashFS, cramFS, JFFS2, YAFFS2, and ext2. The most common filesystem utilized in devices (especially consumer devices) is SquashFS. There are utilities, such as unsquashfs and modified unsquashfs that are used to extract data from squashed filesystems. Modified unsquashfs tools are utilized when vendors change SquashFS to use non-supported compressions, such as LZMA (prior to SquashFS 4.0, the only officially supported compression was .zlib), and will have a different offset of where the filesystem starts than regular SquashFS filesystems. We will address locating and identifying offsets later in this book.

For additional reading on filesystems for embedded Linux, please visit the following link: http://elinux.org/images/b/b1/Filesystems-for-embedded-linux.pdf.

Similarly, there are many types of file compression utilized for firmware images, such as LZMA, .gzip, .zip, .zlip, and .arj, to name a few. Each has pros and cons such as the size after compression, compression time, decompression time, as well as the business needs for the device itself. For our purposes, we will think of the filesystem as the location that contains configuration files, services, account passwords, hashes, and application code, as well as start up scripts. In the next chapter, we will walk you through how to find the filesystem in use as well as the compression in use.

Within the filesystem, device-specific code resides, written in C, C++, or other programming languages, such as Lua. Device-specific code, or even all of the firmware itself, can be a mix of third-party developers contracted out, known as Original Design Manufacturers (ODM), or in-house developers working with the Original Equipment Manufacturer (OEM). ODMs are an important piece of the embedded device development supply chain. They are often small companies in Asia and are a dime a dozen. Some OEMs have trusted ODMs they work with on product lines, while others will do business with ODMs that have the lowest fees for only one product. Depending on the industry, an ODM can also be referred to as a supplier. It is important to note that ODMs are free to work with a number of different OEMs and can even distribute the same code base. You may be familiar with this notion or even wondered why a critical public advisory affects ten plus device manufactures for a software bug. This occurs due to a lack of secure development life cycles processes by the ODM and verification by the OEM. Once an ODM completes their application deliverables, which may be an SDK or firmware to the OEM, the OEM will merge its code base(s) into the firmware, which may be as small as OEM logos on web interfaces. The implementation varies depending on how the ODM and OEM merge their code; however, it is not uncommon for an ODM to provide a binary file to the OEM. OEMs are responsible for distributing the firmware, managing firmware, and supporting the device itself. This includes firmware security issues reported by third-party researchers, which puts a strain on OEMs if ODMs retain the source code and the OEM only has access to a binary image.

In Chapter 3, Analyzing and Exploiting Firmware we will learn how to reverse engineer firmware binary images by recognizing the filesystem, identifying compression, and emulating binaries for testing, to take advantage of common firmware issues.

Websites, otherwise known as web applications, need no introduction. At the very least, web applications contain frontend HTML, JavaScript, a backend web server, an application server, and a database. As web applications progress, heavy reliance on frontend code such as JavaScript is utilized more often in order to take the computational load off of the backend infrastructure or device. Web applications on the greater internet are slightly different than the web applications that are served via embedded devices.

The web applications you are used to have many more dependencies including the separation of web servers, application servers, database servers, as well as micro services that run in the backend. Separating each server is due to performance and availability reasons. Traditionally, embedded web applications are designed to run in their own self-contained environment. In a broad sense, there is less of a focus on performance and availability for embedded web applications.

There are two different models of web applications being utilized within the IoT space today, such as the hybrid cloud model and the embedded server standalone model. The hybrid model is a mix of the vendor or manufacturer providing Software as a Service (SaaS) web application(s) and also connecting the embedded device's web application running off of the firmware. The data is then synced from the manufacturer's cloud with the embedded device on the device's local network. For some IoT devices, IoT cloud service provider SDKs are utilized, such as AWS' IoT SDK and Azure's IoT SDK, and are built into the device web application stack. Recognizing a hybrid model is important in order to stay within a company's terms of service as well as within the legal bounds of your region. Many IoT companies who do utilize a hybrid model often use a third-party software development firm or ODM to host their web application on behalf of the OEM. These ODMs' web applications are usually rebranded for the specific OEM product, which can go unnoticed without proxying the communication.

A hybrid cloud model with IoT devices that have internet capabilities may look like the following figure. A user accesses the device's interface, where web services between the vendor's cloud and the user's device makes changes or collects data behind the scenes:

Embedded device web applications are, as mentioned, running internally off the device's firmware utilizing an embedded web server such as lighttpd or nginx with no outside dependencies. You might be familiar with these standalone embedded web apps, which are known to be run on printers, VoIP phones, and home routers. Quite often, input is sent directly to the device firmware, and if the user input is not validated or sanitized, attackers can perform arbitrary command execution within the device's context. In some cases, embedded web applications are designed to operate only within the Local Area Network (LAN) to protect from outside attacks or for administrative purposes. This can be the case for home IoT, industrial, and commercial devices. Often, having devices only available locally to a LAN is for security purposes, but as we have learned, this is not a stopgap for mitigating attacks. Device makers who design products with this intent are learning that customers are knowingly or unknowingly putting their devices on the internet, posing a risk to customer networks.

The following diagram demonstrates a user connecting to an embedded standalone web application via a web browser without outside system dependencies:

The communication between browsers, embedded servers, and web application servers is typically done through a web service such as Simple Object Access Protocol (SOAP)/XML or an API which is based on Representational State Transfer (REST) over HTTP/HTTPS. SOAP requests consist of an envelope element, an xmlns:soap namespace, an encodingStyle attribute, and various elements such as the SOAP body element. Additional details on SOAP can be found by visiting the following link: 
https://www.w3schools.com/xml/xml_soap.asp.

An example of a HTTP SOAP request querying for an account balance is shown here:

POST http://example.com/soap/webservices HTTP/1.1 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Language: en-US,en;q=0.5 
Authorization: BasicYWRtaW46YWRtaW4= 
Content-Length: 821 
Content-Type: text/plain;charset=UTF-8 
DNT: 1 
Connection: keep-alive 
Host: example.com 
 
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v1="http://example.com/webservices/BillingAccountSummary/V1"> 
   <soapenv:Header/> 
   <soapenv:Body> 
      <getAccountBalance> 
         <messageHeader> 
            <action>get</v1:action> 
            <scopeObject>AccountBalance</v1:scopeObject> 
            <revision>1.0</v1:revision> 
           <createdTimestamp>2017-01-13T09:15:01.469</v1:createdTimestamp> 
            <sourceInterface>WEB</v1:sourceInterface> 
            <messageIdentifier>00810187-101EDDA4</v1:messageIdentifier> 
            <functionName>getAccountBalance</v1:functionName> 
         </messageHeader> 
         <billingAccountIdentifier>1234566</v1:billingAccountIdentifier> 
      </getAccountBalance> 
   </soapenv:Body> 
</soapenv:Envelope> 

REST style APIs utilize various HTTP methods that may not be standard in traditional web applications, such as the PUT method, to update resource values as well as DELETE methods to remove values within an API. REST requests can utilize parameter calls via the URL (not recommended for sensitive data) or via the HTTP body in JavaScript Object Notation (JSON).

An example REST request subscribing the test@example.com email address to an email distribution list is shown here:

POST /rest/email/subscribe HTTP/1.0 
Host: example.com 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Content-Type: application/json 
Content-Length: 160 
Connection: close 
 
{ 
  "subscriberId":"12345", 
  "emailAdress":"test@example.com", 
  "confirmed":"Y" 
} 

In order to view SOAP or REST requests, a man-in-the-middle proxy is required. Tools such as Burp Suite and/or OWASP ZAP are used as web proxies to view all requests being made from the browser and the mobile application to the application's web backend infrastructure. We will go through setting up the configuration to proxy the application traffic later on in Chapter 4, Exploitation of Embedded Web Applications.

As it pertains to IoT, web applications are a common way to control devices and are just one attack entry point from both the internal and external network perspective. In Chapter 4, Exploitation of Embedded Web Applications, we will learn how to identify common IoT web application flaws and exploits.

In the IoT space, mobile applications are similar to the web application models previously discussed. Although discussing specific details about security models for mobile device platforms is beyond the scope of this book, having a foundational knowledge of mobile application development models will help with testing when moving forward.

Mobile applications installed on an Android, iOS, or Windows phone device can be hybrid or native. Although the terms hybrid and native have different meanings in the mobile application sense rather than web applications, the principals are similar. A hybrid application utilizes both web technologies, such as HTML/HTML 5, CSS, and JavaScript, as well as some native platform hardware, such as GPS or Bluetooth. Access to hardware resources is only through the use of plugins provided by the hybrid framework. Think of hybrid apps as web applications packaged up into a wrapper that the native platform can use. This means that a web developer can now code a mobile app without having the learning curve of a new language.

Hybrid applications use one code base for multiple platforms, such as Windows Phone, Android, and iOS, which is a huge plus when thinking of the first to market for IoT devices. Applications are called over the web using an embedded web browser known as WebView. There are many hybrid frameworks that the most popular apps use in the market today, such as Apache Cordova, Adobe PhoneGap, and Xamarin, to name a few.

Each of the mobile hybrid frameworks contains a third-market place which contains plugins for various features. Some frameworks such as Xamarin are written in one programming language (C#) and translated into a native language (Objective C and Java) for rapid development purposes. These mobile frameworks are known to have a number of security advisories ranging from critical remote code execution issues on the native platform to privacy concerns. If you happen to notice a certain mobile hybrid framework being utilized, it might be a good idea to have a look at a vulnerability database for easy wins.

To give you a better idea about the architecture it takes to run a hybrid application, the following diagram shows the different components between the application code, WebViews, plugins, and the mobile device itself. Keep in mind, most of the wrapper code and plugins are developed by the hybrid framework or third-party developers who contribute to the framework:

Native applications are built for specific operating systems and written within the device platform's native language, such Java, Objective C, Swift, and even C# for Windows phones. Native applications use their respective platform SDKs, which gives the app access to hardware such as the camera, Bluetooth, and GPS. Performance and security are better with native apps but they are dependent on an experienced developer who knows a native language. This may be difficult, in some cases, for staffing developers as platform APIs often update and deprecate language classes or methods. More and more, platforms such as iOS and Android are developing native security APIs that developers can take advantage of without the need for utilizing third-party libraries. This is important for secure communication and secure data storage.

A native architecture is much simpler than hybrid application architectures. The following diagram shows a native application running native code directly on the device without the need for third-party components to access hardware resources:

It's important to understand the pros and cons of each mobile application model for efficient testing. As device control is delegated to mobile apps, they are another attack entry point into a device that can sometimes be easier than another entry point. In Chapter 5, Exploitation of IoT Mobile Applications, we will delve into some of the most common vulnerabilities in IoT mobile apps as we dissect an IoT device.

Device hardware starts with the Printed Circuit Board (PCB), which is comprised of fiberglass, copper, the solder mask, silkscreen, traces, and pads. Components such as resistors, capacitors, chips for Wi-Fi, EEPROMs, and serial and microcontrollers are soldered onto the PCB. There are various layers of thin copper foil that make a PCB conductive and also insulated layers that make it non-conductive. It's important to identify components of interest when looking at a PCB. Components of interest include sources of input into the device firmware either directly or indirectly. Components such as the EEPROM, NAND flash, Universal Asynchronous Receiver/Transmitter (UART), and Joint Test Action Group (JTAG) are some of the most common components to focus on for testing purposes.

This is what a PCB board looks like for a Digital Video Recorder (DVR):

The EEPROM is a non-volatile storage location which is read and writable as single blocks of bytes. The EEPROM can be erased by electrical charges or UV exposure. Similar to other flash storage types, EEPROM allows a limited number of write cycles. EEPROM is a chip of interest, as firmware may be loaded on an EEPROM and can be removed from the PCB to an EEPROM reader for further analysis:

NAND flash memory is written and read in blocks, which are commonly found in USB drives but are also in IoT devices as well as game consoles. The NAND flash typically contains a device's bootloader which follows various instructions to start the operating system and can be manipulated; we will walk you through this later on in this book.

UART is one of the most common ways to gain access to devices. Manufacturers use UART for diagnostics, log messages, and as a debug console for verifying configurations when deploying devices, which makes it one of the most common sources of input in firmware. Since it's used for debugging, root access is commonly granted once connected. However, there are times when UART access is password protected, which may add extra time for brute-forcing. UART contains about eight data lines with control pins and also has two serial wires which are the receive data and transmit data wires (RX/TX). No external clock is needed for UART. UART pinouts on the PCB are TX, RX, Vcc (voltage), and GND (ground). In order to connect to a UART, the TX, RX, and GND must be located using a multimeter. Sometimes, a locating UART may be more difficult on some devices, than others. Some manufacturers may remove the UART header pins from the PCB, requiring soldering to take place. Manufacturers may also cover UART header pins with various layers of silkscreen and cover the headers with another integrated circuit which may be a bit of a pain.

JTAG is another serial communication under IEEE 1149.1. It was created for chip-and system level testing. Manufacturers use JTAG as a source of debugging, similar to UART. There is the ability to password protect JTAG access, but the BYPASS mode should still work. Firmware can be dumped for analysis or upgraded using JTAG. It provides a direct interface to hardware on the board which means it can access devices connected to it, such as flash or RAM. There is a TDI (data in), TDO (data out), TMS (test mode select), TCK (test clock), and TRST (test reset). JTAG connects to an on-chip test access port (TAP) which regulates a state when accessing registers on chips. Similar to UART, manufacturers may obfuscate header pins or traces.

To view the PCB and locate components in an IoT device, one can either disassemble the device or search through third-party sites such as https://fccid.io. An FCC ID is a product ID that is assigned by the FCC in order to keep track of wireless products in the market. Fccid.io is awesome and provides us with loads of detailed information on devices! The FCC publishes various design documents, datasheets, internal images, external images, test reports, various manuals, wireless frequencies, and more. In Chapter 6, IoT Device Hacking, we will walk you through the methodology of hardware hacking to locate hardware details and connect to inputs.

The most common way for IoT devices to connect and interact is via wireless Radio Frequency (RF) communication. There are loads of different wireless frequencies, modulations, and protocols used in today's current market. Some wireless protocols are proprietary and others are standard. Opening up a device will unveil one or multiple chips that perform wireless communication. This is definitely common for IoT gateways and hubs that are required to ingest a variety of different wireless communication protocols and frequencies. One of the advantages of wireless technology is the ability to be remote and still control a device. This is also the case when exploiting devices with wireless communication. It is important to understand the distance that each wireless technology is capable of. One wireless protocol may have a distance of 105 ft., or about 32 meters, while others can be as short as 20 cm. Amongst the many wireless protocols in the IoT ecosystem, some of the most common protocols used are Wi-Fi (802.11), ZigBee (802.15.4), Z-Wave, Bluetooth (802.15.1), and Bluetooth Low Energy.

Wi-Fi has been the most common wireless technology used in many devices for years. It operates on 2.4 GHz and 5 GHz ISM bands. There are a number of Wi-Fi standards in use, such as 802.11a, 802.11b, 802.11g, 802.11n, and 802.11ac. 802.11b and 802.11g operate on the 2.4 GHz band while 802.11a, 802.11n, and 802.11ac use the 5 GHz band. There are 14 wireless channels which operate on different frequencies. Depending on the region, there are certain channels that Wi-Fi routers are allowed to broadcast on.

ZigBee is based on the IEEE 802.15.4 specification for the physical and media access control layers, which support low-powered wireless mesh networking. ZigBee operates on different ISM bands based on region, but mostly on 2.4 GHz worldwide with 915 MHz in the US and 868 MHz in the EU. ZigBee is comprised of a coordinator (ZC), router (ZR), and end devices (ZED). The coordinator automatically initiates the formation of the network. There is only one coordinator in a network and it's generally the trust center for authenticating and validating each device that has joined the network and has a unique network key. The router passes data from other devices and associates routes to end devices.

Routers have to be continually powered in order to properly pass messages to the network. End devices are IoT devices such as light switches, sensors, cameras, or monitors. They cannot route data inside the network but can be put to sleep in a low power mode while not transmitting. ZigBee networks are based on two security keys known as the network key and link key. The network key is used to securely transport communication and is a 128-bit key shared with all devices in the network. The link key is used to secure the unicast communication in the application layer of ZigBee. The link key is also a 128-bit key which is only shared between two devices. Link keys can be pre-installed on devices or distributed through a key exchange. Vulnerable key exchanges during device pairing is a known flaw in consumer-based ZigBee networks, which has allowed attackers to sniff the exchange network key and compromise the entire network.

A good slide deck for referencing ZigBee security flaws can be found via the ZIGBEE EXPLOITED talk given at Blackhat in 2015:

https://www.blackhat.com/docs/us-15/materials/us-15-Zillner-ZigBee-Exploited-The-Good-The-Bad-And-The-Ugly-wp.pdf.

Z-Wave is another low-powered wireless communication protocol that supports mesh networks with a master-slave model. It uses the sub-1 GHz band which varies by region (916 MHz in the US or 868.42 in the EU). Its physical and media access layers are ratified under ITU as the international standard G.9959. Z-Wave's range between two devices is 328 ft. or 100 meters, but it can reach up to 600 ft. or 200 meters when traffic traverses through Z-Wave products with in its mesh network. The Z-Wave network is identified by a 4 byte (32-bit) HomeID which is the controller or master node's unique ID. All nodes within the same network share the same HomeID. Each node is identified by a 1 byte (8 bits) NodeID which is provided by the controller once they are joined to the network. Nodes with different HomeIDs cannot communicate with each other. Z-Wave can use AES encryption, which is supported by Z-Wave hubs, but it is purely optional for manufacturers to implement. Z-Wave does include a nice signal jamming detection feature that prevents Denial of Service (DoS) attacks.

For additional specifications on the Z-Wave protocol, please visit http://www.z-wave.com.

Bluetooth is a commonly used wireless technology standard (IEEE 802.15.1) used for data communication over short distances. Bluetooth broadcasts at over 2.4 to 2.485 GHz and can reach up to 100 m but is more commonly used under 10 meters or 30 ft. This book will contain Bluetooth and Bluetooth Low Energy (BLE) testing techniques, as plenty of IoT devices do utilize a form of Bluetooth as a primary means of communication. For additional reading on Bluetooth, visit the following link:

https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works

Now that all the foundational IoT technology has been covered, let's work on setting up an IoT pentesting lab. Due to the suite of technologies employed by IoT devices, there are several tools required for the software and hardware portions of testing. There is a mix of paid commercial tools, as well as free tools that we will use. Some upfront purchasing will be required for hardware and radio analysis tools. There are modest licensing fees for web application proxy tools, but we will try to keep the price tag as low as possible and offer free tools where possible.

Software tools will cover firmware, web applications, and mobile application testing tools. The majority of testing tools are free for each of the three categories, with the exception of Burp Suite for web application testing. For convenience, time has been taken to set up and install most of the software tools for firmware analysis, web testing, mobile testing (limited), and radio analysis within a virtual machine for this book. However, a list of all tools has been compiled and is recorded here.

Fortunately, most firmware analysis tools are free and open source. Some of the tools are actively updated while others may be dated but still work. The following are a number of firmware software tools which can analyze firmware images, disassemble images, and attach to firmware processes during runtime:

• Binwalk
• Firmadyne
• Firmwalker
• Angr
• Firmware-mod-toolkit
• Firmware analysis toolkit
• GDB
• Radare2
• Binary Analysis Tool (BAT)
• Qemu
• IDA Pro (optional)

For web application testing, the most common tools of the trade are Burp Suite and OWASP Zed Attack Proxy (ZAP). Burp Suite has a free and pro version available for a modest price. ZAP is completely free and open source, which may be a good alternative to keep costs low. Additional plugins or add-ons may be used to help with web service and API testing. Unfortunately, to install plugins with Burp Suite, a pro license is required. All tools listed here are cross-platform, as they are either Java based or within your browser:

• Burp Suite
• OWASP Zed Attack Proxy (ZAP)
• REST Easy Firefox plugin
• Postman Chrome extension

Like firmware tools, most mobile application security tools are also free and open source. The mobile tools that will be used are broken down according to the mobile platform below.

There are many Android testing tools and virtual machines available online as of the writing of this book. Some tools focus purely on statically analyzing an APK's code while other tools focus on app analysis during runtime. Most of the Android testing virtual machine distributions are free and contain the necessities for testing an Android app such an Android's SDK. Although Android testing tools are listed here, it is recommended you download an Android testing virtual machine distribution that suits your testing needs, and install any supplemental testing tools in that virtual machine.

Although not required, keeping your Android testing tools separate from your host computer will lead to a more stable mobile testing workbench and prevent dependency issues as well.

• Android testing virtual machine distribution:
  • Android SDK
  • Android emulator
• Enjarify
• JD-Gui
• Mob-SF
• SQLite browser
• Burp Suite
• OWASP ZAP

iOS testing tools are unique in that an OS X computer and a jailbroken iDevice are required for testing. Without these two prerequisites, the testing of iOS applications will not be possible. Here are some of the tools that may be utilized for iOS mobile testing:

OS X computer

The following listed items are software tools that are to be installed on your host computer for testing and/or assessing iOS applications:

• idb
• Xcode tools
• Class-dump
• Hopper (optional)
• Mob-SF
• SQLite browser
• Burp Suite
• OWASP ZAP

Jailbroken iDevice

The following list includes packages that need to be installed on to your jailbroken device in order to start testing:

• Cydia
• openURL
• dumpdecrypted
• ipainstaller
• SSL Kill Switch 2
• Clutch2
• Cycript

Hardware tools vary for the specific device that is being analyzed; however, there are basic tools that are valid for all hardware and even electrical requirements. Manufactures will use different types of screws, housing, and security bits as a stopgap for hardware disassembly. Sometimes, the screws will be hidden under labels or rubber feet. It's important to identify the screw types. We will list toolkits available that can bypass this obfuscation technique used by vendors. The following figure should assist with some of the different types of screw type:

Listed here are the options for hardware tools and hardware analysis software that will be used in this book.

Hardware testing tools require some upfront investment to get started. Here are the required and optional tools needed for disassembling devices, finding ground, and accessing device interfaces:

• Multimeters
• IFixit classic pro tech toolkit for hardware disassembly
• Bus Pirate
• USB to serial adapters
  • Shikra, FTDI FT232, CP2102, PL2303, Adafruit FTDI Friend
• JTAG adapters
  • Shikra, JTAGulator, Arduino with JTAGenum, JLINK, Bus Blaster
• Logic analyzer (optional)
  • Saleae Logic or others

For more information, you can visit these following links:

• https://www.ifixit.com/Store/Tools/Classic-Pro-Tech-Toolkit-/IF145-072-1
• http://int3.cc/products/the-shikra
• https://www.sparkfun.com/products/12942
• http://www.grandideastudio.com/jtagulator/
• https://www.saleae.com/

Here are some hardware analysis tools that are all free. These tools enable us to access hardware interfaces for things such as console access or side-loading firmware onto the device:

• OpenOCD
• Spiflash
• Minicom
• Baudrate

In order to start sniffing wireless technology, certain wireless chipsets are required. In this book, we will focus on sniffing traffic from ZigBee and Z-Wave protocols. Special software will be required to go along with the wireless cards or dongles. Suggestions on which wireless cards and analysis software to use are provided here.

The following is a list of hardware that will be used for analyzing radio frequencies:

• Atmel RZ Raven USB (KillerBee framework)
• Attify Badge (alternatively, a combination of a C232HM-DDHSL-0 cable and Adafruit FTDI Breakout)
• HackRF One
• Yardstick One
• XBee with Xbee Shield
• Ubertooth
• BLe adapter

The following is a list of common software defined radio analysis software. Most of the listed items will be used in this book.

• KillerBee Framework
• Attify ZigBee Framework
• GNU Radio
• BLEAH
• GQRX
• Ubertooth tools
• Blue Hydra
• RTL-sdr
• Hackrf packages
• EZ-Wave