diff --git a/.gitbook/assets/image (307) (2).png b/.gitbook/assets/image (307) (2).png
new file mode 100644
index 000000000..0dc16dd3f
Binary files /dev/null and b/.gitbook/assets/image (307) (2).png differ
diff --git a/.gitbook/assets/image (307).png b/.gitbook/assets/image (307).png
index 0dc16dd3f..3f14c6127 100644
Binary files a/.gitbook/assets/image (307).png and b/.gitbook/assets/image (307).png differ
diff --git a/.gitbook/assets/image (651) (1) (1) (1) (1).png b/.gitbook/assets/image (651) (1) (1) (1) (1).png
new file mode 100644
index 000000000..47a9e657a
Binary files /dev/null and b/.gitbook/assets/image (651) (1) (1) (1) (1).png differ
diff --git a/.gitbook/assets/image (651) (1) (1) (1).png b/.gitbook/assets/image (651) (1) (1) (1).png
index 47a9e657a..4d79f5764 100644
Binary files a/.gitbook/assets/image (651) (1) (1) (1).png and b/.gitbook/assets/image (651) (1) (1) (1).png differ
diff --git a/.gitbook/assets/image (651) (1) (1).png b/.gitbook/assets/image (651) (1) (1).png
index 4d79f5764..fcb7c18a6 100644
Binary files a/.gitbook/assets/image (651) (1) (1).png and b/.gitbook/assets/image (651) (1) (1).png differ
diff --git a/.gitbook/assets/image (651) (1).png b/.gitbook/assets/image (651) (1).png
index fcb7c18a6..5c11c2d01 100644
Binary files a/.gitbook/assets/image (651) (1).png and b/.gitbook/assets/image (651) (1).png differ
diff --git a/.gitbook/assets/image (651).png b/.gitbook/assets/image (651).png
index 5c11c2d01..3f14c6127 100644
Binary files a/.gitbook/assets/image (651).png and b/.gitbook/assets/image (651).png differ
diff --git a/cloud-security/concourse.md b/cloud-security/concourse.md
index 75700ad03..fbcc94a2c 100644
--- a/cloud-security/concourse.md
+++ b/cloud-security/concourse.md
@@ -143,6 +143,31 @@ Moreover, Concourse supports different credential managers:
 Note that if you have some kind of **write access to Concourse** you can create jobs to **exfiltrate those secrets** as Concourse needs to be able to access them.
 {% endhint %}
 
+## Architecture
+
+![](<../.gitbook/assets/image (651).png>)
+
+### ATC: web UI & build scheduler
+
+The ATC is the heart of Concourse. It runs the **web UI and API** and is responsible for all pipeline **scheduling**. It **connects to PostgreSQL**, which it uses to store pipeline data (including build logs).
+
+The [checker](https://concourse-ci.org/checker.html)'s responsibility is to continously checks for new versions of resources. The [scheduler](https://concourse-ci.org/scheduler.html) is responsible for scheduling builds for a job and the [build tracker](https://concourse-ci.org/build-tracker.html) is responsible for running any scheduled builds. The [garbage collector](https://concourse-ci.org/garbage-collector.html) is the cleanup mechanism for removing any unused or outdated objects, such as containers and volumes.
+
+### TSA: worker registration & forwarding
+
+The TSA is a **custom-built SSH server** that is used solely for securely **registering** [**workers**](https://concourse-ci.org/internals.html#architecture-worker) with the [ATC](https://concourse-ci.org/internals.html#component-atc).
+
+The TSA by **default listens on port `2222`**, and is usually colocated with the [ATC](https://concourse-ci.org/internals.html#component-atc) and sitting behind a load balancer.
+
+The **TSA implements CLI over the SSH connection,** supporting [**these commands**](https://concourse-ci.org/internals.html#component-tsa).
+
+### Workers
+
+In order to execute tasks concourse must have some workers. These workers **register themselves** via the [TSA](https://concourse-ci.org/internals.html#component-tsa) and run the services [**Garden**](https://github.com/cloudfoundry-incubator/garden) and [**Baggageclaim**](https://github.com/concourse/baggageclaim).
+
+* **Garden**: This is the **Container Manage AP**I, usually run in **port 7777** via **HTTP**.
+* **Baggageclaim**: This is the **Volume Management API**, usually run in **port 7788** via **HTTP**.
+
 ## Concourse Enumeration
 
 In order to enumerate a concourse environment you first need to **gather valid credentials** or to find an **authenticated token** probably in a `.flyrc` config file.
@@ -206,3 +231,7 @@ If you have enough privileges (**member role or more**) you will be able to **li
 ```bash
 fly -t tutorial intercept --job pipeline-name/job-name
 ```
+
+## References
+
+* [https://concourse-ci.org/internals.html#architecture-worker](https://concourse-ci.org/internals.html#architecture-worker)
diff --git a/cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md b/cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md
index 0473afb31..4d2091991 100644
--- a/cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md
+++ b/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) (1).png>)
+![](<../../../.gitbook/assets/image (651) (1) (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.
 
diff --git a/pentesting-web/http-response-smuggling-desync.md b/pentesting-web/http-response-smuggling-desync.md
index e3629d3bc..64866ae15 100644
--- a/pentesting-web/http-response-smuggling-desync.md
+++ b/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) (1).png>)
+![](<../.gitbook/assets/image (651) (1) (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):
 
diff --git a/pentesting/5353-udp-multicast-dns-mdns.md b/pentesting/5353-udp-multicast-dns-mdns.md
index 7250c88bc..7b32b3274 100644
--- a/pentesting/5353-udp-multicast-dns-mdns.md
+++ b/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) (1).png>)
+![](<../.gitbook/assets/image (651) (1) (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.
 
diff --git a/todo/hardware-hacking/i2c.md b/todo/hardware-hacking/i2c.md
index 49fa6e18e..3cbf305ed 100644
--- a/todo/hardware-hacking/i2c.md
+++ b/todo/hardware-hacking/i2c.md
@@ -51,7 +51,7 @@ As you can see in the previous command line it said that it found 0 errors. This
 
 To connect with the bus pirate you can follow the docs:
 
-![](<../../.gitbook/assets/image (307).png>)
+![](<../../.gitbook/assets/image (307) (2).png>)
 
 In this case I'm going to connect to an EPROM: ATMEL901 24C256 PU27:
 
diff --git a/todo/hardware-hacking/jtag.md b/todo/hardware-hacking/jtag.md
index cde088bdb..6c898af42 100644
--- a/todo/hardware-hacking/jtag.md
+++ b/todo/hardware-hacking/jtag.md
@@ -17,6 +17,6 @@ In Arduino, after connecting the cables (pin 2 to 11 to JTAG pins and Arduino GN
 Configure **"No line ending" and 115200baud**.\
 Send the command s to start scanning:
 
-![](<../../.gitbook/assets/image (651).png>)
+![](<../../.gitbook/assets/image (651) (1).png>)
 
 If you are contacting a JTAG, you will find one or several **lines starting by FOUND!** indicating the pins of JTAG.