1. Firmware
    1. Encrypted
      1. Possible XOR? Identify by Hexdump and look for repetitive strings
        1. Use XOR decryption script to get the decrypted firmware
      2. Non-XOR? Manual Analysis using a disassembler
      3. Dump from the flash memory while the firmware is in decrypted state
    2. Non-Encrypted
      1. Extract file system using Binwalk (binwalk -e firmware.bin)
        1. Analyze configuration files and hardcoded sensitive values and certificates (manually + automated tool - Firmwalker)
        2. Disassemble individual binaries using Hopper/Binary Ninja/IDA Pro
          1. Identify vulnerabilities such as command injection and backdoors in the disassemblers
          2. Analyze strings present in the binary
          3. Analyze the function list
          4. Look for Xrefs to system()
        3. Emulate individual binaries using qemu (sudo chroot . ./qemu-arch -L optional-lib-path -g gdb-port binary-to-emulate)
          1. Attach GDB-Multiarch (or IDA Pro) to the emulated binary
          2. Set breakpoints at functions like strcmp and analyze the context (registers, stack and disassembly) at that point.
          3. Identify overflow based vulnerabilities (pass a large string and see if the program crashes)
          4. Exploit the overflow by forming a ROP chain (use ROPGadget to find useful gadgets)
      2. Modify firmware image using FMK (Firmware-Mod-Kit)
        1. ./extract-firmware.sh to extract the firmware
          1. Add backdoor or bindshell to the extracted firmware and ensure that it starts at bootup. Build the firmware using build-firmware.sh with the flags -nopad -min
        2. Upload the modified version of the firmware to the target device
          1. If the DUT accepts the new firmware, it is missing firmware integrity verification
          2. If it does not accept, look for code sample in the firmware (or other components) where it's checking for signature verification.
    3. Obtaining the firmware
      1. Vendor website and support forums
      2. Sniffing the package during OTA update
      3. Reversing mobile application
      4. Dumping from the device using H/W Exploitation tactics
  2. Hardware
    1. Recon
      1. FCC-ID database : Look up the FCC ID of the DUT on fccid.io
        1. Identify the chipsets being used
        2. What frequency does the device operates on
        3. Internal/External pictures
      2. Public searching of previous accessible resources of the device
        1. Look for research done on previous versions of the device if that's available to get an idea of the process
    2. Teardown
      1. Identify the kind of enclosure holding the packaging together and use appropriate tools to open it
        1. Look for screws beneath the rubber pads
        2. Pry open the device
        3. Apply heat (make sure to not damage the device)
        4. Cut/Remove the enclosure (as the last option)
        5. XRays/Focused Ion Beam Workstation
    3. Exploitation
      1. What does the PCB Reveal
        1. Identify different chips and part numbers
          1. Look for datasheet to figure out more information about a given chip
          2. What protocol does it work on
          3. Data storage size
          4. Support for communication interfaces
        2. Can you see any possible interfaces?
          1. UART - usually in pair of 3 or 4 with one of the pins being GND
          2. Identify GND using continuity test
          3. Identify Tx and Rx with voltage fluctuations (Tx will have more fluctuations during bootup due to device bootup messages)
          4. Connect to Attify Badge once pinouts are identified Run "sudo python baudrate.py" Hit Ctrl+C once you see readable characters Save conf Hit enter to get shell
          5. SPI - presence of a flash chip
          6. Once pinout is identified from the datasheet, connect the pins to Attify Badge either using Mini Test Probes or pulling out the chip and putting on an adapter
          7. You can use tools like spiflash.py or flashrom to dump the entire flash image / firmware (sudo python spiflash.py -r firmware.bin -s size-to-dump)
          8. JTAG - set of 6,12,13,20 pin headers (or could also be scattered across the board)
          9. Use JTAGulator to identify the pinouts
          10. Connect to all possible JTAG pins Run "sudo screen /dev/ttyUSBx 115200" Set target voltage (using "V") Hit "B" to start the scan
          11. Use Attify Badge once pinouts are known
          12. TDI => TDI TDO => TDO TCK => TCK TMS => TMS
          13. Run openocd with the configuration file obtained from openocd github repo (or on your local system) sudo openocd -f badge.cfg -f target-device-chip.cfg
          14. Run GDB and connect to :3333 to gain debugging access to the target device
          15. hbreak strcmp or break interesting-function You can even use memory manipulation commands to change the contents of memory at any given address (this could be used to change boot args)
          16. Unfamiliar protocol
          17. Research the chip to identify the possible communication protocols
          18. Use a logic sniffer to see what data is being communicated (can use different analyzers and see which one shows something meaningful)
          19. External interfaces like USB (can plug in a keyboard and brute force with special key combinations)
    4. Backdooring
      1. Upload malicious firmware to the device using Flash re-write or using JTAG
      2. Add your own new component for persistent hardware backdooring on the device
  3. Conventional
    1. Mobile
      1. Find out information such as how the firmware is downloaded from the remote endpoint and flashed to the device
      2. Protocol and encryption (key could be found here or by dumping the flash contents in h/w) used for communication
      3. Reverse the API communication
      4. What kind of data is being stored on the mobile device
      5. Use Frida to perform runtime manipulation and analysis
      6. Automated mobile application security tools
      7. Replay based attacks
      8. Insufficient authentication and authorization checks when communication with the device
    2. Web
      1. IDOR (Insecure Direct Object Reference)
      2. Check for permission level bugs (admin, user, superadmin)
      3. Typical bugs - XSS, SQLi, XXE, XSRF etc.
    3. Network
      1. Check for running services on the device
      2. Outdated services
      3. Password brute-forcing and cracking
      4. Unfamiliar port open?
      5. Sniff the network communication
    4. Thick Clients
      1. RE the Thick Client to find vulnerabilities such as Command Injection and Overflows
      2. Communication to the remote endpoint
      3. Reversing the APIs
      4. Exploiting Trust components of the Thick Client
  4. Radio
    1. Raw Radio Communication protocol
      1. Identify the frequency using HackRF / RTL-SDR (Notice the spikes in GQRX when device sends bursts of data)
        1. Capture the data being transmitted at that frequency and process it in GNURadio to obtain meaningful information
        2. Use hackrf_transfer to replay the captured data
    2. BLE
      1. Identify the BLE devices around you and their addresses (using a BLE dongle)
        1. Identify characteristics and services of the target device
        2. Capture the BLE traffic while interacting with the target device using Ubertooth One (Or with 2 BLE dongles with projects like BTLEJuice)
          1. Clear-text traffic
          2. Relay based attacks
        3. Write data to the target devices's BLE Characteristics using Gatttool
        4. Capture the initial pairing packets and use crackle to decrypt traffic (if encrypted)
    3. ZigBee
      1. Find the ZigBee channel on which the DUT is operating on
        1. Capture communication using zb_dump and analyze in wireshark
        2. Perform replay based attacks using zb_replay
        3. Identify keys in the captured communication