GitBook: [#3052] No subject

SUMMARY.md

@@ -630,6 +630,8 @@
   * [I2C](todo/hardware-hacking/i2c.md)
   * [UART](todo/hardware-hacking/uart.md)
   * [Radio](todo/hardware-hacking/radio.md)
+  * [JTAG](todo/hardware-hacking/jtag.md)
+  * [SPI](todo/hardware-hacking/spi.md)
 
 ***
 

cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md

@@ -537,7 +537,7 @@ More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security
 
 An admission controller is a piece of code that **intercepts requests to the Kubernetes API server** before the persistence of the object, but **after the request is authenticated** **and authorized**.
 
-![](<../../../.gitbook/assets/image (651) (1).png>)
+![](<../../../.gitbook/assets/image (651) (1) (1).png>)
 
 If an attacker somehow manages to **inject a Mutationg Adminssion Controller**, he will be able to **modify already authenticated requests**. Being able to potentially privesc, and more usually persist in the cluster.
 

pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md

@@ -36,7 +36,7 @@ This is exactly the same technique as before, but checking the requests James no
 
 In this case **the header Transfer-Encoding was injected**.
 
-![](<../../.gitbook/assets/image (648) (1) (1).png>)
+![](<../../.gitbook/assets/image (648) (1) (1) (1).png>)
 
 ### H2.TE via Header Name Injection
 
@@ -46,7 +46,7 @@ HTTP/2 on some servers lets you put a **colon in the header name, and with a \r\
 
 Note that if you put just the new line characters sending a header without content, the request is going to be treated as **invalid**:
 
-![](<../../.gitbook/assets/image (647) (1).png>)
+![](<../../.gitbook/assets/image (647) (1) (1).png>)
 
 ### H2.TE via Request LIne Injection
 

pentesting-web/http-response-smuggling-desync.md

@@ -70,7 +70,7 @@ Therefore, if an attacker **injects** a **HEAD** request, like in this images:
 
 Then, **once the blue one is responded to the attacker**, the next victims request is going to be introduced in the queue:
 
-![](<../.gitbook/assets/image (651) (1) (1).png>)
+![](<../.gitbook/assets/image (651) (1) (1) (1).png>)
 
 Then, the **victim** will **receive** the **response** from the **HEAD** request, which is **going to contain a Content-Length but no content at all**. Therefore, the proxy **won't send this response** to the victim, but will **wait** for some **content**, which actually is going to be **response to the yellow request** (also injected by the attacker):
 

pentesting/5353-udp-multicast-dns-mdns.md

@@ -29,7 +29,7 @@ To request a PTR record, clients use the name form "\<Service>.\<Domain>". The *
 
 The part of the PTR record to the **left** of the colon is its **name**, and the part on the **right** is the **SRV** **record** to which the PTR record points. The **SRV** record lists the target **host** and **port** where the **service** instance can be reached. For example, the next image shows a "test.\_ipps.\_tcp.local" SRV record in Wireshark in host ubuntu.local and port 8000:
 
-![](<../.gitbook/assets/image (651).png>)
+![](<../.gitbook/assets/image (651) (1).png>)
 
 Therefore, the **name of the SRV** record is **like** the **PTR** record **preceded** by the **\<Instance>** name (test in this case). The **TXT** has the **same** **name** as the **SRV** record and contains the information needed when the IP address and port number (contained in the SRV record) for a service aren’t sufficient to identify it.
 

radio-hacking/pentesting-ble-bluetooth-low-energy.md

@@ -8,7 +8,7 @@ BLE devices communicate is by sending **advertising packets** (**beacons**), the
 
 The listening device, also called a central device, can respond to an advertising packet with a **SCAN request** sent specifically to the advertising device. The **response** to that scan uses the same structure as the **advertising** packet with additional information that couldn’t fit on the initial advertising request, such as the full device name.
 
-![](<../.gitbook/assets/image (201) (2) (1).png>)
+![](<../.gitbook/assets/image (201) (2) (1) (1).png>)
 
 The preamble byte synchronizes the frequency, whereas the four-byte access address is a **connection identifier**, which is used in scenarios where multiple devices are trying to establish connections on the same channels. Next, the Protocol Data Unit (**PDU**) contains the **advertising data**. There are several types of PDU; the most commonly used are ADV\_NONCONN\_IND and ADV\_IND. Devices use the **ADV\_NONCONN\_IND** PDU type if they **don’t accept connections**, transmitting data only in the advertising packet. Devices use **ADV\_IND** if they **allow connections** and **stop sending advertising** packets once a **connection** has been **established**.
 

todo/hardware-hacking/README.md

@@ -1,39 +1,6 @@
 # Hardware Hacking
 
-## UART
-
-UART is a serial protocol, which means it transfers data between components one bit at a time. In contrast, parallel communication protocols transmit data simultaneously through multiple channels. Common serial protocols include RS-232, I2C, SPI, CAN, Ethernet, HDMI, PCI Express, and USB.
-
-Generally, the line is held high (at a logical 1 value) while UART is in the idle state. Then, to signal the start of a data transfer, the transmitter sends a start bit to the receiver, during which the signal is held low (at a logical 0 value). Next, the transmitter sends five to eight data bits containing the actual message, followed by an optional parity bit and one or two stop bits (with a logical 1 value), depending on the configuration. The parity bit, used for error checking, is rarely seen in practice. The stop bit (or bits) signify the end of transmission.
-
-We call the most common configuration 8N1: eight data bits, no parity, and one stop bit. For example, if we wanted to send the character C, or 0x43 in ASCII, in an 8N1 UART configuration, we would send the following bits: 0 (the start bit); 0, 1, 0, 0, 0, 0, 1, 1 (the value of 0x43 in binary), and 0 (the stop bit).
-
-![](<../../.gitbook/assets/image (648) (1).png>)
-
-Hardware tools to communicate with UART:
-
-* USB-to-serial adapter
-* Adapters with the CP2102 or PL2303 chips
-* Multipurpose tool such as: Bus Pirate, the Adafruit FT232H, the Shikra, or the Attify Badge
-
-### Identifying UART Ports
-
-UART has 4 ports: **TX**(Transmit), **RX**(Receive), **Vcc**(Voltage), and **GND**(Ground). You might be able to find 4 ports with the **`TX`** and **`RX`** letters **written** in the PCB. But if there is no indication, you might need to try to find them yourself using a **multimeter** or a **logic analyzer**.
-
-With a **multimeter** and the device powered off:
-
-* To identify the **GND** pin use the **Continuity Test** mode, place the back lead into ground and test with the red one until you hear a sound from the multimeter. Several GND pins can be found the PCB, so you might have found or not the one belonging to UART.
-* To identify the **VCC port**, set the **DC voltage mode** and set it up to 20 V of voltage. Black probe on ground and red probe on the pin. Power on the device. If the multimeter measures a constant voltage of either 3.3 V or 5 V, you’ve found the Vcc pin. If you get other voltages, retry with other ports.
-* To identify the **TX** **port**, **DC voltage mode** up to 20 V of voltage, black probe on ground, and red probe on the pin, and power on the device. If you find the voltage fluctuates for a few seconds and then stabilizes at the Vcc value, you’ve most likely found the TX port. This is because when powering on, it sends some debug data.
-* The **RX port** would be the closest one to the other 3, it has the lowest voltage fluctuation and lowest overall value of all the UART pins.
-
-You can confuse the TX and RX ports and nothing would happen, but if you confuses the GND and the VCC port you might fry the circuit.
-
-With a logic analyzer:
-
-### Identifying the UART Baud Rate
-
-The easiest way to identify the correct baud rate is to look at the **TX pin’s output and try to read the data**. If the data you receive isn’t readable, switch to the next possible baud rate until the data becomes readable. You can use a USB-to-serial adapter or a multipurpose device like Bus Pirate to do this, paired with a helper script, such as [baudrate.py](https://github.com/devttys0/baudrate/). The most common baud rates are 9600, 38400, 19200, 57600, and 115200.
+##
 
 ## JTAG
 

todo/hardware-hacking/i2c.md

@@ -6,6 +6,49 @@
 
 ## Bus Pirate
 
+To test a Bus Pirate is working, connect +5V with VPU and 3.3V with ADC and access the bus pirate (Using Tera Term for example) and use the command `~`:
+
+```bash
+# Use command
+HiZ>~
+Disconnect any devices
+Connect (Vpu to +5V) and (ADC to +3.3V)
+Space to continue
+# Press space
+Ctrl
+AUX OK
+MODE LED OK
+PULLUP H OK
+PULLUP L OK
+VREG OK
+ADC and supply
+5V(4.96) OK
+VPU(4.96) OK
+3.3V(3.26) OK
+ADC(3.27) OK
+Bus high
+MOSI OK
+CLK OK
+MISO OK
+CS OK
+Bus Hi-Z 0
+MOSI OK
+CLK OK
+MISO OK
+CS OK
+Bus Hi-Z 1
+MOSI OK
+CLK OK
+MISO OK
+CS OK
+MODE and VREG LEDs should be on!
+Any key to exit
+#Press space
+Found 0 errors.
+```
+
+As you can see in the previous command line it said that it found 0 errors. This is very useful to know it's working after buying it or after flashing a firmware.
+
 To connect with the bus pirate you can follow the docs:
 
 ![](<../../.gitbook/assets/image (307).png>)
@@ -120,7 +163,7 @@ NACK
 
 In this scenario we are going to sniff the I2C communication between the arduino and the previous EPROM, you just need to communicate both devices and then connect the bus pirate to the SCL, SDA and GND pins:
 
-![](<../../.gitbook/assets/image (201) (2).png>)
+![](<../../.gitbook/assets/image (201) (2) (1).png>)
 
 ```bash
 I2C>m

todo/hardware-hacking/jtag.md

@@ -0,0 +1,22 @@
+# JTAG
+
+## JTAGenum
+
+****[**JTAGenum** ](https://github.com/cyphunk/JTAGenum)is a tool can be used with a Raspberry PI or an Arduino to find to try JTAG pins from an unknown chip.\
+In the **Arduino**, connect the **pins from 2 to 11 to 10pins potentially belonging to a JTAG**. Load the program in the Arduino and it will try to bruteforce all the pins to find if any pins belongs to JTAG and which one is each.\
+In the **Raspberry PI** you can only use **pins from 1 to 6** (6pins, so you will go slower testing each potential JTAG pin).
+
+### Arduino
+
+In Arduino, after connecting the cables (pin 2 to 11 to JTAG pins and Arduino GND to the baseboard GND), **load the JTAGenum program in Arduino** and in the Serial Monitor send a **`h`** (command for help) and you should see the help:
+
+![](<../../.gitbook/assets/image (643).png>)
+
+![](<../../.gitbook/assets/image (650).png>)
+
+Configure **"No line ending" and 115200baud**.\
+Send the command s to start scanning:
+
+![](<../../.gitbook/assets/image (651).png>)
+
+If you are contacting a JTAG, you will find one or several **lines starting by FOUND!** indicating the pins of JTAG.

todo/hardware-hacking/radio.md

@@ -76,13 +76,13 @@ Checking AM info with [**SigDigger** ](https://github.com/BatchDrake/SigDigger)a
 
 And this is how part of the symbol looks like with the waveform:
 
-![](<../../.gitbook/assets/image (650).png>)
+![](<../../.gitbook/assets/image (650) (1).png>)
 
 #### Checking the Histogram
 
 You can **select the whole signal** where information is located, select **Amplitude** mode and **Selection** and click on **Histogram.** You can observer that 2 clear levels are only found
 
-![](<../../.gitbook/assets/image (647).png>)
+![](<../../.gitbook/assets/image (647) (1).png>)
 
 For example, if you select Frequency instead of Amplitude in this AM signal you find just 1 frequency (no way information modulated in frequency is just using 1 freq).
 
@@ -163,7 +163,7 @@ This is because I capture the signal in booth frequencies, therefore one is appr
 
 If the synchronized frequency is **closer to one frequency than to the other** you can easily see the 2 different frequencies:
 
-![](<../../.gitbook/assets/image (648).png>)
+![](<../../.gitbook/assets/image (648) (1).png>)
 
 ![](<../../.gitbook/assets/image (634).png>)
 
@@ -179,7 +179,7 @@ In this case if you check the **Amplitude histogram** you will find **only one a
 
 And this is would be phase histogram (which makes very clear the signal is not modulated in phase):
 
-![](<../../.gitbook/assets/image (201).png>)
+![](<../../.gitbook/assets/image (201) (2).png>)
 
 #### With IQ
 
@@ -187,7 +187,7 @@ IQ doesn't have a field to identify frequencies (distance to centre is amplitude
 Therefore, to identify FM, you should **only see basically a circle** in this graph.\
 Moreover, a different frequency is "represented" by the IQ graph by a **speed acceleration across the circle** (so in SysDigger selecting the signal the IQ graph is populated, if you find an acceleration or change of direction in the created circle it could mean that this is FM):
 
-![](<../../.gitbook/assets/image (643).png>)
+![](<../../.gitbook/assets/image (643) (1).png>)
 
 ### Get Symbol Rate
 

todo/hardware-hacking/spi.md

@@ -0,0 +1,24 @@
+# SPI
+
+## Basic Information
+
+## Dump Flash
+
+### Bus Pirate + flashrom
+
+![](<../../.gitbook/assets/image (201).png>)
+
+Note that even if the PINOUT of the Pirate Bus indicates pins for **MOSI** and **MISO** to connect to SPI however some SPIs may indicate pins as DI and DO. **MOSI -> DI, MISO -> DO**
+
+![](<../../.gitbook/assets/image (648).png>)
+
+In Windows or Linux you can use the program [**`flashrom`**](https://www.flashrom.org/Flashrom) **** to dump the content of the flash memory running something like:
+
+```bash
+# In this command we are indicating:
+## -VV Verbose
+## -c <chip> The chip (if you know it better, if not, don'tindicate it and the program might be able to find it)
+## -p <programmer> In this case how to contact th chip via the Bus Pirate
+## -r <file> Image to save in the filesystem
+flashrom -VV -c "W25Q64.V" -p buspirate_spi:dev=COM3 -r flash_content.img
+```

todo/hardware-hacking/uart.md

@@ -2,7 +2,42 @@
 
 ## Basic Information
 
+UART is a serial protocol, which means it transfers data between components one bit at a time. In contrast, parallel communication protocols transmit data simultaneously through multiple channels. Common serial protocols include RS-232, I2C, SPI, CAN, Ethernet, HDMI, PCI Express, and USB.
+
+Generally, the line is held high (at a logical 1 value) while UART is in the idle state. Then, to signal the start of a data transfer, the transmitter sends a start bit to the receiver, during which the signal is held low (at a logical 0 value). Next, the transmitter sends five to eight data bits containing the actual message, followed by an optional parity bit and one or two stop bits (with a logical 1 value), depending on the configuration. The parity bit, used for error checking, is rarely seen in practice. The stop bit (or bits) signify the end of transmission.
+
+We call the most common configuration 8N1: eight data bits, no parity, and one stop bit. For example, if we wanted to send the character C, or 0x43 in ASCII, in an 8N1 UART configuration, we would send the following bits: 0 (the start bit); 0, 1, 0, 0, 0, 0, 1, 1 (the value of 0x43 in binary), and 0 (the stop bit).
+
+![](<../../.gitbook/assets/image (648) (1) (1).png>)
+
+Hardware tools to communicate with UART:
+
+* USB-to-serial adapter
+* Adapters with the CP2102 or PL2303 chips
+* Multipurpose tool such as: Bus Pirate, the Adafruit FT232H, the Shikra, or the Attify Badge
+
+### Identifying UART Ports
+
+UART has 4 ports: **TX**(Transmit), **RX**(Receive), **Vcc**(Voltage), and **GND**(Ground). You might be able to find 4 ports with the **`TX`** and **`RX`** letters **written** in the PCB. But if there is no indication, you might need to try to find them yourself using a **multimeter** or a **logic analyzer**.
+
+With a **multimeter** and the device powered off:
+
+* To identify the **GND** pin use the **Continuity Test** mode, place the back lead into ground and test with the red one until you hear a sound from the multimeter. Several GND pins can be found the PCB, so you might have found or not the one belonging to UART.
+* To identify the **VCC port**, set the **DC voltage mode** and set it up to 20 V of voltage. Black probe on ground and red probe on the pin. Power on the device. If the multimeter measures a constant voltage of either 3.3 V or 5 V, you’ve found the Vcc pin. If you get other voltages, retry with other ports.
+* To identify the **TX** **port**, **DC voltage mode** up to 20 V of voltage, black probe on ground, and red probe on the pin, and power on the device. If you find the voltage fluctuates for a few seconds and then stabilizes at the Vcc value, you’ve most likely found the TX port. This is because when powering on, it sends some debug data.
+* The **RX port** would be the closest one to the other 3, it has the lowest voltage fluctuation and lowest overall value of all the UART pins.
+
+You can confuse the TX and RX ports and nothing would happen, but if you confuses the GND and the VCC port you might fry the circuit.
+
+With a logic analyzer:
+
+### Identifying the UART Baud Rate
+
+The easiest way to identify the correct baud rate is to look at the **TX pin’s output and try to read the data**. If the data you receive isn’t readable, switch to the next possible baud rate until the data becomes readable. You can use a USB-to-serial adapter or a multipurpose device like Bus Pirate to do this, paired with a helper script, such as [baudrate.py](https://github.com/devttys0/baudrate/). The most common baud rates are 9600, 38400, 19200, 57600, and 115200.
+
+{% hint style="danger" %}
 It's important to note that in this protocol you need to connect the TX of one device to the RX of the other!
+{% endhint %}
 
 ## Bus Pirate